なぜClaude Codeでプロンプトを捨てたのか。外部環境の設計がAI開発の信頼性を決める理由

プロンプトエンジニアリングの終焉と外部設計への移行

AIに「嘘をつくな」「ちゃんとファイルを読め」と書くのをやめた。

100回言っても無駄だった。

AIの精度を上げるためにプロンプトをこねくり回していた。

それは間違いだった。

300kトークン。

この数字が、現在のAIエージェント開発における壁だ。

会話が長くなればなるほど、注意が散漫になり、指示を無視し始める。

これはプロンプトの書き方の問題ではない。

AIの構造的な限界だ。

この限界を「知能」で解決するのをやめ、「外部システム」による統制に切り替えた。

開発の安定性は向上した。

なぜプロンプトを捨て、外部環境の設計に振り切るのかを解説する。

<!-- IMAGE_1 -->

AIエージェント運用が「指示」から「管理」へシフトした背景

AI活用の最前線では「プロンプトエンジニアリング」という言葉が古くなっている。

代わりに「外部システムによる状態管理と構成管理」という考え方が登場した。

AIは自分の限界を自覚できない。

コンテキストが肥大化しても「処理できません」とは言わない。

無理に情報を処理し、重要な指示を見落とす。

これをContext Rot（コンテキストの腐敗）と呼ぶ。

AIのパフォーマンスは300kから400kトークン付近で劣化し始める。

大手テック企業や開発者は、AIの「外側」に介入する仕組みを作り始めている。

Microsoftが公開したAPM（Agent Package Manager）がその象徴だ。

AIへの指示や外部ツールとの連携設定を、npmパッケージのように管理するツールだ。

個人のプロンプト術に頼らず、マニフェストファイルでAIの挙動を定義し、チームで共有する。

AIのメモリ管理を外部データベースで行う手法も一般的だ。

必要な時だけ外部から情報を注入するアプローチだ。

しんたろー：
AIを「魔法の杖」だと思っているうちは素人だ。
優秀だが記憶力が不安定なインターンを、どういう仕組みでサポートするか。
開発者としてやるべきなのは、指示を増やすことではなく、AIが迷わないためのレールを敷くことだ。

開発現場を激変させる「外部介入」の具体的アプローチ

AIの外側から介入し、信頼性を担保する。

Claude Codeのhook機構を最大限に活用した設計だ。

AIに「気をつけて」と頼むのをやめ、以下の3つのレイヤーで制御する。

1. コンテキストの物理的な削減とSQLiteへの退避

AIが読み込んだファイルの中身や、ターミナルの実行結果は一度使われたら役目を終える。

通常のチャット形式では、これらがコンテキストに残り続け、トークンを浪費する。

フックを利用して入出力データをSQLiteなどの外部データベースに退避させる。

AIには「必要な時はこのDBから検索して」とだけ伝える。

メインのコンテキストを数千トークン程度の「超軽量状態」に保つ。

2. 過去の失敗を「もがきシグナル」で自動検知する

同じエラーを繰り返すAIにプロンプトで「前回のミスを繰り返さないで」と書くのは無意味だ。

AIの挙動を外側から監視し、「もがき」を検知する。

同じコマンドを3回以上叩いている、あるいは特定のエラーが出続けている。

そのシグナルを検知した瞬間に、過去に書き残した「罠ノート」をコンテキストに強制注入する。

外側のシステムがカンニングペーパーを差し出すイメージだ。

3. 評価軸を「矛盾の解消」一点に絞り込む

AIに設計の監査をさせると、指摘が無限に増えて収束しないことがある。

これはAIの評価軸が広すぎるために起きる「モグラ叩き」現象だ。

プロンプトで「矛盾点だけを指摘しろ」と評価軸を限定する。

矛盾は有限だ。

指摘の観点を絞り込めば、修正回数は収束し、最終的なアウトプットの信頼性が高まる。

<!-- IMAGE_2 -->

