Claude Codeで開発が変わる理由。AIにコードを書かせず文脈を管理するエージェント工学の現在

開発者が「史上最も後れを取っている」と感じる時代の幕開け

「自分はプログラマーとして史上最も後れを取っている気がする」。

この言葉が、世界最高峰のAIエンジニアの口から飛び出した。

2025年12月。これが一つの大きな転換点だった。

それまでのAIコーディングは、AIが生成した不完全なコードを人間が手で修正する作業の繰り返しだった。

しかし、その景色は一変した。

AIが生成するコードの塊を、人間がほとんど直さなくていい瞬間が訪れた。

雰囲気のままにAIへ指示を出し、アプリが完成していく「バイブ・コーディング（vibe coding）」という新しいスタイルが定着した。

コードを書く時代から「文脈を組み立てる」時代への地殻変動

いま、AI開発の現場で起きているのは、既存のプログラミングの延長線上にある進化ではない。

ソフトウェア3.0と呼ばれる新しいパラダイムへの移行だ。

これまでのプログラミングが「コードを書く」行為だったのに対し、これからは「文脈を組み立てる」行為へと変わる。

大規模言語モデル（LLM）は、もはや単なるチャットツールではない。

それは「もう一つのコンピュータ」であり、開発者が操作すべきはソースコードではなく、AIというインタプリタに渡すための「コンテキスト（文脈）」そのものだ。

例えば、あるコーディング用エージェントの導入手順を見てほしい。

従来なら、複雑なシェルスクリプトを実行し、環境変数を手動で設定するのが当たり前だった。

しかし、最新のエージェントにおけるインストール方法は、驚くほどシンプルだ。

「エージェントに渡す一片のテキスト」。

ユーザーがやることは、そのテキストをコピーしてエージェントに渡すだけだ。

あとはエージェントが自分の環境をスキャンし、必要に応じてループの中でデバッグしながら、勝手に処理を進める。

象徴的な話がある。

あるエンジニアが自作した、レストランのメニューを撮影すると料理画像を生成してくれるアプリの話だ。

かつては苦労してコードを書いたその機能も、今や最新のAIモデルに「メニューに料理画像をオーバーレイして」と頼むだけで完結する。

つまり、「自作アプリのコードそのものが、もはや存在する必要がない」という事態が起きている。

既存のものを高速化するのではなく、これまで存在しえなかったものを作る発想が、「バイブ・コーディング」の核心にある。

しかし、AIには特有の弱点がある。

それは「スパイキーな知能（jagged intelligence）」だ。

ある領域では人間離れした能力を発揮するのに、別の領域では信じられないような初歩的なミスを犯す。

最新のモデルが10万行のコードベースを完璧にリファクタリングできる一方で、「50メートル先の洗車場に歩いて行くべきか、車で行くべきか」という問いに、正気とは思えない回答をすることがある。

このアンバランスさは、AIが「検証可能なドメイン」、つまり正解がはっきりしている数学やコーディングのデータで集中的に鍛えられているからだ。

検証が難しい日常的な常識の領域では、AIはまだ危うい。

そこで登場するのが「エージェント工学（Agentic Engineering）」という考え方だ。

これは、気まぐれで強力なAIエージェントを、いかに制御し、協調させて、プロの品質を担保するかという技術体系を指す。

かつては、普通の人の10倍の成果を出す「10xエンジニア」がもてはやされた。

しかし、エージェント工学を使いこなすエンジニアと、そうでないエンジニアの間には、測定不能なほどの格差が生まれている。

採用のあり方も変わる。

アルゴリズムのパズルを解かせる古い試験は、もはや意味をなさない。

これからは、「AIエージェントを指揮して、30分以内に複雑なシステムを構築できるか」が、エンジニアの真の価値になる。

<!-- IMAGE_1 -->

※この記事は、Claude Codeで1人SaaS開発しているしんたろーが、
海外AI最新情報を開発者目線で解説する「AI活用Tips」です。

しんたろー：
2025年末からの流れ、早すぎて笑うしかない。
Claude Codeを使い始めてから、キーボードを叩く回数が激減した。
以前は「どう書くか」を考えていた時間が、今は「AIに何を伝えて、どう検証させるか」を考える時間に置き換わっている。
戻れないタイプの進化だ。

エージェント工学の核心。AIを迷わせないための「仕様書」設計術

