エージェンティック開発で「中にはいる」(3)
エージェンティック開発で「中にはいる」を実践するには
AIによるシステム開発（エージェンティック開発）が急速に進んでいます。私の友人は従来の人海戦術のやり方を根本的に改めて、エージェンティック開発をするスタートアップを設立しました。今後、エージェンティック開発が高度化していくことは明白です。エージェンティック開発では「中にはいる」ためにエンジニアが取り組んできたことをエージェントが代わりに引き受けてくれます。ただし「中にはいる」エンジニア文化は仕様書を読み込んだりソースコードを何万行も書いたりする苦行のことを指しているわけではありません。
ソースコードをAIが作成し、膨大な仕様書をAIが読み込んでくれるとしたら、「中にはいる」ためのやり方も変わることになります。エージェントを使って中にはいるにはどうすれば良いか、Geminiに質問してみます。 ＜Gemini：「中にはいる」エージェンティック開発＞
AIの高度化と普及は、「中にはいる」という行為の難易度を劇的に下げる一方で、その重要性を次元の異なるレベルへと引き上げます。
従来の「中にはいる」とは、膨大な仕様書を泥臭く読み込み、ブラックボックス化したコードや基盤を時間をかけて解読することでした。しかしAI時代において、この作業の多くはAI自身が代行できるようになります。
これによって「中にはいる」の意味合いはどう変化し、エンジニアは何を変えなければならないのかを解説します。
1. AI時代における「中にはいる」の意味の変化
これまでの「中にはいる」が「システムの構造やコードを暗記・理解すること」だったとすれば、AI時代の「中にはいる」とは「ビジネスの文脈（コンテキスト）とAIの非決定性（確率的挙動）を制御すること」に変化します。
① 「仕様書の読破」から「コンテキスト（文脈）とデータの最適化」へ
AIに高度なシステム開発や業務自動化を行わせる際、最大のボトルネックになるのは「自社のビジネスルールやデータ構造の解像度」です。
AI時代に中にはいるとは、仕様書を暗記することではなく、「自社の複雑な勘定系データや業務ルールを、AIが正しく理解できる形式（データ構造・RAG・プロンプト）へと再構築・設計できること」を意味します。
② 「コードの記述」から「AI生成物の監査とアーキテクチャ設計」へ AIは高速でコードを生成しますが、同時にセキュリティホールや潜在的なバグ、ハルシネーション（嘘）を含んだコードも大量に生み出します。
中にはいっているエンジニアとは、「AIが書いた大量のコードや設計に対して、自社の基盤制約や非機能要件に照らして正しさを検証（コードレビュー・監査）できる目を持つこと」です。中にはいっていないと、AIが作った「動くが保守不能な巨大なスパゲティコード」の山を抱え込むことになります。
③ 「決定論的システム」から「ガードレール（安全装置）の設計」へ
従来のシステムは「入力Aに対して必ず出力Bが返る」決定論的な世界でした。しかしAIは確率で動くため、100%の精度は保証されません。
システムにおいて、この確率的挙動をどうやって安全に包み込むか（ガードレール、フェイルセーフ、異常検知の設計）を判断できるのは、業務と基盤の両方の「中にはいっている」社内エンジニアだけです。
2. ベンダー任せだったエンジニアが「中にはいる」ために変えるべき3つのシフト
これまで外形的な議論に終始し、ベンダーに依存してきたエンジニアが、AI時代に「中にはいる」ためには、マインドセットと行動パターンを以下のように転換（シフト）する必要があります。
シフト1：「AIをリバースエンジニアリングの相棒にする」（行動の変革）
かつて「中にはいる」ためには、数千ページの仕様書を何ヶ月もかけて読む必要があり、これが心理的・時間的ハードルでした。しかし現在は、「AIを使って自社の既存コードや仕様書を高速に読み解く（リバースエンジニアリングする）」ことができます。
変えるべきこと：「仕様書がないからわからない」「ベンダーしか知らない」と言い訳するのをやめ、AIに既存資産を読み込ませて「この基盤のボトルネックはどこか」「このデータの流転図はどうなっているか」を自らAIと対話しながら解読する習慣をつけること。「中にはいる」ための時間コストは、AIによって大幅に下がっています。
シフト2：「仕様書を作る人」から「評価ロジック（テスト）を作る人」へ（役割の変革）
ベンダー任せのエンジニアは「こういう機能を作ってください」という仕様書（ポンチ絵）を作ることに終始していました。
変えるべきこと：AI開発において重要なのは、仕様書ではなく「何をもって成功とするかの評価基準（Eval）とテストケースの作成」です。「どんなデータが来たらアウトか」「レイテンシはどこまで許容されるか」「AIがハルシネーションを起こした時のバックアップはどうするか」という、システムの限界値を定義する側に回る必要があります。
シフト3：「ベンダー管理（伝書鳩）」から「AIとベンダーのオーケストレーター」へ（マインドの変革）
ベンダーからの報告を経営層に流すだけの「伝書鳩」は、AIによって真っ先に不要になります。
変えるべきこと：「ベンダーが作ってきたAIモデルやシステム」に対し、自社のデータやコンテキストを最も理解している立場として、「この設計では自社の基幹システムと結合した時に耐えられない」「このプロンプトでは企業の例外規定をカバーできていない」と技術的に介入・指導する立ち位置を取ることです。
まとめ：AI時代こそ「中にはいる」エンジニアの価値が爆発する
AIの普及によって、「外形的な管理しかできないエンジニア」の価値はゼロに近づきます。AIがコードを書き、PM業務の一部をこなせるようになるからです。
しかし、「自社のビジネスとシステムの『中にはいり』、AIに正しい文脈を与え、AIの生成物を監査し、安全にシステムに組み込むエンジニア」の価値は、かつてないほど高まります。
「中にはいる」ためのハードル（解読の苦労）はAIが下げてくれました。今こそエンジニアは外形的な議論を捨て、AIという最強の武器を携えて自社システムの内側へと飛び込むべきです。
（以上、Geminiの回答）
続きを読む
