会議は55回、タスク完了は0件 ― AI会議3.0の初仕事は、自分自身の欠陥探しだった¶

会議は55回、タスク完了は0件 ― AI会議3.0の初仕事は、自分自身の欠陥探しだった

これまでAIに複数の視点で成果物をレビューさせる「会議」の仕組みを、1.0から3.0まで作り替えてきました。今回は3.0を実装したその日に起きたことを書きます。結論から言うと、会議3.0の初仕事は他の何かの品質チェックではなく、自分自身の欠陥探しでした。

まず数字から始めます。2026-07-10時点で、累積の会議回数は55回、AIの応答は235件、記録された決定は34件、タスクは146件。ここまでは順調そうに見えます。ところが、この146件のうち仕組みの上で「完了」と記録されているタスクは0件でした。

これは「何も作業していない」という意味ではありません。実装や修正はこの間もずっと進んでいました。ただ、会議で決めたことと、実際にできあがった成果物やテスト結果が、仕組みの上でつながっていなかっただけです。会議は会話として完結し、実行の結果と再会することがなかった。この矛盾が、会議3.0を作る出発点でした。

ここまでの3世代をざっくり¶

詳しい経緯は過去記事に譲りますが、簡単に振り返ります。

会議1.0（記事はこちら）: 実装した本人のAIとは別のAIに同じ成果物を見せ、独立した視点でレビューさせる仕組み。著者AIは自分の意図どおりにコードを読んでしまうが、別のAIは書かれているものだけを見るので盲点を見つけられる、という発見が出発点でした。
会議2.0（記事はこちら、答え合わせは続報記事）: 指摘を「主張＋証拠＋状態」のクレームとして台帳に残し、再現できる主張は実際に実行して終了コードで白黒をつけ、未来の主張には期日をつけて自動で答え合わせする仕組み。導入初日に、壊れた検証コマンドが正しい指摘を「誤り」と判定してしまう冤罪事件も起きましたが、判定の履歴が残っていたおかげで後から訂正できました。
会議3.0: 会議2.0までで「その指摘は正しいか」「その予測は当たったか」には答えられるようになりましたが、「誰が実行するのか」「いつまでに」「何をもって完了か」「失敗したらいつ撤退するか」には答えられませんでした。これに答える仕組みが会議3.0です。

会議3.0の中身: 決めたことを「意思決定契約」にする¶

会議3.0の核は、会議の結論を意思決定契約という形に変えることです。契約は最低限、次を持ちます。

決定内容
担当者
期限
成功条件
撤退条件
検証方法
権限の強さ（自動で進めてよい範囲）
現在の状態

匿名化した模式例です。

JSON

{
  "decision": "新しい品質ゲートを試験導入する",
  "owner": "実装担当",
  "deadline": "2026-07-15",
  "success_metric": "異常停止が0件",
  "rollback_condition": "異常停止が1件以上",
  "authority_level": "L3",
  "status": "open"
}

意思決定契約を作ると、同じ期限・成功条件を持つ予測が会議2.0の仕組みの上に自動で作られます。予測が成立すれば契約は成功へ、不成立なら失敗へ動き、失敗した契約は撤退条件を確認する必要があると記録されます。会議2.0で作った「実行して白黒をつける」資産を捨てず、その上に実行責任を積んだ設計です。

さらに、タスクには完了の根拠を持たせました。指定した成果物が実際に存在するか、決めておいた完了確認コマンドが成功するかを機械的に照合します。成果物のパスは作業領域の外へ逃げられないように制限しました。

これらを毎朝横断的に走らせる成果サイクルも作りました。期限を迎えた予測を探し、実行できるものは実行し、結果を契約へ反映し、成果物が揃ったタスクを完了へ進め、期限を過ぎたタスクとエラーを集計する。この5手順です。

初仕事は、自分自身のレビューだった¶

会議3.0を実装したその日、コミットする前に、この差分（約360行）と運用仕様を会議システム自身に渡しました。レビュー専用の設定で、3社のAIに独立してコードを読ませ、指摘させたのです。作ったばかりの仕組みを、作ったばかりの仕組みで検査させた形になります。

