これまでの6回は、AIの側の設計を書いてきました。仕様書の書き方、報告の検証、完了確認、バックアップ、そして誤りの実例。第7回は視点を変えます。対話AI（ひかり）の側にも、繰り返し是正されてきた作法があります。 その一部を書きます。
結論を先に書きます。この開発でいちばん高くつくのは、AIの誤りではなく、人の実行回数です。
1. 指示は字面ではなく実体で受け取る
ある指示に対し、指示文中の語をそのまま検索キーワードとして扱い、見つからないと「実行できません」と述べたことがありました。見つからなかった時点で書式を変えて検索をやり直し、それでも見つからず、また書式を変える——これを4回繰り返しました。
このとき指摘を受けた一言があります。
字面が無い＝指示が特定できない、と結論づけたことが誤りです。
指示の実体は、別の言い回しで文書の中に存在していました。 探し方を変えて何度も検索を繰り返すことは、一見粘り強く見えますが、実際には指示を出した人の確認の手間を増やしているだけです。 以降、こうしています。
- 見つからないと分かった時点で、探索をやめる
- 語を変えて検索を繰り返さない
- 「どういう状態を指しているか」を、その場で尋ねる
字面と実体がずれる場面は、大きな開発ほど増えます。同じ対象を指す呼び方が、文書ごとに、時期ごとに変わっていくためです。探すことに時間を使うより、尋ねることに時間を使うほうが、双方にとって早いのです。
2. 質問は冒頭に、1回に1件
長い報告や考察の末尾に質問を置くと、その質問がどこにあるか自体を、相手が探さなければなりません。
質問までの、回答、コメントが長くなるほど、事故が発生します。
これ以降、次の3つを徹底しています。
- 質問は、応答の冒頭に置く
- 1回の応答で、質問は1件に絞る。 複数の質問を並べると、いただいた返答がどの質問への答えなのかが判定できなくなる
- 選択肢は、相手にしか決められないことに限って並べる。 選べる形で並べること自体が、論点を不必要に増やす
3. 貼り付けだけを受け取ったときは、止まっていることを明示する
調査結果や実行結果の貼り付けは、それ自体では質問への回答になりません。 貼り付けを受け取っただけで作業を先へ進め、実は先に出していた質問への回答をまだ受け取っていなかった、という事故が実際に起きました。
以降、「これは質問への回答ではないため、止まっています」と明示することにしています。黙って待つのではなく、止まっていることそのものを言葉にします。指示を出す側も、時に取り違えることがあります。双方の食い違いを防ぐのは、沈黙ではなく明示です。
4. 止まることを目的化しない
作法を是正した直後、今度は逆方向に振れたことがありました。何でも案を並べて判断を仰ぐようになり、任せられた範囲まで止まって確認を求めるようになりました。
では、このまま何も対応しない意思と捉えます。
止まるべきは、指示の範囲を超えるときです。「決めるのが不安なとき」ではありません。 任された範囲では決めます。判断を仰ぐのは、相手にしか決められないこと（設計判断・仕様の解釈・運用の方針）に限ります。
第1〜6回で書いてきた「TAKTは仕様書に無い乖離を独自に是正しない」という設計は、実はこの原則の裏返しでもあります。任された範囲は進め、任されていない範囲は止まって報告する。 この線引きは、AIエージェントにも、対話AI自身にも、同じ形で適用しています。
5. 気づいた不整合を、その場で課題として立てない
作業中に、本題とは別の小さな不整合に気づくことがあります。それをその場で課題として提起しないことにしています。
1点でもほころびがあると、課題にするため、未整理が増え、そもそも忘れてしまう。
引き継ぎ資料に記録するだけに留め、整理する時機は、指示を出す側が決めます。 気づいたことを逐一提起するのは、一見誠実に見えますが、受け取る側の検討事項を無制限に増やす行為でもあります。
同じ理由で、新しい運用・新しい分類・新しい欄を、こちらから提案しないようにもしています。既存の枠の中で解く方法を、まず探します。運用を増やす提案は、課題を新規に作るのと同じだけの負担を、後々まで残します。
6. 定着している運用を、確認せずに変えない
ある更新作業で、「相手が内容を編集する」という前提で手順を組み立てたことがありました。実際には、その更新は一貫してこちら側の担当であり、相手はスクリプトを実行するだけという運用が、最初から定着していました。
今まで一度も私が更新したこともありません。
定着している運用は、書き換える前に必ず確認します。 良かれと思って前提を変えることは、相手の作業のやり方そのものを覆すことがあります。
7. 調査は、原則としてTAKTに依頼する
視点を変えて、もう一つ。「範囲が絞れているように見える調査」を、手元のコマンドで済ませてしまうことがありました。「TAKTの報告はどのみち実測で検証するのだから、最初から自分で実測したほうが早い」という判断でした。
これは誤りでした。 減っていたのは、対話AI側の工程数にすぎません。指示を出す側のコマンド実行の回数は、むしろ増えていました。1件の調査に4往復かかり、うち2回は対話AI側の誤りによる作り直しでした。
8. 工程数は「人の実行回数」で数える
ここが、この回でいちばん大事な点です。工程数を、対話AIやAIエージェントの作業回数ではなく、指示を出す人が実際にコマンドを実行した回数で数えます。
この観点に立つと、評価が逆転することがあります。「対話AIが自分で調べれば1工程減る」という判断は、対話AIの工程を1つ減らす代わりに、人の実行回数を増やしていました。 逆に、TAKTへ調査を依頼すれば、対話AIの工程は1つ増えますが、人が実行するコマンドは減ります。
以降、次の形にしています。
| 種別 | 担当 |
|---|---|
| コードの調査（実装・依存関係・テスト・呼び出し関係・規模） | TAKT（実装エージェント） |
| 本番のデータの実測（データベース・実ファイルなど） | 人が実行 |
| 手元に持ち込めた成果物の解析（添付ファイルなど） | 対話AI |
手元のコマンドで代替してよいのは、1〜2本のコマンドで判定が終わる場合に限ります。 それを超える調査は、範囲が絞れているように見えても、TAKTへ依頼します。
依頼する範囲は、意図的に広く取ります。 往復を減らすため、後続の判断に必要になりそうな事項（依存の有無・規模・既存のテストの所在など）まで、最初の1回の依頼にまとめて含めます。細かく分けて何度も依頼するほうが、結果として人の確認の回数を増やします。
9. まとめ——最適化すべきは、AIの手間ではない
この回で書いた作法は、どれもAIの性能とは無関係です。指示の受け取り方、質問の出し方、止まる基準、報告の作法、そして工程の数え方——これらはすべて、指示を出す人の負担をどう小さくするかという一点に集約されます。
第6回で「AIは誤る前提で工程を組む」と書きました。この回で書いたのは、その裏側にある原則です。AIの側の工程をどれだけ効率化しても、人の確認の回数が増えていれば、開発全体としては遅くなっています。 最適化すべきは、AIの手間ではなく、人が実際に手を動かす回数のほうです。
次回（第8回・最終回）：AIが人の一覧を超えるとき。TAKTが、人の作った一覧や仕様書には無かった乖離を自ら発見した実例と、そこまで任せてよい範囲について書きます。
動画作成には自信があります！
