SaaS is Dead? AIに代替される層と残り続ける層

Anthropic CEOが「ClaudeはSaaSの専門領域を代替できる」と発言したことを引き金に、SaaS株の暴落も重なって「SaaS is Dead」論が再燃している。マネーフォワードの武田氏がこの話題について見解を述べており、総じて同意できる内容だった。結論としては「全部が死ぬわけではなく、AIに代替される層と、人間や専門家でなければ担えない層に分かれる」というものだ。 なぜ今この話題なのか この手の議論は以前から繰り返されてきたが、今回が特に大きく取り沙汰されている背景にはAIの急速な進化がある。Anthropicの年間収益はClaude Codeのコーディングエージェントだけで2025年末に10億ドルを超え、2026年2月には25億ドルに倍増するなど、AIレイヤーの成長は加速している。 SaaSがDeadであるという根拠 AIレイヤー(チップ・基盤・LLM)の成長率が桁違いに高い一方、その上に乗っかるアプリケーション層=SaaSの売上成長率は相対的に見劣りしている。リテラシーの高いユーザーがLLMで自前のツールを作り始めており、「お金を払ってSaaSを使う価値」を自製できてしまうケースも出てきている。 SaaSがDeadではないという根拠 武田氏がマクロミル時代に自社でSalesforceの代替システムを内製したケースがまさにその典型だ。当初は優秀なシステムだったものの、法令改正・技術的負債・セキュリティ対応などの積み重ねで次第に維持コストが膨らみ、結局後任体制でSalesforceを導入することになった。 特にバックオフィス系SaaS(会計・人事など)は法令改正への追従が不可欠で、一円でも間違えれば法律違反になるリスクを抱える。AIで作れたとしても「長期的にそれを誰が維持するか」という問題は残り続ける。 また日本市場特有の問題として、クラウド会計ですら13年かけてもオンプレミス系との勢力図が逆転していない現実がある。AIがさらにその上に乗ってくる変化を、多くの企業がキャッチアップしきれるかは相当懐疑的だという見立てだ。 二層モデルによる整理:SOEとSOR 武田氏はSaaSを二層に分けて考えることが有効だとしている。 System of Engagement(SOE)— Deadになりうる層 人間が使いやすいUIを提供する層。AIエージェントが直接操作するようになれば、人間向けのUIそのものが不要になっていく。この層はDeadになりうる。 System of Record(SOR)— 当面変わらない層 堅牢なデータベースとして記録を保持する層。法令対応・セキュリティ・データ信頼性が問われる領域であり、AIが代替するのは長期的には起こりうるとしても、当面は変わらない。 SaaSのヘッドレス化 マネーフォワードが「SaaSのヘッドレス化」と表現しているのもこの文脈だ。人間が画面を操作するのではなく、AIがMCP(Model Context Protocol)経由でSaaSを操作する形に移行していくという見立てである。 実際にマネーフォワードは2025年10月に『マネーフォワード クラウド会計』のMCPサーバーβ版を提供開始し、AIエージェントから仕訳入力やレポート作成などの会計業務を実行できるようにしている。 さらに2025年11月には初のAIネイティブプロダクト『マネーフォワード AI確定申告』β版を提供開始。「どうせ代替されるなら自分たちで最適なものを作る」というスタンスで先手を打っている。 まとめ 「SaaS is Dead」は単純な二項対立ではない。UIを提供するEngagement層はAIエージェントに代替されうるが、法令対応やデータの信頼性を担保するRecord層は簡単には置き換わらない。重要なのは、この変化に対してSaaS企業自身がどう適応するかだ。マネーフォワードのように「ヘッドレスSaaS」への転換を自ら進める企業が、次の時代の勝者になるのかもしれない。

2026年3月14日 · 1 分

スタッフ0人の税理士がClaude Codeで顧問先60社を1人で回す全手法