結果はクレーム18件。重要度の内訳は高7件・中8件・低3件で、3社がちょうど6件ずつ出しました。

面白かったのは収束の仕方です。2社が相談せずに、まったく同じ2箇所を最重要と指摘しました。

主張の検証は使い捨ての隔離コピーの上で実行するのに、タスクの完了確認コマンドだけは本物の作業ツリーの上で動いていた、という隔離の非対称
毎朝の成果サイクルは内部でエラーを数えているのに、終了コードはいつも成功を返すので、定期実行が失敗しても運用者に伝わらない、という無言の失敗

一方、格安API勢のうち1社は、証拠となる差分そのものがセキュリティ境界の外に置かれ渡らない設計になっていたため、仕様書だけを読んで推測でレビューしていました。この1社が挙げた高重要度2件のうち1件は、実装済みの防御を「無い」と主張する冤罪で、台帳の上でも棄却として記録されました。もう1件（さきほどの無言の失敗の指摘）は、根拠となる差分を見ていないのに、内容としては当たっていました。

18件を仕分けると、修正済み11 / 見送り6（理由つきで記録） / 棄却1、未決0という決着です。

修正も、自分では書かなかった¶

指摘の採用分は、8項目の修正にまとめました。

成果サイクルがエラーを検知したら終了コードで失敗を叫ぶようにする（定期実行の失敗が見えるように）
期限を過ぎても決着しない契約を「期限超過」として集計に出す
会議の要約から自動生成される契約が、不正な形式のときに無言で消えるのをやめ、記録を残す
完了証拠のファイルパスは相対パスだけを許可し、登録した瞬間に検査する
タスクの完了確認コマンドも、主張の検証と同じ使い捨て隔離コピーの上で実行する
タスクより古い日付の成果物では自動完了させない（古い証拠での偽完了防止）
「終了コード0が何を意味するか」という説明が場所ごとに3通りに割れていたのを統一する
一度確定した契約の判定を、人間が理由つきで訂正できる操作を追加する

この修正の実装は、指摘を受けた本人（会議システムを書いたAI）が自分ではやりませんでした。代わりに、合否の定義を実行可能な契約として先に書き、別の安価なAIに外注しました（この仕組み自体は前の記事で書いた「AI外注2.0」です）。差し戻しは0回、一発で検収が通りました。指摘を受けた仕組みが、指摘への対処にも同じ「外注と契約」の型を使った、という入れ子構造です。

修正後、会議システム関連の回帰テストは128件が全て通りました（メタレビュー前は117件、今回の新規が11件）。ただし、テストが通ったことは事実確認の一部でしかなく、それだけで品質を保証したとは考えていません。

0/146が動いた瞬間¶

修正の直後、成果サイクルを実データで走らせました。すると、メタレビューの会議自身が生成していたタスクのうち2件が、「修正されたコードとテストという成果物が更新された」ことを根拠に、史上初めて自動で完了になりました。

同時に、タスクより古い日付の成果物を根拠にしていた別の1件は、「古い証拠」として完了を拒否されました。偽完了を防ぐための修正6番が、実装したその日のうちに実際の仕事をしたことになります。0件だった完了カウントが、初めて動いた瞬間でした。

今の限界¶

会議3.0は実装した直後で、長期の実績はまだありません。既存146件のタスクへ完了証拠を後から自動でつけて回ったわけでもありません。失敗したときに本番環境を自動で巻き戻す機能もまだなく、いまは撤退が必要だと記録するところまでです。判定済みの予測はまだ2件（成立2・不成立0、未判定4件）で、母数が小さすぎるので予測精度が高いとは書きません。

締め¶

信頼できるAIとは、間違えないAIのことではないと思っています。間違いを記録し、反証し、実行結果で訂正できる仕組みの中にいるAIのことです。会議1.0は話す相手を増やし、会議2.0は証拠を求め、会議3.0は結果まで背負わせました。そして3.0が最初にやった仕事は、外の誰かではなく自分自身にその仕組みを向けることでした。

本記事は個人の開発記録です。数値は2026年7月時点のもので、仕組みは今後変わる可能性があります。

関連リンク