なぜClaude Codeは賢いのか｜AnthropicのManaged Agentsから学ぶ堅牢な開発設計

Claude Codeの挙動が変化した。指示を忘れる。テストを書かない。

AIエージェントの挙動を左右するのはモデル本体の知能ではない。その外側にある「ハーネス」と呼ばれる制御機構だ。

AIエージェントの品質低下に関する調査結果が発表された。

原因はAIモデルそのものの劣化ではない。製品レイヤー、つまりモデルを包み込む「ハーネス」の変更が引き起こした副作用だ。

具体的には3つの変更が重なっていた。

1つ目は推論パラメータの変更だ。

UIのフリーズを防ぐため、推論の深さをデフォルトで一段階下げた。結果として約3%の品質低下が発生した。

2つ目はキャッシュのバグだ。

再開時の遅延を減らすため、古い思考履歴を消す最適化が行われた。実装のバグにより、毎ターン履歴が消え続けた。

AIが「指示を忘れる」「同じことを繰り返す」原因はこれだ。

3つ目はシステムプロンプトの短文化制約だ。

冗長さを抑えるため、「ツール呼び出し間の説明は25語以下、最終応答は100語以下」という制約が追加された。

これがコーディング品質を損ね、AIが自発的にテストを書かなくなる原因になった。

<!-- IMAGE_1 -->

これらは基盤モデルの変更ではない。

推論パラメータ、キャッシュ、システムプロンプトという「ハーネス層」の調整だ。

モデルが賢くても、外枠の設計次第でAIの挙動は変化する。

AIエージェントのアーキテクチャは、すべての機能を1つの箱に詰め込まない。

セッション、ハーネス、サンドボックスの3つに分離されている。

セッションは、発生したすべての履歴を記録するログだ。

ハーネスは、AIを呼び出し、ツールの実行をルーティングする制御ループだ。

サンドボックスは、AIが実際にコードを実行し、ファイルを編集する隔離環境だ。

この疎結合な設計が、AIエージェントの安定性を支える。

1つのコンテナにすべてを詰め込むと、エラー発生時にセッションごと消滅する。

機能を分離することで、インフラストラクチャとして安定稼働が可能になる。

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

AIの生産性を決めるのは、モデル単体の性能ではない。その周囲に構築する「仕組み」だ。

AI駆動開発では、設計思想や命名規則を言語化せずにコードを書かせると、ファイルごとにバラバラの実装が出来上がる。

AIは常にその場の局所最適でコードを出力する。土台がないまま生成を繰り返すと、システムの歪みは複利で膨らむ。

しんたろー：
Claude Codeに丸投げして後から全部書き直す経験がある。人間がルールを敷かないとAIはサボる。賢いアシスタントではなく、タイピングが速いだけの新人だと認識している。

セキュリティ、パフォーマンス、可観測性といった非機能要件は、明文化されていなければAIは忘れる。

ハッピーパスのコードだけが量産され、後から重大な欠陥が見つかる。

AIの出力を検証する「決定論的なゲート」が必要だ。

人間の目視レビューだけでは限界がある。テストの自動実行や型チェックといった、機械的な検証システムをハーネスに組み込む。

<!-- IMAGE_2 -->

AIエージェントのアーキテクチャが示す通り、責務の分離が鍵を握る。

何をAIに判断させ、何を人間が判断し、何を決定論的に自動化するか。この線引きが明確でないプロジェクトは破綻する。

AIは確率的に動作する。それを受け止めるインフラは決定論的である必要がある。

モデルの出力がブレても、テストや型チェックが防波堤になる。

この「多層防御」の仕組みこそが、AI駆動開発の真のハーネスだ。

しんたろー：
AIが書いたコードをそのままマージするのは避けている。型チェックが通らないと次のステップに進めないようにしてから、精神的な負荷が減った。AIの不確実性をシステムで殴って黙らせる感覚がある。

コンテキストの管理も重要だ。

AIに大量の情報を与えすぎると、本来の目的を見失う。

