失敗 1: 目標を十分に明確に説明しないこと

「LinkedIn 用のリードスクリパーが必要です。」

この一文を Claude Code に投げかけた場合、どのようなことが起こるのか見てみましょう。エージェントはどの業界のリードを求めているのか、どの役職をターゲットにしているのかを知りません。結局、無作為なプロフィールを収集し始めます。時間とモデルの計算リソースを無駄にし、使い物にならない Excel ファイルが残るだけです。

前章で 622 件の求人広告をウェブスクレイピングした際を思い出してみましょう。計画モードで URL を提供し、ページ数を伝え、必要なフィールドを説明しました。そうすると Claude Code が返してきたのは具体的な質問でした。個別の詳細ページまでスクレイピングするのか、保存先はどこか、フィルタ条件はあるのか。これらの質問に答えた後で、エージェントは実行計画を策定しました。

曖昧さが生む連鎖反応

目標が曖昧であれば、エージェントの各判断が不確実なものになります。「リードスクリパー」とだけ指示した場合、エージェントは以下のような判断を独自に行わなければなりません。

これらの質問のうち一つでも誤った判断を下せば、全体の結果は誤ったものになります。エージェントが質問を投げかけることも可能ですが、それは計画モードにおいて十分な文脈が提供された場合に限った話です。バイパスパーミッションモードで曖昧な指示を出せば、エージェントは自身で推測して進めてしまいます。

明確な目標設定の公式

優れた目標設定には一定のパターンがあります。

曖昧な依頼：

明確な指示:

違いが明確です。後者には、対象（技術企業のCEO）、数量（75件）、必要なデータ（氏名、会社名、メールアドレス、プロフィールリンク）、出力形式（スプレッドシート）、完了条件（75件達成）がすべて含まれています。

[図18-1] 曖昧な指示と明確な指示の結果の比較

エージェントを専門家として扱おう

ここで重要な視点の転換が必要です。エージェントは指示を機械的に実行する道具ではありません。専門家です。ユーザーは管理者（マネージャー）の役割を担い、技術的な詳細はエージェントに委譲します。

実際のソフトウェア開発者にアプリ制作を依頼すると想像してみましょう。「アプリを一つ作ってください」とだけ伝えると、開発者も困ってしまいます。どのような機能が必要で、誰が使用するのか、締切はいつかなどの情報が必要です。エージェントも同様です。

ただし、すべての技術的詳細を知る必要はありません。「このような結果を望んでいますが、どのようなアプローチが適切でしょうか」と尋ねれば、エージェントは Opus 4.5 などの推論モデルの能力を用いて五つのアプローチを比較し、最適なものを選定してくれます。

失敗 2: 「完了」の基準を定義しないこと

最初の失敗が「何を」に関するものであれば、二つ目の失敗は「いつ止めるか」に関するものです。

エージェントに明確な終了地点を与えないと、三つの問題が発生します。過度な複雑化、不必要な反復、そして尽きることのないリサーチです。エージェントはより良い結果を生み出せると判断すれば、試行を続けます。これは強みであると同時に弱みでもあります。

無限ループの危険

歯科医リードのウェブ情報収集事例を振り返りましょう。「アメリカの歯科医を探して連絡先をまとめてください」という指示のみを出しました。もしエージェントが120件収集した後も「さらに収集できる」と判断したらどうなるでしょうか。新しい都市を追加し、新しいデータソースを探り、ウェブ情報収集ツールを改善し続けることで、止まらなくなる可能性があります。

コンテキストは枯渇し、モデルが生成するテキストの費用は膨らみ、望む結果は得られません。

完了条件の設計

完了条件は、定量的基準と定性的基準の2つの軸で構成されます。

定量的基準の例:

定性的基準の例:

欧州営業職のウェブ情報収集事例において、この原則が機能する様子を確認しました。「500件」という目標を提示した際、エージェントが欧州で52件しか発見できなかった場合でも、完了条件が明確であったため、自ら代替案を提示しました。これは、目標に対する現在の状態の乖離をエージェントが自ら認識した結果です。

[図18-2] 完了条件ありのワークフローとなしのワークフローの実行経路比較

プロジェクト要件文書（要件文書）をエージェントと共につくる

2 つの失敗に対する解決策は 1 つに収束します。プロジェクト要件文書（要件文書、Project Requirements Document）をエージェントと共に作成することです。

要件文書の共同作成の実践プロセス

計画モードをオンにし、こう伝えてください。

この依頼を受けたエージェントは、3 つの段階を経て処理を行います。

第 1 段階：ブレインストーミングとリサーチ エージェントは、説明された目標に基づき、関連する API、MCP 接続サーバー、データソースを調査します。ウェブ検索を実行することもあります。YouTube 分析ワークフローを設計する際、エージェントが YouTube データ API と MCP 接続サーバーを比較検討したのが、この段階に該当します。

