社内ノートに4機能を1日で実装して、デプロイで本番を止めた話
2026年8月22日の朝、ChordOne Noteのやることリストには4つの機能が並んでいた。サブアイテム、公開フォーム、ボタン、オートメーション。普通のSaaSなら、四半期分のロードマップです。夜にはぜんぶ本番に出ていました。そして翌未明のデプロイで、本番のNotesが開けなくなりました。この記事は、その1日と、失敗も含めた記録です。
朝、4つ並んでいた
先にこの日の結果だけ書いておきます。
- 実装した機能: 4つ（サブアイテム・公開フォーム・ボタン・オートメーション）
- 書いた自動テスト: サーバ179件・画面129件（全部通過）
- コミット: 4つ、それぞれ機能単位で本番へ
- 起こした障害: 1件（デプロイ時、Notesのデータベースが全社で開けない状態に）
- 障害の検知から復旧まで: 約40分
4機能を並べると景気のいい話に見えますが、白状すると、最後の2行がこの記事を書いた理由です。うまくいった話だけ書いても、たぶん誰の役にも立たないので。
まず、何を作ったのか。ChordOne Noteは社内Wikiと管理表（データベース）が一体になった機能で、この日はNotionとの機能差分リストの「大物」が4つ残っていました。
| 機能 | 何ができるか |
|---|---|
| サブアイテム | 行の下に子の行をぶら下げてツリーで管理。「入社準備」の下に「PC手配」「アカウント発行」を折りたたんで持てる |
| 公開フォーム | URLを知っている人がログイン不要で回答。回答は管理表の行としてそのまま届く |
| ボタン | 「完了にする」ボタン1つで、状態＝完了・完了日＝今日・確認者＝押した人、をまとめて更新 |
| オートメーション | 「ステータスが完了になったら担当者に通知して完了日を記録」を、ノーコードで設定 |
4つはバラバラの機能ではなく、つなげると1本の業務になります。求人ページにフォームのURLを貼る。候補者が回答すると応募管理表に行が増える。オートメーションが担当者に通知する。面接後は「通過にする」ボタンを押す。選考タスクはサブアイテムでぶら下げる。フォームツールと自動化ツールとタスク管理ツールを別々に契約してつなぎ込む、あの作業が丸ごと要らなくなる。ここを1日で仕上げたかった理由です。
なぜ1日で作れるのか（種明かし）
ChordOneの開発は、設計・実装・テストコードの作成までをAIが担い、人間はレビューと判断をします。今回の4機能で人間がやったことは、順番の決定（サブアイテム→フォーム→ボタン→オートメーション）、途中のレビュー、そしてリリース判断です。
速さの源泉はAIのタイピング速度ではありません。「1機能＝1コミット＝その日のうちに本番」という単位の小ささです。4機能をまとめて1つの大きなリリースにすると、レビューも切り戻しも重くなる。1つずつ完結させると、それぞれ数時間で回る。テストはこの日だけでサーバ179件・画面129件になりましたが、これもAIが実装と同時に書くので、テストを書く時間を「別途確保」する感覚はもうありません。
リリース後の確認も、AIが実際の本番環境をブラウザで操作しました。フォームに回答し、行が増えるのを見て、ボタンを押し、通知が届くのを確認する。ここまでやって、その日は終わり。のはずでした。
そして、本番が止まった
翌未明のデプロイ後、本番のNotesでデータベースを開くと「データベースを表示できませんでした」。全社のワークスペースで、です。
原因はコードではなく、デプロイの工程にありました。新機能はデータベースに新しいテーブルや列を追加します（サブアイテム用の親子関係の列、フォームとオートメーションのテーブル）。この変更（migration）はデプロイ時に自動で適用される仕組みなのですが、過去に失敗したまま残っていた別の変更が引っかかり、新しい変更が全部ブロックされていました。結果、「コードは新しいのに、データベースは古いまま」という食い違いが起きて、レコードを読むAPIがすべてエラーを返した。
気づいたきっかけは、監視ではありません。リリース後の動作確認をしようとしたら開けなかった、それだけです。つまり確認しに行かなければ、誰も気づかないまま朝を迎えていた。ここが一番まずかった点です。
復旧自体は速かった。エラー本文から「列がない」ことは一目で分かったので、必要な変更だけを手で適用する応急SQLを用意し、約40分で全機能が復帰しました。追加した4機能もそのまま動きました。
問題は再発防止です。同じ日に3つ入れました。
- 「コードとデータベースの食い違い」を直接検知するヘルスチェックAPI。今回の障害パターンを、そのまま検査項目にした
- 10分おきに本番の主要ページとAPIを外から叩いて、異常ならSlackに通知する外形監視。「確認しに行かないと気づけない」の対策
- デプロイ時の自動リカバリ処理の強化。今回すり抜けた失敗パターンを拾えるようにした
AIで開発が速くなると、リリースの回数が増えます。回数が増えれば、デプロイ工程の弱点は必ずどこかで露出する。速く作る能力と、壊れたら即気づく仕組みは、セットでないと成立しない。当たり前のことを、身をもって確認した日でした。
それでも「機能の足し算」はやらない
1日で4機能と聞くと、機能をどんどん積む会社に見えるかもしれません。方針は逆です。
私たちが競合だと思っているのは、特定の製品というより「使わない機能にも払っている状態」です。多機能SaaSの料金表は立派ですが、現場で使われるのはその一部で、それでも「うちに必要なあの1機能」だけは、なぜか無い。要望を送ると「今後の参考にさせていただきます」と返ってきて、結局ツールに合わせて業務のほうを変える。多くの会社で、それが当たり前になっています。
だからChordOneのノートには、高度な機能を全部は載せていません。たとえば数式は日常の計算に必要な範囲に意図的に絞っています。その代わり、多くの会社が実際に使う機能は、要望が来たら数日で、標準機能として無料で足す。今回の4機能もこの2週間で足したリレーション・数式・タイムライン・ダークモードも、すべてこの方針の産物です。料金は10以上の標準機能込みで月800円/人が上限、20人までは無料のまま変わっていません。
この「要望から反映まで」の実績は、更新履歴（Changelog）に日付つきで公開しています。アプリ内のフィードバックボードに投稿された要望は、他のユーザーの「同感」で優先度が上がり、対応可能なものから反映されます。昨日投稿された要望が今日のChangelogに載っていることも、実際にあります。
この日の学び
覚えて帰ってもらうとしたら、3つです。
1. リリースの単位を小さくすると、速さと安全は両立する。4機能を1日で出せたのは、1機能ずつ完結させたから。まとめて出していたら、障害の切り分けももっと苦しかったはずです。
2. 速く作る仕組みには、速く気づく仕組みが要る。テストが300件通っていても、デプロイ工程は別の生き物です。外形監視は障害のあとではなく、開発を速くした時点で入れるべきでした。
3. 失敗は隠すより書いたほうが強い。この記事の初稿には障害の話がありませんでした。書き直したのは、成功談だけの記事を誰も信用しないと私たち自身が知っているからです。
ChordOne Noteは20人まで無料で、今日書いた4機能もすべて含まれます。試して、足りない機能があれば、フィードバックボードに書いてください。それが来週のChangelogになるかもしれません。
足りない機能は、一緒に作りましょう。
Wiki・管理表・フォーム・オートメーション込みで月800円/人が上限。従業員20人までは無料です。
関連記事
編集部メモ
この記事はChordOne開発チームによる開発記録で、自社製品「ChordOne Note」に関する内容を含みます。記載の実装件数・テスト件数・障害対応の経緯は2026年8月22日〜23日の実際の記録に基づきます。機能・料金は2026年8月24日時点のサービス仕様と公開価格に基づきます。開発スピードは今回の実績であり、要望の内容・規模によって対応可否や期間は変わります。
確認資料
- ChordOne 更新履歴（Changelog）
日付つきのリリースノート。この記事の4機能と再発防止策も記載。
- ChordOne Note 機能紹介
ページ、データベース、フォーム、オートメーション、共有、料金の説明。
- ChordOne 料金
無料範囲、標準機能、採用管理（ATS）の価格。