AIコーディングエージェントを使い始めると、誰もが同じ壁にぶつかる。

「指示したはずの規約を守ってくれない」「途中で文脈を忘れる」「期待外れのコードが出てくる」。

こうした不満に対し、多くの人は「もっと細かく、丁寧に仕様を書けばいい」と考えがちだ。

しかし、事実はその真逆だ。

仕様書を巨大化させればさせるほど、AIモデルはフォーカスを失い、指示の遵守率は低下する。

これは「指示の呪い（Curse of Instructions）」と呼ばれる現象だ。

プロンプトに指示やデータを詰め込みすぎると、AIはどの指示が重要なのか判断できなくなり、すべてを中途半端にしか守らなくなる。

そこで、エージェント工学において提唱されているのが、「AIを導くのに十分なニュアンスだけを含む、明快な仕様（spec）」を設計する技術だ。

具体的には、以下の3つの原則がある。

第一に、「人間は高いレベルの方向性だけを示し、詳細はAIに書かせる」ことだ。

最初から完璧な仕様書を人間が書こうとするのは、AI時代の開発としては非効率だ。

人間がプロダクトの概要（product brief）を書き、それをもとにAIに詳細な仕様書（spec.md）を生成させる。

この仕様書は、人間とAIが共有する「唯一の真実（source of truth）」として、開発が進むにつれて継続的に更新される。

第二に、仕様書を「構造化された6つのセクション」で構成することだ。

数千件のエージェント設定ファイルを分析した結果、効果的な仕様には共通の型があることがわかった。

「目的（Objective）」「技術スタック（Tech Stack）」「コマンド（Commands）」「プロジェクト構造（Project Structure）」「境界線（Boundaries）」「成功の定義（Definition of Success）」の6つだ。

特に重要なのが「境界線」だ。

「常に実行すべきこと」「まず人間に確認すべきこと」「絶対にやってはいけないこと」の3段階で制約を明示する。

例えば、「シークレット情報をコミットしない」という1行の制約があるだけで、エージェントの事故率は低下する。

第三に、「並列エージェントと文脈の切り出し」だ。

一つの巨大なプロンプトですべてを解決しようとするのは、最先端のモデルであっても悪手だ。

タスクごとにコンテキストをリフレッシュし、必要な情報だけを渡す。

データベースのスキーマを実装するときは、データベース関連のセクションだけを渡す。

認証機能を実装するときは、認証セクションと、それに関連する最小限のスキーマ情報だけを渡す。

このように、「文脈を絞り込んでAIのフォーカスを維持する」ことが、エージェント工学におけるスキルの一つとなる。

<!-- IMAGE_2 -->

しんたろー：
「指示の呪い」は、ThreadPostの開発中に何度も食らった。
あれこれ詰め込みすぎると、Claudeが急に「あ、それ忘れてました」みたいな動きをする。
今は、機能を細かく切り分けて、その都度コンテキストをリフレッシュするようにしている。
AIをどう「集中」させるかが、開発者の腕の見せ所だ。

Claude Codeを最強のパートナーに変える「メモリ設計」の極意

AIエージェントとの共同開発において、単なる仕様書以上に重要になるのが「メモリ（Memory）」の概念だ。

Claude Codeのような最新のツールには、過去の対話や決定事項を記憶する機能が備わっている。

メモリとは、AIにとっての「外部脳」であり、プロジェクトの「文脈設計の場」だ。

効果的なメモリ運用のためには、情報を「3つの種類」に明確に分ける必要がある。

1つ目は、「ユーザー・メモリ（user）」だ。

これはAIが「誰と対話しているか」を理解するための土台だ。

開発者の役割、経験、技術的な好み、重視する価値観などを記述する。

これにより、AIは「ECSのタスク実行ロールとは何か」といった初歩的な解説を省き、最初から高度な技術的議論ができるようになる。

2つ目は、「フィードバック・メモリ（feedback）」だ。

過去に人間がAIの提案を修正したり、スタイルを指定したりした記録を残す。

ここで重要なのは、単に「ルール」を書くのではなく、「なぜそうするのか（Why）」と「いつ適用するのか（How to apply）」を必ず添えることだ。

3つ目は、「プロジェクト・メモリ（project）」だ。

進行中のタスクや関係者、期日、現在の開発フェーズなど、寿命の短い情報を置く。

「現在は3部構成の記事の2番目を執筆中」といった情報を入れることで、AIは文脈に沿った提案ができるようになる。