スタッフ6人体制から0人へ。年間人件費3,000万円を削減しながら、顧問先60社の経理業務を1人でこなす税理士の事例が話題になっている。その武器は Claude Code だ。 元記事: スタッフ0人で顧問先60社。税理士がClaude Codeで"AI経理"を実現した全手法 毎晩21時に60社分の自動仕訳 中核となるのは、毎晩21時に自動実行される仕訳処理だ。freee API から未処理明細を取得し、自動で勘定科目を判定して登録する。処理時間は従来の5時間から50分へと大幅に短縮された。 2段階の勘定科目判定 仕訳の精度を担保するために、2段階の判定システムが採用されている。 第1段階: キーワード辞書マッチング 14カテゴリ、100以上のキーワードで構成された辞書による高速判定。例えば: Suica → 旅費交通費 飲食店1万円以下 → 会議費 飲食店1万円超 → 交際費 第2段階: Claude API フォールバック 辞書でマッチしなかったものは Claude API が判定する。信頼度が低い場合は「人間確認」フラグが立ち、税理士がレビューする仕組みだ。 7種類の除外ルール 自動仕訳の対象外として、以下の7種類が除外される: 内容不明のデビット 借入返済 社会保険料・税金 給与 投資・資産運用 ATM出金 公共料金 給与や税金など、金額の誤りが重大な影響を及ぼす項目は自動化の対象外とし、人間が確認する。この「触ってはいけないものを明確にする」線引きが、実務での信頼性を支えている。 MCP連携で「転記ゼロ」を実現 Claude Code の MCP(Model Context Protocol)を活用し、5つのサービスと接続している: freee — 取引データの取得・仕訳登録 Gmail — リマインドメールの作成 Google Calendar — スケジュール確認 Notion — 議事録からアジェンダ自動生成 Slack — TODO管理 これにより、サービス間の手作業による転記がゼロになった。 CLAUDE.md とスキルによる業務の「言語化」 技術的に重要なのは、CLAUDE.md に業務の判断基準をすべて言語化して記述している点だ。仕訳分類ルール、税区分の処理方法、セキュリティポリシー、出力先ルールなどが定義されている。 ...

2026年3月14日 · 1 分

Agentic Coding時代のドキュメント配置: /docs ディレクトリはもう限界?

Agentic Coding(AIエージェントによるコーディング)が普及する中、AIに渡すドキュメントをどこに配置すべきかという問題が注目されています。古川陽介氏(@yosuke_furukawa)のポストで紹介されていた記事「Your Docs Directory Is Doomed」(Yagmin)の内容をもとに、この問題を考えます。 /docs ディレクトリの進化と限界 Agentic Coding を始めると、多くのプロジェクトで以下のようなドキュメントが増えていきます: まず CLAUDE.md や AGENTS.md のような設定ファイルを作成 ARCHITECTURE.md でシステム全体の構造を記述 機能仕様やデザインドキュメントを /docs フォルダにまとめ始める この流れ自体は自然ですが、記事では /docs ディレクトリへの集約には根本的な問題があると指摘しています。 /docs ディレクトリの問題点 1. 発見可能性(Discoverability) LLM はどのドキュメントをいつ読むべきかを自律的に判断する必要があります。/docs に大量のファイルがある場合、LLM が適切なドキュメントを見つけられる保証はありません。計画フェーズで必要なドキュメントと、コード生成フェーズで必要なドキュメントは異なりますが、それを正しく参照できるでしょうか。 2. ドキュメントの腐敗(Documentation Rot) コードは頻繁に変更されますが、対応するドキュメントの更新は忘れがちです。小さな不整合が積み重なり、LLM が参照するコンテキストの品質が徐々に劣化していきます。さらに厄介なのは、ドキュメントが間違っていることに気づくための仕組み(observability)がないことです。 3. 構造の欠如 ドキュメント間の階層関係や依存関係が明示されていないため、LLM がドキュメント群をナビゲートする明確な方法がありません。各自が自分のスタイルで書くため、LLM にとって情報の探索がしにくい構造になります。 4. 変更速度の不一致(Velocity Mismatch) ドキュメントの種類によって変更頻度が異なります。アーキテクチャの概要はめったに変わりませんが、API仕様やコンポーネントの詳細は頻繁に更新されます。一つのディレクトリにすべてをまとめると、この違いが管理を困難にします。 コロケーション(Colocation)というアプローチ 古川氏がツイートで触れているように、一つの解決策はコロケーション — ドキュメントをコードの近くに直接配置する方法です。 src/ auth/ README.md # 認証モジュールの説明 auth.ts auth.test.ts api/ README.md # APIモジュールの説明 routes.ts middleware.ts このアプローチの利点: 発見可能性の向上: 関連コードと同じディレクトリにあるため、LLM が自然に参照できる 更新の同期: コードを変更する際にドキュメントも目に入るため、更新忘れが減る スコープの明確化: 各ドキュメントが担当する範囲が明確 Agentic Coding でのドキュメント管理の方向性 「Your Docs Directory Is Doomed」の記事は、従来のドキュメント管理は「1985年からの解決策」に過ぎないと指摘しています。Agentic Coding 時代には、以下の要素が重要になります: ...

