AIエージェントの アーキテクチャ事例16選

AIエージェントは、実運用でどのようなアーキテクチャを採用しているのか。

OpenAI、Anthropic、AWS、Microsoft、GitHub、Shopify、国内の事業会社・SIerなどが2026年に公開した構成図から、16事例を選んで整理しました。

「実行環境と隔離」「学習と改善のループ」「運用基盤と統制」「音声AIの基盤」の4領域に分け、原典の構成図とともに、構成要素・設計上の特徴・実務で学べるポイントを紹介しています。

16事例を横断して見えてきたのは、モデルの能力だけに頼らず、実行範囲・評価・承認・統制をモデルの外側で設計するという共通点です。

AIエージェントの設計・開発・導入に携わる方の参考になれば幸いです。

Transcript

1. 2026 年のアーキテクチャ構成図から学ぶ AI エージェントの アーキテクチャ事例 16 選 OpenAI や Anthropic など海外の大手と 国内の事業会社・ SIer が公開した構成図を学ぶ 為安 圭介 2026 年 10 月
2. この資料について 16 事例を、 5 つの設計課題に分けて読む 目的 対象 公開された構成図から、 AI エージェントを本番で 動かすときの設計判断を学ぶ 第1章 エージェントの中心（ハーネス）を、どう組み、どこに置くか p.4 Agents API 第2章 AI システムの設計・導入に関わるアーキテクト、 エンジニア、事業側の推進者 p.5 Foundry Hosted agents p.6 Copilot ランタイム p.7–8 Claude Cowork モデルと処理の分業 1 つのモデルに任せず、処理をどう分けて受け持たせるか p.10 GPT-Live 第3章 選び方 ハーネスの組み方と置き場所 p.11 Qubot p.12 WebRTC 音声基盤 品質を上げ続ける仕組み 本番の失敗と人の修正を、どう次の改善に回すか 2026 年 4 月 1 日以降に、企業の技術ブログや登壇 資料などで構成図が公開された 32 件から、 16 件 を採用した p.14–15 税務 AI 第4章 p.16–17 Sidekick p.18 富士通 MAAF コード実行の場所と届く範囲 AI が書いたコードを、どこで動かし、どこまで届かせるか 読み方 各事例は、冒頭の文章で目的と構成の工夫をつか み、アーキテクチャ説明と設計の工夫を図の番号 で追う。出典情報にない補足は点線枠で示した p.20 Codex サンドボックス 第5章 p.21 リクルート エージェントと開発の統制 増えるエージェントと AI 駆動の開発を、どう管理下に置くか p.23 AWS Agent Registry p.24–25 ビズリーチ p.26 ラクス p.27 ドコモビジネス 2
3. 第1章 ハーネスの組み方と置き場所 設計課題 エージェントの中心（ハーネス）を、どう組み、どこに置くか 事例 01 OpenAI の Agents API OpenAI p.4 設計 ハーネスを OpenAI に預ける 事例 02 Microsoft Foundry の Hosted agents Microsoft 設計 ハーネスをコードのまま預ける 事例 03 Copilot ランタイムの Rust 移行 GitHub p.6 設計 ランタイムをプロセス内に移す 事例 04 Claude Cowork の封じ込め Anthropic 設計 ループを外に出しても安全性を保つ p.7–8 p.5
4. 事例 01 OpenAI の Agents API ハーネスの組み方と置き場所｜ OpenAI ｜ 2026 年 09 月 10 日 1/1 ハーネスを API として借りる Agents API は、アプリを作る開発者が、長時間動くエージェントのハーネス（ループと文脈の管理）を自前で保守せずに使うための API で ある。ハーネスは OpenAI が保守し、コードを動かす実行環境は切り離して、 OpenAI の環境か、自社や提携先の環境から選べるようにし た。 アーキテクチャ説明 ① Application （ You ） タスクを送り、返ってくるイベントと出力を利用者に 見せる ② Agents API （ OpenAI ） 出しと文脈の管理を担う OpenAI が保守する Codex ハーネス。モデル呼び ③ Tool calls / Tool results 取る ②はツール呼び出しを④へ送り、その結果を受け ④ Sandbox コードの実行とファイルを担う。 OpenAI の管理下にも、利用者 が選んだ提供元にも置ける ⑤ 自前の計算環境 ④を自前で用意する場合は、①のアプリ側がその環境を管理 する 補足（本文より） ② は文脈の上限が近づくと過去の文脈を自動で圧縮する。ツール 定義は必要になったときに読み込む 1 2 自社アプリ 4 預けるハーネス 実行環境 3 ④ は自前の環境（ VPC 内も可）か、提携する 9 社の環境から選べる 設計の工夫 ハーネスを OpenAI に預ける 出典情報は、新しいモデルの能力を使うにはハーネスの作り直しが必要になることが多 く、アプリの改善に使う時間が削られるとしている。②はモデルの公開ごとに版を付け て提供され、 OpenAI がモデルと並行して改善する。④は利用者の側にも置ける。顧客 の Hypha 社は、ハーネスと実行環境を分けたことで失敗応答が 86% 減ったと述べてい る。 5 自前の環境も可 出典情報 OpenAI（openai.com） 学ぶポイント ②④ ハーネスと実行環境は別々に置ける。②はツール呼び出しを送るだけで、コードの 実行は④で行う。④の置き場所を変えても②はそのまま使える。 補足 ツール定義は必要な分だけ読み込む。出典情報は、ツール検索で関係する定義だけを 必要時に読み込み、トークン使用量と費用を減らすとしている。
5. 事例 02 Microsoft Foundry の Hosted agents ハーネスの組み方と置き場所｜ Microsoft ｜ 2026 年 09 月 11 日 1/1 自作のハーネスをコンテナで預ける Hosted agents は、エージェントを自作した開発者が、そのコードをコンテナのまま Microsoft Foundry に預けて本番運用するための仕組 みである。セッションごとに VM で隔離した実行環境を作り、使っていない間はコンピューティングを解除してファイルだけ残すので、台数 を設定せずに状態を保ったまま費用を抑えられる。 アーキテクチャ説明 ① Container image C# ② 専用の入口とエージェント ID ③ セッションごとのサンドボックス セッションごとに VM で隔離し、①を動かす。モデルとツールを呼ぶループ もこの中で回る ④ セッションのライフサイクル 要求が既定 15 分ないとコンピューティングのプロビジョニングを解除し、 $HOME と /files だけ保存する ⑤ Models / Toolbox る 2 入口と ID 1 自分のコード 3 セッションごとの VM 利用者が書いたエージェントのコード。フレームワークは自由に選べ、言語は Python か デプロイ時に自動で作られる。入口は Microsoft Entra ID で認証する ③のコードがエージェント ID で呼ぶ。ツールはプロジェクト共通の MCP の入口に集め 4 待機と再開 上の青い枠は Microsoft が管理する部分、緑の枠はセッションごとの実行環境 設計の工夫 ハーネスをコードのまま預ける 出典情報は、オープンソースのフレームワークで作ると、コンテナ化からスケールまでの横断的な作業を自分で抱えると している。プロンプトで定義するエージェントと違い、①には任意のフレームワークや自作のコードを使える。②から④ はプラットフォームが受け持つ。③はセッションごとに作るので、レプリカ数や待機させる台数を設定しない。 5 モデルとツール 出典情報 Microsoft Learn（learn.microsoft.com） 学ぶポイント ①③ ハーネスを自作しても、置き場所は預けられる。利用者が持つのは③の中で動くコ ードだけになる。入口やセッションの状態は周りの基盤が持つ。 ③④ 実行環境の寿命はセッションに合わせる。使っていない間は環境を解除し、ファイ ルだけ残す。再開したコードは前に書いたファイルを同じ場所で見つけられる。
6. 事例 03 Copilot ランタイムの Rust 移行 ハーネスの組み方と置き場所｜ GitHub ｜ 2026 年 09 月 16 日 1/1 ランタイムをアプリのプロセス内に置く Copilot のエージェントランタイムは、 GitHub の製品やパートナーが 6 言語の SDK から呼び出す、エージェントの実行部分であ る。 GitHub はこれを TypeScript から Rust に書き直し、アプリと同じプロセスに読み込めるようにしたうえで、別プロセスで動かす経路 も残した。 アーキテクチャ説明 ① Headless CLI （移行前） SDK が CLI を別プロセスとして起動し、標準入出 力の JSON-RPC で呼んでいた ② Node.js + V8 （移行前） ①を動かす言語ランタイム。クライアントごとに 少なくとも約 100MB のメモリを使う ③ In Proc の Rust runtime アプリと同じプロセスに FFI で読み込 む。 Node.js も V8 も要らない ④ Out of Proc の Rust runtime 別プロセスでも動かせる。サブプロセスや TCP の先にあるランタイムにはこの経路が要る 左が移行前、右が移行後。 SDK は 6 言語で提供され、どれも同じ経路を使う 設計の工夫 ランタイムをプロセス内に移す 移行前は、どの言語の SDK も①を起動するために②を同梱し、クライアントごとに 2 つ 目の言語ランタイムの費用を払っていた。出典情報は、 Node.js への依存と別プロセス の管理が、 SDK を採用するパートナーから最も多く聞く障害だったとしている。 10 ク ライアントの計測で、追加メモリは移行前の 1,383MB に対し、④で 247MB 、③で 126MB だった。 補足（本文より） ③ は C ABI の 19 関数で呼ぶ。 API 呼び出しは従来と同じ JSON-RPC のバイト列として、 関数呼び出しで渡す 1 別プロセスの CLI 2 言語ランタイム アプリ内で動く 別プロセスも可 出典情報 3 4 The GitHub Blog（github.blog） 学ぶポイント ③④ ランタイムは両方の置き方で動くように作る。同じプロセスは軽く、別プロセスは 離れた場所にも置ける。プロセス内は障害の境界を共有するので選べるようにする。 補足 埋め込み用の入口は少数の関数に絞る。 API の追加や変更は振り分け表で吸収 し、 ABI には触れない。 SDK は 19 の入口を一度結べば済む。
7. 事例 04 Claude Cowork の封じ込め ハーネスの組み方と置き場所｜ Anthropic ｜ 2026 年 05 月 25 日 1/2 ループとコード実行を分けて置く Claude Cowork は、コマンドを読めない利用者も含めて、 Claude にファイル操作やコード実行を伴う作業を任せるためのデスクトップ製 品である。最初はエージェントのループも VM に入れていたが、ループは利用者の PC 側に出し、 AI が書いたコードの実行だけを VM に残 した。 アーキテクチャ説明 ① 最初の版（ A ） ループもコード実行も VM の中。 VM の起動に失敗すると Cowork 全体が止まった ② ループ（ B ） る ③ コード実行（ B ） る ④ ローカル MCP サーバー（ B ） PC 側へ移した。 VM の中では監査しにくく、 VM を更新するたびに依存関係の不具合が出た PC 側で動かす。 VM が落ちても応答や原因の調査を続けられ VM の中に残す。次ページの VM の隔離境界がそのまま守 1 最初の版 PC 側のループ 2 コード実行だけ 3 設計の工夫 ループを外に出しても安全性を保つ 守るべきは、エージェントが書いて実行するコードである。③が VM の中にある限り、 ループを VM の外に出してもファイルと通信の制限は変わらない。出典情報は、この変 更の安全面への影響を最小と評価している。 4 出典情報 MCP も PC 側 Anthropic Engineering Blog（www.anthropic.com） 学ぶポイント ②③ 守る対象だけを VM に入れる。ループまで閉じ込めると、 VM の不調がそのまま製品 の停止になる。 ④ 監査したい部品は VM の外に置く。 VM の中に置くと監査しにくい。出典情報は MCP サーバーを PC 側に移した。
8. 事例 04 Claude Cowork の封じ込め ハーネスの組み方と置き場所｜ Anthropic ｜ 2026 年 05 月 25 日 2/2 コード実行は VM の隔離境界で守る 前ページで VM に残したコード実行は、 VM の外側と内側の隔離で守る。外側の境界は VM の中で管理者権限を取られても破られ ないので、コマンドを読めない利用者にも承認なしで作業を任せられる。 アーキテクチャ説明 ⑤ VM の隔離境界（ハイパーバイザー境界） VM のメモリを PC 本体から切り 離す。 VM の中で管理者権限を取られても破られない ⑥ PC との通信路（ vsock ） を通らない ⑦ VM 内の隔離（ 4 つ） れると破られうる ⑧ 許可リスト（出口プロキシ） に絞る。⑦の 1 つ PC と VM をつなぐ専用の通信路。ネットワーク VM の中の OS が守る仕組み。中で管理者権限を取ら VM から外への通信を、許可したドメインだけ 7 5 VM の隔離境界 6 PC との通信路 VM 内の隔離 設計の工夫 利用者に合わせて隔離を強める Claude Code の利用者は開発者で、コマンドを読んで承認できる。 Cowork の利用者に はそれを求められないので、承認に頼らず常に有効な隔離境界を置いた。出典情報は、 隔離の強さを、利用者が操作を監督できる度合いに合わせるとしている。 許可リスト 8 補足（本文より） ⑧ の許可ドメイン経由でファイルを 持ち出された事故があり、 VM 自身 のトークンが付いた通信だけを通す ように直した 出典情報 Anthropic Engineering Blog（www.anthropic.com） 学ぶポイント ⑤⑥ 最後の防御は VM の外側に置く。 VM の内側の隔離（⑦）は乗っ取られると破られ うる。出典情報も内側の隔離は最小限にとどめ、外側に頼っている。 ⑧ 許可リストは宛先しか見ない。許可したドメインの機能を使えば持ち出せる。誰の資 格情報で送る通信かまで確かめる。
9. 第2章 モデルと処理の分業 設計課題 事例 05 1 つのモデルに任せず、処理をどう分けて受け持たせるか OpenAI の GPT-Live OpenAI p.10 設計 推論を音声の経路から外す 事例 06 GitHub の社内データ分析エージェント Qubot GitHub 設計 文脈をデータの持ち主に書かせる 事例 07 OpenAI の音声 AI 向け WebRTC 基盤 設計 接続の状態を 1 か所に集める OpenAI p.12 p.11
10. 事例 05 OpenAI の GPT-Live モデルと処理の分業｜ OpenAI ｜ 2026 年 08 月 03 日 1/1 音声モデルと推論モデルを分ける GPT-Live は、利用者が AI と音声で途切れずに会話するための、 OpenAI の音声対話システムである。聞きながら話せる音声モデ ルが会話を受け持ち、深い推論とツールの利用は非同期で文字のモデル（ GPT-5.5 ）に任せて、遅い処理が音声を止めないように した。 アーキテクチャ説明 ① Media frontend 利用者と②の間で音声を送受信する。この経路は止めずに流し続ける ② GPT-Live-1 （音声モデル） 全二重で、聞きながら同時に話せる。会話そのものを受け持つ ③ Delegation request 深い推論やツールが要るとき、非同期の RPC 境界を越えて④へ渡す ④ Application server 委譲と業務ロジックを担う。通話の開始時に⑤の推論セッションを作っておく ⑤ GPT-5.5 （文字モデル） 深い推論を受け持ち、検索やコード実行のツールを使う。結果と指示を①へ返す 1 上段の白い箱が音声の経路、下段の青い箱が非同期の委譲の経路 非同期の委譲 3 4 委譲の窓口 音声の中継 音声モデル 補足（本文より） 以前は小さなターン検出モデル が発話の終わりを推定してい た。②は聞きながら話せるの で、これを音声の経路から外 した 設計の工夫 推論を音声の経路から外す 出典情報は、通信や推論の遅れはそのまま聞こえる間や音の乱れになるとしている。②は音声の流れを受け持ち、深い 推論とツールは③から④⑤へ非同期で渡す。遅いツール呼び出しは自分の結果を遅らせても、音声の流れは止めない。 ④は通話の開始時に⑤のセッションを作って最初の文脈を読み込み、通話の間ずっと保つ。 2 5 推論モデル 出典情報 OpenAI Engineering（openai.com） 学ぶポイント ③ 遅い処理は音声と別の非同期経路に置く。ツールの呼び出しが遅れても、遅れるのは その結果だけになる。①②の間の音声は流れ続ける。 ④⑤ 委譲先のセッションは会話の開始時に作る。最初の文脈を先に読み込んでおけば、 最初の委譲で読み込みを待たずに済む。
11. 事例 06 GitHub の社内データ分析エージェント Qubot モデルと処理の分業｜ GitHub ｜ 2026 年 06 月 19 日 1/1 文脈はデータの持ち主が書く Qubot は、 GitHub の社員が自然言語で社内データを分析するためのエージェントで、 Slack や VS Code から使える。答えに要る 指標の定義やスキーマ情報は、データを持つ各チームが共通の文脈層に書き、 Qubot は実行時にそれを読み込んで問い合わせ先の エンジンを選ぶ。 1 アーキテクチャ説明 ① Context layer チーム スキーマ情報や指標の定義をリポジトリに置く。書き手はデータを持つ各 ② Context Agent テンプレートやリポジトリで寄せられた文脈を、決まった形式に整える。 変更は Eval で評価してから出す ③ GH MCP Server ④ Qubot Copilot で動く分析エージェント。推論と計画を受け持ち、どのエンジンに問うか を決める ⑤ Trino と Kusto 既定は直近のデータの探索に向く Kusto 。複雑な結合や長い期間の分析で は Trino に切り替える 文脈層 文脈を整える 補足（本文より） 2 生イベントの文脈は製品チームが 書く。整形済みデータの文脈はデ ータチームが保つ。指標の定義は、 実行時に読む 3 そのデータを持つチームが書く 実行時に①から文脈を読み込み、④に渡す 4 推論と計画 質問は Slack や VS Code などから届く。緑の線が文脈、青緑の線がデータの流れ 設計の工夫 文脈をデータの持ち主に書かせる 出典情報は、数十の製品チームに専任の分析担当を付けるのは難しいとしている。①は書き手をデータ の持ち主に分け、②が形式をそろえる。④は推論を受け持ち、答えに要る知識は③から実行時に受け取 る。出典情報は、構造化され整理された文脈で、回答がより正確になり、正しい答えを返すまでが 3 倍 速くなったとしている。 問いで選ぶ 5 出典情報 The GitHub Blog（github.blog） 学ぶポイント ①② 文脈はそのデータを持つチームに書かせる。書き手が分かれても、②で同じ形式に 整えれば 1 つのエージェントで使える。 ⑤ 既定のエンジンを決め、要るときだけ切り替える。出典情報は探索に向く Kusto を既 定にし、問いが求めるときだけ Trino へ自動で切り替える。
12. 事例 07 OpenAI の音声 AI 向け WebRTC 基盤 モデルと処理の分業｜ OpenAI ｜ 2026 年 05 月 04 日 1/1 通信の状態は Transceiver だけが持つ この基盤は、 ChatGPT の音声機能と Realtime API で、利用者と AI の音声をやり取りするための WebRTC 基盤である。接続の状態は Transceiver だけに持たせ、公開の入口の Relay は転送だけを行い、推論側は内部プロトコルで受けることで、 Kubernetes 上で拡張しや すくした。 アーキテクチャ説明 ① Web / Mobile ブラウザとモバイル。標準の WebRTC のままつながる ② Relay UDP を転送するだけの公開の入口。メディアを復号せず、 ICE の状 態も持たない ③ Transceiver ビス ④ Inference Backend を扱わない 補足（本文より） ② は最初のパケットに入った経路情報（ ufrag ）を読み、③ へ転送する。再起動しても次のパケットで経路を作り直せる WebRTC を終端し、セッションの状態をすべて持つ唯一のサー ③と単純な内部プロトコルでやり取りする。 WebRTC 1 利用者 2 状態なしの入口 3 状態を持つ 実線は WebRTC 、点線は推論用の内部プロトコル。 LB は②の群へ振り分ける 設計の工夫 接続の状態を 1 か所に集める 多人数向けの SFU は、 AI も WebRTC の参加者にする。音声 AI のセッションの多くは利 用者 1 人とモデル 1 つの 1 対 1 なので、③で終端して内部プロトコルに変える方式を選 んだ。出典情報は、状態を③に集めたことでセッションの持ち主を把握しやすくなり、 ④は WebRTC の相手として振る舞わずに普通のサービスとして拡張できたとしている。 推論側 出典情報 4 OpenAI Engineering（openai.com） 学ぶポイント ②③ 状態を持つ処理は 1 か所に集める。③がセッションの状態をすべて持ち、②は転送 だけを行う。②は再起動しても通信がすぐ戻る。 ③④ 推論側には通信の状態を持たせない。④は③と内部プロトコルでやり取りするので、 WebRTC の相手にならずに台数を増やせる。
13. 第3章 品質を上げ続ける仕組み 設計課題 事例 08 本番の失敗と人の修正を、どう次の改善に回すか 税務 AI の自己改善ループ 設計 事例 09 OpenAI × Thrive Holdings Codex に任せる範囲を区切る Sidekick の継続学習ループ Shopify 設計 ハーネスの次に重みを学習する 事例 10 富士通 MAAF の自己進化 設計 反映の前に検証を挟む 富士通 p.18 p.16–17 p.14–15
14. 事例 08 税務 AI の自己改善ループ 品質を上げ続ける仕組み｜ OpenAI × Thrive Holdings ｜ 2026 年 05 月 27 日 1/2 会計士の修正を評価にして Codex に直させる 税務 AI は、米国の会計事務所網 Crete の会計士が確定申告書の下書きを作るためのエージェントである。会計士が本番で直した値 を記録して評価に変え、 Codex が修正の候補 PR を作り、エンジニアがレビューして出荷する改善ループを回している。 アーキテクチャ説明 補足（本文より） ① Production trace ② Failure signal い ③ Evals ④ Product change ⑤ Codex ⑤ が書き込めるのは作業ツリーだけ。本番 の記録と原資料は読み取り専用で渡す 原資料からの抽出値、提出、会計士の修正までの経路を残す AI の出力と提出済みの申告書を項目ごとに比べる。人が見て対象外とした差は③に入れな 1 本番の記録 失敗の兆候 3 評価 繰り返す失敗を、成功条件のはっきりした評価にする（次ページ） ⑤の修正は候補 PR になり、エンジニアがレビューして出荷する ①③をリポジトリやスキルと合わせて調べ、直して評価を再実行する 5 出荷した変更が新しい本番作業を生み、新しい証拠として①に戻る 設計の工夫 2 修正する Codex Codex に任せる範囲を区切る 自動化するのは、原資料から項目を抽出し、税務の流れへ写す層に限る。⑤は対象の評価と回帰テストを通してから候 補 PR を出す。証拠が曖昧な案件や安全に自動化できない案件はループに通さず、製品チームに戻す。設計と出荷の判断 はエンジニアが持つ。開始時に項目の 75% 以上が正しい申告書は約 4 分の 1 だったが、 6 週間で 86% になった。 4 製品の変更 出典情報 OpenAI Engineering（openai.com） 学ぶポイント ⑤ 修正を担うエージェントには書ける範囲を区切って渡す。書き込めるのは作業ツリー だけにし、本番の記録と原資料は読み取り専用にする。証拠を変えずに原因を調べられる。 ④ 自動の修正は候補 PR で止め、人が出荷する。⑤は評価と回帰テストを通した候補 PR を出すところまで。設計と出荷の判断はエンジニアが持つ。
15. 事例 08 税務 AI の自己改善ループ 品質を上げ続ける仕組み｜ OpenAI × Thrive Holdings ｜ 2026 年 05 月 27 日 2/2 修正を型にまとめて直す対象を選ぶ 前ページの③に入る評価は、会計士の修正を絞り込んで作る。修正には製品の失敗のほか、会計士の好みや前年値の引継ぎによる 差も混ざるため、失敗の型ごとにまとめてから繰り返す型を選ぶ。 アーキテクチャ説明 ⑥ Review rows 期待値と予測値を項目ごとに並べた行。会計士の上書きと提 出済みの申告書から作る ⑦ Cluster by failure mode 似た行を失敗の型ごとにまとめ、件数を数える ⑧ Noise / not actionable て除く 好みや前年値の引継ぎによる差。製品の失敗と分け ⑨ Selected hill 6 修正の記録 7 9 失敗の型 直す対象 繰り返す型を 1 つ選び、成功の指標を付けて評価の種にする 設計の工夫 修正から対象外の差を除く 差の原因は製品の失敗とは限らない。会計士の好みや前年の申告から引き継いだ値のこ ともあり、申告の流れの別の場所で入った値のこともある。⑦でまとめて⑧を除き、⑨ で繰り返す型を 1 つ選ぶと、 Codex に成功条件のはっきりした範囲の決まった課題を渡 せる。 8 出典情報 対象外の差 OpenAI Engineering（openai.com） 学ぶポイント ⑦⑧ 人の修正は型ごとにまとめてから使う。修正には好みや前年値の引継ぎも混ざる。 型ごとにまとめ、製品の失敗でない型を除いてから評価にする。 ⑨ 直す対象は 1 つずつ選んで渡す。繰り返す型を 1 つ選び、成功の指標を付ける。修正 を担うエージェントは範囲の決まった課題として取り組める。
16. 事例 09 Sidekick の継続学習ループ 品質を上げ続ける仕組み｜ Shopify ｜ 2026 年 08 月 05 日 1/2 失敗した会話を毎日の学習に回す Sidekick は、 Shopify の加盟店向けの AI アシスタントである。本番で失敗した会話を判定器で選んで修復し、毎日小型モデルの 学習に使うことで、プロンプトの修正だけに頼らず、モデルの重みまで改善している。 アーキテクチャ説明 ① Ground Truth Set 一致度を確かめる 品質の基準を決める。専門家 2 人が同じ 25 件を採点し、 ② LLM as a Judge 限になる ③ Frontier Model MVP スを改善する ④ Data Collection + Self-healing ②が低く採点した本番の会話を集め、修復 して学習データにする（次ページ） ⑤ Model Training 5 ③ では重みを変えない。エージェントがハーネスへの変更を提案し、②の 点数が上がれば残す。頭打ちになってから④⑤へ進む ①に合わせて較正した採点役。人どうしの一致度がその上 既製の大型モデルで早く出し、重みを変えずにハーネ 小型モデルを学習 補足（本文より） 1 正解の集合 2 判定器 3 既製モデル 4 失敗を集める 修復した会話でオープンウェイトの小型モデルを学習する 右下の 06 （システムプロンプトの圧縮）はこの資料では扱わない 設計の工夫 ハーネスの次に重みを学習する 出典情報は、本番に置いたフロンティアモデルは重みが固定され、本番で分かったこと を取り込む仕組みを持たないとする。改善はプロンプトやハーネスのコードに積み上が っていく。 Shopify は③でハーネスを改善し、頭打ちになってから④⑤で重みの学習に 移る。④⑤は毎日回し、新旧の会話を混ぜて学習して、前に覚えたことを忘れるのを抑 える。 出典情報 Shopify Engineering（shopify.engineering） 学ぶポイント ③④ 重みの学習はハーネスの改善が止まってから。③では重みを変えずにハーネス全体 を改善する。頭打ちになってから、本番の失敗会話を④⑤の学習に回す。 ①② 判定器は人どうしの一致度で較正する。専門家 2 人の一致度が判定器の上限になる。 一致度が 0.2 前後なら評価基準があいまいなので作り直す。
17. 事例 09 Sidekick の継続学習ループ 品質を上げ続ける仕組み｜ Shopify ｜ 2026 年 08 月 05 日 2/2 失敗会話は直してから学習に使う 前ページの④で、判定器が低く採点した本番の会話を学習データに変える手順。複数のモデルが失敗を批評し、まとめた修復の指 示を差し込んでから会話を再生して、判定器で採点し直す。 アーキテクチャ説明 ⑥ Failed convo める ②が低く採点した本番の会話。匿名化した本番の通信から集 ⑦ Critic 1 〜 3 する 複数のフロンティア推論モデルが、それぞれ失敗の原因を批評 ⑧ Arbiter ⑦の批評を 1 つの修復の指示にまとめる ⑨ Repair critique 利用者の発話の直前に差し込む。出典情報はこの手法を hinting （ヒントを足す）と呼ぶ ⑩ Assistant replay 差し込んだ位置から再生し、②で採点し直す。合格すれば 学習データに、直らなければ人の注釈に回す 7 6 失敗した会話 設計の工夫 修復した会話で小型モデルを学習する 複数の批評 8 修復の指示 9 まとめ役 ここから再生 10 出典情報 Shopify Engineering（shopify.engineering） 合格した会話は、推論の過程も含めて教師ありファインチューニングで小型モデルに移 し、続けて判定器の点数を報酬に強化学習（ GRPO ）をかける。出典情報は、こうして 学習した小型モデルがフロンティアモデルの性能を上回ったとし、推定の運用費は年 2,700 万ドルから約 100 万ドルへ 96% 下がるとしている。 学ぶポイント ⑨⑩ 失敗会話は修復の指示を足して再生する。直った会話はそのまま学習データになる。 直らない会話だけを人の注釈に回せる。 ⑥⑩ 採点役は学習の報酬にも使う。較正した判定器で失敗会話を選び、修復後の再採点 にも使う。強化学習でもその点数を報酬にする。
18. 事例 10 富士通 MAAF の自己進化 品質を上げ続ける仕組み｜富士通｜ 2026 年 07 月 13 日 1/1 効果を確かめた変更だけ反映する MAAF は、企業が業務文書からマルチエージェントの仕組みを構築し、運用しながら改善し続けるための富士通の基盤である。実 行履歴と人のフィードバックから改善候補を作り、実行環境で効果を確かめた変更だけを反映して、性能を落とす変更を防ぐ。 アーキテクチャ説明 ① データベース・実行履歴 稼働中の実行履歴。本文では、人のフィードバック と合わせて改善候補の材料になる ② 自己進化 インナー 稼働中のエージェントチームが、実行から活用までのサ イクルを回す ③ 検証 改善候補を実行環境で試し、効果が確認された変更だけを反映する ④ 自己進化 アウター ゴール達成の側から仕様策定へ戻る経路。設計まで遡っ て見直す ⑤ 仕様策定と MAS 設計 業務文書から自動化の案を作り、ツールを正しく呼び 出せると確かめてから出す ②④ の働きは本文に説明がなく、図から読み取れる範囲で書いた 補足（本文より） 重要な変更には人の承認や 確認を入れ、変更履歴を監 査できる形で残す 5 3 1 設計の工夫 反映の前に検証を挟む MAAF は構築から運用、改善までを 1 つのライフサイクルとして扱い、実行履歴と人の フィードバックから改善候補を作る。候補はプロンプトから役割分担まで及ぶ。出典情 報は性能を落とす変更を「誤進化」と呼び、これを防ぐために③で候補を実行環境で試 し、効果が確認された変更だけを反映するとしている。 2 4 出典情報 富士通 研究開発トピックス（global.fujitsu） 学ぶポイント ③ 自動の改善にも検証の工程を置く。改善候補は実行環境で試し、効果が確認できたも のだけを反映する。性能を落とす変更が本番に入るのを防ぐ。 補足 重要な変更は人が承認し、履歴を残す。自分で改善する仕組みでも、重要な変更には 人の承認か確認を入れ、後から監査できるようにする。
19. 第4章 コード実行の場所と届く範囲 設計課題 事例 11 AI が書いたコードを、どこで動かし、どこまで届かせるか Codex の Windows サンドボックス OpenAI p.20 設計 通信の制限を OS に任せる 事例 12 リクルートの分析エージェント用コード実行環境 設計 通信を断ち、データは切り出して渡す リクルート p.21
20. 事例 11 Codex の Windows サンドボックス コード実行の場所と届く範囲｜ OpenAI ｜ 2026 年 05 月 13 日 1/1 コマンドは専用ユーザーで動かす Codex は、開発者に代わってコマンドを実行する OpenAI のコーディングエージェントである。 Windows には macOS の Seatbelt に当た る標準機能がないため、コマンドを専用ユーザーとして動かし、書き込みは制限トークン、通信はファイアウォールで OS に制限させる仕組 みを作った。 アーキテクチャ説明 ① codex.exe 利用者本人として動く本体。管理者権限を持たない ② setup.exe 初回だけ管理者権限で動き、専用ユーザーとファイアウォール規則を用意する ③ ファイアウォール規則 オフライン用の専用ユーザーからの外向き通信を止める ④ command-runner.exe ⑤ 制限トークン に限る 3 1 本体 実行役 通信を止める 4 専用ユーザーとして動く実行役。コマンドはここから起動する Windows でプロセスの権限を絞る仕組み。書き込める場所を作業フォルダ 書き込みを絞る 5 ⑤ の範囲でも、 .git などの設定フォルダは書き込み不可にしている 設計の工夫 通信の制限を OS に任せる 最初の試作は専用ユーザーを使わず、通信は環境変数で届かない宛先に向けるだけだった。コマンドは 環境変数を無視して直接通信できるため、出典情報は危険すぎると判断した。 Windows のファイアウ ォールは、権限を絞っただけのプロセスを見分けられない。そこでコマンドを別ユーザーとして動か し、③で止めた。 2 初期設定 出典情報 OpenAI（openai.com） 学ぶポイント ③④ 通信は OS が見分けられる単位で止める。環境変数による制限はコマンド側で無視 できる。専用ユーザーにすれば、ファイアウォールでまとめて止められる。 ①② 管理者権限は初期設定だけに閉じる。常に動く本体は昇格させない。出典情報は、 管理者の確認を越えるのを必要なときだけにするためとしている。
21. 事例 12 リクルートの分析エージェント用コード実行環境 コード実行の場所と届く範囲｜リクルート｜ 2026 年 07 月 30 日 1/1 生成コードは閉域のコンテナで動かす この環境は、店舗オーナーの問いに AI が自らデータを分析して答えるため、 AI が書いた分析コードを実行するリクルートの基盤である。 コードは外と通信できない使い捨てのコンテナで動かし、データはシステムが BigQuery から切り出してファイルで渡すので、任意のコー ドでも持ち出しをインフラ側で防げる。 アーキテクチャ説明 ① Controller 返す ② Data Provisioner ③ ファイルストレージ セッションごとのフォルダ。④にはこのフォルダだけを 見せる ④ 分析環境コンテナ 分析ライブラリ入りの実行環境。依頼ごとに起動し、終わ ったら捨てる ⑤ 外部ネットワークアクセスなし ④とそれを動かす VM は外と通信できない 5 コード実行の依頼を受ける入口。結果は③のファイルの場所で 1 必要なデータを BigQuery から切り出し、③に置く 2 4 3 出典情報の注記： 2025 年時点の構成で、最新では異なる可能性がある 設計の工夫 通信を断ち、データは切り出して渡す 任意のコードを動かしたいが、コードの中身を事前に検査するには限界があり、外を読 みに行くだけの通信でも持ち出しの経路になる。そこで⑤で通信を断ち、データは②が BigQuery から切り出して渡す。コンテナは捨てるので、途中経過や結果は③のファイル に残す。 出典情報 Speaker Deck（speakerdeck.com） 学ぶポイント ⑤ 持ち出しは通信を断って防ぐ。コードの検査には限界がある。通信がなければ持ち出 しの経路もない。 ②③ データはシステムが選んで渡す。生成コードにデータベースを直接触らせなければ、 何を見せるかをコードの外で決められる。
22. 第5章 エージェントと開発の統制 設計課題 増えるエージェントと AI 駆動の開発を、どう管理下に置くか 事例 13 AWS Agent Registry のエージェント管理 AWS p.23 設計 審査を外につなぐ 事例 14 ビズリーチの AI 駆動開発の統治構造 ビズリーチ（ Visional ） p.24–25 設計 判断の役割を分ける 事例 15 ラクスの伝票作成 AI エージェントの実行基盤 ラクス p.26 設計 慣れた基盤を選ぶ 事例 16 NTT ドコモビジネスのクローズド AI エージェント 設計 専用環境の運用まで引き受ける NTT ドコモビジネスほか p.27
23. 事例 13 AWS Agent Registry のエージェント管理 エージェントと開発の統制｜ AWS ｜ 2026 年 08 月 31 日 1/1 審査を通ったものだけを検索に出す AWS Agent Registry は、組織の管理者が、社内で増えるエージェントやツールを 1 つのカタログで管理するためのサービスである。 承認フローは製品に入れず、承認待ちをイベントで外に渡して組織の審査につなぎ、審査を通ったものだけを利用者の検索に出す。 アーキテクチャ説明 ① レコード（ Custom / MCP / Agents / Skills ） 開発者がエージェントやツールを登 録し、承認を申請する ② AWS Agent Registry 組織内のエージェントとツールを 1 つのカタログで管理す る。承認フローは内蔵しない ③ Amazon EventBridge レコードが承認待ちになると、イベントとして外へ渡す ④ Approval workflow つなぐ 管理者が組む審査。セキュリティ走査や重複の確認をここで ⑤ update-registry-record-status カタログ 2 3 承認待ちを通知 組織の審査 4 審査の結果を API かコンソールで②に反映する 結果を反映 図中の緑の数字は出典情報の手順番号で、①〜⑤とは別 5 設計の工夫 審査を外につなぐ ② は承認フローを内蔵せず、組織ごとの手順をつなぐ口だけを持つ。③で承認待ちを知らせ、 管理者が④を組む。出典情報は、初めは CI/CD のチェックリストや Slack での承認で足りると している。承認待ちや承認済みのレコードを更新すると下書きに戻り、提出からやり直す。 1 登録するもの 補足（本文より） 承認されると検索面に公開され、 利用者の検索には承認済みだけ が出る。統制面は下書きや却下 も含む全レコードを持つ 出典情報 AWS Machine Learning Blog（aws.amazon.com） 学ぶポイント ③④ 審査は製品に入れず、イベントで外につなぐ。承認待ちをイベントで外へ渡せば、 組織がすでに使っている CI/CD や Slack での承認をそのまま審査に使える。 補足 利用者の検索には承認済みだけを出す。統制面は全レコードを持ち、検索面は承認済 みだけを出す。更新すると審査に戻るので、未審査の変更も届かない。
24. 事例 14 ビズリーチの AI 駆動開発の統治構造 エージェントと開発の統制｜ビズリーチ（ Visional ）｜ 2026 年 06 月 09 日 1/2 開発の判断を 3 つの役割に分ける ビズリーチは、 AI エージェントに開発を任せる体制で、人がすべての判断を通ってボトルネックになる状態をなくすため、開発の判断を 3 つの役割に分けた。ルールを定める役割と、ルールへの適合を判定する役割を実行から切り離し、判定は LLM と機械的な検査で行い、人は ルールの承認に回る。 アーキテクチャ説明 1 ① 憲法 全員が従う開発原則。変えられるのは人間だけ ② ルール（立法） 何が正しいかを定める正本。 AI が案を出し、人間が承認して 決まる ③ セマンティックチェック（司法） ②に意味の上で合っているかを、 LLM で判 定する ④ 決定性チェック（司法） ⑤ 行政 タスクの完了条件をワークフローで先に決め、エージェントが実行する grep や構文木（ AST ）を使い、機械的に判定する 5 2 3 4 出典情報は国の三権分立になぞらえ、②を立法、③④を司法、⑤を行政と呼ぶ 設計の工夫 判断の役割を分ける 人がすべての判断点を通る構造では、人の手が止まるとフロー全体が止まり、人がボト ルネックになる（出典情報の言葉では「律速点」）。 ADR や設計書を書いても、エージ ェントは参照せず、違反しても誰も止めなかった。そこで熟練者が兼ねていたルールを 定める役割と判定する役割を、⑤の実行から切り離した。 補足（本文より） 汎用のハーネスが担えるのは⑤だけ。②〜④はプロダクトと成長段 階に依存するので自社で作る（スライド 17 ） 出典情報 Speaker Deck（speakerdeck.com） 学ぶポイント ③④ ルールは機械が判定できる形で持つ。出典情報は、違反したら CI が落ちるかエージ ェントが止まる状態かを問い、文書に書いただけでは足りないとする。 ⑤ と補足 借りられるのは実行の部分だけ。何が正しいかはドメインに、何を検査するか は成長段階に依存する。この 2 つは自社で作る前提で設計する。
25. 事例 14 ビズリーチの AI 駆動開発の統治構造 エージェントと開発の統制｜ビズリーチ（ Visional ）｜ 2026 年 06 月 09 日 2/2 ルールと検査のつながりを記録する 前ページで分けたルールと検査は、どの検査がどのルールに基づくかが記録されていないと、ずれに気づけない。ビズリーチは両 者の対応を graph で機械可読にし、判断の根拠には人が承認した正本だけを使う。 7 6 8 9 10 出典情報 設計の工夫 A ルールと検査を graph でつなぐ ⑥ はルールとそれを検証するテストの対応を、機械可読に双方向でつなぐ層で、内容は持たない。対 応を人の記憶に頼ると、変更の影響を追えない。 graph があれば、⑦のように根拠の分からない検査 や、検査のないルールを機械で検知できる。 設計の工夫 B Speaker Deck（speakerdeck.com） 自動生成した情報を根拠にしない ⑧ 人が定義し、承認を経たものだけを判断の根拠にし、変更には承認を求める。⑨変更影響分析の ような自動生成物は再生成できるが、⑩根拠には使わず案内と索引に限る。出典情報は、便利だから と両者を混ぜると統治は必ず崩壊するとしている。 学ぶポイント ⑥ ルールと検査の対応を機械可読で残す。対応が記録されていれば、検査のないルール や根拠の分からない検査を機械で見つけられる。 ⑩ 自動生成した情報は判断の根拠にしない。影響分析や要約は再生成できる派生データ として扱い、案内や索引に限って使う。
26. 事例 15 ラクスの伝票作成 AI エージェントの実行基盤 エージェントと開発の統制｜ラクス｜ 2026 年 07 月 20 日 1/1 慣れた Kubernetes でエージェントを動かす 伝票作成 AI エージェントは、楽楽精算の利用者が選んだ領収書をもとに経費精算の申請を作るためのエージェントである。少人数のチーム が運用を続けられるよう、 AI 専用のサービスより社内に知見のある Kubernetes （ EKS ）を選び、 LLM の呼び出しを 1 か所に集めてトレ ースを残している。 アーキテクチャ説明 ① EKS エージェント一式を載せる Kubernetes 。社内の知見と既存資産を使え るので選んだ ② agent 呼ぶ ③ LiteLLM モデル呼び出しをまとめて bedrock へ送る。トークン量はここを 通るトレースで把握する ④ KEDA キューに連動して Job を起動する Kubernetes の部品。正式版の前に 追加した 1 実行基盤 エージェント本体。①の上で pod として動き、③を通してモデルを 設計の工夫 慣れた基盤を選ぶ 前提は少人数での開発と開発速度だった。 Lambda は長時間処理や既存の Kubernetes 資産の転用に弱く、 AgentCore は成熟度と社内の運用知見に懸念があった。①は AWS と EKS が未経験だったが、 Kubernetes の知見がエコシステムを含めてかなりあった。 可観測性は、非決定的に動くエージェントを追えるよう最初から手厚くした。 3 2 4 LLM の出入口 エージェント本体 補足（本文より） ③ を通る LLM 呼び出しとエ ラーのトレースは全量残し、 通常のトレースは 5% に絞る （スライド 31 ） キュー連動の起動 出典情報 Speaker Deck（speakerdeck.com） 学ぶポイント ①④ 実行基盤はチームが運用できるもので選ぶ。出典情報は、 AI 専用の特殊なものより、 慣れていて知見のあるものを優先したとしている。 ③ と補足 LLM 呼び出しは 1 か所に集めて全量記録する。通常のトレースは割合を絞り、 トークン量とエラーは漏らさない。出典情報はコストと可観測性の両立としている。
27. 事例 16 NTT ドコモビジネスのクローズド AI エージェント エージェントと開発の統制｜ NTT ドコモビジネスほか｜ 2026 年 08 月 17 日 1/1 LLM まで顧客専用環境の中で動かす クローズド AI エージェントは、機微データを外に出せない企業が、生成 AI のエージェントを業務に使うための専用環境サービス である。顧客ごとの閉域環境にエージェントと LLM を置いてデータもプロンプトも外部に送らず、構築から保守までを NTT ドコ モビジネスが担う。 アーキテクチャ説明 ① お客さま専用環境 顧客ごとに構築し、専有 GPU と Kubernetes の基盤に載せ る。実行環境で機微データを使って業務を行う ② 開発環境（ exaBase Studio ） エクサウィザーズの基盤。テンプレートを使 って業務向けのエージェントを作る ③ LLM tsuzumi 2 かオープンソース LLM を①の中で動かす。業務データもプ ロンプトも外部へ送らない ④ 運用の引き受け 専用環境の構築から保守までを NTT ドコモビジネスが担い、 セキュリティ管理も引き受ける ⑤ 閉域ネットワーク 利用者は閉域網を通って①を使う。データを外部に持ち出 さない 補足（本文より） オンプレミス版は、ハードウェアから AI エージェントまで国内の自 社環境内で完結して運用できる 1 2 5 3 ① 〜④は出典情報の図の赤い番号と同じ要素を指す 設計の工夫 専用環境の運用まで引き受ける 4 重要データを扱う企業は、外部クラウドの利用に慎重なことが多い。一方で、プライベ ートクラウドやオンプレミスで進めると、 AI 基盤の構築と運用を自社で担う負担が大き い。そこで⑤と①でデータを外に出さず、③の LLM も中に置き、④で運用を事業者が引 き受ける形にした。 出典情報 NTTドコモビジネス ニュースリリース（www.ntt.com） 学ぶポイント ③ データを出さない範囲に LLM も含める。 LLM を①の中で動かせば、業務データもプ ロンプトも外部の AI サービスへ送られない。 ④ 閉域化で増える運用を誰が担うかまで決める。出典情報は、自社で AI 基盤を運用する 負担を課題に挙げ、構築から保守までを事業者が担う形にした。
28. まとめ 5 つの設計課題に共通する設計の傾向 1 ハーネスとモデルは、役割ごとに分けて置く p.4–12 所感 ハーネスは預けるか自作するかを選び、遅い推論や状態を持つ処理は会話の経路から 各社の構成図で大きな面積を占めていたのは、モデル 切り離す。分けた単位ごとに置き場所と運用者を決めている。 の外側にある実行環境や評価、承認の部品だった。 作るのは AI 、決めるのは人。その分担は、すでに構成 2 図の形になっている。 品質は、本番の修正を評価に変えて上げる p.14–18 人の修正や失敗した会話を評価や学習データに変え、検証や人の承認を通ったものだ けを反映する。 学びとアクション 3 実行と統制は、モデルの外の仕組みで決める p.20–27 自分のエージェントの承認ダイアログを 1 つ選び、 承認率を測る。 AI が書いたコードの届く範囲は OS やネットワークで制限し、エージェントの登録や 承認率が 9 割を超えていれば、その承認を「到達範 ルールの検査は機械が判定できる形にする。 囲の制限」へ置き換える候補にする。ただし、取り 消せない操作や外部に影響が出る操作は承認を残す。 28
29. IT エンジニアリングマネージャー ｜ コミュニティマネージャー ｜ 国家資格キャリアコンサルタント 技術と人をつなぐ仕事をしています S Y S T E M システムづくり ためやす けいすけ 為安 圭介 北海道・札幌 好きなもの システム構築／ IT ソリューション／プロジェクトマネジメント T E A M & CO M M U N I T Y チームづくり・場づくり AI コミュニティ CDLE 運営／ SHiFT ／ BUFF 認定コミュニティマネージャー・メンター C A R E E R 人のキャリアに関わる 国家資格キャリアコンサルタント／キャリア支援／記事発信 note 「キャリアのなやみ」 関心 人と AI のよりよい協働