AIに計算させるな。Claude Code開発者が導き出すコード主導の設計

エージェントの敗北と「足場」の発見

AIが自律的に動く。僕らはこの言葉に期待を寄せた。

最新の検証結果がある。

12種類の最先端AIモデルを並べて、複雑なタスクを解かせた。

人間が書いたプログラムの信頼性には届かない。

成功率は低い。

AIに「低レベルな処理」を直接やらせると崩壊する。

画像から座標を読み取り、物理的な計算を行い、コードに落とし込む。

この工程をAIに丸投げすると、わずか数行のミスで全てが止まる。

解決策がある。

プロンプトを磨くことではない。

AIが動くための「足場（スキャフォールディング）」を人間が設計することだ。

これが、僕ら開発者が向き合う「AI時代の設計図」になる。

あわせて読みたいClaude Codeの使い方完全ガイド｜インストールから実践まで2年運用の開発者が解説 →

「何でもできる」AIが「何もできない」理由

AIモデルは単体では「記憶のない金魚」だ。

数分、あるいは数時間動かし続けるタスクにおいて、AIは過去の行動を忘れる。

推論の過程で「計算ミス」を犯す。

世界中のエンジニアが提唱するのが「エージェント・スキャフォールディング」だ。

以下の3つの要素がある。

* 推論のハブ化: AIに判断だけをさせる。

* 決定論的なコードへの切り出し: 算術や物理制御など、答えが一つに定まる処理は人間が用意した関数を呼び出させる。

* 検証可能なコンポーネント: AIの出力が正しいか、プログラム的に即座に判定できる仕組みを組み込む。

ロボット制御の実験では、AIに生のカメラ画像を渡して「動かせ」と命令しても失敗する。

成功率を上げたのは、「中間的な構造化データ」を介在させた手法だ。

別のAIが画像をテキストで説明し、何が変わったかを構造化して報告する。

メインのAIが、「あらかじめ人間が用意したコマンド」を組み合わせてコードを書く。

この「人間が用意した抽象化レイヤー」があるかないかで、パフォーマンスは変わる。

しんたろー：
AIに全部任せるのは丸投げだ。
Claude Codeで開発していると、AIが「全部書き直す」と言い出した時が失敗の始まりだ。
小さな関数を組み合わせて、一つずつテストを通していく。
この「人間が引いたレール」の上を走らせる感覚が、今のAIには不可欠だ。

開発者の仕事は「コードを書くこと」から「条件を整えること」へ

AIエージェントと付き合うための道具がある。

開発者の役割は、「1行ずつコードを書くこと」ではない。

「コードがうまく書かれるための条件を整えること」だ。

アプローチは以下の通りだ。

1. インタビュー形式の仕様策定:

いきなりコードを書かせない。

AIに「ユーザーに質問させる」ツールを持たせる。

AIが自ら仕様の穴を見つけ、人間にインタビューして仕様書を固める。

この「曖昧さを消す工程」を仕組み化する。

1. HTMLによる計画の可視化:

計画をテキストではなくHTML構造で出力させる。

モデルは複数のデザイン案や方向性を「構造的」に捉える。

人間も、AIの思考を視覚的に比較できる。

1. 検証（evals）の先行実装:

「コードを書いてからテストする」のではない。

「成功とはどういう状態か」を先に定義し、それを判定するコード（Grader）をAIに渡す。

AIは自分の書いたコードがそのテストを通るまで、自律的にデバッグを繰り返す。

「検証の自動化」が、エージェントを「同僚」に変える。

フロントエンド開発でも手法がある。

Reactの状態（useState）を、「data-verify-*」のようなカスタム属性としてDOMに書き出す。

AIエージェントは「document.querySelector」を使って、ブラウザ上で正しく動作しているかを「外側から」検証する。

内部の実装がどう変わろうと、この「検証用の窓口」があれば、AIは自律的に品質を担保できる。

しんたろー：
「data-verify」の発想は目から鱗だ。
Claude Codeに「このボタン押して、状態がこう変わってるか見て」と頼める。
自分でブラウザを開いて確認する時間が消える。
開発者の仕事は、この「窓口」をどこに作るか考えるゲームに変わる。

信頼性とプライバシーを両立する「軽量アーキテクチャ」

