Claude Codeで開発を全自動化しない理由。AIエージェントの権限設計と人間介入が成功の鍵

「AIに開発を全自動化させて、自分は寝ている間にプロダクトを完成させる」。そんな夢を見て、Claude Codeにすべてを委ねた結果、待っていたのは「指示出しで消耗する毎日」でした。

AIエージェントの性能が上がるほど、僕らは「何をさせるか」ではなく「何をさせないか」という権限設計に直面します。プロダクト開発を成功させる鍵は、AIを賢くすることではなく、人間が介入する「安全装置」をどこに置くかというアーキテクチャにあります。

この記事では、AIエージェントの失敗から学んだ「人間とAIの責任分界点」の設計思想と、Claude Codeを開発パートナーに変えるためのアプローチを共有します。

AIエージェント開発における「全自動化」の幻想と現実

AIエージェントを活用した開発現場で、ある共通した行き詰まりが報告されています。AIに開発フローのすべてを委ねようとして、指示出しのコストが爆発し、AIの金銭的コストも上限に達する事態です。

ある開発者の事例では、103回のコミットのうち、機能追加は14件にとどまり、残りの大部分が差し戻しや失敗の記録という結果でした。AIは指示通りに動きますが、「ダッシュボードを簡素にする」「実装都合の情報を表示しない」といった、人間が暗黙的に理解する前提を網羅的に指示書へ書き込まなければ、期待通りの成果物は得られません。

この指示書作成に費やす時間は、AIによる実装時間の短縮分を超えます。軽量モデルと上位モデルを使い分ける戦略をとっても、手順書の重さがモデルの切り替えと連動していないため、単純なバグ修正でも4つのフェーズにわたる重厚な手順書を読み込ませることになり、トークン消費とコストの増大を招きます。

一方で、別の現場では、チームメンバーが本番ログとコードを安全に調査できる仕組みとして、AIエージェントが機能しています。ここでは、roles/logging.viewerなどのIAMロールで権限を厳格に制限し、さらにPreToolUse Hookを活用して、許可されたgcloudコマンド以外を強制的に遮断するガードレールを構築しています。これにより、エンジニアを待たずに初動を切り分けられる体制が整いました。

これらの事例が示すのは、AIエージェントの運用において「どこまで任せるか」という判断は、モデルの性能ではなく「失敗した際のリスク」で決まるという事実です。決済やデータ更新のような不可逆な操作は人間が承認し、ログ調査のような読み取り作業は権限を絞って自動化します。この「Human-in-the-loop」の設計が、開発効率と安全性を両立させます。

しんたろー：
「AIに全部任せて楽したい」という気持ちは理解できます。結局、指示書のメンテに追われる「AIの管理職」になって消耗するのがオチです。僕もClaude CodeでThreadPostを開発する際、権限を絞って「ここから先は人間がやる」というラインを引いてからの方が、エージェントの迷いが減ったと感じます。

AIエージェントを導入するプロジェクトでは、3つのパターンが標準的な設計として認識されています。

1. 人間による承認型: AIが処理を行い、人間が最終確認・承認した後に実行する（実行リスクが高い業務向け）。
2. 例外エスカレーション型: 通常は自動化し、一定の条件を満たした場合のみ人間に判断を仰ぐ（コストと安全性のバランス重視）。
3. 事後確認型: 自動実行後に人間が成果物をレビューする（品質重視）。

AIエージェントは「判断を代替する存在」ではなく、「判断を補助する存在」として位置づけます。技術的な全自動化は可能でも、その結果に対する責任をAIが負うことはできません。責任の所在を明確にし、人間が制御し続けるためのアーキテクチャを設計します。

あわせて読みたいAIエージェントを自作して本番運用する方法｜最小構成の実装とサブエージェント設計 →

AIエージェントの権限設計と手順の標準化

AIエージェントを「全自動で動く魔法の箱」と捉えるか、「手順を厳格に管理された実行ユニット」と捉えるかで、開発の難易度は変わります。Claude CodeでThreadPostを開発していて痛感するのは、エージェントに「いい感じにやって」と丸投げした瞬間に、コストと品質が崩壊するという事実です。モデルの能力に依存した全自動化は、実務においては指示コストの増大を招きます。