重い調査は別のセッションに委ね、メインのコンテキストは常に必要最小限に保つ。

履歴を適切にクリアし、進捗ファイルで状態を管理する。

最先端のAIエージェントが、セッションとハーネスを分離している理由はここにある。

状態管理と実行制御を切り離すことで、AIの挙動を予測可能な範囲に収める。

明日からAIツールを使う時の心構えを変える。

まず、AIの挙動がおかしいと感じたら、自分のプロンプトを疑う前に環境をリセットする。

コンテキストが汚れすぎているか、裏側のハーネスでキャッシュのバグが起きている可能性が高い。

長時間のセッションは避け、タスクごとに細かく区切るのが鉄則だ。

次に、プロジェクトの土台を徹底的に固める。

ドメイン知識、命名規則、ディレクトリ構成。これらをテキストファイルに書き出し、AIが常に参照できるようにする。

人間の暗黙知をゼロにすることが、AIの暴走を防ぐ第一歩だ。

そして最も重要なのが、決定論的な検証ゲートの構築だ。

テストコードの自動実行環境を整える。型チェックを厳格にする。

AIがコードを生成したら、即座に機械的な検証が走るワークフローを作る。

<!-- IMAGE_3 -->

非機能要件はAIに任せない。

ログの出力フォーマットや認証の仕組みは、フレームワーク側で強制する。

AIは「ビジネスロジックを埋めるだけ」の状態に持っていくのが理想だ。

しんたろー：
ThreadPostの開発でも、コアなロジックは全部テストで固めている。AIが変なコードを吐いてもテストが落ちるため一瞬で気づける。最後は昔ながらの堅牢な設計手法がものを言う。

AIエージェントの進化は速い。

昨日まで使えていたテクニックが、今日のアップデートで無意味になることもある。

特定のモデルやツールに依存しすぎるのはリスクだ。

AIツールの課金は年額ではなく月額を選ぶ。

品質低下や仕様変更が起きた時、すぐに別のツールに乗り換えられる機動力を残しておく。

数週間単位で状況が変わるこの領域で、1年先の前提を固定するのはリスクが高い。

AIは魔法の杖ではない。

強力だが不安定なエンジンだ。それを安全に乗りこなすための車体作りは、開発者の仕事だ。

ハーネスの設計に投資すること。それがAI時代に生き残るための解だ。

FAQ

Q1: AIエージェントが急に「バカになった」と感じた時、まず何をすべきですか？

A1: まずは自身のプロンプトや指示を疑う前に、セッションをクリアしてコンテキストをリセットしてください。次に、推論パラメータの変更やキャッシュのバグが公式から発表されていないか確認しましょう。根本的には、AIの出力に依存しすぎないよう、テストコードの自動実行や型チェックといった「決定論的な検証ゲート」をワークフローに組み込み、AIの出力が期待通りか機械的に判定できる仕組みを構築することが重要です。

Q2: 「ハーネス」を設計する上で、最も重要な要素は何ですか？

A2: 「責務の分離」です。セッション、ハーネス、サンドボックスを疎結合に保つことが重要です。開発者視点では、何をAIに判断させ、何を人間が判断し、何を決定論的に自動化するかを明確に線引きすることです。特に、非機能要件やセキュリティ、型安全性はAIに任せず、コードベース側に決定論的な制約として埋め込むのが成功の鍵です。

Q3: AIツールへの課金は年額と月額、どちらが良いですか？

A3: 月額をおすすめします。AI製品の品質や提供条件は数週間単位で激変します。今回のようにハーネス層の調整で突然品質が低下することもあります。年契約は12ヶ月分の前提を一括で固定する行為であり、変化が早い領域とは相性が悪いです。問題が起きた時にすぐ別のツールに乗り換えられるよう、機動力を残しておくべきです。

AIの賢さはモデルではなく、外枠のハーネス設計で決まる。

不確実なAIを使いこなすには、決定論的な検証ゲートによる多層防御しかない。

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