Article by: Dan Mindru
数年前はブロックチェーンが話題の中心でした。その前はIoT、その前はビッグデータ、さらにその前はクラウドでした。それぞれの時代が一種のパラダイムシフトをもたらし、大規模な投資と約束が生まれました。成功したものもあれば、そうでないものもありましたが、いずれもテクノロジーの進化を促進したといえます。
現在、私たちは2022年頃にOpenAIから始まったAIの誇大広告サイクルを全面的に受け入れています。しかし、今回はこれまでとは異なる感覚があります。マーケティングが優れているからではありません（「OpenAI」の「Open」と「AI」について議論の余地はあります）が、前例のない速度で実際のアプリケーションが次々と登場しているからです。これは未来の約束ではなく、「今」起きている現象です。そして、その進展は非常に速いのです。では、どのくらい速いのか。その速さは、2025年の現在、誰もが次のビッグトレンドである「AIエージェント」に飛びついていることからもよくわかります。
OpenAIは「Operator」を発表しました。これは自分のブラウザを使ってユーザーのためにタスクを実行できるAIエージェントです。中には2024年の時点で一足先にAIエージェントをリリースした企業（Chatbaseなど）もあります。
しかし、そもそもAIエージェントとは何でしょうか？
初めて聞く方にもわかるように説明しましょう。14歳の子どもにも説明できると言いたいところですが、正直なところ、最近では私たちより彼らの方がAIエージェントについて詳しいかもしれません。
では、始めましょう！
AIエージェントとは？
想像してみてください。
あなたの会社で極秘のエンタープライズアップグレードが導入されたとします。ITチケットも不要、ダウンタイムもなし、マニュアルもいりません。目に見えない裏方チームが、カスタマーサポートの対応、コードの記述、ドキュメントの翻訳、マーケティングコピーの作成など、あらゆる作業を同時にこなします。しかも月額200ドル、24時間365日稼働し、「至急」案件も数分で「完了」へ。ミーティングもオンボーディングも不要。まるでワークフローに誰も予想しなかったターボボタンを追加したようなものです。それがAIエージェントであり、どのように見ても魅力的です。
では、仕組みはどうなっているのでしょうか？
AIエージェントは、大規模言語モデル（LLM）を強化するためのシステムであり、タスクの計画、サードパーティサービスとの統合、プロンプトの連鎖による回答の洗練を行います。
LLMとは？
LLM（大規模言語モデル）は、大量のテキストデータで学習されたディープラーニングモデルで、人間のような言語を理解し生成します。文章の次に来る単語を予測し、質問への回答、コンテンツの執筆、言語の翻訳、アイデア出しなどを、学習データ内のパターン認識を通じて実行します。
簡単に言えば、比較的シンプルなプロンプトを受け取り、それを複数のプロンプトとAPIコールの組み合わせに変換できます。もちろん、単一のプロンプト実行よりはコストが高くなります（この点については後述します）。話を複雑にしすぎずに言えば、AIエージェントのワークフローは「彼ら」が従うフローに基づいて大きく2つのカテゴリーに分かれます。
- 処方型ワークフロー
- 探索型ワークフロー
これらについて詳しく見ていきましょう。
処方型ワークフロー 単一のレスポンスで完結
シンプルに言えば、AIエージェントは「通常の」プロンプトを連結したものです。魔法のようなものではありませんが、実用的な実装が可能になります。
例えば、AIエージェントのシンプルな実装は、好みのAIモデルに対して複数回のLLMコールを行うforループであり、その前後にサードパーティAPIコール（あるいはインテグレーション）を組み合わせる形です。
一部のAPIコールは他のサードパーティAPIへのアクセスでもあり、ユーザーの「ゲート」（入力待ち状態）によって制御される場合もあります。
これは、リアルタイムデータや他のシステムに隔離されたデータへアクセスするなど、LLMの本質的な制限を克服するのに特に有効です。
例えば、AIエージェントが従業員の休暇申請を処理するケースでは、内部APIを介して分離された人事データベースにアクセスし、残りの有給休暇を確認し、条件を満たせば自動承認する、という流れです。
他の例としては以下のようなものがあります。
- カスタマーサポートFAQエージェント
クエリの意図を特定するために4つのプロンプトを連鎖させ、内部ナレッジベースから関連情報を取得し、ユーザーにわかりやすい形で返します。 - コンテンツ作成ワークフロー
ブログ記事作成のために3つのプロンプトを連鎖し、アウトラインの生成、各セクションへの展開、最終稿のスタイル調整までを行います。 - ミーティングスケジューラー
APIコール、プロンプト、再度APIコールを連鎖し、個人のカレンダーを確認し、最適な時間にミーティングを提案・予約し、Slackチャンネルへ通知します。
処方型ワークフローでは、タスクを小さなマイクロタスクに分割し、並列処理したうえで最終的に1つのレスポンスにまとめることもできます。このアプローチは非常に高性能かつ柔軟性があります。
さらに、各マイクロタスクがそれぞれ独自にAPIコールを行い、リアルタイムデータや隔離されたデータを取得することも可能です。
つまり、これらのワークフローは、私たちがよく知っていて好むLLMの特性（文脈理解、タスク非依存の多用途性、柔軟な推論、人間らしい対話など）を活かしつつ、それ単体では難しい、あるいは不可能な機能を補完しています。
処方型ワークフローの利点はコストが予測しやすい点です。単一のLLMコールよりは高くなりますが、APIの使用量やタスクの複雑さが一定ならコストは安定します。
しかし、統合数を増やすと難易度や非効率が増すこともあります。APIコールがすべて必要とは限らず、場合によっては動的なユーザー入力が求められることもあります。
では、もしエージェント自身がこれを判断できたらどうなるでしょう？
探索型ワークフロー：適応的かつ動的
ここまで読んでこう思ったかもしれません。
「AIエージェントって、トレンチコートを着たLLMコール3回分の塊じゃない？」
しかし、実は時には冬用ジャケット、金融用ベスト、さらにはダサいクリスマスセーターにもなり得ると言ったらどうでしょう？実際、すべてのAIエージェントが同じように作られているわけではありません。多くのエージェントはプロンプトの連鎖に基づいていますが、それだけでなく計画、推論、反復、自己指向的なワークフローの遂行も可能です。
探索型ワークフローは動的で適応性があります。処方型ワークフローで可能なすべての経路をたどることができますが、あらかじめ定義されているわけではなく、APIやインテグレーション、人間からのフィードバックに基づいて自ら計画・実行・適応します。根本的には、プロンプト技法、ループ処理、APIコールの集合体です。そこにユーザー入力を少し加えることで、数年前には構築不可能だったようなシステムが実現できます。
このようなワークフローは、より汎用的になり、ツールやAPIコールの数に関わらずスケールし、何千もの個別かつ動的なワークフローを構築できる可能性があります。これも拡張手法の一つですが、より多くの工夫が加わっています。
- 動的な計画立案：エージェントが中央レジストリから使用するツールを自分で決定します。
- ツール統合：OpenAPI仕様のようなコンテキストを利用して、CRMシステムや各種APIと統合します。
- セキュアアクセス：OAuthのようなプロトコルを使い、エージェントが安全にプライベートデータへアクセスします。
- 反復的推論：結果を評価し、成功または失敗の基準に達するまで計画を調整します。
- フィードバックループ：強化学習や人間のフィードバックを通じてパフォーマンスを改善します。
例えば、クラウドストレージやメールを横断検索するよう指示されたAIエージェントを考えてみましょう。このエージェントは、必要に応じてDropboxやGmailのAPIを呼び出し、実行ステップを動的に計画し、タスクが完了するまで結果に基づいて繰り返し処理を行います。実際のアプリは単純な入力インターフェースであり、ユーザーは「Dropboxを検索」といった特定のサービスを指定したり、「メールとカレンダー全体を検索」といった一般的な指示を出したりします。
その後、AIエージェントはこの初期プロンプトに基づいて実行ステップを計画し、複数のAPIコールを行ったり、ページネーションやソートを処理したり、複数のフィードバックループを経ることもあります。ここで重要なのは、「スーパーバイザー」プロンプトの存在であり、これは成功またはエラーのいずれかでプロセスを終了させる「能力」を持ちます。
このようなワークフローの欠点は、フィードバックループ内でどの「経路」を選ぶかエージェントが判断するため、コストの予測が難しくなることです。そのため、通常は反復回数に上限（ハードストップ）を設定し、無限ループで月間IT予算を消費し続ける事態を防ぎます。こうした仕組みを拡張すれば、可能性は無限大になりますよね？そのため、AIエージェントの盛り上がりも果てしなく続いているのです。
では、全てをAIエージェントに置き換えた方がいいのでしょうか？
…実際は、状況によります。
探索型AIエージェントは本当に必要か？
探索型AIエージェントが必要か、それとももっとシンプルな処方型ワークフローで十分か判断するには、次の例え話を考えてみてください。
スーパーでバナナを運ぶのにフェラーリが必要でしょうか？それともホンダで十分でしょうか？
ほとんどの場合、ホンダで何の問題もなく運べます。一方フェラーリなら燃費は5倍悪く、騒音は大きく、しかも「フェラーリの運転方法を知らず溝に落ちた！」なんてことになるかもしれません（筆者の住む地域は寒いです）。
言いたいことは伝わったかと思いますが、ほとんどの場合、処方型ワークフローで十分なのです。ほとんどのタスクは、より低コストかつ高速で、しかも内部の動作をより細かくコントロールしながら実行できます。
AIエージェントを使うべき場合・使うべきでない場合は以下の通りです。
- 次の場合は処方型ワークフローを選びましょう。
- タスクが単純で予測可能な場合
- スピードと低コストを重視する場合
- 単一のLLMコールで十分な場合
- 地味でも安定したシステムが好みの場合
- 次の場合は探索型ワークフローを選びましょう。
- タスクがオープンエンドで予測不可能な場合
- 柔軟性と動的な意思決定が必要な場合
- テストやエラー対応に時間とコストをかけても問題ない場合
- 時にはフルーツではなくAppleのアクセサリーを注文してしまうような、スリリングで予測不能なシステムが好きな場合
スプレッドシート好きの方のために（批判しているわけではありません。）、別のまとめ方もあります。
結局のところ、重要なのは「目的に合った適切なツールを選ぶこと」です。AIエージェントを「ハンマー」として持てば、釘（タスク）は簡単に見つかりますが、パフォーマンスやコスト次第では素晴らしいアイデアも失敗に終わる可能性があります。
私自身が魅力を感じているのは処方型ワークフローです。安価で高速、かつ既存の価値あるシステムを予測可能な形で強化できます。一方、探索型ワークフローは「賭け」に近いものです。
自分だけのAIエージェントを作るには
ここまで読んでいただければ、AIエージェントに特別な魔法のようなものはないとおわかりいただけたと思います。AIそのものと同じくらい普通の存在です。つまり、ゼロからAIエージェントを作るのもまったく現実的な選択です。
エージェントの構築を簡単にすると謳うツールはたくさんあります。
これらのツールは素晴らしく、多彩な工夫が詰まっていますが、注意が必要です。不要な複雑さを招き、デバッグやデプロイを難しくすることもあります。シンプルに始めましょう。いきなり凝ったフレームワークを使う前に、まずはLLM APIを直接使うのがおすすめです。わずか数行のコードでも驚くほど多くのことが実現できます。
まとめ
他の流行サイクルと同様に、将来の可能性に過度な期待を寄せるのではなく、短期的に実現可能なことに集中する姿勢が大切です。コーディングからカスタマーサービスに至るまで、あらゆるものを変革するという見出しを目にしたことがあるでしょう。しかし、果たしてそれは万能薬なのでしょうか。実際はそうではありません。とはいえ、世界を変えないという意味でもありません。すぐにではなく、段階的に変えていくのです。
課題は、コストとパフォーマンス、そして柔軟性のバランスをどう取るかです。多くのシンプルなタスクは、今でも「通常のAI」でより効率的に処理できます。最近の性能向上と価格低下のスピードを考えると、明日にはAIの標準的な使い方がこうなっている可能性も十分にあるのです。
Original Page: AI Agents: Hype or Reality?
IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。
