はじめに
これまでの記事では、Harness、Loop Engineering、Tool Engineering、Memory、そしてClaude Codeのサブエージェントや並列実行といった、AIエージェントの設計そのものを扱ってきました。どれも、エージェントをどう作るか、どう賢く動かすか、という視点でした。
今回は少し角度を変えて、実際に企業の中でAIエージェントを使おうとしたとき、何が壁になるのかを整理してみます。良いエージェントを設計できることと、それが実務で使われ続けることのあいだには、思っている以上の距離があると感じています。
1. 導入はする、けれど動かない
ある調査では、企業の78％がAIエージェントの導入に着手している一方で、実際に本番運用まで進んでいるのは14％にとどまるという結果が出ています。この数字を見て、意外だと感じる人と、やっぱりそうかと感じる人に分かれるのではないかと思います。
自分の実感としては、後者に近いです。デモや検証環境ではうまく動くのに、実際の業務データと実際の権限設計のなかに置いたとたん、途端に扱いづらくなる。これは技術力の問題というより、検証環境と本番環境のあいだにある前提の違いに起因していることが多いように感じます。
2. PoCが成功して見えてしまう理由
PoCの段階では、きれいに整形されたサンプルデータを使い、権限もゆるく設定し、失敗しても誰も困らない環境で動かすことがほとんどです。この状態でうまく動くのは、ある意味当然だと思います。
本番環境はそうはいきません。データは表記揺れだらけで、部署ごとにアクセスできる範囲が異なり、間違った操作をすれば実際に業務が止まります。以前の記事で扱ったTool Engineeringの話がここで効いてきます。PoCの段階で「とりあえず全部のツールを使えるようにしておく」という設計をしていると、本番で権限を絞り込む作業が後から重くのしかかってきます。
3. ガバナンスは後付けできない
データガバナンスの設計は、アーキテクチャ設計と同時に組み込んでおくべきものだとされています。個人情報や社内機密データを扱う可能性がある以上、アクセス権限の設計、認証情報の管理、動作ログの記録と監査体制は、後から追加する付属品ではなく、最初から土台に組み込んでおく部分なのだと思います。
これを後回しにしてしまうと、PoCがうまくいったあとに「では本番に上げましょう」となった段階で、ガバナンス要件を満たすための作り直しが発生します。結果として、せっかく動いていたものが一度止まってしまう、という状況をよく見かけます。
4. アクセス権限をどう設計するか
以前の記事でサブエージェントの権限設計について触れました。読み取り専用の作業には読み取り専用のツールしか渡さない、という考え方です。企業データを扱う場面では、この境界線がより重要になります。
顧客データを参照するエージェントと、それを更新するエージェントは、役割としても権限としても分けておいたほうが安全です。一つのエージェントに何でもできる権限を与えてしまうと、想定していない操作が起きたときの影響範囲が読めなくなります。権限は、そのタスクに本当に必要な最小限に絞る。地味な作業ですが、ここを丁寧にやっておくかどうかで、後々のトラブルの起きやすさがかなり変わってくるように思います。
5. 監査ログという地味だが重要な要素
以前の記事で扱ったObservabilityの考え方は、企業導入の文脈ではそのまま監査要件と重なります。エージェントが何を見て、何を判断し、何を実行したのか。この記録が残っていないと、問題が起きたときに原因を追えませんし、そもそも問題が起きたことにすら気づけないことがあります。
監査ログは、開発者のためのデバッグ情報であると同時に、組織としての説明責任を果たすための材料でもあります。この二つの役割を意識して設計しておくと、あとから「なぜこの動きをしたのか」を聞かれたときに、きちんと答えられる状態を保てます。
6. Human-in-the-loopをどこに置くか
以前の記事で扱ったHuman-in-the-loopの考え方は、企業データを扱う場面でこそ本領を発揮すると感じています。すべての操作を自動化するのではなく、影響範囲が大きい操作や、取り消しが難しい操作については、人間の承認を挟む設計にしておく。
例えば、顧客への一括メール送信や、給与データの更新、契約書の外部送付といった操作は、自動化の恩恵は大きい一方で、間違えたときの被害も大きい領域です。こうした操作にだけ承認ステップを設けておけば、日常的な作業は自動化しつつ、リスクの高い部分だけ人間が最終確認する、というバランスの取れた運用がしやすくなります。
7. 段階的に任せる範囲を広げるという考え方
多くの企業では、PoC、限定運用、そして横展開という3段階を踏んで導入を進めているようです。最初から全社展開を狙うのではなく、まず一つのチーム、まず読み取り専用の範囲から始めて、実際の運用のなかで信頼を積み上げてから、権限とスコープを少しずつ広げていく。
この進め方は、以前の記事で扱ったLoop Engineeringの発想とも重なります。一度に完璧な設計を目指すのではなく、小さく動かして、うまくいかない部分を観察し、改善を積み重ねていく。企業導入という文脈でも、同じサイクルが機能するのだと思います。
8. 実践するうえで意識したいこと
ここまでの内容を踏まえて、実務でAIエージェントを導入する際に意識したいポイントを挙げてみます。
まず、ガバナンス設計を後回しにしないことです。PoCの段階から、本番でどのような権限設計、監査体制が必要になるかを見据えておくと、後からの手戻りを減らせます。
次に、権限は最小限から始めることです。最初から広い権限を与えるのではなく、必要になったときに広げる、という順序にしておいたほうが、トラブルが起きたときの影響範囲を小さく保てます。
そして、リスクの高い操作にだけ人間の確認を挟むことです。すべてを自動化しようとすると、かえって現場の信頼を得にくくなります。どこに人間の判断を残すかを最初に決めておくことが、結果的に自動化の範囲を広げやすくする土台になると感じています。
なお、ある調査会社は2027年までにエージェント型AIプロジェクトの4割がROIの不透明さを理由に中止されるだろうという予測を出しています。あくまで予測であり、そのとおりになるとは限りませんが、技術的に動くことと、組織として続けられることは別の問題だという点は、頭の片隅に置いておいて損はないだろうと思います。
9. まとめ
AIエージェントの実務導入は、良いエージェントを設計するだけでは完結しません。データガバナンス、アクセス権限、監査ログ、Human-in-the-loopの設計。これらはどれも地味な作業ですが、PoCから本番運用へと進むための土台になる部分です。
これまでの記事で扱ってきたHarness、Tool Engineering、Observability、Human-in-the-loop、Loop Engineeringといった考え方は、個々のエージェントを賢くするためだけでなく、組織のなかでエージェントを安全に、そして継続的に動かし続けるためにも、そのまま活きてくるのだと感じています。
次回は、RAGとローカルLLMについて扱う予定です。
関連記事
- AIエージェントのTool Engineering入門
- AIエージェントのObservability設計
- AIエージェントの失敗とRecovery Engineering
- Human-in-the-loopとは何か
- Loop Engineeringとは何か？AIエージェントを「失敗から改善するシステム」に変える方法