AIエージェントの実装方式は4種類ある ── claude直叩きからMastraまで、全部作って分かった選び方
はじめに
AI エージェントをプロダクトに組み込む実装方式は、2026年現在、大きく4種類から選べます。数年前は「CLI を直接叩く」か「API の上に全部自作する」しか選択肢がなかったことを思うと、状況は様変わりしました。
この記事のポイント
- 実装方式は4種類（CLI 直接実行、ベンダー公式 SDK、オープンな部品で自作、統合フレームワーク）。優劣ではなく要件で選ぶ
- 自作の判断基準は「作れるか」ではなく「その層自体が製品価値になるか」
- 判断を日付入りで記録しておくと、次の基盤の設計はその再評価から始められる
私たちはこの3年間、選択肢が増えていく過程で、4方式すべてを実プロダクトで実装してきました。事業会社の社内 AI プラットフォーム、自社の業務アシスタント、マルチテナントの SaaS、そして現在 Mastra を使って開発中の自社基盤です。本記事はその経験を「選び方」として整理する、開発連載の第0回です。
AIエージェントの実装方式には何があるか？
実装方式の4つの選択肢とは、エージェントの中核（LLM の呼び出し、ツール実行のループ、状態管理）を誰が所有するかの違いです。
| 方式 | 実装 | 中核の所有者 | 向いている場面 |
|---|---|---|---|
| A: CLI 直接実行 | claude -p をサーバから実行 | ベンダーの CLI | エージェントの成果物だけを最短で製品に足したい |
| B: ベンダー公式 SDK | Claude Agent SDK | ベンダーの SDK | 特定ベンダー固定でよく、開発速度を優先したい |
| C: オープンな部品で自作 | LLM ゲートウェイ（LiteLLM 等）+ Vercel AI SDK など | 自社 | 基盤の層そのものが製品価値になる |
| D: 統合フレームワーク | Mastra など | OSS フレームワーク | 基盤より上のサービス開発に集中したい |
この4つは進化の順でもあります。方式A と C しかなかった時代から、ベンダー SDK が整い（B）、低レイヤーから高レイヤーまでカバーする OSS フレームワークが定番化して（D）、ようやく「選べる」状態になりました。
方式AとB: ベンダーに最適化するとどうなるか？
最初の基盤では、開発支援の機能に方式A を使いました。Claude Code CLI をサーバ側から直接実行し、その成果物を製品の画面へ返す構成です。素朴に見えますが、Claude Code が持つ計画、実装、検証の能力をそのまま借りられるため、「AI が開発作業を代行して成果物を返す」体験を最短距離で製品化できました。同じ基盤の業務エージェント側は Messages API を直接呼ぶ自前ループで作っており、用途別のループを手作業で同期し続ける保守負担が課題として残りました。
2つ目の基盤では、この反省から方式B に寄せ、Claude Agent SDK にエージェントループを一本化しました。ループを自分で書かなくてよくなった代わりに、コンテナ環境でのセッション永続化や承認フローの組み直しといった、SDK の外側の工夫が必要になりました。そして方式AとB に共通する構造的な制約が、ベンダー固定です。モデルを選びたいという要件には応えられません。
方式C: 自作はいつ「戦略」になるか？
3つ目はマルチテナントの SaaS で、モデルを差し替えられることが要件でした。LLM ゲートウェイでモデル名を抽象化し、オープンな部品の上に実行管理、コスト計測、監査ログ、スキル読み込み、サブエージェントを自作しました。
ここで強調したいのは、この自作が「フレームワークが無かったから仕方なく」ではないことです。統合フレームワークは当時すでに選択肢にありました。それでも自作を選んだのは、AI ネイティブな業務アプリとして製品を設計する以上、統合フレームワークで模倣できるものを作ってしまうと競合製品に対する優位性が保てない、と考えたからです。どこが競争優位になるかの具体は企業秘密のため書けませんが、たとえばスキル管理やサブエージェントの仕組みを既存の SDK やフレームワークとは違う概念で設計し、所有すること自体が競争力になるという判断です。この判断は、AIスタートアップは「黄色いレンガの道」を避けよで書いた、生き残る側の「4つの防衛線」の議論そのものです。
ただし維持コストは現実です。汎用的な機能はフレームワーク側が猛烈な速度で標準搭載していくため、自作を選ぶなら「それでも所有する価値がある層はどこか」の線引きを、追い上げ前提で引き直し続ける必要があります。
4方式を全部作って何を学んだか？
第一に、要件が方式を決めます。ベンダー固定でよければ方式B が最短、成果物だけ欲しければ方式A が最小、基盤の層が製品なら方式C、基盤より上に集中したいなら方式D です。「どの方式が最強か」という問いは、要件を決めていないことの裏返しでした。
第二に、自作の判断基準は「その層自体が製品価値か」です。方式C で自作した中断・再開付きワークフロー、会話メモリ、モデルルーティングは、2026年現在の Mastra にすべて標準搭載されています。Firecrawl の2026年フレームワーク比較によれば、Mastra は TypeScript ネイティブのエージェントフレームワークとして事実上の定番になりました。汎用機能の自作は約1年で追い抜かれる前提で、それでも所有すべき層だけを自作すべきです。
第三に、判断の記録が次の基盤の設計書になります。方式C ではフレームワーク選定の比較検討を日付入りの文書で残しており、4つ目の設計はその記録の再評価から始められました。作り直しを「損失」ではなく「学習」に変えるのは、この記録の有無です。
方式D: なぜ次の自社基盤は Mastra なのか？
現在開発中の自社基盤は、基盤の上に載るサービスが製品で、基盤の層自体は売り物ではありません。方式C で得た判断基準をそのまま適用すると、答えは方式D になります。ループ、ワークフロー、メモリ、モデル切り替えは Mastra に任せ、自作は開発オペレーションをスキルとして注入する仕組みなど、製品の競争力に直結する部分だけに絞ります。
4方式を歩いてきたからこそ、フレームワークが肩代わりする範囲と、自分で持つべき範囲を具体的に見積もれます。この見積もりの過程を、本連載で設計判断ごと公開していきます。次回は、本番実績で先行する LangGraph ではなく Mastra を選んだ判断を扱います。
よくある質問
Q. エージェント基盤は自作すべきですか？
A. 判断基準は「作れるか」ではなく「その層自体が自社の製品価値や競争力になるか」です。なるなら自作に投資する価値があり、ならないなら統合フレームワーク（TypeScript なら Mastra、Python なら LangGraph）に乗って、浮いた投資をサービス側に回すことを推奨します。
Q. AI ベンダーは1社に固定してよいですか？
A. できるだけ避けることを推奨します。2026年現在、検索、コーディング、デザインなど領域ごとに得意なモデルが明確に分かれており、業界の進化も速いため、後からモデルを乗り換えられる作りにしておく価値は年々上がっています。固定する場合も、それが意識的な選択であることを判断記録に残すべきです。
Q. モデルはどう選べばよいですか？
A. 話題の最上位モデルから考えないことです。業務自動化の大半は、ルールを明文化して渡せば標準クラスのモデル（Claude なら Sonnet）で事足ります。料金はモデルのクラスで数倍変わるため、「最上位を何に使い、どこまでを標準クラスに任せるか」の線引きが費用対効果を決めます。
まとめ
AI エージェントの実装方式は、CLI 直接実行、ベンダー公式 SDK、オープンな部品での自作、統合フレームワークの4種類から、要件で選ぶ時代になりました。選び方の指針は、要件を先に決めること、自作は「その層が製品価値か」で判断すること、そして判断を記録することの3つです。
ZenChAIne では、4方式すべての実装経験をもとに、AI 駆動開発の導入診断と技術顧問を提供しています。自社の要件にどの方式が合うかを判断したい方は、技術顧問・開発支援からご相談ください。