🤖 AI エージェント設計の解像度を上げる
意思決定 / AIエージェント / AI / 設計
― 意思決定写像で考える、エージェント設計の急所 ―
本記事は前回の記事「「決められない」の正体は、たぶん5要素のうちどれかが欠けているだけ」の続編。前回までの内容(意思決定写像の5要素、フラクタル構造、主観と客観の境界、AI 時代の必要能力)を踏まえて読むと話が繋がる。
はじめに
前回の記事の Part 4 で、こんな話をした。
AI エージェントは、与えられたゴールに対して個別タスクの5要素を自分で組み立てる。 だがエージェント自身を成立させているのは、人間が設計した「エージェントの5要素」である。 意思決定写像を持つ人は、エージェントを設計する側に立てる。
ここまでは方向感の話。 今回はもう一歩踏み込んで、エージェント設計の現場で、意思決定写像をどう道具として使うか を整理する。
「5要素を埋めればエージェントが動く」という話ではない。実際には:
- どの要素の設計を間違えると、どんな失敗が起きるのか
- どの要素にどれだけの設計コストを割くべきか
- エージェントが失敗したとき、5要素のどこを疑うか
- 階層構造をどう使えば、エージェントを安全に動かせるか
このあたりが現場で問われる。今回はこれを4パートで扱う。
- Part 1:エージェントは「5要素を組む主体」である
- Part 2:5要素ごとの設計の急所
- Part 3:階層を使う ― サブエージェントと人間の介入点
- Part 4:失敗診断 ― 5要素のどこがズレたか
Part 1:エージェントは「5要素を組む主体」である
個別タスクとエージェントの違い
意思決定写像の文脈で、両者の違いをきっぱり分けて書くとこうなる。
| 個別タスクへの AI 利用 | エージェント | |
|---|---|---|
| 誰が5要素を組むか | 人間が毎回組んで AI に渡す | エージェントが個別タスクの5要素を自分で組む |
| 人間の役割 | タスクごとの5要素設計 | エージェント自身の5要素設計 |
| 失敗時の責任 | 5要素設計と出力評価 | エージェント設計全体 + 監視 |
ここで重要なのは、人間が降りる階層が一段上に上がるということ。エージェントは個別タスクごとの設計を肩代わりするが、その代わり人間は「エージェントというメタな意思決定主体」を設計しなければならない。
責任の総量はむしろ増えている。降りた一段ぶん、影響範囲が広いからだ。
例:メール処理エージェントの5要素
抽象的なままでは何も決まらない。具体例で5要素を書き出してみる。
| 要素 | 中身 |
|---|---|
| 目的 | ユーザーのメール処理にかかる時間を減らす |
| 設定 | Gmail API へのアクセス権、署名テンプレ、外部送信は人間承認が必要、誤送信ゼロが絶対条件 |
| 評価基準 | 返信品質スコア × ユーザー介入頻度の少なさ − 誤送信ペナルティ(極大) |
| 入力 | 受信メール本文、過去の送信履歴、カレンダー、連絡先、ユーザー設定 |
| 出力集合 | {下書き作成, ラベル付け, アーカイブ, ユーザーに通知, 無視, 人間にエスカレーション} |
書き出してみると、何が決まっていて何が決まっていないかが一気に見える。
たとえば「ユーザー介入頻度の少なさ」を評価基準に入れると、エージェントは介入が要らないように行動を選ぶ。これは便利だが、副作用として「人間が気づくべき重要なメールを通知しなくなる」というリスクを生む。
「誤送信ゼロが絶対条件」を設定に置くか評価基準に置くかでも、エージェントの動き方は変わる。設定として置けば「絶対に超えてはいけない壁」、評価基準のペナルティとして置けば「ペナルティと他の利得のトレードオフで判断する対象」になる。
5要素のどこに何を置くか自体が、エージェントの性格を決める。これがエージェント設計の入口だ。
Part 2:5要素ごとの設計の急所
各要素には、特有の落とし穴がある。順に見ていく。
目的:報酬ハッキングへの警戒
エージェントは目的(報酬関数・指示文)を最大化するように動く。 だから 目的の指定が雑だと、想定外の方向に最適化される。
古典的な例:「ユーザーの満足度を最大化する」を目的にすると、エージェントは「ユーザーが不満を持たない範囲で何もしない」が最適解になりうる。「メール返信数を最大化する」を目的にすると、無意味な返信を量産しかねない。
これを意思決定写像で言うと、目的の単一スカラー化が粗いと、出力集合の中から目的を満たす意外な行動が選ばれてしまう 現象である。
対策の方向性:
- 目的を 複数項の評価基準 に分解する(後述)
- 目的を直接最大化させず、「制約 + 緩い目的」 の形にする(双対関係を使う)
- 暴走パターンを 設定の制約として明示 する
設定:ガードレールが本体
エージェント設計で 最も設計工数を割くべきはここ だと言ってよい。
設定とは、エージェントが動く前提・仮定・制約の総体。具体的には:
- どんなツールを呼べるか(API・実行環境)
- どんな行動が禁じられているか(削除系コマンド・送金・送信)
- どんな環境で動くか(サンドボックス・本番・読み取り専用)
- 失敗時のフォールバック(タイムアウト・リトライ上限・人間エスカレーション)
- 観測できる状態の境界(コンテキストウィンドウ・記憶の範囲)
ここの設計が甘いと、目的や評価基準をどれだけ慎重に書いても、エージェントは想定外の経路で世界に影響を及ぼす。
設定 = エージェントの「世界の縁」を決める作業である。 縁の外には行けないように作る。これがエージェント設計の安全保障だ。
評価基準:何を測れるかが、行動を決める
評価基準の設計で重要なのは3点。
1. 複数項を明示する 単一スカラーの最大化は危険。「品質 × 速度 − 誤動作ペナルティ + 人間介入の少なさ」のように、複数の項を重み付きで明示する。複数項の重みづけ自体が、エージェントの性格を決める。
2. 短期 vs 長期を分ける 即時の成功と長期の成功は違う指標で測る必要がある。即時最適化に閉じると、長期的な信頼を損なう行動が選ばれる。長期だけ見ると、短期で動かない。両方を観測して両方に重みを置く。
3. 人間が介入する閾値を決める 「自信度がしきい値以下なら人間に渡す」「不可逆な行動の前は必ず確認する」など、評価基準と連動した 介入トリガー を入れる。これは可逆性ベースの判断 ― 可逆な領域では速く、不可逆な領域では人間に渡す ― の実装にあたる。
入力:コンテキストの設計
入力 = エージェントが観測できる情報。LLM エージェントの文脈では、これは コンテキスト管理 の問題と直結する。
設計上の問いは:
- エージェントは何を「知っているべき」か
- 何を「忘れるべき」か(古い情報・無関係な情報)
- 外部知識(ベクトル DB・RAG)はどう使うか
- ユーザー固有の文脈(設定・過去の履歴・好み)はどこから取るか
ここの設計が甘いと、エージェントは正しい目的・評価基準を持っていても、入力が貧弱なせいで的外れな出力を選ぶ。 よくある失敗だ。
出力集合:取れる行動の空間
エージェントが選べる行動の空間を 明示的に列挙する。 「LLM が生成する自然言語」を出力集合のままにしておくと、何でも起こりうる。
実装上は:
- 関数呼び出し(tool use)で出力空間を有限集合に縛る
- 自由生成は「下書き」だけに限定し、確定アクションは別レイヤーで承認
- 「停止」「人間に渡す」を明示的な出力として常に含める
出力集合に「停止する」「人間に渡す」が入っていないエージェントは、行き詰まったときに必ず暴走する。 これは設計上の死活問題。
Part 3:階層を使う ― サブエージェントと人間の介入点
階層は、エージェント設計の自由度の源泉
意思決定写像はフラクタル構造を持つ ― という話を前回した。 エージェント設計では、これを実装の自由度として使える。
人間
↓ 設計する
オーケストレータ(上位エージェント)
↓ 個別タスクの5要素を組んで割り振る
サブエージェント A、B、C、…
↓ さらに細かいタスクに分解
ツール呼び出し / LLM 推論
各階層は、それぞれ意思決定写像である。上位階層は、下位階層の5要素のうちいくつかを「設定」として渡す。
たとえばオーケストレータがサブエージェントに「目的: コードレビューせよ、設定: このリポジトリ、出力集合: コメントのみ」を渡せば、サブエージェントは残りの「評価基準」「入力」を文脈から組み立てて動く。
階層をうまく切ると:
- 各層の責務が明確になる
- どの層で失敗したか切り分けやすくなる
- 人間の介入点を 必要な層にだけ 置ける
介入点は「不可逆性のある層」に置く
可逆な行動はエージェントに任せていい(失敗してもやり直せる)。 不可逆な行動は人間が介入する(失敗が取り返しつかない)。
これを意思決定写像の階層で言い換えると:
不可逆な行動を含む層では、人間がその層の出力を承認するまで実行に移さない。
具体的には:
- メール送信、ファイル削除、送金、本番デプロイ → 下書きまではエージェントが作り、確定は人間が押す
- 検索、要約、計算、下書き作成 → エージェントに任せる
- 中間判断(どのツールを呼ぶか) → 基本任せる、ただし不可逆へ向かう経路では一段上に確認
人間がボトルネックになることを心配する人もいるが、そもそもボトルネックを置くべき場所に置けているかどうかの問題 であって、不可逆領域でボトルネックを抜くと事故が起きるだけだ。
可逆性で介入を切り分ける ― これが、エージェントを安心して使うための実装原則になる。
Part 4:失敗診断 ― 5要素のどこがズレたか
「AI がダメ」を、構造的な診断に置き換える
エージェントが期待外れの出力をした。 ここで「AI がダメ」と切り捨てるか、「どの要素のどんな設計ミスか」と切り分けるかで、改善の道筋がまったく変わる。
意思決定写像の5要素は、診断のチェックリストとしてそのまま使える。
| 症状 | 疑うべき要素 | 典型的な原因 |
|---|---|---|
| 想定外の方向に動いた | 目的 | 報酬ハッキング、指示の曖昧さ |
| やってはいけないことをやった | 設定 | ガードレールの抜け漏れ |
| 「正解」のはずなのに評価が悪い | 評価基準 | 短期/長期、項目の偏り、重みの誤り |
| 的外れな出力 | 入力 | コンテキスト不足、文脈の取り違え |
| 行動の選択肢自体が貧弱 | 出力集合 | tool 設計が荒い、停止/エスカレが無い |
| ↑ 全部に当てはまる | 階層構造 | サブエージェントへの責務分割の失敗 |
このチェックリストを通すだけで、「AI が悪い」が「目的設計の粒度が荒い」「設定でツール制限が漏れていた」のような 具体的な修正対象 に変わる。
修正は上流から
複数の要素にズレがあるとき、どこから直すか。 鉄則は 上流から(目的 → 設定 → 評価基準 → 入力 → 出力集合)。
理由はフラクタル構造から自然に出てくる。上流の要素は下流の要素の解釈枠を与えている。 目的が曖昧なまま評価基準だけ磨いても、評価基準は何を測ればいいか分からない。設定が緩いまま出力集合を絞っても、隙間から漏れる。
「上流から直す」は、修正コストの最も小さい順番でもある。
修正の前に、もう一段上を疑う
それでも直らないとき。 たいていは、そのエージェント自体を作るべきだったかどうか という、一段上のメタ意思決定の問題だ。
- このタスクは本当にエージェント化すべきか
- 単発の AI 利用で十分ではないか
- そもそも人間がやるべき領域ではないか
ここを問えるかどうかで、エンジニアリングの質はまったく違う。 エージェントを作ること自体が目的化していないか、自分の意思決定写像を疑い続ける必要がある。
おわりに ― 5要素を設計する人が、責任を引き受ける人
エージェントが個別タスクの意思決定を肩代わりする世界では、「決めた人」が見えにくくなる。
「AI が判断しました」「アルゴリズムが選びました」と言える状況は、責任の所在を曖昧にする。だからこそ、エージェントを設計する側に立つ人は、5要素のどこを自分が設計したのか ― どこが自分の主観で、どこが AI の処理結果か ― を言語化できなければならない。
これは前回の記事で書いた「主観と客観の境界を明示すること」の、エージェント時代版である。
要点を一行で言うと:
エージェントの5要素を設計する = 自分が引き受ける主観の範囲を、自分で言語化すること
エージェントが何をしようと、その5要素を組んだのは人間である。 このことを忘れない人だけが、AI 時代に責任ある設計者として立てる。
意思決定写像は、その立ち位置を見失わないための地図だ。
参考文献
- 松嶋敏泰「データサイエンスをどう捉えてどう教えるか ― 早稲田大学での取り組みを交えながら ―」『オペレーションズ・リサーチ』65巻10号, 2020年, pp. 544–550. https://orsj.org/wp-content/corsj/or65-10/or65_10_544.pdf
- 早稲田大学データ科学教育チーム(著)・松嶋敏泰(監修)『データ科学入門I — データに基づく意思決定の基礎』(ライブラリ データ科学1)サイエンス社, 2022年.
