はじめに
こんにちは！KDDIアイレットの伊藤です。
「AI エージェントを開発したいが、どう設計すればいいかわからない」「いざ作ってみたものの、思ったほど成果が出ていない」「動き始めてから追加の構成が次々に必要になり、うまく回らなくなった」— そんな悩みはありませんか?
私はサポートデスクの現場で、人海戦術の限界という課題を解決するべく、Google Cloud を用いた AI チャットボットと AI エージェントを開発・本番運用してきました。結果として、かなりの業務工数削減に成功し、増員なしで現場を回すことができています。
この記事では、その開発・運用を通じて確信した、AIエージェント開発はここを意識することが重要だという点をお伝えします。個別の実装詳細には踏み込まず、どの技術スタックでも当てはまる設計の話に絞ります。
なお、この記事で「AI エージェント」と呼ぶのは、LLM(大規模言語モデル)が検索・API 呼び出しなどのツールを使いながら、複数ステップのタスクを自律的に進める仕組みのことです。単発の質問応答(チャット)とは区別して書きます。
結論: AI が改善し続ける「エコシステム」を設計する
先に結論を書きます。
AIエージェント開発で重要なのは、エージェント単体の出来ではなく、「開発 → 観測 → 人の介入 → 改善」というサイクルが回り続けるエコシステムを設計することです。
AI エージェントは、デモまでは驚くほど早く作れます。しかし「作って終わり」にしたエージェントは、本番に載せた瞬間から 3 つの理由で死に向かいます。
死因①: 現実は、デモと違う入力を投げ続けてくる
デモで見せた成功パターンは、現実の入力のごく一部にすぎません。本番では想定外の聞き方・例外ケース・変則的な依頼が次々に届き、精度は「デモで見た数字」から徐々にずれていきます。
死因②: エージェントの外側の世界が変わり続ける
エージェント自体は何も変わらなくても、参照するナレッジ・連携先の仕様・業務のルールは更新され続けます。昨日まで正しかった出力が、今日は事実と違う。リリース時点が品質のピークで、あとは劣化していくのはこのためです。
死因③: 一度裏切られたユーザーは、黙って使うのをやめる
もっともらしい誤りに一度でも当たったユーザーは、エージェントを信用しなくなります。厄介なのは、「使うのをやめた」はエラーログに出ないことです。使われなければフィードバックも集まらず、改善の材料すら残らない。エージェントは止まらないまま、静かに死にます。
この 3 つに共通するのは、どれもエージェントのコードのバグではないということです。つまり、作った時点の品質をどれだけ高めても防げません。さらに死因③が示すとおり、ユーザーの離脱を劣化検知のアラート代わりにすることもできません。裏切ってから直しても、そのユーザーはもう戻ってこないからです。
だから対策は「もっと良く作る」ことでも「壊れてから直す」ことでもなく、誤りがユーザーに届く前に食い止め、劣化にユーザーより先に気づく仕組みを最初から組み込んでおくこと — つまり冒頭のサイクルを回し続けることになります。
逆に、運用しながら自分で良くなり続ける仕組みを持ったエージェントは、モデルを乗り換えなくても成果を出し続けます。私自身、この構成で開発・運用してきて、モデルの進化よりもサイクルの設計のほうが成果を左右すると実感しました。
以降、このサイクルを 4 つのステップに分けて、開発に取り組むストーリーとして書いていきます。
- 作る — 任せる範囲を決め、任せられる作りにする
- 観測する — 回し続けるための「目」を最初から入れる
- 人が介入する — 最終判断とフィードバックを人が担う
- 改善する — フィードバックを仕組みで AI に還元する
STEP 1: 作る — 任せる範囲を決め、任せられる作りにする
サイクルの起点は、当然「作る」ことです。ただし、後のステップ(観測・介入・改善)が回る前提で作るかどうかで、この時点の設計は変わります。
万能を狙わず、任せる範囲に線を引く
最初に決めるべきは「何をさせるか」ではなく「何をさせないか」です。
- 高頻度: 何度も発生する(自動化の効果が積み上がる)
- 既知: 過去に人が対応したパターンがある(参照できる正解がある)
- 定型: 手順がある程度決まっている(逸脱の判定がしやすい)
この 3 条件が重なる業務だけを AI に任せ、前例のない対応や判断が割れる案件は人が担当します。範囲を絞ったエージェントは期待値が明確になり、後のステップで「外れた」ことを検知しやすくなります。万能を狙うと、精度が安定しない領域に引きずられて全体の信頼を失います。
改善できる単位に分割する
1 つの巨大なプロンプトにすべての指示を詰め込んだエージェントは、初期には動いているように見えますが、改善のフェーズで行き詰まります。どの指示が効いていて、どこを直せば精度が上がるのかが切り分けられないためです。
私は、司令塔となるエージェントが配下の専門エージェント(判定・検索・作文・査読など)にタスクを振り分けるマルチエージェント構成で開発してきて、この分割には明確な効果を感じました。各エージェントのプロンプトが簡潔になって精度が安定し、問題が起きたときにエージェント単位で直せる。つまり**「分割する」は「後で改善できる」の裏返し**です。あわせて、工程ごとにモデルを使い分けて、コスト・速度・品質のバランスを取ります。
| 工程 | 使うモデル | 理由 |
|---|---|---|
| タスクの振り分け・検索クエリ生成 | 軽量・高速なモデル | 呼び出し回数が多く、速度とコストへの影響が大きい |
| 回答可否の判断・ユーザー向け文面の生成 | 高精度なモデル | 間違いの影響が大きく、精度を張る価値がある |
失敗と暴走を前提に組む
自律的に動く仕組みである以上、途中の失敗と無限ループを前提に設計します。
- 部分失敗を許容する: 複数の情報源を並列で検索するとき、1 つが失敗しても取得できた分で処理を続ける
- ループには必ず上限を付ける: 「生成 → 査読 → 作り直し」のような自己修正ループは、収束しないことがある。上限回数で打ち切り、「人の確認が必要」という警告を付けて確定させる
- 権限は読み取り専用から始める: データの作成・更新・削除をエージェント自身に行わせない。「読むだけ」なら想定外の動作も誤った参照で済む
共通するのは、劣化しながらでも人に引き継げる形で終わるという設計目標です。これが次のステップ「人の介入」への接続点になります。
STEP 1 の要点
任せる範囲に線を引き(高頻度 × 既知 × 定型)、後で改善できる単位に分割し、失敗しても人に引き継げる形で終わるように作る。
STEP 2: 観測する — 回し続けるための「目」を最初から入れる
作ったエージェントは、デプロイした瞬間から「中で何が起きているか分からないもの」になります。従来のアプリケーションと違い、同じ入力でも出力が揺れるためです。観測できないものは改善できません。だから観測は「あとで入れる」ではなく、開発とセットで入れます。
LLM の処理を追跡・可視化する仕組みは LLM Observability と呼ばれ、各種の監視サービスやオープンソースで実現できます。最低限、次が見えると運用が変わります。
| 見るもの | 分かること | 介入アクションの例 |
|---|---|---|
| 処理のトレース | どのステップが遅い / 失敗したか | ボトルネックのエージェントだけを改修する |
| トークン量とコスト | 想定外のコスト増 | 呼び出し回数の上限やモデル選定を見直す |
| 入出力の品質・傾向 | 出力品質の劣化、ユーザーの反応の傾向 | 反応が悪化したやり取りを検知し、人の介入に備える |
重要なのは、観測を障害対応のためだけに使わないことです。たとえばユーザーの反応が悪化したやり取りを検知して通知すれば、人が介入すべき場面に先回りして備えられます。つまり観測とは、人が介入すべき瞬間を機械に見張らせる仕組みであり、次のステップ「人の介入」のトリガーそのものです。
効果測定も「作る前」に設計する
観測に含めて意識してほしいのが効果測定です。これは実績が積み上がってから考えるのでは手遅れです。
- 導入前のベースライン(対応時間・件数など)を、導入前に計測しておく
- 「AI が短縮する時間を本当に測れるか」を過去データで確かめる
- 前後比較が成立する集計条件(対象範囲・期間・除外条件)を先にそろえる
これをやらずにリリースすると、「効果があった気がするが証明できない」状態になります。AI 施策は投資判断を問われ続けるので、測れない改善は続けられません。サイクルを回し続ける予算と信頼を確保するためにも、測る設計はエージェントの設計と同時に行うものです。
STEP 2 の要点
観測は「人が介入すべき瞬間を機械に見張らせる目」。効果測定の設計も含めて、開発とセットで最初から入れる。
STEP 3: 人が介入する — 最終判断とフィードバックを人が担う
LLM の出力には、もっともらしいが事実と異なる内容(ハルシネーション)が混ざります。これはモデルが進化しても確率的にゼロにはなりません。だからエージェントの出力がそのまま外部(顧客・本番システム)に届く設計は避け、人が最終判断を挟む前提で作ります。いわゆる Human in the Loop です。
ただし「人がレビューするから大丈夫」で止まると、今度はレビューが形骸化します。もっともらしい誤りを人の目だけで見抜き続けるのは現実的ではありません。ここで効くのが、レビューする人を AI で支援するという発想です。
検品 AI(LLM-as-a-Judge)でレビューを支援する
生成用の AI とは別に「検品用の AI」を置く二層構成です。生成された成果物を別の LLM が評価する手法は LLM-as-a-Judge と呼ばれます。以下では成果物を「回答」と書きますが、コードやレポートなど、あなたのエージェントが作るものに読み替えてください。
実務で効いたポイントは 3 つあります。
- 出典との突き合わせを機械にやらせる: 回答が引用している出典を実際に取得し、主張が出典に書いてあるか(根拠性)を主張ごとにチェックする
- 照合は「全文」で行う: 出典ページの一部だけを読んで採点すると、実際には書いてあることを「根拠なし」と誤判定する
- スコアではなく「確認ポイント」を返す: 「85 点です」ではレビュアーは動けない。「この主張の根拠が出典に見当たらない」のように、人が何を確認すべきかを提示する
判定は安全側へ倒す — 失敗の重さは非対称
検品 AI を設計するとき、見落としがちなのが「失敗の重さの非対称性」です。
| 失敗の種類 | 何が起きるか | 重さ |
|---|---|---|
| 過剰検知(良い回答を「要確認」とする) | 人の確認で吸収できる | 軽い |
| 見逃し(悪い回答を「問題なし」で通す) | 誤った情報がそのまま外に出る | 重い |
この 2 つは重さがまったく違います。だから精度指標は「全体の正解率」ではなく「重大な見逃しをどれだけ減らせたか」を最重要に置き、判定は安全側(疑わしきは要確認)へ倒します。
もう 1 つ、警告の精度は仕組みの生命線です。警告が外れ続けると、人は警告そのものを信用しなくなり、その時点でどれだけ作り込んだ仕組みも機能しなくなります。このとき「警告が多いから基準を緩める」という対処は危険で、本当に危険な回答も一緒に通してしまいます。私が経験したケースでも、警告が外れる原因は採点基準の厳しさではなく、照合に使う情報の不足(前述の一部照合)でした。警告がうるさいときは、基準を疑う前に入力を疑う。この順番は覚えておいて損がありません。
人の介入を「次の改善の燃料」にする
そして、このステップで一番意識してほしいのはここです。人のレビューを「品質の最終防衛線」で終わらせず、判断の結果をデータとして残すところまで設計します。たとえばレビュー結果を OK / NG のワンクリックで記録できる導線を作り、蓄積する。この一手間のあるなしが、サイクルが円として閉じるかどうかの分かれ目です。人の介入は、品質保証であると同時に、AI への教師データの供給でもあります。
STEP 3 の要点
人が最終判断を担い(Human in the Loop)、検品 AI でレビューを支援する。判定は安全側へ倒し、人の判断は OK / NG のデータとして残す。
STEP 4: 改善する — フィードバックを仕組みで AI に還元する
サイクルの最後は、集めたフィードバックと観測データを AI に還元することです。ここで絶対に避けたいのが「気づいた人がナレッジを更新する」という善意頼みの運用です。善意は必ず止まります。
改善は善意ではなく仕組みで回す。 具体的には以下のような設計です。
- 蓄積した OK / NG フィードバックを、生成プロンプトと評価基準の改善に使う
- エージェントが参照するナレッジの登録・更新をパイプラインに組み込み、自動で鮮度が保たれるようにする
- 観測データ(品質・コスト・レイテンシの推移)から、直すべきエージェントを特定する
改善の判断材料となる指標にも、1 つ注意点があります。似た指標を混同しないことです。たとえば「AI の回答自体に重大な誤りがある割合」と「検品側が悪い回答を見逃した割合」は別物です。名前が似た指標は定義を分けて管理しないと、議論がかみ合わなくなります。
STEP 4 の要点
改善は善意ではなく仕組みで回す。フィードバックと観測データを、プロンプト・評価基準・ナレッジの更新に自動で還元する。
まとめ — AIエージェント開発は「エコシステム」を意識しよう
ここまでをつなげると、こういう循環になります。
AI が成果物を作り、人が最終判断を下し、観測がその間を見守る。そして人の判断が AI を育てる。 この円が閉じて回り始めたとき、AI エージェントは「導入したツール」ではなく、運用しながら改善し続けるエコシステムになります。
モデルは今後も進化し続けますし、フレームワークの流行も入れ替わるでしょう。それでも、このサイクルを最初から設計するという考え方は、しばらく普遍だと考えています。これから AI エージェントを開発する方は、コードを書き始める前に、ぜひ「この円をどう設計するか」から考えてみてください。