意思決定者のためのAIエージェント設計論

AIエージェントとは何か ― 従来の常識が通じない理由

　「AIエージェントを導入したい」という声が経営会議で当たり前に聞かれるようになった。だがその前に、確かめておきたいことがある。私たちが長年前提にしてきた「ソフトウェアはこう動くもの」という常識が、AIエージェントには通じない。連載の初回では、意思決定者がまず頭を切り替えるべき「3つの性質」と、それがもたらす3つの設計課題を整理する。

「チャットボット」と「エージェント」を分けるもの

　まず用語を整理したい。AIエージェントという言葉は驚くほど多義的に使われている。私たちは、これを「環境を観察し、複数のステップにわたって自律的に行動し、次のアクションを動的に決定するシステム」と定義する。事前に定義された手順に沿って処理を進める「ワークフロー」とは明確に区別する。両者を見分ける問いはシンプルだ。「次に実行するステップを、LLMが実行時に決めるか」。答えがYesならエージェント、Noならワークフローである。

　この区別は用語の問題ではない。エージェントとワークフローでは、必要なガバナンスの強度も、テストの方法も、リスクの質も根本的に異なる。「AIエージェント」と名のつくものが実はワークフローだった、あるいはその逆だった――この取り違えが、過剰な統制でプロジェクトを止めたり、逆に暴走リスクを見落としたりする原因になる。実際、社内で「エージェント」と呼ばれているものの多くは、決められた分岐を順にたどるワークフローにすぎない。逆に、ワークフローのつもりで導入したものが、いつの間にかLLMに判断を委ねる範囲を広げ、実質的にエージェント化していることもある。まず自社の仕組みがどちらなのかを見極めることが、あらゆる議論の出発点になる。

従来のソフトウェアと決定的に違う3つの性質

　従来の業務システムは、同じ入力に対して必ず同じ出力を返す「決定論的」な仕組みだった。この決定性こそ、私たちが業務をシステムに安心して任せられた根拠である。AIエージェントは、この前提の外側にある。次の3つの性質が重なり合うところに、従来のソフトウェア工学では扱いきれない難しさが生まれる。

　第1に、確率的な振る舞い。 エージェントの中核であるLLMは確率的に動作する。同じ問いに毎回同じ答えが返るとは限らない。基盤モデルがバージョンアップすれば、これまで期待通りだった出力が変わることもある。「唯一の正解を確実に返してほしい」業務にとって、これは看過できない特性だ。

　第2に、自律的なツール選択。 現代のエージェントは文章を生成するだけではない。検索する、社内データベースを照会する、メールを送る――こうした「道具（ツール）」を、状況に応じて自分で選んで使う。人間が手順を一つ一つ指示しなくても、目的から逆算して行動を組み立てる。ここがチャットボットとの決定的な違いである。

　第3に、外部世界への作用。 そして最も重いのが、エージェントが現実世界に作用する点だ。データを書き換え、発注し、顧客に連絡する。生成した文章が誤っていた場合と、誤った発注を実行してしまった場合とでは、影響の重さがまるで違う。「考える」だけでなく「行動する」ことが、リスクの質を一段引き上げる。

　ここで押さえておきたいのは、これらが単独ではなく、重なり合うことで難しさを生むという点だ。確率的なだけなら、出力を人間が確かめてから使えばよい。ツールを選ぶだけなら、選択肢を絞ればよい。外部に作用するだけなら、従来のシステムでも承認フローで管理してきた。ところが3つが同時に成立すると、「何をするか予測しづらいものが、自分で道具を選び、現実を書き換える」という事態になる。従来のソフトウェア工学が積み上げてきた前提の多くが、この重なりの前で通用しなくなる。

3つの性質が生む、3つの設計課題

　これらが重なると、従来の常識が次々に通じなくなる。私たちはこれを3つの構造的な課題として整理している。

　課題1：網羅的テストの不可能性。 決定論的システムなら、入力を分類し代表ケースを検証すれば実用上十分な網羅性が得られた。だが振る舞いに幅があり、実行経路も一定でないエージェントでは、「テストの網羅」という概念そのものが再定義を迫られる。「合格か不合格か」の二値判定から、「どの程度の品質が、どの程度の確率で得られるか」という確率的な品質基準への転換が避けられない。

　課題2：実行時制御の必要性。 全ての実行パスを事前に定義できない以上、運用中の制御が欠かせない。従来は「想定される異常」に事前対処すればよかったが、エージェントでは「想定していなかった行動」に備える必要がある。ツール実行の権限管理、実行量の上限設定、そして重要な操作への人間の承認――これらは「念のため」ではなく前提条件である。

　課題3：説明可能性の困難。 従来はログをたどれば「なぜその結果になったか」を再現できた。エージェントでは「なぜそのツールを選んだか」の説明が本質的に難しい。現実的な対応は、完全な透明性ではなく、十分な追跡可能性の確保――プロンプトから推論、ツール呼び出し、結果に至る実行トレースを記録し、事後に検証できる状態を保つことである。

　この3つの課題は、それぞれ独立しているように見えて、根は1つだ。いずれも「決定論を前提に築かれてきた品質保証・運用・監査の方法論が、確率的なシステムには素直に適用できない」ことから生じている。だからこそ、個別のツールや対策を継ぎ足すだけでは追いつかない。テスト・制御・説明という3つの局面を、確率的なシステムに合わせて設計し直すという発想の転換が要る。

意思決定者が向き合う構造変化

　この変化は情報システム部門だけの話ではない。エージェントは、これまで分かれていた「記録系（基幹システム）」「顧客接点系」「分析系」という企業ITの三層を、1つの処理ループの中で横断する。従来のアーキテクチャが前提にしてきた層の境界が、構造的に曖昧になる。結果として、IT部門の役割は「ソフトウェアの管理者」から「エージェントのガバナー（統治者）」へと転換を迫られる。管理対象が「決定的に動くソフトウェア」から「確率的に判断する自律システム」へ変わるとき、管理の方法論も根本から変わる。

　この転換は、意思決定者にとって決して他人事ではない。層の境界が曖昧になるということは、リスクとその責任の所在も、従来の部門の縦割りに収まらなくなるということだ。1つのエージェントが基幹データを参照し、顧客に連絡し、その結果を分析系に書き戻す――この一連の動きに問題が起きたとき、誰が責任を持つのかは、技術ではなく組織設計の問いになる。AIエージェントの導入とは、システムを1つ増やすことではなく、組織の意思決定と責任の構造に手を入れることなのである。

　AIエージェントの設計とは、優れたモデルを選ぶことではない。この不確実性を、組織としてどう飼いならすかを決めることである。次回以降、その具体――対象選定、セキュリティ、ガバナンス、運用――を順に論じていく。

意思決定者のためのAIエージェント設計論

AIエージェント導入の本質は技術選びではなく「不確実性の統制」にある。従来の常識が通じない自律システムを組織として飼いならし、安全に実装するための設計論の要諦を解く。

この連載の記事をもっと見る

この記事の著者

関連記事

• 

  ビジネスもセキュリティも「数字で示すしかない」 - JERA CIO兼CISO 行徳セルソ氏

• 

  第1回：到来した「自律型AI時代」

• 

  Agentic AI前提でセキュリティを作り直す - Sansan 鴨志田氏

• 

  世界のトップ層は何を議論している？　第一線の論客から見えた「やらかしの正体」

• 

  「エラーの滝」にも怯まず挑戦を続けたから今がある――DeNA IT本部長 金子氏

• 

  「やりたくない仕事」からAI化せよ　――NEC CISOが語る、生成AIでセキュリティ防御を変えるための組織の作法