Claude CodeでAIエージェントを構築する際に技術的負債を防ぐ判断と実行の分離設計

AIに要件を投げれば数分で動くものができる。この体験は中毒性が高い。設計をAI任せにすると、後から修正不可能な技術的負債が積み上がる。

Claude Codeで開発を加速させる中で「このままでは詰む」と直感する瞬間がある。AIの「知的な判断」と、システムの「機械的な実行」を明確に切り分ける。

この記事では、AIエージェントの自律性と安全性を両立させるための「判断と実行の分離設計」と、OpenTelemetryを活用した監査体制について解説する。AIを真のパートナーにするための設計思想を共有する。

SNS運用を自動化しませんか？

ThreadPostなら、投稿作成・画像生成・スケジュール管理までAIがサポート。

無料で始める

AIエージェントの自律化と「判断のブラックボックス化」という課題

AIエージェントの運用現場では、LLMにツール実行までを丸投げする「全自動化」から、決定論的なコードと確率的な推論を分離する「判断と実行の分離」へと設計思想がシフトしている。

これまで多くの開発者が採用してきた構成は、LLMにツールを与え、状況を渡して、あとは実行まで任せるものだった。この構成を常時稼働するシステムに適用すると、3つの問題が浮き彫りになる。

第一に「挙動の予測不能性」である。LLMは確率的に動作する。テスト環境で問題なくとも、本番環境で予期せぬツール呼び出しが発生する。

第二に「事後追跡の困難さ」である。ツール呼び出しのログは残る。しかし「なぜそのツールを選んだのか」という推論プロセスがブラックボックス化しているため、事故発生時に原因を特定できない。

第三に「安全性の不確実性」である。プロンプトで「削除するな」と指示しても、それはシステム上の保証にはならない。指示が複雑になるほど、制約が守られる確率は低下する。

こうした課題に対し、最新のAI開発現場では「身体」と「頭脳」を分離するアプローチが注目されている。「頭脳」であるLLMは、外部への書き込み権限を持たない。LLMは「こうしたい」という構造化データ（アクション）を出力するだけに留める。その出力は、決定論的に動作する「身体（executor）」へと渡され、ゲートを通過したものだけが実行される。

しんたろー：
LLMに「削除しないで」とプロンプトを書いても、いつか必ずやらかす。実行側のコードで「その操作は許可されていません」とガードレールを作るのが、一番精神衛生上いい。

さらに、このプロセスを可視化するための技術として、OpenTelemetryの活用が進んでいる。Claude Codeなどのツールが備えるOpenTelemetry対応により、プロンプトIDを軸にした「どのプロンプトが、どのツールコールを呼び出し、どんなAPIリクエストに至ったか」というチェーン全体を外部から観測できる。

これにより、開発者は「AIがどの程度自律的に働いているか」を指標で捉えることが可能となる。AIが処理している時間とユーザーのタイピング時間を比較した「AI依存度」のような指標を算出することで、AIが実務の自動化に貢献しているかを定量的に評価できる環境が整いつつある。

「動くもの」を素早く作るフェーズから、「安全に運用し続けるための構造」を作るフェーズへ。AIエージェント開発は今、この転換点にある。

身体と頭脳を切り離す設計思想

AIエージェントの運用において、最も危険なのは「LLMに実行権限を丸投げする」ことである。多くの開発者がやりがちな「状況を渡して、ツールを持たせて、あとは任せる」という構成は、プロトタイプならいい。常時稼働させるシステムでは、この甘さが技術的負債として牙を剥く。

AIの出力はあくまで「確率的な推論」である。AIに「削除するな」とプロンプトで指示しても、それはただの「お願い」に過ぎない。長期間運用すれば、指示が無視される瞬間は必ず訪れる。

だからこそ、決定論的に動く「身体」と、確率的に判断する「頭脳」を分離する設計が不可欠である。頭脳であるLLMには、外部への書き込み権限を与えない。LLMの出力は、あらかじめ定義された語彙のみで構成される構造化データに限定する。このデータを受け取り、バリデーションを行い、実行の可否を判断する「ゲート」をコードとして書き込む。

この設計なら、AIが何をしようとしたか、なぜその判断に至ったかというプロセスが、ログとして残る。「なぜそのツールを選んだか」というブラックボックス問題は、LLMの推論プロセスをOpenTelemetryでトレースし、決定論的な実行ログと紐付けることで可視化される。

しんたろー：
AIに全部投げたくなる気持ちはわかる。でも、お金や顧客データが絡む処理で「AIが勝手にやった」は許されない。ゲートを設けるコードを書くのが一番の近道だ。

AIエージェントの運用における最大の罠は、LLMの利便性を享受しつつ、いかにして「制御不能な暴走」を防ぐかという点にある。「自律境界」をコードで明示的に定義することが、両者の折衷点になる。読み取りや調査は自律的に行わせ、外部への送信や削除、金銭が絡むアクションにはコードレベルで「承認ゲート」を挟む。設定ファイルではなく、コード自体にこの境界を書き込むことで、運用中に安易にルールが緩められるリスクを排除できる。