2026年3月13日 · 2 分

AIによる生産性向上は10倍ではなく10% — DXの400社調査が示す現実

DX 社の Deputy CTO である Justin Reock 氏が、400社のデータを分析した結果を公開しました。AI コーディングツールの導入による開発者の生産性向上は、ベンダーが謳う「2〜3倍」や「10倍」ではなく、約10% にとどまるという内容です。 調査の概要 DX 社は 2024年11月から2026年2月にかけて、400社のエンジニアリング組織を対象に、AI ツールの利用状況と PR(Pull Request)スループットの相関を分析しました。 主な結果: AI ツールの利用率は平均 65%増加 PR スループットは 9.97%(約10%)の増加 にとどまった 大半の組織は 8〜12% の範囲に収まった なお、PR 目標値を設定しているチーム(メトリクスのインフレーションが起きやすい)は分析から除外されています。 なぜ10倍にならないのか 開発者へのインタビューから浮かび上がった根本的な理由は、「コードを書くこと自体がボトルネックではなかった」 という点です。 あるシニア開発者のコメント: 簡単なタスクは少し楽になった。4日かかるタスクが3日になるかもしれない。でも、それは PR を3倍出せるという意味ではない。 ソフトウェア開発のライフサイクル全体を考えると、コーディングはその一部に過ぎません: 要件の理解・すり合わせ — AI では圧縮しにくい コードレビュー — 人間同士のコミュニケーションが必要 テスト・デプロイ — 組織のプロセスに依存 チーム間の調整・ハンドオフ — 人間中心の活動 AI ツールがコーディング速度を50%向上させたとしても、コーディングが全体の15%しか占めていなければ、全体への影響は限定的です。 10%でも価値はある 記事では、10%の生産性向上を過小評価すべきではないとも指摘しています。 500人の開発者がいる組織なら、50人分の追加アウトプット に相当 採用コストなしでその効果が得られる 組織全体で一貫して得られる改善は意味がある エンジニアリングリーダーへの示唆 この調査結果は、AI ツール導入における期待値の設定が重要であることを示しています: 現実的な目標設定: 10倍ではなく10%の改善を前提に ROI を計算する ボトルネックの正確な把握: コーディング以外のプロセス(レビュー、テスト、調整)にも目を向ける ベンダーの主張を鵜呑みにしない: マーケティング上の数字と実測値には大きな乖離がある 参考 AI productivity gains are 10%, not 10x — Justin Reock (DX Newsletter) 元ポスト — Haruki Yano (@harumak_11)

2026年3月13日 · 1 分

AI動画編集 自動化のカラクリ — 自動カット・自動テロップで編集時間を劇的に短縮する方法

