なぜ最新のAI開発でプロンプトに頼らないのか。Claude Codeで暴走を防ぎ外部システムで確実な制御を行う理由。

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

ThreadPostなら、投稿作成・画像生成・スケジュール管理まで全てAIにお任せ。

無料で始める

AIは「お願い」じゃ制御できない

プロンプトを磨けば磨くほど、壊れ方も派手になる。

これ、LLMを実業務に組み込もうとした人なら全員ぶつかる壁だ。「もっと正確に答えてください」と書いても、AIは自信満々に間違える。「必ず確認してから行動してください」と書いても、デモ中に勝手に待機モードに入る。

実際に動いている事例を3つ並べると、共通点が見えてくる。プロンプトに頼っていない。全員、外部システムで制御している。

月20時間の作業を1.8時間に。自動返信率91%。数字だけ見ると「すごいプロンプト書いたんだろうな」と思う。違う。アーキテクチャの話だ。

3つの実装事例から見えてくること

事例1：社内Slack botで商品企画を自動化

Google Cloud上にSlack botを構築し、商品企画業務を自動化した事例がある。

構成はこうだ。Cloud Run ServiceがSlackのイベントを受け取り、Cloud Run Jobに処理をオフロード。社内データはCloud SQLから直接叩かず、BigQuery経由でクエリする。Firestoreで重複排除。Google Sheetsに成果物を書き出す。

Slackには進捗をスレッドに逐次投稿し、最後に「使える」「修正すれば使える」「全然使えない」の3択ボタンを表示する。

コストは1回の実行で$0.15。

重要なのは設計思想だ。LLMに「ツールを選ばせる」Tool useは使っていない。 システム側がデータを取得し、その結果だけをLLMに渡す。LLMの仕事は「渡されたデータをもとに企画を考える」だけ。判断の範囲を徹底的に絞っている。

開発フローも面白い。最初はClaude Codeでプロトタイピング。担当者の「もっとメリハリをつけて」という感覚的なフィードバックを、Claude Codeに社内データを見せながら「この指標は○○%以下であるべき」という定量指標に変換した。暗黙知の言語化をAIにやらせた。

事例2：20名のAIエージェントチームで相互検証

マルチエージェント構成で「AIが自信満々に間違える」問題に正面から向き合った事例がある。

チーム構成は常駐コアメンバー4名＋専門チーム。常に参加するのはPM/チームリーダー、デビルズアドボケイト（DA）、ファクトチェッカー（FC）、シナリオマネージャー。

DAの役割が面白い。「成果物を受け取ったら必ず反論する義務を持つ」。AIの最大の弱点は迎合することだ。「いいですね！」と言ってしまう。DAはそれを構造的に防ぐ役割として設計されている。

FCは数値・日付・APIの仕様を検証する専門役だ。「2ヶ月の運用実績」と書かれた記述が、実際には「プロトタイプ開始から約3週間」だったというインシデントが実際に起きている。FCが検証して発見した。

そしてClaude CodeのHookシステムを使った強制実行の仕組みがある。「clear-instruction-guard.sh」というスクリプトが毎回自動チェックし、明確な指示があるのに待機状態に入ろうとしたら即座にリマインドを注入する。「お願い」ではなく「強制」。

事例3：Make.com × GPTで問い合わせ対応を90%自動化

月額$15〜20のツールコストで、月20時間の作業を1.8時間に削減した事例がある。

構成はシンプルだ。Make.comがGmailを監視し、GPT-4o-miniで問い合わせを分類。confidence（確信度）スコアが0.8以上なら自動返信、未満なら担当者にエスカレーション。全ログはGoogleスプレッドシートに記録。

GPTへの指示はJSON形式で出力させる。「category」「confidence」「can_auto_reply」「suggested_reply」「escalation_reason」の5フィールド。AIに自然言語で答えさせず、構造化データを吐かせてシステムが判断する。

3ヶ月後の自動返信率は91%。平均返信速度は3〜24時間から3分以内に。ROIは約2,000%。

しんたろー：
3つの事例を並べて最初に思ったのは「全員LLMを"関数"として使ってる」ってこと。
AIに考えさせる範囲を絞って、フローの制御は外部システムに任せてる。
Claude Codeで毎日コード書いてる身からすると、これは設計の話であってプロンプトの話じゃないんだよな。

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

