以前、生成AI活用の鍵は「出力だけ見てレビューできるか？」で、生成AIに任せる・任せないの判断軸として出力による妥当性判断のしやすさという切り口で整理しました。

今回はその延長線上で、AIエージェントがうまくフィットする問題は何かを考えていたところ「試行錯誤が必要な探索問題」だと感じたので、改めて考えを整理しました。

そのタスク、ほんとにAIエージェントに向いてる？

「AIエージェントがExcelを操作できる！ブラウザを操作できる！」というインフラが整ってきました。
しかしAIエージェントにこれらの操作を任せるのは、正直怖いと感じます。

Excelの操作を任せたら、どのセルがどのように編集され、不必要な変更がないかをチェックする必要があります。
ブラウザの操作を任せたら、個人情報をばら撒いたり、不必要な課金をしてないか確認や注意が必要です。
だとしたら、本当に楽になってる？そこまで確認するなら、むしろ自分でやったほうが早くない？？

…と思っているのですが、世の中はAIエージェントブーム。とにかくAIエージェントを使えという風潮すら感じます。
そこで「じゃあAIエージェントに向いてるタスクって何なんだ？？」ということを考えました。

そもそもAIエージェントとはなにか？

ここでのAIエージェントは「モデル・プロンプト・ツールを使ったエージェントループによる実装」を指します。
（OpenAIのAgent Builderのような、いわゆるAIワークフローではありません）

エージェントループは意外とシンプルで、LLM APIを繰り返し呼び出す仕組みです。
LLM APIでもツール（Function Calling）は使用できますが、AIエージェントはツールを何度も連続実行可能な形式に拡張したものと捉えることができます。

しかし、このエージェントループで実行されたツールの内容をすべて確認するのは大変です。
ツールの使用回数が増えて複雑になるので「出力だけで妥当性が判断できるかどうか」はより重要になります。

「ツールを繰り返し使う」というのは、言い換えれば「試行錯誤による解の探索」です。
そこに「出力だけで妥当性を判断できる」という条件を加えると、AIエージェントに適したタスクが見えてきます。 それは解を見つけるのは難しいが、解の検証は容易であるような探索問題です。

検証が容易な探索問題とは？

（計算量理論でいう「NP問題」に近い話をしています。知っている人は読み飛ばしてください）

イメージしやすい例としては「因数分解」でしょうか。
因数分解は、大きな数字であるほど経験や直感では判断できません。
例えば143とか1219の因数分解を考えるときには、試行錯誤を必要とする人が多いでしょう。

しかし答えが分かってしまえば、それを確認することは簡単です。
解となる数字を掛け合わせれば検証できるので、その答えが妥当であることの判断は容易です。
試行錯誤のプロセスを見る必要はありません。

ここで伝えたいことは、AIエージェントはこのような探索的要素を持つ問題に適するだろうということです。
問題構造がフィットしていれば、あとは試行錯誤する上でどれだけ効果的なツールを渡せるかが鍵となります。

解の検証のしやすさを4段階で分類する

前述のとおり、AIエージェントには「解の検証が容易な探索問題」が向いています。
ここで「誰がどうやって検証できるか」という観点で、以下の4つに分類してみます。

1. AIエージェント自身がツールを使って正解を判定できる
2. AIエージェントは正解を判定できないが、人間は出力だけを見て判断できる
3. AIエージェントは正解を判定できないが、人間は出力とプロセスを見て判断できる
4. AIエージェントも人間も正解かどうかを判定・判断できない

1 > 2 > 3 > 4 の順にAIエージェントが活用しやすい問題といえそうです。
1のように、AIエージェント自身が正解を判定できるツールを持っていることが理想的です。

コーディングエージェントの事例を考える

既に利用が進んでいるコーディングエージェントについて、その活用場面やプラクティスを4分類で考えてみます。

テスト駆動開発・バグ修正（分類1に該当）

バグ修正では、仮説を立て、ログを読み、コードを修正して実行する、という試行錯誤が必要です。
しかし適切なテストコードがあれば、あとはコーディングエージェントに任せられます。
エージェント自身がテストの Pass/Fail で正解を判定でき、Pass するまで自律的に試行錯誤するからです。

これはトラブルシューティングなども同様です。
「このコマンドがエラーにならず実行できるように」と依頼すれば、解消するまで試行錯誤してくれます。

リファクタリング（分類2、3に該当）

一方、リファクタリングはエージェント活用が比較的難しくなります。
「良いコード」の指標をツールとして渡すことができず、人間がコードを見て判断する必要があるためです。
また何かしらのトレードオフがある場合、プロセス（他にどんな選択肢を考慮したのか等）も確認したくなります。

その他の領域を考える

コーディングエージェント以外の領域で、どのようなタスクがどの分類に該当しそうかを考えてみました。

旅行プランの作成（分類1に該当）

目的地候補・移動手段・時間配分などでいろいろなプランを探索する問題です。
立てたプランが制約（移動時間・営業時間・予算上限）を満たしているかは機械的にチェックすることができます。

うろ覚えの本を売っているお店を探す（分類2に該当）

いろんなお店で検索する必要があるし、あれこれキーワードを試す必要があります。
しかし自分が表紙を見れば思い出せるので、検索したプロセスについて確認する必要はありません。

ほしい商品の最安値を検索（分類3に該当）

最安値で買うことを重視する場合は、調べたときのプロセスが気になってきます。
Amazonも楽天もチェックした？価格で並び順をちゃんと変更した？類似商品はなかった？等々。

まとめ

AIエージェントに向いているタスクは「検証が容易な探索問題」というお話でした。 ポイントは以下の2つです。

1. 試行錯誤の余地があること
AIエージェントが試行錯誤を代行してくれることに、活用する価値があります。
試行錯誤が不要なタスクはプログラムで自動化するほうが高速・確実です。
むしろ生成AIを使ってそのプログラムを書くほうが適切でしょう。

2. 解の検証が容易であること
AIエージェントの出力を検証できなければ、責任を持って使うことができません。
理想的にはAI自身が判定できるツールを持っていることが重要です。
人間が判定する場合でも出力結果だけを見て判断できることが重要になります。

AIエージェントを使う視点では、このような問題構造にフィットしたユースケースの選定が重要になりそうです。
そしてAIエージェントを作る視点では、試行錯誤や検証を可能にするツールの提供が重要になると感じました。