AIエージェント
本番で動く AI エージェントはどう作るのか — Linear が「Slack の依頼からコード提出まで6分」を実現した5つのルール
Linear Agent の実例から、本番運用に耐えるエージェント設計の順序と、その前提となる社内システム投資の優先順位を考える。
原題
“5 Rules for Building AI Agents That Work in Production” （プロダクションで動くAIエージェントを構築するための5つのルール）
原文からの引用
“If work starts in Slack, make Slack the on-ramp instead of forcing users into a separate chatbot." "Give agents tools to find context instead of stuffing context into the prompt.”
日本語訳 仕事が Slack で始まるなら、ユーザーを別のチャットボットに追い込むのではなく、Slack を入口にせよ。 コンテキストをプロンプトに詰め込むのではなく、コンテキストを見つけるためのツールをエージェントに与えよ。
要点
- Linear Agent（$1.25B企業のLinearが開発）は、Slackからのリクエストをコードに変換するまでを6分で完結させた、エージェント設計の実例である
- Linear のエージェント設計ではワークフローマッピングが第一。どこで仕事が始まり、どのシステムがコンテキストを保有し、何が完了条件かをまず明確にする
- コンテキストをプロンプトに詰め込むのではなく、エージェントにコンテキスト取得ツールを与える設計が鍵になる
- 開発チームは、プロトタイピング段階では最大モデルを使用してから段階的に最適化する
- エージェントの入口はユーザーが既に使うプラットフォーム（Slack等）にし、別のチャットボットを強要しない
編集部の考察
Linear Agentが「Slackでの依頼からコード提出まで6分」を実現した鍵は、モデルの性能ではなくワークフロー設計の順序にある。彼らはまず「どこで仕事が始まり、どのシステムがコンテキストを保有し、何が完了で、どこに人間のレビューが要るか」をマッピングしてから着手し（要点2）、しかもその後は「コンテキストをプロンプトに詰めるな、取得ツールを与えよ」という原則で、エージェントに社内システムへのアクセス手段を持たせる設計に振り切っている。これを自分の組織に当てはめると、着手すべきは「どの業務でエージェントを作るか」の選定ではなく、その前段——顧客情報も設計仕様も進捗も別々のSaaSに散在している現状で、エージェントに読ませられる形でコンテキストを一元的に保持しているシステムがどれだけあるかの棚卸しだ。ここが手薄な組織では、エージェント構築のたびにコンテキスト取得の配線をゼロから組む羽目になり、Linearのような速度は出ない。つまり経営が判断すべきは個々のエージェント導入の可否ではなく、どの内部システムを「エージェントが参照する正のデータソース」として位置づけ直し、そこへの投資を先行させるかという、社内システム構成の優先順位づけそのものである。
本記事は海外記事の独自キュレーション・考察であり、原文の翻訳ではありません。引用部分の著作権は原著者に帰属します。