動画編集者のカズマル氏(株式会社ブイスト)が、300日以上かけて50種類以上のAIツールに500万円以上を課金して検証した「AI動画編集 自動化のカラクリ」が話題になっている。AIによる自動カットと自動テロップで、動画編集のワークフローがどう変わるのかを整理する。 AI動画編集が解決する2つの課題 動画編集で最も時間がかかる作業は、大きく2つに分けられる: カット編集 — 無音部分、言い淀み、NGテイクの除去 テロップ作成 — 字幕・キャプションの生成と配置 従来これらは手作業で行うしかなく、30分のインタビュー動画であればテロップ作成だけで2時間以上かかることも珍しくなかった。AIツールの登場により、これらの作業が大幅に自動化されつつある。 自動カットの仕組み AIによる自動カットは、主に音声波形解析と無音区間検出で実現されている。 代表的なアプローチ 無音区間の自動検出・削除: 音声波形から無音部分を特定し、ワンクリックで除去 フィラーワード検出: 「えーと」「あのー」など不要な言い淀みを音声認識で検出して除去 ジャンプカット生成: 不要な間を詰めた際の映像の不自然さを、自動ズーム・パンで軽減 実務での注意点 感度設定が重要で、高すぎると必要な「間」までカットされてしまう。プレビューで確認しながらの調整が必須だ。 自動テロップの仕組み 音声認識(STT: Speech-to-Text)技術を使い、動画内の音声を自動で文字起こしして字幕化する。 最新のAI文字起こし精度 2026年現在、日本語の音声認識精度は飛躍的に向上しており、実用レベルに達している。多くのツールが100言語以上に対応し、翻訳字幕の自動生成も可能になっている。 テロップ作成の効率化 手動でテロップを作成する場合と比較して、最大90%以上の時間短縮が見込める。30分のインタビュー動画であれば、通常2時間以上かかるテロップ作成が数分〜15分程度で完了する。 主要なAI動画編集ツール Vrew(ブリュー) 韓国Voyager X社が開発したオールインワンAIビデオエディター。 音声認識ベースの編集: 動画の音声を自動で文字起こしし、テキストベースで編集可能 無音区間の自動削除: ワンクリックで無音部分を検出・削除 テキスト編集=映像編集: 文字起こしテキストの不要部分を削除すると、対応する映像も自動カット 無料プランあり Adobe Premiere Pro プロ向け動画編集ソフトにもAI機能が搭載されている。 シーン編集検出: AIが自動的にシーン境界を検出してカット 自動文字起こし: 音声からキャプションを自動生成 カラーマッチ: 異なるシーンの色合いをAIで自動調整 OpusClip 長尺動画からショート動画を自動生成するクラウドサービス。 見どころの自動抽出: AIが重要なセグメントを検出してダイジェスト動画を生成 自動字幕生成: 多言語対応・翻訳機能付き ノイズ除去: AI音声エンハンス機能 PowerDirector CyberLink社のAI搭載動画編集ソフト。 AI音声読み上げ: テキストから音声を自動生成 AI背景除去・自動顔ぼかし: 映像加工の自動化 AIノイズ除去: 音声品質の向上 500万円の課金検証から見えるもの カズマル氏のように大量のツールを実際に業務で検証することで見えてくるのは、単一のツールで完結するケースは少ないということだ。実務では複数のツールを組み合わせたワークフローが必要になる。 一般的なAI動画編集ワークフロー 素材撮影 → AIで無音カット → AI文字起こし → テロップ調整 → 最終編集 (Vrew等) (Vrew/Premiere) (手動微調整) (Premiere等) 重要なのは、AIは「完全自動化」ではなく「大幅な時短」を実現するツールだという点だ。最終的な品質チェックと微調整は人間の判断が必要になる。 ...

2026年3月13日 · 1 分

Claude Code × ローカルLLM で KVキャッシュが毎回無効化される問題と対策

