記事一覧

Foundry Labs / コミュニティから

AIエージェントの実装を支える全体設計:検索・実行環境・ツール

Foundry Labs公開日: 開催日 ·
目次
Tokyo AI「Beyond the Wrapper - Engineering End-to-End Agentic Systems」のイベント告知画像。
Tokyo AI「Beyond the Wrapper - Engineering End-to-End Agentic Systems」、2026-04-15。 · Tokyo AI (TAI).

AIエージェントが期待どおりに動かないとき、原因がモデルの推論能力にあるとは限りません。必要な情報にたどり着けない、ツールの意味が曖昧、実行結果を確認できない。こうした環境側の問題も、回答の誤りや無駄な試行につながります。

2026年4月15日のTokyo AIイベント「Beyond the Wrapper」では、Adam Gibson氏、Leonard Lin氏、Jason Mooberry氏が、検索、実行、ツール設計という三つの方向からエージェントを支える仕組みを扱いました。

検索は、複数の判断がつながった処理

KompileのCTO兼共同創業者、Adam Gibson氏は、検索、再ランキング、知識グラフ、分類、ルーティングを含む全体を、モデル中心の構成として捉えています。部品を増やすだけでなく、各部品の関係を見渡せることが重要です。

RAGは「関連文書を検索してモデルへ渡す」と説明できます。しかし実際には、文書をどう分割するか、候補の何を優先するか、どの情報を最終的な文脈へ含めるかで結果が変わります。注文状況のような構造化された事実なら、文章検索より業務システムへの問い合わせが適している場合もあります。

誤答を調べるときも、情報がなかったのか、検索に失敗したのか、順位付けで落ちたのか、取得後に読み違えたのかを分ける必要があります。この区別がなければ、性質の異なる問題に対して一律にプロンプトを修正し続けることになります。

「Beyond the Wrapper - Engineering End-to-End Agentic Systems」の講演風景。
2026-04-15開催、Tokyo AI「Beyond the Wrapper - Engineering End-to-End Agentic Systems」の会場。

実行結果を、次の判断の根拠にする

Shisa.AIのCTO兼共同創業者、Leonard Lin氏は、仕様、実装、テスト、レビュー、修正をつなぐ開発ループを紹介しています。作業を構造化して記録することで、どこで時間がかかり、どの失敗が繰り返されるかを確認できます。

この考え方は開発以外にも当てはまります。エージェントが「処理しました」と答えることと、業務システムに処理結果が存在することは別です。検証結果やツールからの応答を通じて、意図した操作が本当に完了したかを確認できる必要があります。

Lin氏の講演では、依存関係やソフトウェア供給網の管理も実行環境の一部として扱われます。ソフトウェアの導入や認証情報の利用ができるツールには、相応の権限管理が必要です。モデルの提案が誤っていても、制御が機能する構成を考えます。

ツールを、エージェントが扱う仕事の単位に合わせる

Sumato AI創業者のJason Mooberry氏は、AI Experience(AX)という視点から、エージェントが作業場所を探したり、同じファイルを読み直したりする負担を問題にしています。

講演で紹介するSpathは、コード内のシンボルを意味のある単位として指定します。Splanは対象、操作、内容をまとめ、複数の変更を一体として適用する方式です。操作全体が成功するか、適用しないかを明確にすることで、途中だけ変更された状態を扱いやすくします。

Splanは変更対象・操作・内容をまとめ、コード変更をトランザクションとして表現する。
Splanは変更対象・操作・内容をまとめ、コード変更をトランザクションとして表現する。

業務システムでも、複数の項目を自由に書き換えるより、「承認済みの配送先を更新する」という明確な操作を用意した方が、権限や検証を結び付けやすくなります。重要なのは、ツールの単位と業務上の意味を合わせることです。

「Beyond the Wrapper - Engineering End-to-End Agentic Systems」の講演風景。
2026-04-15開催、Tokyo AI「Beyond the Wrapper - Engineering End-to-End Agentic Systems」の会場。

Foundryの視点:一つの業務判断を、情報から実行まで追う

顧客への交換対応が可能かを判断する社内アシスタントを、仮の例として考えます。必要なのは、規定の文章、購入記録、過去の申請状況です。すべてを同じ検索で処理する必要はありません。規定は文書から取得し、注文は構造化された問い合わせで確認する設計が考えられます。

回答には適用した規定の版と、判断の根拠を残します。注文が見つからなければ、それは未解決の条件です。もっともらしい購入履歴で補ってはいけません。

次に、「交換を提案する」と「交換手続きを実行する」を分けます。承認後に実行する操作は、後から確認できる処理番号を返すようにします。通信が途切れた場合も、再実行する前に、すでに処理済みかを確認できる必要があります。

こうして一件の失敗を、検索、規定の解釈、権限、実行のどこに問題があったか分類できるようになります。モデルの変更が有効な問題もあれば、業務ルールや接続先を直すべき問題もあります。Foundry Labsが重視する全体設計の視点は、この情報と責任のつながりを、本番の業務として検証できる形にすることです。

出典・関連情報

本記事は、Beyond the Wrapper - Engineering End-to-End Agentic Systemsのイベント案内と上記の講演をもとに構成しています。Tokyo AI(TAI)は研究者、エンジニア、企業をつなぐコミュニティです。Foundry Labsのコミュニティ活動もご覧ください。

Adam Gibson、Leonard Lin、Jason Mooberryの登壇資料をご希望の方は、お問い合わせフォームより、イベント名と登壇者名を添えてご連絡ください。

登壇者プロフィール

Adam Gibson。Kompile共同創業者・CTO。深層学習システムの開発に携わる。 LinkedIn

Leonard Lin。Shisa.AI共同創業者・CTO。多言語モデルと推論システムに取り組む。 LinkedIn

Jason Mooberry。Sumato AI創業者。AIを活用する業務のインターフェースと文脈をテーマに登壇。 LinkedIn

記事一覧