成功しているエージェント開発において共通しているのは、タスクの性質に合わせて「調査手順」と「実行権限」を徹底的に分離している点です。特に、新規開発と保守運用では求められる前提知識が異なります。新規プロダクトでは前提の塊を読み込ませる必要がありますが、バグ修正に同じ重い手順書を適用すれば、エージェントは過剰な処理を行い、トークンを浪費します。

ここで有効なのが、開発フローの分岐を「タスクの性質」で切り分けるアーキテクチャです。全セッションで共通のファイルを読み込ませるのではなく、スキル単位で必要な前提条件を動的に注入する設計へ移行します。例えば、バグ修正なら「再現手順の特定」に特化したスキルを、新規機能開発なら「要件の網羅的整理」に特化したスキルを読み込ませます。この粒度で役割を分けることで、上位モデルと軽量モデルの使い分けが機能します。

しんたろー：
AGENTS.mdに全てを詰め込むのは、巨大な技術負債を作っているのと同じです。Claude CodeのPreToolUse Hookでコマンドを制限したとき、ようやく「AIに何をさせないか」を決めるのが設計だと気づきました。

さらに重要なのが、AIの実行権限をモデルのプロンプトだけで制御しようとしないことです。プロンプトに「書き込まないで」と書くのは、セキュリティの観点では不十分です。システムレベルでの権限設計、具体的にはIAMロールによる最小権限の付与と、実行直前のフックによるコマンドフィルタリングを組み合わせることが、安全な自動化の条件です。

特に調査業務をAIに任せる場合、ログの閲覧権限とコードの読み取り権限を適切に分離し、Skill化された手順以外は実行させない仕組みが不可欠です。これにより、バックエンドに不慣れなメンバーでも、エンジニアを待たずに初動の切り分けが可能になります。ここで重要なのは、AIが「何ができるか」よりも「どの手順を踏めば安全に結論を出せるか」という手順の標準化です。

AIエージェントの設計とは、AIの推論能力をどこまで信じ、どこからを人間が制御すべきかという「境界線の引き方」そのものです。単一機能の修正のような前提が少ないタスクは軽量モデルに任せ、リスクの高い決済処理やデータ更新は人間が承認するHuman-in-the-loop構造を組み込みます。このタスクの性質に応じた動的な権限管理と手順の切り替えが、AIを「責任ある開発パートナー」へと昇華させます。

AIエージェントが自律的に動くほど、指示を出す側の人間は「何を指示するか」ではなく「どのような手順と権限を与えれば、AIが迷わずに正しい結果を出せるか」というアーキテクト的な視点が求められます。AIを「優秀な部下」として扱うのではなく、厳格で融通の利かない「実行エンジン」として扱い、そのエンジンが安全かつ効率的に動作するためのレールを敷きます。

開発現場に持ち込むべき「ガードレール」の設計思想

AIエージェントを実務に組み込む際、最も避けるべきは「AIに全権限を委譲して、あとは結果を待つ」という思考停止です。実務においてAIを導入するということは、単に自動化スクリプトを増やすことではなく、開発プロセスそのものに「制御可能な境界線」を引くことです。明日からの開発で意識すべきアクションは、大きく分けて2つあります。

一つは、権限の「最小化」と「可視化」です。AIエージェントに本番環境のログ調査やコード修正を許可する場合、IAMロールで読み取り専用にするのは当然として、Claude CodeのようなCLIツール側でも実行可能なコマンドをホワイトリスト化する必要があります。`PreToolUse Hook`を活用し、特定のサブコマンド以外は実行前に拒否する仕組みを強制的に組み込みます。これを行えば、万が一AIがハルシネーションを起こして危険な操作を試みても、システム側で物理的にブロックできます。