2 段階目：質問と回答エージェントは、一度に複数の質問を投げかけます。「どのチャネルを追跡するか」「どのくらいの頻度で報告書を受け取りたいか」「データをスプレッドシートにも記録するか」「報告書をどのメールアドレスに送信するか」といった質問です。これらの質問は、要件定義書の空欄を埋める役割を果たします。

3 段階目：計画立案の質問と回答が終了すると、エージェントは包括的な実行計画を提示します。ここでは、目標、ワークフローの構造、必要なツールのリスト、入力値、出力値、エッジケースへの対処方法がすべて含まれます。

ワークフロー文書の構造

完成したワークフロー文書を確認すると、その構造はそのまま要件定義書となっています。

この文書が存在するため、次回同じワークフローを実行する際にも、エージェントは一貫した結果を生み出します。文書がなければ毎回異なるアプローチとなり、結果の品質がばらついてしまいます。

[図 18-3] 要件定義書に基づくワークフロー文書の実際の例

エージェントワークフローの3つの利点：自動デバッグ、制御、自己学習

ミスを避ける方法についてお話ししたので、今度はエージェントワークフローが従来の自動化手法と比べて本質的に異なる点を3つの観点からご紹介します。

自動デバッグ：もはやログを読む必要はありません

従来のワークフロー自動化の日常とは、何かを作り、実行し、予期せぬエッジケースでシステムが停止するものでした。その後、ログを開き、エラーメッセージを分析し、実行データを一つずつ追跡して原因を特定する必要がありました。すると、あっという間に1時間が過ぎてしまいます。

エージェントのワークフローでは、このプロセスが自動化されます。前章で、歯科医のリード情報を収集するウェブツールが2件しか抽出できなかった場面を覚えておられるでしょう。エージェントは「パースパターンに問題がある」と自ら診断し、正規表現を修正し、ツールファイルをアップデートして再実行しました。人の介入なしに、これらすべてが完了しました。

これは自己修復（自らを修復する）という特性です。実務上、これは大きな意味を持ちます。右側のモニターでエージェントがワークフローを構築している間、左側のモニターで他の業務を行うことができるのです。時々確認して方向性を示すだけで十分です。AIは非決定性（ノン・デターミニスティック）であるため、経路から外れることもありますが、ほとんどのエラーは自ら修復します。

言葉による制御：ノードを学ぶ必要はありません

n8nのようなツールでは、各ノードが何をするのか、いつ使用すべきか、パラメータや設定値が何を意味するのかを学習する必要がありました。APIに接続するには、ドキュメントを読み、エンドポイントを見つけ、JSON構造を正しく設定し、認証方式を理解しなければなりませんでした。参入障壁は高かったのです。

エージェントのワークフローでは、望むものを自然言語で説明するだけです。エージェントは利用可能なツールを検証し、MCP接続サーバーがあるか確認し、必要であればAPIドキュメントを自ら調査します。「ヨーロッパの営業職のウェブ情報を収集してください」という一言が、ウェブ情報収集ツールの選択、フィルタリングロジックの実装、Excel出力形式の決定をすべて含みます。

この違いを表にまとめると以下のようになります。

[図 18-4] 従来の自動化とエージェントのワークフローを比較した図

自己学習：使うほどに改善されます

かつては自動化を更新するにはノードを直接修正して再設定する必要がありました。しかし、エージェントのワークフローでは、エージェントが問題に直面するたびに学習し、ワークフローとツールを更新します。

求人情報のウェブ情報収集ワークフローの進行過程を振り返れば、この特性が明確になります。最初の実行では 209 件の情報を成功裏に収集し、2 回目の実行では以前作成したツールを再利用しました。3 回目の実行（歯科医のリード獲得）では完全に新しいツールを作成しましたが、過去の経験から得たウェブ情報収集のパターンを活用しました。各ワークフローファイルとツールファイルは、実行を繰り返すごとに洗練されていきます。

手動トリガーとスケジュールトリガーの違い

一つ明確にしておくべき区別があります。Claude Code の前に座って「この作業を行ってください」と指示することは、手動トリガー（人間トリガー）です。この場合、エージェントはリアルタイムで自己修復し、学習を行います。

一方、毎週月曜日の午前6時に自動実行されるようにデプロイすれば状況は異なります。デプロイされるのはワークフローとツールであり、エージェント自体がデプロイされるわけではありません。したがって、デプロイされたワークフローが実行中にエラーに直面しても、エージェントが同席していないため、自ら修正することはできません。

これは現在、エージェントによる作業フローにおける限界です。スケジュールトリガーで稼働しているワークフローを改善するには、Claude Code に戻ってワークフローを修正し、更新されたバージョンを再度デプロイする必要があります。

ワークフローを堅牢に設計する方法と、エージェント型アプローチがもたらす利点について見てきました。目標を明確にし、完了条件を定義し、要件定義をエージェントと共に行うことで、ワークフローの品質は飛躍的に向上します。今度はこれらの原則に基づき、Google が提供する強力なツールエコシステムをエージェントに接続する方法を見ていきましょう。