AIに全部判断させるのをやめた ― AI ModelとCoding Agent Runtimeの責務をどう分けたか

AI がコード変更を提案するエージェント型ツールが増えている。最新の実装を見ると、ある設計思想の転換が起きていることが分かる。最初の世代は「AIが賢いなら判断を全部任せてもいい」という発想だった。ファイルを読むか読まないか、どこを変更するか、テストは通ったか。これら全てを AI に判断させる。人間のランタイムシステムは、単なる手足。この単純さが、初期段階では魅力的に見えた。ところが実装を進めると、別の問題が浮かぶ。「ランタイムが意味判断を始める」という落とし穴だ。AI が「ファイル A を確認したい」と言ったのに、それが存在しないとき、ランタイムが勝手に「ファイル B のことだろう」と補完してしまう。すると記録の上では「誰がその判断を下したのか」が不明確になる。

こうした教訓から、最新の実装では別の原則が採られ始めている。それが「判断を渡さない、事実だけは完全に渡す」という設計だ。AI が存在しないパスを要求したら「補完しない」。ファイルが無いなら沈黙する。その沈黙を見て AI は自分で別の手を考える。テスト検証が失敗したら「失敗した」だけでなく、失敗したコマンド、終了コード、エラー出力の全部を AI に返す。重要なのは、AI の「宣言」と「確認済みの事実」を同じ記録に混ぜないこと。AI が「この変更で問題ない」と言っても、システムが「テスト失敗」と記録したら、最終結果は「検証失敗」にする。AI の主張は消さないが、事実が上書きする。

中小企業の実務では、これは直接的な意味を持つ。AI を業務に組み込む際、「AI にやらせたから大丈夫」という思考だけでは危ない。むしろ、AI と人間の仕事をどこで分けるか、AI の判断にどの段階で人間の確認を挿むか、その設計こそが安定性を左右する。特に重要なのは、失敗時の情報の扱いだ。AI が「直しました」と言ったら、本当に直ったか人間が見る。その検査に必要な情報（エラーログ、変更内容、テスト結果）を完全に人間に渡す。AIエージェントの出力を「最終成果」ではなく「素案」として扱い、人間の確認を挟む組織設計こそが、AI 時代の実務の基本形になりつつある。