AIエージェント
社内 AI アシスタントは自作すべきか購入すべきか ― Headway が Claude Code SDK で「Eddy」を自社構築した判断基準
セキュリティ・コンプライアンス要件を満たす AI ツールが市場にないとき、自作・購入・様子見をどう判断するか。900人規模のヘルスケア企業 Headway の自社構築の実例から、権限境界の設計とビルド判断の基準を見る。
原題
“The Healthcare Company That Built the AI Tool It Couldn't Buy” （購入できなかった AI ツールを自分たちで構築したヘルスケア企業）
原文からの引用
“It doesn't matter. This is a throwaway container of a conversation." Waiting for a vendor to put those pieces together would have cost Headway more than building Eddy.”
日本語訳 問題にならない。会話ごとに使い捨てるコンテナなのだから。 ベンダーがそれらの要素を組み上げるのを待つほうが、Headway にとっては Eddy を自社構築するより高くついただろう。
要点
- Headway（900人規模のメンタルヘルスケア企業）は既存ベンダー製品では対応できない「セキュリティ・コンプライアンス・ワークフロー要件」を満たすため、Claude Code SDK を用いて独自 AI アシスタント「Eddy」を自社構築した。
- Eddy は会話ごとに使い捨ての Docker コンテナで実行され、完全隔離されたセキュアな設計を採用し、全社が週次で、900人のうち650人が日次で利用して、構築開始以降 26 万件の会話を処理している。
- Eddy は Model Context Protocol（MCP）で Figma・Snowflake など既存ツールと連携し、複雑な規制要件と実務ワークフローの両立を実現している。
- 記事は企業が「自作」「ベンダーを待つ」「購入」を判断するための意思決定フレームワークを示す。待つ場合は必要な機能が近く提供される見通しがあり、買う場合はセキュリティ・データ・ワークフロー要件を満たし、作る場合は制約が根本的かつ重要で継続的な保守コストに耐える必要がある。
- 自社構築を選んだ企業は、その代償として信頼性維持・機能開発・新しい AI 能力への追従を常時実行する必要があり、ベンダーが通常担う運用負担を背負うことになる。
編集部の考察
AIエージェントのガバナンスを、承認プロセスの厳格さでなく権限境界の設計精度で測る — この発想への転換が、自律型 AI 活用を安全に前進させる分水嶺になる。Headway が Eddy に与えたのは「各ステップで承認を求めずに行動していい」という自律性であり、それを可能にしたのは会話ごとに使い捨てる Docker コンテナと、Snowflake は読み取り専用・書き込み不可、外部ネット閲覧不可（検索はプロキシ経由のみ）、メール送信不可という具体的な権限制御だった（要点2）。だからこそコンプライアンスチームは、各ステップの承認なしに動くエージェントを受け入れられた。CTO の Arnaud Ferreri は「Claude Code がハードディスクを丸ごと消すと決めたとしても構わない。会話ごとに使い捨てるコンテナだから」と語っている。この設計の要点は、自律性の可否を「AI をどこまで信用するか」という精神論ではなく、書き込み権限・外部通信・データ持ち出し経路をどこで物理的に遮断するかという技術的な境界設計の問題として扱った点にある。メガベンチャーで社内 AIエージェントの自律実行範囲を広げようとするとき、承認フローを緩めるかどうかを議論する前に、まず「このエージェントはどのシステムに書き込めるか」「社外への通信経路はどこにあるか」「セッション終了後にデータはどう消えるか」という3点を技術的に先に固められているかを確認すべきだ。それがそのまま、冒頭の「設計精度で測るガバナンス」の実践になる。
本記事は海外記事の独自キュレーション・考察であり、原文の翻訳ではありません。引用部分の著作権は原著者に帰属します。
この記事の調査と下書きにはAIを使っています。数値や事実は出典と照合し、公開するかどうかは運営者が判断しています。（制作方針）