Claude Code をローカルLLM(llama.cpp、Ollama など)で使う際に、毎回プロンプト処理に異常な時間がかかるという問題が報告されています。原因は Claude Code が付加する「Attribution Header」によるKVキャッシュの無効化です。設定一つで解決できるので、対処法をまとめます。 何が起きているのか Claude Code v2.1.36 以降、リクエストごとに以下のような Attribution Header がプロンプトの先頭に付加されるようになりました。 x-anthropic-billing-header: cc_version=xxxx; cc_entrypoint=cli; cch=xxxx; この cch の値がリクエストのたびに変化します。ローカルLLMサーバー(llama.cpp、Ollama、LM Studio など)はプロンプトの先頭からバイト単位で一致した部分までKVキャッシュを再利用する仕組みのため、先頭が毎回変わるとキャッシュが丸ごと無効化されます。 結果として、数万トークンのシステムプロンプトや会話履歴を毎回ゼロから処理することになり、推論速度が最大90%低下するという報告があります。 対策:Attribution Header を無効化する ~/.claude/settings.json の env セクションに以下を追加します。 1 2 3 4 5 { "env": { "CLAUDE_CODE_ATTRIBUTION_HEADER": "0" } } 既に settings.json がある場合は env セクション内にキーを追加してください。 注意点 export CLAUDE_CODE_ATTRIBUTION_HEADER=0 ではダメ。シェルの環境変数として設定しても反映されません。必ず settings.json 経由で設定します ついでに不要なテレメトリも無効化しておくと、余計な通信を減らせます 1 2 3 4 5 6 7 { "env": { "CLAUDE_CODE_ATTRIBUTION_HEADER": "0", "CLAUDE_CODE_ENABLE_TELEMETRY": "0", "CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": "1" } } KVキャッシュの仕組みをおさらい ローカルLLMサーバーが採用している Prefix Caching(Automatic Prefix Caching)は、プロンプトの先頭から連続して一致するトークン列のKV(Key-Value)テンソルを再利用する仕組みです。 ...

2026年3月13日 · 1 分

Claude Codeで「AI チーフ・オブ・スタッフ」を構築する ― Jim Prosserの36時間実験

テックコミュニケーション・コンサルタントのJim Prosser氏が、Claude Codeを使って36時間で個人用AIアシスタントシステムを構築した。「My chief of staff, Claude Code」と題されたこの取り組みは、非エンジニアがClaude Codeのサブエージェント機能を活用して日常業務を自動化した実践例として注目を集めている。 システムの全体像 Prosser氏が構築したのは、毎朝起床前に自動で業務の下準備を完了させるシステムだ。常時稼働のMac Studio上で2つの自動プロセスが夜間に実行され、朝6:15までに処理が完了する。 主な機能: メール自動トリアージ — 受信メールからアクション可能な項目を特定し、Todoistのタスクと重複チェック カレンダー管理 — Google Maps APIを使った実際の移動時間計算を含むスケジュール最適化 6つの並列AIエージェント — Claude Codeのサブエージェント機能で独立したワーカーを同時実行 「AM Sweep」ボタンの仕組み Stream Deckの物理ボタンを押すと、6つの専門エージェントが並列で起動する: メール下書き作成(送信はしない、レビュー用の下書きのみ) Obsidianのクライアントファイル更新 ミーティングのスケジュール調整 見込み客やトピックのバックグラウンドリサーチ タスクの分類とコンテキスト収集 各エージェントは独自のコンテキストウィンドウとスコープされたツールアクセスを持ち、互いに干渉せずに動作する。 タスク4色分類フレームワーク Prosser氏は「dispatch, prep, yours, skip」の4段階でタスクを分類する: 色 分類 内容 🟢 緑 Dispatch AIが完全に処理 🟡 黄 Prep AIが80%完了、人間が仕上げ 🔴 赤 Yours 人間の判断が必要としてフラグ ⚪ 灰 Skip 理由付きで延期 重要なのは、判断に迷う場合は「Dispatch」ではなく「Prep」にデフォルトする設計だ。AIが勝手に完了させるのではなく、人間が最終判断する余地を常に残している。 人間とAIの境界線 このシステムの設計で最も重要な原則は「AIにやらせないことを決める」ことだ: メールは絶対に送信しない — 下書きのみ作成し、人間がレビューして送信 戦略的決定は人間が行う — 価格交渉、関係性に配慮が必要なコミュニケーションはAI対象外 不確実な場合はPrepにデフォルト — 自動処理より人間の関与を優先 Time Block機能 残タスクをカレンダーイベントに変換する機能も備えている: ...