「プロンプトで解決しようとするな」という共通メッセージ

3つの事例に共通しているのは、AIの弱点をプロンプトで補おうとしていない点だ。

AIの弱点は3つある。

ハルシネーション — 自信を持って間違える
迎合 — 「いいですね！」と言ってしまう
暴走・停止 — 指示があっても勝手に待機モードに入る

これをプロンプトで解決しようとすると、どうなるか。「必ず正確に答えてください」「確認してから行動してください」「反論があれば言ってください」。書けば書くほど、プロンプトが長くなり、トークンが増え、かえって挙動が不安定になる。

3つの事例が採用したアプローチはこうだ。

事例1（Slack bot）： LLMの役割を「渡されたデータをもとに企画を考える」だけに限定。データ取得・書き込み・フロー制御はすべてシステム側。Tool useを排除することでLLMの判断ミスを防ぐ。

事例2（マルチエージェント）： 「反論役」「検証役」を別のエージェントとして独立させる。1つのLLMに「正確に答えて、かつ自分を批判して」とプロンプトで頼むのではなく、役割を持つ別のエージェントに構造的にやらせる。

事例3（Make.com）： LLMにconfidenceスコアを出力させ、0.8未満は自動的に人間にエスカレーション。「わからないときは正直に言ってください」とプロンプトで頼むのではなく、システムが強制的に止める。

この3つのアプローチは、要件の複雑さで使い分けられる。

直線的・定型的なタスク → 事例1のように役割を絞り、外部システムで制御
複雑な意思決定が必要なタスク → 事例2のようにマルチエージェントで相互検証
コストと速度を優先したい場合 → 事例3のようにconfidenceスコアで人間とAIを振り分け

ただし、事例1と事例2の間には明確な矛盾がある。事例1は「分岐やリトライがないためエージェントフレームワークは不要」と判断してシンプルさを選んだ。事例2は「複雑なタスクのために複数エージェントによる議論と検証」を重視してあえて複雑な設計を選んだ。

どちらが正しいかではなく、タスクの性質に合わせて選ぶ。 これが答えだ。

もう一つ面白い共通点がある。Claude Codeの使われ方だ。

事例1ではプロトタイピングと暗黙知の言語化に使っている。担当者の感覚的なフィードバックを定量指標に変換するという、コーディング以外の用途だ。事例2ではHookシステムでエージェントの暴走を防ぐ基盤として使っている。

Claude Codeは「コードを書くツール」だと思われがちだが、業務ロジックの設計やエージェントシステムの制御基盤としても機能する。

しんたろー：
事例2のHookシステムの話、これは地味にデカいと思う。
「AIが勝手に待機モードに入る」問題、Claude Codeで長いタスクを回してると普通に起きる。
プロンプトで「止まるな」と書くより、Hookで強制的にリマインドを注入する方が確実なんだよな。
うちの構成でも似たような問題が出そうで、ちょっと設計を見直したくなってきた。

ここまで読んだあなたに

今なら無料で全機能をお試しいただけます。設定後は完全放置でプロ品質の投稿を毎日生成。

無料で始める

実際に設計するときに知っておくべきこと

LLMをどこに置くかを最初に決める

「LLMに何をやらせるか」ではなく「LLMに何をやらせないか」を最初に決める。

事例1の設計が参考になる。データ取得・フロー制御・書き込みはすべてシステム側。LLMは「渡されたデータをもとにテキストを生成する」だけ。この境界線を引くだけで、デバッグが劇的に楽になる。

LLMが関与する範囲を絞れば、問題が起きたときに「LLMの問題か、システムの問題か」がすぐわかる。

Tool useを使うかどうかの判断基準

毎回決まった手順でデータを取得・書き込みするなら、Tool useは使わない方がいい。

理由は3つ。

トークン消費 — ツール定義のたびにトークンが増える
判断ミスのリスク — LLMがどのツールを使うか間違える可能性がある
デバッグの難しさ — LLMの判断が介在すると原因特定が難しい

一方、状況に応じて動的にツールを選択する必要がある複雑なタスクでは、Tool useが有効だ。判断基準は「LLMに選ばせる必要があるか」。ない場合はシステム側で固定する。

confidenceスコアの設計

事例3で使われているconfidenceスコアの仕組みは、どんなLLM活用でも応用できる。

