AI依存から脱却せよ！『答えを教えないAI』が変えるエンジニア育成

若手エンジニアがエラーを3秒でAIに丸投げし、スタックトレースすら読まずに「動いたからヨシ！」とする光景。これは現代の開発現場で日常茶飯事だ。しかし、この「見事な手さばき」を我々シニアエンジニアは笑っていられるだろうか。私自身、ふと見慣れないエラーに遭遇した際、自力でスタックトレースを追う集中力が著しく低下していることに気づき、背筋が凍るような恐怖を覚えた。AIに依存しきった脳は、デバッグというエンジニアの最も基礎的かつ重要な筋肉を急速に萎縮させている。まるで、コンパイルエラーが出るたびに無限ループに陥るスパゲッティコードのように、我々の思考プロセスはAIという外部リソースにデッドロックされているのだ。

さらに、マネージャーの視点に立てば、この状況は「評価の死」を意味する。成果物も、開発速度も、コミットログもすべてAIとの共同作品であり、個人の「地力」が完全に見えなくなっている。評価面談で語れるのが「印象」だけという、極めて不健全な状況が生まれているのだ。この「AIが下駄を履かせることで実力が見えなくなる」という課題は、若手自身の不安（AIがなければ何もできない自分への恐怖）とも直結している。納期優先の現場において、個人の意志だけでこの依存のループを抜け出すことは不可能であり、組織的な「仕組み」による解決が不可欠なのだと私は考える。

この深刻な地力低下と評価のブラックボックス化に対し、極めてユニークなアプローチで一石を投じたのが、Webサービス「SocraMetry（ソクラメトリー）」である。その思想は「AIに答えを出させるのではなく、問いを出させる」というコペルニクス的転回に基づいている。エラーを投げると、AIは内部で原因を特定しつつも、決して答えを教えない。代わりに、ユーザーに対して「問い」を投げかけ、自力で原因に気づくよう誘導する。これはまさに、古代ギリシャの哲学者ソクラテスの「産婆術（対話法）」をLLMによって再現したシステムだ。

しかし、業務の現場で「答えを教えない」ツールが本当に実用に耐えうるのか。その懸念に対し、SocraMetryは「3段階のゲート設計」という現実的な解を提示している。

• Gate A（ヒント）：最初の気づきを促す段階
• Gate B（設問）：具体的な問いに答える段階
• Gate C（答えの開示）：最終的な解決策を提示する段階

時間が経てば自動的に次のゲートへ進むため、業務がスタックすることはない。ただし、どのゲートで解決したか、どれだけヒントに依存したかというプロセスはすべて記録され、デバッグ能力の5軸（観察、切り分け、仮説、検証、修正）としてスコア化される。ここで特筆すべきは、計測される側のエンジニアが不利益を被らないための「Goodhartの法則」への対策だ。総合点の一人歩きを防ぎ、主指標を「絶対値」ではなく「成長率」に置くことで、若手のモチベーションを削がない設計が徹底されている。評価の歪みを防ぐこの配慮こそ、現場に根ざしたシニアエンジニアならではの視点と言える。

エンジニアとして最も興奮させられるのは、この「答えを言わないAI」をいかにして技術的に実現しているかというアーキテクチャの妙だ。LLMに「答えを言わずに質問して」とプロンプトでどれだけ懇願しても、確率的に必ずどこかで答えを漏洩（リーク）してしまう。そこで開発チームは、確率で防ぐのをやめ、「構造で防ぐ」選択をした。システムは、役割を完全に分離した2段構成のLLMを採用している。

1段目の「Diagnoser」がエラーの原因を特定するが、2段目の「Questioner」には「着眼点」のみを渡し、具体的な答えは教えない。出題者自身が答えを知らないため、物理的に漏洩のしようがないのだ。さらに、最終出力の手前で、LLMを使用しない決定的なルールベースの検問「LeakGuard」を通すことで、安全性を二重に担保している。この役割分離は、そのまま劇的なコスト最適化へと直結している。1セッションで10〜15回発生するLLM呼び出しのうち、高度な推論が必要な「Diagnoser」は最初の1回のみ。残りの出題や判定は、安価なモデルで十分に賄える。LLMゲートウェイ「OrcaRouter」を採用することで、クライアント側のコードを変更することなく、Anthropic（高品質）、OpenAI（安価）、Google（退避先）といったマルチプロバイダのモデル出し分けを「modelパラメータの変更のみ」で実現している。

実測されたコスト構造も極めて興味深い。以下に、開発チームが実測した1セッションあたりのコスト比較を示す。

さらに、セッション開始時点で約4.2円（診断と振り返り）が確定し、その後ユーザーがどれだけ悩んで設問を重ねても、100問あたりわずか+4.3円しか増えないという原価構造を突き止めている。これは「じっくり考えさせる」というサービスのコア価値と、ビジネス的な持続可能性が完璧に調和した、極めて美しい設計である。インフラに採用された「enebular」の制約（ストリーミング不可など）を逆手に取り、診断結果を1回だけ保存して再利用する設計に落とし込んだ点も、シニアエンジニアの老獪な技術選定の賜物だ。

「電卓が普及した時代に、暗算を鍛える意味はあるのか？」という問いは、AI時代のエンジニア育成において必ず提起される。しかし、我々が鍛えるべきは「桁数の多い掛け算を素早く解く暗算力」ではなく、「出力された計算結果の桁数が、そもそも直感的におかしいと気づく感覚」である。AIが生成したコードを無批判に本番環境へデプロイし、障害が発生した際にスタックトレースすら読めないチームが、果たしてプロフェッショナルと呼べるだろうか。AIが定型業務を奪うからこそ、人間に残されるのは非定型の極めて難解なバグだけであり、我々に求められるデバッグの地力はむしろ向上しているのだ。

SocraMetryが提示した「AIに何をさせないか」という設計思想は、今後のAIプロダクト開発における強力なパラダイムシフトとなるだろう。禁止は約束（プロンプト）ではなく、構造（アーキテクチャ）で実装する。この原則こそ、我々がこれからのシステム設計で肝に銘じるべき真理だ。

ここで、我々エンジニア、そしてマネージャーは自らに問い直さなければならない。明日、あなたの開発環境からAIが消え去ったとき、あなたには何が残るのか？AIが提示する『動くコード』の裏にある脆弱性や設計の歪みを、あなたは自分の言葉で指摘できるだろうか。我々が明日から取るべき実践的な処方箋は、エラーが出た瞬間に「3秒間、AIへのコピー＆ペーストを我慢する」という極めて泥臭い一歩から始まる。スタックトレースを上から3行だけ、自分の目で凝視し、仮説を立ててみる。AIという強力な松葉杖を使いこなしつつも、自らの足で立つ筋力を維持し続けること。それこそが、このAI全盛時代を生き抜くための、最大の生存戦略なのだ。