AIを実務に投入する壁は「信頼性」と「データの主権」だ。

全てのデータをクラウドのAIプラットフォームに投げ込むのは、セキュリティの観点から避けるべきだ。

提唱されているのが、「知識ベースはローカル、推論はAPI」という構成だ。

* 100%ローカルなナレッジベース: ユーザーのドキュメントや機密データは、完全にローカルのデータベースで管理する。

* ベクトル検索の分離: 検索ロジックもローカルで完結させ、関連する「断片」だけを抽出する。

* 推論の最小化: AIには「検索結果を元に回答を生成する」という推論タスクのみを依頼する。

AIプラットフォーム側にデータを学習されるリスクを排除しつつ、最新モデルの推論能力を享受できる。

この構成は「軽量さ」にも貢献する。

既存のWebサーバーに、シンプルな検索ロジックとAPI呼び出しを組み込むだけでいい。

数人のチームや、1人開発者が求めているのは、こうした「身軽な信頼性」だ。

しんたろー：
ThreadPostの開発でも、データの扱いは悩みの種だ。
「推論だけ外出しする」設計なら、ユーザーのプライバシーを守りつつ、最新のAI機能を導入できる。
複雑なシステムを組むより、いかに「シンプルに保つか」が強みになる。

僕らの開発をどう変えるべきか

AIを使いこなすとは、「AIを信じない仕組みを作ること」だ。

取るべきアクションは明確だ。

まず、「AIに計算をさせるな」。

論理的な推論は得意でも、算術や厳密なデータ処理でAIは嘘をつく。

その部分は、人間が書いたコードへ追い出す設計にする。

次に、「評価（evals）を資産にする」。

プロンプトをいじくり回す時間は終わりだ。

AIの出力を採点する「評価コード」を書く。

それが積み重なれば、モデルがアップデートされても、システム全体の信頼性は揺るがない。

最後に、「中間層のデザイン」に注力する。

AIに生のデータを渡すのではなく、AIが理解しやすい「構造化されたテキスト」や「抽象化された関数」を用意する。

この「足場」の質が、開発効率の差になる。

AIは魔法の杖ではない。

正しく設計された「足場」の上では、最強のエンジンになる。

僕らは、そのエンジンのための「最高に頑丈なシャーシ」を作る設計者になる。

しんたろー：
プロンプトエンジニアリングという言葉は消える。
代わりに「エージェント・アーキテクト」という役割が重要になる。
Claude Codeを相棒にして、いかに楽をして、いかに堅牢なものを作るか。
その答えは、「コード主導」の設計にある。

あわせて読みたい【2026年版】AI活用1人SaaS開発の完全ロードマップ｜5ステップで始める個人開発 →

AI活用に関するFAQ

Q1: LLMに複雑なタスクを任せると精度が落ちる場合、どう改善すべきですか？

タスクを「推論が必要な部分」と「計算・処理が可能な部分」に分解してください。計算可能な部分はPython関数や外部APIとして切り出し、LLMにはその関数を呼び出す「判断」のみをさせます。生データを直接渡さず、一度テキストベースの構造化データに変換する中間層を設けることで、モデルの推論精度は安定します。

Q2: プライバシーを重視しつつAIを導入する現実的な構成は？

知識ベース（RAGのソースデータ）は完全にローカルのデータベースに保持し、AIには「検索結果を要約・回答させる」という推論タスクのみをAPI経由で依頼する構成を推奨します。これにより、機密データを外部サーバーにアップロードして学習されることなく、LLMの推論能力だけを安全に活用する運用が可能です。

Q3: エージェントの「検証（evals）」は具体的にどう始めればいいですか？

実装前に「成功とは何か」を言語化し、それを判定するコード（Grader）を先に書いてください。出力結果が期待されるJSON形式か、特定のキーワードを含んでいるか、といったテストケースを先に用意します。プロンプトを修正するたびにそのテストを自動で回すサイクルを作ります。決定論的に測れるものはコードで、ニュアンスが必要なものは別のLLMに採点させるのがコツです。

まとめ

AIエージェントの真価は、モデルの性能ではなく、用意する「足場（スキャフォールディング）」で決まる。

計算をコードに逃がし、検証を自動化し、構造化データで推論を支える。

この「コード主導の設計」こそが、AI時代の開発者の武器だ。