GPTへの指示にconfidenceフィールド（0.0〜1.0）を含めるだけだ。閾値は0.8から始めて、ログを見ながら調整する。閾値を下げると自動化率が上がり、上げると精度が上がる。 このトレードオフをログで可視化できるのが強みだ。

注意点がある。confidenceスコアはLLMが「自己申告」する数値なので、完全に信頼するのは危険だ。事例2のファクトチェッカーのような別の検証レイヤーと組み合わせるのが理想的だ。

インフラ選定：ノーコードかスクラッチか

判断軸はセキュリティ要件だ。

一般的なSaaS間の連携（Gmail、Slack、Googleスプレッドシート） → Make.comで十分。月額$15〜20で動く
社内のセキュアなデータベースへのアクセスが必要 → Cloud Runなどスクラッチ開発が必要
独自の複雑なビジネスロジック → スクラッチ一択

事例3のROI2,000%という数字は、ノーコードで解決できる問題をノーコードで解決したから出た数字だ。スクラッチで同じことをやっても、開発コストでROIが下がる。

エージェントが「止まる」問題への対処

事例2で起きた「チーム待機状態です。指示をお待ちしています」問題。明確な指示を出したのに待機モードに入った。しかもデモ中に。

これはプロンプトで「止まるな」と書いても解決しない。Claude CodeのHookシステムで強制的にリマインドを注入するのが確実だ。

同じ思想が事例1のアーキテクチャにも流れている。Slackの3秒制限の問題も、「3秒以内に返信する」という制約をプロンプトで解決しようとせず、Cloud Run JobへのオフロードというアーキテクチャレベルのHackで解決している。

しんたろー：
「プロンプトで解決しようとするな」って、言葉にすると当たり前に聞こえるんだけど、
実際に開発してるとついプロンプトを足したくなる。
「もっと丁寧に確認してください」「間違えたらやり直してください」って。
でも結局、それって制御をLLMに委ねてるんだよな。
アーキテクチャで制御する、という発想に切り替えるのが一番の改善だった。

よくある質問

Q1. LLMに外部ツールを使わせる（Tool use）べきか、通常の関数呼び出しで処理すべきか？

タスクの性質で決まる。毎回決まった手順でデータ取得や書き込みを行う直線的なパイプラインなら、Tool useを使わずシステム側で通常の関数としてデータを用意し、その結果だけをLLMに渡す設計が推奨だ。これにより、毎回のツール定義や往復によるトークン消費を抑えられ、LLMの判断ミスも防げる。デバッグも格段に楽になる。一方、状況に応じて動的にツールを選択・実行する必要がある複雑なタスクではTool useが適している。判断基準は「LLMに選ばせる必要があるか」。ない場合はシステム側で固定する。

Q2. AIが間違った回答や不適切な対応をするリスクをどう防げばよいか？

AI単体のプロンプトで完璧を求めず、システム的なセーフティネットをアーキテクチャに組み込むことが重要だ。アプローチは大きく2つある。1つは、LLMに回答の「確信度（confidenceスコア）」を0.0〜1.0で出力させ、閾値（例：0.8）未満の場合は自動処理を停止して人間にエスカレーションする仕組みだ。もう1つは、「ファクトチェッカー」や「デビルズアドボケイト（反論役）」という役割を持つ別のAIエージェントを配置し、生成された回答を相互検証させる仕組みだ。前者はシンプルで低コスト。後者は複雑なタスクに向いているがトークンコストが増える。用途の複雑さに応じて使い分けてほしい。

Q3. ノーコードツール（Make.comなど）とスクラッチ開発（Cloud Runなど）はどのように使い分けるべきか？

連携するシステムのセキュリティ要件によって決まる。GmailやGoogleスプレッドシート、Slackなど一般的なSaaS間の連携で完結する定型業務なら、Make.comなどのノーコードツールで月額$15〜20程度で構築・運用できる。一方、社内のセキュアなデータベース（Cloud SQLやBigQueryなど）に直接アクセスしてデータを取得・加工する必要がある場合や、独自の複雑なビジネスロジックを組み込む場合はCloud Runなどを使ったスクラッチ開発が必要になる。ノーコードで解決できる問題をノーコードで解決するのが最もROIが高い。スクラッチ開発は「ノーコードでは無理」と判断してから選ぶ。