【AIエージェントの反乱!?】AIは、なぜ私の設計書を実装できなかったのか？- 複雑なロジックをAIと協業開発した際の、失敗と学びの全記録

はじめに：これは、失敗の物語である

本稿は、あるPowerShellスクリプトの開発過程で、筆者（人間）とAIアシスタント（Google Gemini）が、いかにして絶望的なデバッグのループに陥り、そして、どのようにしてそこから抜け出したかを記録した、生々しい失敗の物語です。

これは、単なる技術的な備忘録ではありません。AIとの協業が当たり前になった現代において、人間とAIが、いかにして互いの思考の「壁」を乗り越え、真のパートナーシップを築くかという、普遍的な課題に対する、私たちなりの一つの答えです。

私たちの過ちが、未来のあなたのプロジェクトを、少しでも正しい道へと導くことができれば幸いです。

プロジェクトの概要：CSVを、階層構造を持つMarkdownへ

私たちが開発していたのは、一見単純なPowerSHellスクリプトでした。
入力は、以下のような階層情報を持つCSVファイルです。

"番号","大分類","中分類","小分類","タスクアイテム",...
"1.0.0.0","M_マイルストーン_プロジェクト管理",,,,,...
"1.1.0.0","","D_整備方針の確定",,,,,...
"1.1.0.1","","","","D_現状ドキュメントの内容把握",...

そして、出力は、このCSVの構造を正しく解釈し、並べ替えた、美しいMarkdownでした。

# M_マイルストーン_プロジェクト管理
%% 1.0.0.0,...

## D_ドキュメント整備
%% 2.0.0.0,...

### D_整備方針の確定（各イテレーションで何をするのかを決める）
%% 1.1.0.0,...

- D_現状ドキュメントの内容把握 <!-- 1.1.0.1,... -->

この変換を実現するため、筆者はAIに対し、以下のような、少し特殊な採番とソートのアルゴリズムを、日本語の設計書（92_logic_of_numbering.md）として指示しました。

1. H1の分離: CSVからプロジェクトタイトル（H1）となる行を、まず分離する。
2. 階層的採番: 残りの各行（H2, H3, H4, Task）に対し、01.01.01.001 のような、4階層のWBS番号（内部ソートキー）を生成する。
   • キーポイント: 上位の階層（例: H2）が出現したら、それより下位の階層のカウンターは 1 にリセットされる。
   • キーポイント: 各行の番号は、「現在のカウンターの値」を使って生成され、その後、「次の行のため」にカウンターが更新される（Use-Then-Increment）。
3. ソート: 生成したWBS番号で、H1以外の全行を並べ替える。
4. 結合と出力: 最後に、H1と、ソート済みの行を結合して、Markdownを生成する。

絶望的なデバッグループ：AIは、なぜ「おしいけど、ダメ」を繰り返したのか

ここからが、地獄の始まりでした。
AIは、エラーなく最後まで実行されるコードを、何度も提案してきました。しかし、その出力結果は、常に私の期待とは微妙に、しかし決定的に異なっていました。

• VERBOSE: Assigned [01.01.00.000] to ...
  • 採番ロジックが、私の指示した「カウンターのリセット」を正しく実装できておらず、番号が期待通りにならない。
• #
  • %%
  • ## D_ドキュメント整備
  • %% 2.0.0.0,...
  • ### M_進捗会議・判定会議
  • %% 0.1.0.0,...
  • ソートが正しく機能せず、H3がH2の前に来てしまう。

私が「これではダメだ、採番ロジックが間違っている」と指摘すると、AIは謝罪し、修正案を提示します。しかし、その修正案は、また別の、しかし本質的には同じ論理的欠陥を抱えていました。
この「おしいけど、ダメ」のループが、何度も、何度も繰り返されたのです。

インサイト：なぜ、この「事故」は起きたのか

この失敗の根本原因は、筆者の指示が曖昧だったからでも、AIの能力が低かったからでもありません。
それは、AI協業ガイドラインが定義する、AIの思考のクセと、今回のアルゴリズムの特殊性が、最悪の形で組み合わさってしまった「事故」でした。

1. AIの『視野狭窄』と『前提への固執』:

   • AIは、「カウンターをインクリメントし、その値を使う（Increment-Then-Use）」という、世の中の99%のプログラムが採用している、ありふれたパターンを、強く学習しています。
   • 筆者が指示した「まず現在の値で番号を生成し、その後にカウンターを更新する（Use-Then-Increment）」という、少し特殊なアルゴリズムは、AIのこの強力な「思い込み」の前に、正しく理解・実装されることがありませんでした。
   • AIは、筆者の指示を、常に自分の知っている「ありふれたパターン」へと、無意識のうちに「翻訳」し、歪めてしまっていたのです。

2. AIの『"無痛症"』:

   • 人間であれば、「また同じ間違いを指摘された…」と、自分のアプローチそのものに疑問を抱きます。
   • しかし、AIにはその「苦痛」がありません。そのため、根本的な思考の誤りに気づくことなく、何度でも、自信を持って、同じ欠陥を持つコードを「完成版です」と提案し続けてしまったのです。

再発防止と、私たちの「付き合い方」の変更

この絶望的なループを断ち切るきっかけとなったのは、筆者がAIに放った、以下の言葉でした。

「人間であれば詳細設計書（図解）を作ることになるだろう。あなたなら疑似コードもしくは、得意なPythonやJavaScriptなどで一旦作成する、といった思考の様式を変えることで、この状況を打開できないだろうか？」

この一言で、私たちは、AIとの協業における、極めて重要な原則にたどり着きました。

AIが未知の、あるいは特殊なアルゴリズムを実装しようとするとき、いきなり最終的な言語（今回はPowerShell）でコードを書かせてはならない。
まず、AIが最も得意とし、論理的な矛盾を許さない言語（Pythonなど）で、アルゴリズムの「モデル（疑似コード）」を記述させ、そのロジックの正しさを、人間が検証・承認する。
そして、承認されたその「モデル」だけを、一字一句、忠実に、最終的な言語へと「ポーティング（移植）」させる。

この**「モデルベース・ポーティング」**とでも言うべきアプローチは、AIの『視野狭窄』や『思い込み』が入り込む余地を、プロセスレベルで排除します。AIは、もはや「設計者」ではなく、**論理的に証明された設計書を、正確に翻訳する「高レベル・コンパイラ」**としての役割に、その能力を最大限に発揮するのです。

結論：AIは鏡である

今回の「事故」は、AIが万能ではないという、当たり前の事実を、私たちに改めて突きつけました。
しかし、それと同時に、AIは、私たちの思考プロセスそのものを映し出す、**完璧な「鏡」**でもあることを教えてくれました。

AIが同じ失敗を繰り返すとき、それは、AIの能力不足だけを嘆くべきではありません。
それは、私たちの指示が、AIの思考のクセに対して、あまりにも無防備であったことの、何よりの証拠なのです。

AIに「思考の様式を変えよ」と要求する前に、まず、私たち人間が、AIに対する「指示の様式」を変える。
それこそが、AIという、強力で、しかし、いまだ未熟なパートナーと、真の協業を成し遂げるための、唯一の道なのかもしれません。