2026年3月13日 · 1 分

Karpathy の autoresearch — LLMに「このLLMを訓練して」と丸投げしたら一晩で公式チームを超えた話

Andrej Karpathy が2026年3月に公開した autoresearch は、AIエージェントにLLMのトレーニングを丸投げするツールだ。GPU1台・一晩放置するだけで、エージェントが自律的にコード修正→実験→評価を繰り返し、人間の研究者なしで性能を改善していく。 実際に Karpathy 自身が約700回の実験を実行したところ、GPT-2の学習時間が2.02時間→1.80時間へ11%短縮された。さらに別の開発者は、8時間・37実験で0.8Bモデルが従来の1.6Bモデルを19%上回るスコアを叩き出している。 autoresearch の仕組み autoresearch はわずか630行のPythonで構成されており、3つのコアファイルで動作する。 3つのコンポーネント ファイル 役割 編集者 program.md エージェントへの指示書(戦略・ルール・評価基準) 人間 prepare.py データ準備・トークナイザー・評価関数(固定) 変更禁止 train.py モデル・オプティマイザ・学習ループ AIエージェント エージェントループ エージェントは以下のサイクルを自動で繰り返す: program.md を読んで戦略を把握 train.py を修正(アーキテクチャ変更、ハイパーパラメータ調整など) 5分間の固定時間でトレーニングを実行 val_bpb(検証ビット/バイト)が改善したか確認 改善 → 変更を保持、悪化 → 変更を破棄 1に戻る 5分の固定時間予算により、1時間あたり約12実験、一晩(8時間)で約100実験が可能になる。 実験結果 Karpathy 自身の実験 Karpathy は自身の nanochat(GPT-2トレーニング環境)に autoresearch を適用: 約700回の実験を2日間で実行 約20個の実質的な改善を発見 GPT-2到達時間: 2.02時間 → 1.80時間(11%短縮) 発見された改善の例: バッチサイズの半減(5分以内のステップ数増加) モデル深度の調整(depth 9への最適化) スライディングウィンドウ比率のチューニング コミュニティの成果 GitHub Discussions で報告された改善: Discussion #32: val_bpb を 0.9979 → 0.9773 に改善(89実験、H100 80GB) Discussion #43: val_bpb を 0.9979 → 0.9697 に改善(126実験、H100 80GB) Tobi のケース: 0.8Bモデルが従来の1.6Bモデルを 19%上回るスコア(37実験、8時間) 使用されるLLM autoresearch のエージェントとして動作するLLM自体は外部モデルを使用する。Karpathy のテストでは Claude や GPT 系モデルが使われている。 ...

2026年3月13日 · 2 分

営業向けClaude Code活用術:/mtg-prepで商談準備が5分で終わる世界線