もう一つは、タスクの性質に応じた「手順のモジュール化」です。すべてのタスクに共通の「AGENTS.md」を読み込ませる手法は、初期段階では便利ですが、開発規模が拡大するにつれ、指示コストとトークン消費の増大という副作用を生みます。バグ修正、新規機能開発、調査業務といったタスクごとに必要な前提条件や手順を切り分け、「必要な時だけスキルを読み込ませる」アーキテクチャへの移行が不可欠です。

しんたろー：
以前は全部入りプロンプトを書いていましたが、AIが迷走して修正コストが跳ね上がりました。今はバグ修正用の小さなSkillをいくつか用意して、状況に応じて叩くスタイルです。AIに渡す「文脈の量」を絞り込むのが、一番の節約術です。

また、Human-in-the-loopの設計も、単に「最後は人が承認する」という運用ルールを作るだけでは不十分です。重要なのは、「どこまでをAIに任せ、どこから先は絶対に人間が介入すべきか」という基準を、技術的に分離することです。例えば、データの集計やエラーログの一次切り分けまではAIに完結させ、最終的なDB更新や外部APIへのリクエスト実行は、人間がUI上で「承認」ボタンを押さない限り動かないように設計します。この「実行の分断」こそが、AIを怖がらずに実務で使い倒すための解です。

これらの設計は、最初は手間がかかるように感じます。しかし、一度「安全なレール」を敷いてしまえば、AIは定型的な調査やテストコードの作成をこなします。開発者がやるべきことは、AIが暴走しないような環境構築と、彼らが導き出した結論に対して「責任を持つ」という最後の意思決定だけです。AIエージェントを「優秀だが指示待ちの部下」として扱うのではなく、「厳格なルールで動く実行エンジン」として管理する。この視点に切り替えた瞬間、開発スピードは一段階上がります。

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

よくある質問

AIエージェントにどこまで権限を渡すべきですか？

技術的な実行能力ではなく、「失敗した際のリスク」で権限を切り分けるのが鉄則です。読み取り専用のログ調査やコードの静的解析などは権限を絞った上で自動化しても安全ですが、決済処理や本番DBの更新など、一度実行すると回復が困難な操作は、必ず人間が最終承認を行う「承認プロセス」を組み込んでください。権限管理にはTerraform等のIaCツールを活用し、最小権限の原則を徹底することが、AIエージェントを安全に運用するための前提条件です。

AIへの指示が長すぎて、APIコストとトークン消費が激しいです

それは「手順書が重すぎる」のが原因です。すべてのタスクに共通のプロンプトを読み込ませるのではなく、タスクの性質（新規開発、バグ修正、調査）ごとにスキルを分割し、必要な時だけ呼び出す設計に変えてください。AIに「網羅的に書け」と指示しすぎるのもコストの無駄です。タスクの文脈に合わせて、その瞬間に必要な前提条件だけを動的に注入する仕組みを構築しましょう。

複数のエージェントを連携させると、指示していない要件まで追加されてしまいます

これはAIが「網羅性」を優先して過剰に働いている証拠です。解決策は、要件定義と実装のフェーズを明確に分離することです。特に新規開発では「要件を確定させてから設計しろ」と制約をかけ、バグ修正では「スコープを広げるな」と指示するだけで挙動は変わります。AGENTS.mdのような共通設定ファイルで開発フローの分岐まで管理しようとせず、タスクの性質に応じて読み込むスキルを切り替えるアーキテクチャへの移行を推奨します。

まとめ

AIエージェントを「ただの自動化ツール」として放置するのは、ブレーキのない車を公道に出すようなものです。開発者に求められているのは、モデルの性能を追いかけることではなく、リスクに応じた「人間介入の設計」と、タスクの性質に合わせた「権限とスキルの切り替え」です。

Claude Codeで効率を最大化しつつ、守るべき境界線を引きます。この「制御しながら使う」という設計思想こそが、AIを単なる実験道具から、本気で開発を加速させるパートナーへと昇華させる鍵になります。

あなたのプロジェクトにも、今日からそんな「責任ある自動化」の仕組みを取り入れてみてください。

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