これらのメモリを運用する上で、最も避けるべきは「書きっぱなし」にすることだ。

メモリは育てるドキュメントであり、同時に古い情報を捨て続けるプロセスでもある。

インデックスとなるファイル（MEMORY.md）には、各メモリの要約と「いつ参照すべきか」を1行で記述する。

Claude Codeは会話のたびにこのインデックスを読み込み、必要なときだけ詳細なファイルを取りに行く。

この「情報の疎結合」こそが、AIの推論精度を高く維持するための秘訣だ。

<!-- IMAGE_3 -->

しんたろー：
メモリに「Why」を書くのは、本当にマジックだ。
以前は同じようなミスを何度も指摘していたが、理由をセットで覚えさせたら、Claudeの「察し」が格段に良くなった。
逆に、古いプロジェクトメモリを消し忘れて、終わったはずのタスクを何度も提案されたときは、自分の管理不足を痛感した。
AIの脳みそをメンテナンスするのも、エンジニアの大事な仕事だ。

エージェント工学がもたらす開発者の再定義

僕らは今、歴史的な転換点に立ち会っている。

「コードを書けること」の希少価値は、今後も下がり続ける。

代わりに求められるのは、AIエージェントという強力な知能を、いかに構造化された文脈で包み込み、正しい方向へ導くかという能力だ。

エージェント工学は、単なるツールの使いこなし術ではない。

それは、人間が「監督・判断・美意識」という、AIには代替できない上位レイヤーの仕事に集中するための、新しいエンジニアリングの形だ。

AIに全権を委ねる「バイブ・コーディング」の軽やかさと、厳格なコンテキスト管理による「エージェント工学」の堅実さ。

この両輪を回せるエンジニアだけが、これからの時代、圧倒的な成果を出し続けることができる。

今すぐ、自分のリポジトリにMEMORY.mdを作ってみてほしい。

そこに、大切にしている開発の「理由」を書き込むことから、新しい時代の開発が始まる。

FAQ

Q1: AIに指示を出す際、なぜ情報を詰め込みすぎると逆効果なのですか？

「指示の呪い（Curse of Instructions）」と呼ばれる現象が起きるからです。LLM（大規模言語モデル）は、一度に処理できる情報の密度と、それらに対する注意の配分に限界があります。プロンプトに大量の指示や制約、データを詰め込むと、モデルは個々の指示の重要度を正しく判断できなくなり、結果として指示の遵守率が著しく低下します。現在のタスクに直結する情報だけを抽出し、段階的にコンテキストを更新する「情報の絞り込み」が、AIの性能を引き出す鍵となります。

Q2: MEMORY.mdを運用する際、なぜ「Why（理由）」を書く必要があるのですか？

AIに「判断基準」を共有するためです。単なる「ルール（何をしてはいけないか）」だけでは、AIは未知のケースや微妙な境界線上の問題に対応できません。例えば「コードの行数を短くする」というルールだけでは、AIは可読性を犠牲にしてまで短縮しようとするかもしれません。しかし、「なぜ短くするのか（保守コストを下げるため）」という理由があれば、AIは「可読性が下がるなら短縮しないほうがいい」という高度な判断ができます。Whyは、AIが人間の意図を汲み取り、自律的に最適な行動を選択するための「思考のテンプレート」として機能します。

Q3: エージェント工学において「検証可能なドメイン」を意識すべきなのはなぜですか？

AIの知能には「ギザギザ（jagged）」な特性があり、得意不得意が極端だからです。数学やプログラミングのように、実行結果やテストで「正解」が客観的に検証できるドメインでは、AIは強化学習を通じて爆発的に進化しています。一方で、検証が難しい「常識」や「文脈依存の判断」では、脆い一面を見せます。開発者が「このタスクはAIにとって検証可能な領域か？」を意識することで、AIに任せるべき部分と、人間が厳密にチェックすべき部分の境界線を正しく引くことができます。

まとめ

AIコーディングは、もはや「コードの自動生成」というフェーズを通り過ぎ、「文脈を管理するエージェント工学」へと進化している。

AIに丸投げするのではなく、人間が「検証可能なドメイン」を定義し、メモリを通じて「現在の文脈」を最適化し続けること。

この新しいワークフローを受け入れたとき、開発スピードは次元が変わる。

👉 ThreadPostでSNS運用を自動化する