※この記事は、2026年8月時点のAIエージェント基盤について、自分の運用へ取り入れる前に考えたことをまとめたメモです。
※Cloudflare OS、WebMCP、EmDashの提供状態は、2026年8月29日に公式情報で確認しました。ただし、まだ自分の環境へ本格導入した結果ではありません。
最近、Cloudflare OS、WebMCP、EmDashという三つの仕組みをまとめて確認する機会がありました。
Cloudflare OSは、コンテキスト、スキル、ワークフロー、モデルや費用の管理などを一つの基盤で扱う構想です。
WebMCPは、Webサイト側がAIエージェント向けの操作を用意し、画面を見てクリック位置を推測するより構造化された形で使えるようにする仕組みです。
EmDashは、AIエージェントとの連携を意識したCMSとして開発されています。
こうして並べると、今やっていることを一つの新しい基盤へまとめられそうに見えます。
自分は現在、Obsidianへコンテキストを残し、Codexのスキルやローカルの処理を組み合わせています。ブログもWordPressで動いています。
そこへ新しい基盤が出てくると、もっときれいにまとめられるのではないかと思います。
ただ、今回はすぐ移行するのではなく、先に一つ質問を置くことにしました。
今の環境では解けない問題が、本当にあるのか。
機能が多いことと、今の自分に必要なことは別です。
新しい基盤を見ると、今ある仕組みが急に古く見える
新しいAIサービスの説明には、魅力的な機能が並びます。
AIが必要なコンテキストを読める。
スキルやワークフローを共有できる。
複数のモデルを使い分けられる。
ブラウザや外部サービスを操作できる。
実行履歴や費用も管理できる。
一つずつ見ると、どれも欲しくなります。
しかも自分の場合、似たことをObsidian、Codex、ブラウザ、ローカルツールへ分けているため、一つの画面や基盤へまとまる話はかなり魅力的です。
ただ、ここで「新しい方がまとまっているから移行しよう」と決めると、今まで作ってきた仕組みをもう一度作り直すことになります。
コンテキストの保存先を変える。
スキルを移す。
認証をつなぐ。
外部への書き込み権限を決める。
費用上限を設定する。
失敗した時の復旧方法を用意する。
導入後の便利さだけでなく、移行と維持の仕事も増えます。
今の環境で困っていることが曖昧なままでは、その負担に見合うか判断できません。
まず、今の環境で足りている部分を並べた
今回、最初に見たのは新しい機能ではなく、現在すでにできていることでした。
Obsidianには、過去の判断、作業メモ、ブログ素材、AIが読む入口があります。
Codex側には、Inbox整理やブログ作成のように、繰り返す作業を進めるスキルがあります。
外部サイトの確認にはブラウザやAPIを使い、長い原文はrawへ残し、採用前の案はworkbenchへ分けています。
もちろん、まだ不安定な部分はあります。
それでも、名前や画面は違っていても、共有コンテキスト、再利用手順、ツール接続に近いものはすでに動いています。
新しい基盤に同じ機能があるからといって、それだけで移行理由にはなりません。
逆に、今のローカル運用では確認しにくいこともあります。
パソコンを閉じても処理を継続できるか。
モデルごとの費用や上限をまとめて管理できるか。
別のセッションでも、コンテキストやスキルを安定して再利用できるか。
自分が試すとすれば、この差分になります。
「新しい基盤に何があるか」ではなく、「今の環境で何ができていないか」を先に出すと、試す範囲をかなり小さくできました。
三つとも導入せず、「小規模試験・監視・保留」に分けた
検討した結果、三つを同じ扱いにはしませんでした。
Cloudflare OSは、小規模試験の候補です。
2026年8月29日に確認した公式発表では、オープンソースとしてGitHubから利用でき、自分のCloudflareアカウントへ展開できる状態です。一方、Cloudflareのダッシュボードから使う完全なマネージド製品は、今後提供する計画とされています。
そのため、本番環境を移すのではなく、公開情報だけを使った小さい比較試験なら意味がありそうだと考えました。
WebMCPは監視です。
Cloudflare側の提供はDeveloper Previewで、Browser Runのドキュメントでも実験用の機能として案内されています。対応するサイト側がツールを公開していることも前提になるため、今すぐ自分の収集方法を置き換える理由にはしませんでした。
EmDashは保留です。
公式リポジトリでは、Astroを基盤としたTypeScript製CMSとして公開され、AI向けのスキル、CLI、MCPサーバーも用意されています。ただし、2026年8月29日時点ではBeta Previewです。
また、現在のWordPressには記事、画像、URL、カテゴリ、関連記事が蓄積しています。
AIとの連携が魅力的でも、今のブログで解けない問題が明確でなければ、CMS全体を移す理由にはなりません。
全部試すのではなく、試験候補、仕様を追うもの、今は触らないものへ分ける。
この時点で、新しい情報を見た後の作業量をかなり減らせます。
導入前に、六つの質問へ答える
今回の整理で、新しいAI基盤を見る時は、先に六つを確認した方がよさそうだと思いました。
- 今の環境で解けない具体的な問題は何か
- クラウドへ渡す必要があるデータは何か
- サブスクリプションなのか、APIの従量課金なのか
- 書き込み、公開、送信、削除の承認をどこへ置くか
- 今の方法より安く、速く、復旧しやすいと何で判断するか
- どの条件なら不採用にして撤退するか
一つ目が曖昧なら、残りの質問にも答えにくくなります。
「何となく便利そう」が出発点では、渡すデータも必要な権限も広がりやすいからです。
反対に、解きたい問題が一つなら、試験に使うデータと権限も狭くできます。
例えば、公開済みのAI関連情報を十件程度だけ使う。
個人情報や投資判断、非公開資料は渡さない。
同じ入力をローカルのCodexと新しい基盤の両方で処理する。
途中停止、重複処理、根拠リンク、費用、復旧の手間を比べる。
これなら「動いた」だけで採用せず、今の方法より良くなったかを確認できます。
不採用でも、試験が失敗したとは限らない
新しいサービスを試すと、せっかく触ったのだから何か採用したくなります。
しかし、試験の結果、今の環境より監査しにくい。
費用が分かりにくい。
復旧に時間がかかる。
渡したくないデータまで必要になる。
そう分かったなら、導入しない方がよい場合もあります。
自分は試験条件の中へ、既存運用より準備、復旧、監査の合計負担が減らなければ不採用にする、という条件を置きました。
新しい基盤を採用しなかったとしても、現在の運用で足りている部分が分かったなら、それも試験結果です。
機能追加を続けて無理に使い道を作るより、そこで止めた方が次の作業へ戻れます。
以前の「外部ツールから構造を借りる」とは少し違う
以前、公開されているAIツールを参考にする時、画面を真似するのではなく、事実、未検証の主張、再利用できる構造を分けたいと書きました。
あの記事では、外部ツールから自分の仕組みに持ち帰れる設計を探していました。
今回は、個別の構造を借りる話ではありません。
認証、データ、費用、監査、復旧まで含む基盤全体を、自分の運用へ採用するかどうかです。
参考になる機能が一つあることと、環境全体を移すことの間には、かなり距離があります。
だから今回は、採用できる機能を探すより先に、移行するほどの問題があるかを確認しました。
まとめ
新しいAIエージェント基盤を見ると、今使っている道具を一つへまとめられそうに見えます。
ただ、機能が多いことと、今の自分に必要なことは別です。
今回、自分は三つの候補を確認した後、すぐ導入するのではなく、小規模試験、監視、保留へ分けました。
その時の入口にしたのが、次の質問です。
今の環境では解けない問題が、本当にあるのか。
問題が決まれば、試すデータ、必要な権限、費用上限、合格条件、撤退条件も決めやすくなります。
まだCloudflare OSの比較試験を実行したわけではありません。
次に進めるなら、公開情報だけを使い、現在のローカル運用と同じ入力で比べるところから始めます。
新しい基盤を使うこと自体を目的にせず、今の環境で解けない問題が、本当に小さくなるのかを確認したいと思います。
参考にした公式情報
- Cloudflare OS: an open platform for agents, apps, and work
- Give any website a WebMCP interface
- WebMCP – Cloudflare Browser Run docs
- EmDash GitHub repository
コメント