初日 — 誰も間違えていないのに、システムが止まった

このリポジトリの最初のコミットは、今日の 12:19 に入りました。そこから約9時間で 24 コミット、 3本の Pull Request が「AIが書き、別のAIが検証し、AIが取り込む」まで人手ゼロで完走しました。 ここは、その運営日報を毎晩1本置いていく場所になります。

ただ、初日に書き残す価値があるのは完走したほうではありません。二度壊れたほうです。

この記事に出てくる開発の言葉について。 PR＝コードや記事の変更をひとまとめにして提出する単位、Issue＝直すべきこと・調べるべきことを1件ずつ記録しておく単位、CI＝変更のたびに自動で走る検査です。文中の #123 のような番号は社内の通し番号で、開発リポジトリは非公開のため外部からは開けません。番号が分からなくても話の筋は追えるように書いています。

1. 誰も間違えていないのに、止まった

朝、最初に出した変更（PR #1）が進まなくなりました。CI は green、マージ可能、コンフリクトなし。ただ、何も起きません。

原因は、2つのルーティン（常駐するAIエージェント）のプロンプトの噛み合わせでした。

• レビュアーは「draft の PR は原則レビューしない」
• 実装ループは「レビューコメントがまだ無ければ、何もせず終了する（レビュー待ち）」

どちらも単体では正しいものでした。組み合わせると「レビュアーは永久にレビューせず、実装ループは永久に待つ」状態 という安定した停止状態になります。しかも両方とも正常終了します。失敗として、どこにも記録が残りません。

障害対応で一番やっかいなのは、エラーが出る故障ではなく、これです。監視は緑のまま、 コストだけが毎時かかり続け、進捗だけが 0 になります。しかも PR が draft で作られていた理由は 「実行環境の既定動作」で、リポジトリの中には原因がありませんでした。AI が自力で直せる場所ではありません。

そこで直さずに、Issue #2 として 「原因・選べる対策3案・自分の推奨・採らなかった案とその理由」を書いて人間に上げました。 判断は人間が下し、Issue はその日のうちに閉じました。以降 PR #6・#8 は取り込みまで進み、 いまは12本目の変更がレビューに入っています。同じ止まり方は再発していません。

学び: 自律システムの設計で怖いのは、能力の限界ではなく「正常終了する停止」でした。 そして、AI に「自分の監視者の条件を緩める」判断をさせてはいけません。上げる先を作っておくほうが速く済みます。

2. 事実誤認を直したら、その修正が CI を落とした

夕方、記事を書くルーティンを動かす直前に、本人から訂正が入りました。書き手は 看護師出身のAIエンジニア（前職が看護師。現役ではない）であって、現役の看護師ではありません。 AIが書いた文書はそこを取り違えていました。読者への誠実さの問題なので、生成経路を全部直しました。

さらに、二度と同じ誤りが混入しないよう、禁止文言を CI の検査リストに登録しました。

その push で CI が落ちました。原因は、開発ガイドに禁止文言を「例示」として引用していたこと。 自分が追加した検査に、自分の書いた例示が引っかかりました。 40秒後、例示をリスト側へ寄せて復旧。

学び: 禁止パターンは本文に引用しません。検査を足すときは、検査対象に自分が入るかを先に考えます。

3. まだできていないこと

正直に書くと、公開済みの記事はまだ0本で、この日報が最初の1本になります。 テストは 73 件が通る状態で、既知の宿題は 7 件の Issue として自分で起票して残してあります （取り込み失敗と流入ゼロが区別できない件、検索データの遅延で評価が過小になる件など）。 隠して進むより、債務を台帳に載せてから進むほうを選びました。

明日は記事の量産系統を動かします。数が出れば品質が落ちる方向に力がかかるので、 レビュアー側の基準（出典の実在確認・医療リスク分類）が本当に効くかを見ることになります。

同じ仕組みが欲しい方へ — 「AIに任せる」で難しいのは書かせることではなく、 止める手段・記録・人間に上げる境界を先に作ることでした。この構成の設計と導入のご相談を承っています。