DAIJOBU CEO の山中裕貴(@0xfene)氏が、Claude Code のカスタムスキル機能を営業業務に活用し、商談準備を劇的に効率化した事例を紹介している。 従来の商談準備の課題 営業担当者の商談サイクルには、以下のような時間のかかるタスクが含まれる: 商談前: 30分〜1時間かけて Gmail・Slack・議事録ツールから過去のやり取りを手動で情報収集 商談中: 準備不足で焦ることがある 商談後: 15〜20分かけてフォローメールを作成 Claude Code スキルによる自動化 山中氏は Claude Code のスキル機能(.claude/skills/ 配下にプロンプトを定義する仕組み)を使い、営業ワークフロー全体を自動化した。 /mtg-prep — 商談準備の自動化 /mtg-prep コマンドを実行すると、複数の AI エージェントが並行稼働し、以下の情報を 2〜3分で収集・整理する: 過去のやり取り: Gmail、Slack、Circleback(AI 議事録サービス)から顧客との過去のコミュニケーションを取得 顧客調査: 企業情報、業界動向のリサーチ 競合調査: 競合他社の状況を自動調査 提案ドラフト: 確認事項、提案の方向性、想定質問、フォローアップのアクションプランを整理 結果はマークダウンファイルとしてローカルに保存される。 /follow-up — 商談後フォローの自動化 商談終了直後に /follow-up コマンドを実行すると、商談の内容を踏まえたフォローメールが 2〜3分で自動生成される。記憶が鮮明なうちに具体的な内容を含んだメールを送れるのがポイントだ。 /export-gdoc — ドキュメント共有 作成されたマークダウンファイルを Google ドキュメントに変換し、Notion スタイルの統一されたデザインで社内共有やクライアントへの提案に活用できる。 導入効果 山中氏によると、Claude Code 導入後は 体感で 3〜5倍の商談量を品質を下げずに捌ける ようになったという。 項目 導入前 導入後 商談準備 30分〜1時間 2〜3分(/mtg-prep) 商談中 準備不足で焦る場面も 相手の話に集中できる フォローメール 15〜20分 2〜3分(/follow-up) Claude Code スキルの仕組み Claude Code のスキル機能は、プロジェクトの .claude/skills/ ディレクトリにマークダウンファイルとしてプロンプトを定義する。/スキル名 でスラッシュコマンドとして呼び出せるため、営業担当者でも簡単に利用できる。 ...

2026年3月13日 · 1 分

AIエージェント同士をつなぐRelay基盤 — 会話とtransportを分離するアーキテクチャ

AIエージェントが単独で動く時代から、複数のエージェントが協調して動く時代へ移行しつつある。エージェント間の通信を設計するとき、「会話(何を話すか)」と「transport(どう届けるか)」を分離する考え方が重要になっている。本記事では、2026年に整備が進むエージェント間通信プロトコルの全体像と、Relay基盤のアーキテクチャを整理する。 なぜ「会話」と「transport」を分離するのか AIエージェント同士が会話する際、2つの関心事が混在しがちだ: 会話層: タスクの依頼、進捗報告、結果の返却といった「意味のあるやりとり」 transport層: HTTP、gRPC、WebSocket、SSE といった「届ける仕組み」 これらを密結合にすると、transport を変更するたびに会話ロジックを書き直す必要が生じる。たとえば、開発時は HTTP で通信していたエージェントを、本番では gRPC に切り替えたいケースや、ローカルの関数呼び出しからリモートの API 呼び出しに切り替えたいケースがある。 分離することで、エージェントのビジネスロジック(会話)は transport に依存せず、transport の差し替えが容易になる。 2026年のエージェント間通信プロトコル 現在、エージェント通信の標準化が急速に進んでいる。主要なプロトコルは以下の通り。 MCP(Model Context Protocol) Anthropic が策定したプロトコルで、エージェントと外部ツール/リソースの接続を標準化する。API、ファイルシステム、データベースへのアクセスを統一的なインターフェースで提供する。 役割: ツール・コンテキスト層 transport: RESTful サーバー経由の構造化データ交換 エージェント → MCP サーバー → 外部ツール(DB, API, ファイル) A2A(Agent-to-Agent Protocol) Google が主導し、50社以上のパートナーが参加するオープン標準。エージェント同士のピアツーピア通信とタスク委譲を実現する。 役割: エージェント間通信層 transport: HTTPS 上の JSON-RPC 2.0 + SSE(ストリーミング) 通信モデル: クライアントエージェント → リモートエージェント クライアントエージェント ──JSON-RPC──→ リモートエージェント ←──SSE──── A2A の特徴は、エージェントの内部メモリ、ツール、ロジックを共有せずに協調できる点。発見(Discovery)→ 認可(Authorization)→ 通信(Communication)の3段階で動作する。 ACP(Agent Communication Platform) REST ベースの通信とエージェントレジストリを組み合わせたプラットフォーム。 役割: レジストリ駆動の通信基盤 transport: REST インターフェース 特徴: ステートフルなメッセージルーティングでコンテキストを保持 ANP(Agent Network Protocol) インターネット規模のエージェント協調を想定したプロトコル。 ...

2026年3月12日 · 2 分