また、AIにコードを生成させる際、「設計の根幹」までAI任せにしない。局所的な実装はAIに任せても、トランザクション管理やデータベース設計といった、システム全体の整合性に直結する部分は人間が主導する。AIは「指示された処理を実装する」のは得意だが、設計の意図や将来的な拡張性までは考慮しない。

設計を捨ててAIに実装を全投げすると、ファイルごとに数値をベタ書きしたり、同じロジックがタブごとにバラバラに実装されたりというカオスが生まれる。最初は半月で動くものができるが、その後の修正コストは、設計を丁寧に行った場合の何倍にも膨れ上がる。これこそが技術的負債の正体である。

AIを賢く使うためには、AIが生成したコードや判断を「監査する仕組み」をインフラとして組み込む必要がある。OpenTelemetryを活用して、AIの呼び出しチェーンを可視化し、エラー分布を収集する。特定のツール判定が頻繁に失敗するなら、それはプロンプトのせいではなく、用意したアクションの定義が曖昧である可能性が高い。

AIの利用を単なる「効率化」で終わらせず、AIの挙動を構造的に制御可能なシステムへと昇華させる。これこそが、開発者がこれからのAIエージェント時代を生き抜くための戦略である。

ここまで読んだあなたに

今なら無料で全機能をお試しいただけます。設定後はAIが投稿案を毎日生成。確認して選ぶだけ。

無料で始める

明日から導入できるAIエージェント運用のステップ

AIエージェントを「とりあえず動かしてみる」段階から「実務で使い倒す」段階へ移行するなら、明日からやるべきことは明確である。まずはAIに実行権限を渡すのをやめ、判断と実行を物理的に分離する設計へ舵を切る。具体的には、AIの出力を「実行命令」ではなく「構造化されたアクションの提案」として受け取るインターフェースを間に挟む。

次に、その提案を検証する「ゲート」をコード内に実装する。AIが何をしようとしているのか、そのアクションは許可リストに含まれているか、機微な操作ではないかをプログラム側で判定する。このゲートを通らない限り、外部DBへの書き込みやAPIリクエストは一切実行させない。たとえAIがプロンプトで「これは安全です」と主張しても、無視してコードのルールを優先させるのが鉄則である。

しんたろー：
AIを信用しすぎないのが一番の最適化だ。ゲートを通す手間は増えるが、後からデバッグで徹夜するよりは100倍マシ。Claude Codeでツールを使うときも、まずは「何を投げたか」をログで追える状態から始めている。

並行して、OpenTelemetryによる観測体制を構築する。AIがどのプロンプトに対して、どのツールを呼び出し、どう失敗したのかを時系列でトレースできるようにしておく。「なぜAIがそのツールを選んだか」というプロセスを可視化できれば、プロンプトの調整も勘に頼る必要はなくなる。失敗したログを集計し、パースエラーが多いのか、未知のアクションを要求しているのかを数字で分析する。

この「観測」の仕組みは、AIのガバナンスにも直結する。組織でAIを活用するなら、誰がどのモデルを使って、どんな処理を自動化しているかを可視化しなければ、いずれ監査で詰むことになる。トークン消費量やAI依存度といったメトリクスをダッシュボードで眺めつつ、AIが「開発のパートナー」として正しく機能しているかを確認し続ける。

最後に、設計の根幹は人間が握り続けること。データベースのスキーマ設計やトランザクションの境界、システムの拡張性に関わる部分は、AIに提案はさせても、最終決定は必ず人間が行う。AIに実装を全投げするのではなく、あくまで「設計に基づいたコード生成」という役割に限定する。この線引きさえ守れば、AIは技術的負債を増やす爆弾ではなく、開発速度を加速させる武器になる。

今の開発環境に「AIの挙動を監査するゲート」があるか。ログを見て、AIがなぜその判断を下したか説明できるか。まずはここから確認する。

よくある質問

AIエージェントの運用で最も避けるべきことは？

LLMにデータベースへの書き込みや外部APIの操作といった「実行権限」を無制限に与えることです。LLMは確率的に動作するため、プロンプトで「削除はするな」と指示しても、長期的には必ず制約を破る事故が発生します。必ず実行側のコードで「許可リスト」や「承認ゲート」を設け、AIの出力が安全な範囲内であるかを決定論的に検証する仕組みを構築してください。

AIによる技術的負債をどう防げばいい？

データベース設計やトランザクション管理などの「システムの根幹」までAI任せにしないことです。AIは局所的な機能実装は得意ですが、アプリケーション全体の拡張性や整合性を考慮してコードを書くことはできません。重要な設計判断は人間が主導し、AIにはその設計に基づいた個別のコード生成をさせるという役割分担を徹底することが、負債を最小限に抑えるコツです。

AIの利用状況を可視化するメリットは？

AIがどのツールを呼び出し、どのような推論プロセスを経て結果を出したかを追跡できるため、エラー発生時の原因究明が圧倒的に早くなります。また、「AI依存度」のような指標を計測することで、AIが単なるコード生成機として機能しているのか、それとも開発効率を向上させるパートナーになっているのかを定量的に評価でき、組織的なガバナンス強化にも直結します。