Forterは、プログラミングの専門知識への依存を減らし、アナリストやエンジニアがアイデアを迅速に試せる環境を設計することで、2週間にわたる実践的な構築スプリントに約200人を参加させ、AIエージェントを構築できるようにした。同社のプリンシパルエンジニアであるBen Maraneyは、この取り組みを、エージェント構築に関するあらゆる課題を一度に解決しようとするのではなく、不要な複雑さを取り除くことについての教訓として説明している。
出発点：5週間の実践的なスプリント
目標は、研究開発チームに自分たちのエージェントを作成する方法を学んでもらうことだった。そこには、法務、心理学、科学のバックグラウンドを持ち、中にはSQLを書いた経験がないアナリストも含まれていた。チームは5週間で環境を整え、その後2週間の構築スプリントを実施する必要があった。そのため、設計ではツール、プラットフォーム、ユーザーの障壁の除去という3つの軸に重点を置いた。
分散したツールではなく中央集約型のMCPサーバー
Forterは、Toolchainと名付けた、MCPプロトコルに基づく社内サーバーを採用した。このサーバーは、ツールの発見と試用、各エージェントに固有の接続の作成を行うための単一のインターフェースを提供した。また、エージェントに広範なアクセスを与えて混乱させたり、不適切なツールを使わせたりするのではなく、ユーザーがエージェントに必要なツールだけを選べるようにした。
ツールの数は、チーム設立時の約20からスプリント開始時には約60に増え、終了から2週間後にはほぼ100に達した。リポジトリの統一と、明確なサンプルおよび設定ファイルの存在により、新しいツールを迅速に追加できたほか、トークン消費やツール利用の監視など、ガバナンス機能も提供された。
短期間で専用の検索拡張生成（RAG）システムを構築する代わりに、同社はToolchainを、Confluence、Asana、Jira、Slack、Salesforceなどの社内ソースを検索するために使われているGleanプラットフォームに接続した。ツールは、関連する文書や抜粋の検索、文書全体の読み取り、エージェントが指定した質問や観点に基づく要約という3種類を提供した。
ノーコードのプラットフォームからカスタマイズ可能なソリューションへ
Forterは、迅速でプログラミングの少ない対話体験を提供するためにLibreChatを使用した。ユーザーは、エージェントが呼び出したツール、送信したクエリやパラメーター、受け取った結果を確認できた。これにより、エージェントの挙動を理解し、問題を早期に発見することができたが、MCP統合が不安定になることがあり、バージョン管理とカスタマイズの制御にも限界があった。
より複雑なケースに対応するため、同社は開発者にコードの完全な制御、ツールやサブエージェントの追加を可能にするテンプレートリポジトリを提供した。ただし、特にアナリストにとっては、セットアップとデプロイが遅かった。その後、ForterはAI Hubという社内インターフェースを作成し、モデルの選択、システムメッセージの記述、ツールの指定を行い、数ステップでエージェントを共有できるようにした。
一方、非対話型エージェントには、スケジュールやJiraおよびAsanaのチケット作成などのイベントに応じて実行するため、Argo WorkflowsとともにStrandsフレームワークを使用した。Maraneyは、既存のスケジューリングおよび実行システムがあれば、エージェント専用の新しい基盤は不要になる可能性があると指摘している。
実際に何が構築されたのか？
用途には、アナリストがより良い仮説や実験を作成するのを支援するエージェント、インシデント後のレポートをレビューするエージェント、SnowflakeとDatabricksのノートブックを使用して加盟店のパフォーマンス低下を分析するエージェントが含まれていた。また同社は、LaylaとPennyという専門エージェントを開発し、コード、設定、データにアクセスして、取引や請求に関する質問に回答できるようにした。Laylaは、システムに関する知識が単独の個人の知識を上回るようになった後、カスタマーサクセスとサポートのチームにも利用が広がった。
非対話型エージェントの例としては、類似した加盟店に基づく新規加盟店向けの初期設定の提案、サポートチケットの到着時に予備調査を準備すること、異常状態のアラートを分析してコード変更と関連付けることなどがあった。Forterはインシデント対応エージェントも試験したが、一見すると優れた結果が、実際には主にBetterNextのレポートに人間が以前記述した根本原因分析のコピーに依存していることを発見した。
実務上、何が変わるのか？
この実験は、可観測性が二次的な機能ではないことを示している。エージェントが依存するツール、パラメーター、結果を表示することは、インシデント対応エージェントが実際には根本原因を推論していなかったことを発見するために不可欠だった。そのためForterは後に、エージェントのセッション、ツール呼び出し、ワークフローを追跡するためにLangfuseを追加した。
また、この実験は、複数のプラットフォームを使い分けることが意図的な場合もあることを示している。迅速な実験にはノーコードのプラットフォーム、カスタマイズにはソフトウェアソリューション、イベントまたはスケジュールに基づく処理にはエージェントを使用するという形だ。一方で同社は、エージェントごとに個別のリポジトリを作成するモデルで問題に直面し、その後、追跡などの共有機能を導入しやすくするため、関連するエージェントを含む少数のリポジトリに戻した。
Maraneyは、適合性、関連性、安全性などの一般的な評価指標が、品質について誤った印象を与える可能性も指摘している。有用な評価では、回答の正確性、適切なツールの利用、正しいコンテキストの取得を検証する必要がある。これらはより難しく、良い回答が何を意味するのかについての正確な知識を必要とする。そのため、人間が意思決定のループ内に留まる社内実験では、高度な評価を先送りできる場合があるが、評価の恒久的な代替とみなすべきではない。
拡大の取り組みでは、特にデータがどこで処理され、保持されるかについて、法務チームとセキュリティチームを早期に関与させる必要もある。Maraneyによれば、Amazon Bedrockのようなクラウドサービスを利用し、データを保持しないポリシーを文書化することで、すべてのエージェントを個別の承認案件に変えるのではなく、企業の管理策の中でこれらの懸念に対処することができた。
ニュースの出典
InfoQ - Architecture Articles
原文を開く ↗