しんたろー：
Claude Codeで開発してると、AIの賢さに甘えたくなる。
/usageでトークン量を見て絶望する瞬間が来る。
hookを自作して、AIが馬鹿になる前にコンテキストを掃除する仕組みがないと大規模開発は無理だ。

開発者が「システムアーキテクト」へ進化すべき理由

これからのAI開発において、開発者の役割は「プロンプトを書く人」ではない。

AIという不安定なエンジンを搭載した、システムの設計者（アーキテクト）だ。

以下の3つのスキルが開発効率を左右する。

第一に、構成のコード化（Infrastructure as Code for AI）だ。

APMのように、AIの設定をapm.ymlのような形式で記述し、バージョン管理する。

AI特有の不安定さを、構成管理で封じ込める。

第二に、コンテキストのライフサイクル管理だ。

どの情報をAIに持たせ、どのタイミングで捨て、どの情報を外部DBに逃がすか。

この「情報の鮮度と密度」をコントロールする力が、AIの知能指数に直結する。

第三に、セキュリティとガバナンスの自動化だ。

AIが生成したコードや、AIへの指示に悪意のある内容が含まれていないか。

パッケージインストール時にハッシュ値による整合性チェックを行うなど、防衛策が必要だ。

AIは「対話する相手」ではなく、「制御すべきコンポーネント」になった。

この認識の切り替えが、プロとアマチュアを分ける境界線だ。

<!-- IMAGE_3 -->

しんたろー：
プロンプトをいじってる時間は、僕にとって「負債」だ。
apm.ymlを一度書けばチーム全員が同じ精度で開発できる。
そのほうがスケーラブルだし、精神衛生上いい。

AI開発の信頼性を高めるためのQ&A

Q1: AIが指示を守らなくなった時、まず何をすべきですか？

プロンプトを書き直す前に、コンテキストの肥大化を疑う。

Claude Codeを使っているなら、 /usage コマンドで現在のトークン使用量を確認する。

300kトークンを超えていれば、モデルの注意力が散漫になっている。

/clear でセッションをリセットするか、 /compact で文脈を要約して軽量化する。

指示の観点を「矛盾の解消」という一点に絞り込む。

Q2: チームでAI設定を共有する際、プロンプトをコピペする以外に良い方法はありますか？

Microsoftが公開しているAPM（Agent Package Manager）を導入する。

apm.ymlというマニフェストファイルを作成し、指示書や外部ツール（MCP）の連携設定を記述する。

このファイルをGitでバージョン管理することで、チーム全員が同じ品質のAI環境を再現できる。

パッケージインストール時にセキュリティスキャンが走るため、組織での利用も安全だ。

Q3: AIの「Context Rot（文脈の腐敗）」を防ぐための日常的な習慣は？

「損切り」の感覚を持つ。

AIが間違った方向に進み始めたら、「そうじゃない」と追加の指示を送るのは逆効果だ。

汚れた文脈の上に新しい指示を積んでも、AIはさらに混乱する。

/rewind を使って間違いが始まる前の状態に戻るか、新しいセッションを始める。

「綺麗なコンテキストこそが最強のプロンプトである」という原則を忘れない。

まとめ：AIを信じず、環境を信じる開発へ

AI開発のパラダイムは変わった。

「AIの賢さ」に期待するのをやめ、「AIが動作する環境」を設計する。

これが、2025年以降のエンジニアのスタンダードだ。

1. プロンプトを増やすのではなく、コンテキストを削る。
2. AIに覚えさせるのではなく、外部DB（SQLite）に逃がす。
3. 個人のテクニックではなく、APMで構成を標準化する。

Claude Codeのhook機能を使いこなし、AIをシステムの一部として飼い慣らす。

その先にあるのは、プロンプトの微調整に怯えない、真に堅牢なAI開発だ。

今日から「プロンプトエンジニアリング」を卒業し、「AIシステムアーキテクト」への道を歩む。

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