翻訳者ノート
こんにちは！コンテンツチームの加藤です。
毎月の記事構成案をスプレッドシートからAsanaのタスクに手作業で移し替える作業、身に覚えのある方も多いのではないでしょうか。この記事は、CDataの米国コンテンツチームが実際にClaudeとConnect AIを使ってその作業を自動化していく過程を、6週間・8回のセッション分、失敗も含めてそのまま記録した一人称のレポートです。「AIエージェントに何を任せて、何を任せないか」の線引きを、実例を通じて感じ取っていただければと思います。 |
In 以前自律性のスペクトラムという記事で、多くのAIエージェントのワークフローは「AIによる探索」か「決定論的なコード実行」かの二者択一ではないと書きました。実際には、ワークフローが成熟するにつれて各ステップは両方の特性を持ちながらこのスペクトラム（軸）上を行き来することになるでしょう。
その記事で取り上げたのが、コンテンツチームが記事の構成案を評価してAsanaタスクを作成する例でした。誰かが一連のブログ記事の構成案を、ブランド適合性とメッセージングの観点でレビューします。そのうえで、執筆者とコンテンツチーム向けにAsanaでタスクを作成する、という内容です。
実は、あの例は私自身の話です。この記事では、上記のプロセスがどう変化していったのかをはじめから最後まで詳しくお話しします。
きっかけは1月のある火曜日の朝、近所のカフェでのことでした。AIとはまったく関係のない、スプレッドシートにまつわる問題です。毎月、デマンドジェネレーション（需要創出）チームからコンテンツチームに15〜20件のブログ記事作成依頼がまとめて届きます。
それぞれのブログ記事構成案へのリンクが記載されたスプレッドシートも一緒に渡されます。各記事の構成案は、狙いたい検索クエリに紐づいています。私の仕事は、そのスプレッドシートをAsanaのタスクに変換することでした。具体的には、次の作業をひとつずつすべてClaude.aiのチャット上で手作業でこなしていました。
BLOG用テンプレートからのタスク起票
公開日の設定
ドラフト・レビューのサブタスク期日の逆算
適切な担当者のアサイン
タスク説明欄への記事の構成案リンクの貼り付け
Claudeが曜日の計算を間違えれば訂正し、アップデートでテンプレート構造が消えれば説明し直します。そんな調整を重ねながら1日でこなせるのは3〜4タスクほどで、それが精一杯でした。
「スペクトラム」記事の言葉を使えば、これは完全に非決定論的なプロセスです。私があらゆる判断をガイドしており、1つとして同じセッションはありませんでした。
6週間後、8回目のセッションを迎えるころには、私が出す指示はたった三語になっています。口にするのは「Do the thing（あれ、やっといて）」――それだけです。
するとClaudeがスプレッドシートを読み込み、依頼されたトピックに記事の構成案を突き合わせます。各記事の構成案を競合の引用や訴求の弱さの観点でレビューし、そのうえで正しい期日と機能するSharePointリンクを備えたAsanaタスクを5件、完全な状態で作成します。
最後に結果を報告してくれます。私がやることは、コピー&ペーストだけでした。その先の工程はすべて自動的に進み、大部分が決定論的な操作へと移っていました。
私のコンテンツチームの制作を自動化したこの仕組みは、CData Connect AIの上で動いています。しかもこれは、まさにそのブログ記事群が扱っている製品そのものです。この記事のために都合よく仕組んだ偶然ではありません。実際に、ヘルスケア業界の専門商社では、同様の仕組みによる導入事例があり、プロンプトだけで追加のチューニングや開発なしにLLMの自動カテゴライズを実現しています。
ワークフローがスペクトラムの上を移動できた理由は、まさにここにあります。だからこそ、その仕組みを具体的に見ていく価値があるのです。
今のワークフローは何をしているのか
現在のワークフローは、2つのインプットから始まります。ひとつは、デマンドジェネレーションチームから届く、その月に依頼されたトピックのリストです。もうひとつは、SharePoint上のExcelにまとめられた記事の構成案のスプレッドシートです。
ClaudeはConnect AI経由でこのスプレッドシートを読み込みます。Connect AIは、Excel Onlineを検索・参照可能なデータソースとして公開しています。そのおかげで、各記事の構成案の狙いたい検索クエリが依頼トピックとどれだけ合致するかを確認できるのです。最も価値の高い記事の構成案を、それぞれのトピックに突き合わせていきます。同じ発想でPower BIレポートの更新をAIに任せる活用例もあり、Power BIレポート自動更新の3ステップでも紹介しています。
マッチングができると、Claudeはリンク先のWordドキュメントを開き、編集者の目線で読み込みます。リンクされている記事の構成案はどれも良い出発点です。ただ、論点を説明するために競合製品を引き合いに出していることが多いのです。そのため、CDataならではの訴求が十分に効いていないケースも見られます。
Claudeはこうした競合の引用を検出し、同じ主張を裏づけつつ競合名を出さない第三者ソースに置き換えます。そのうえで、執筆者の手に渡る前に製品メッセージングとCTAの訴求を磨き上げます。このステップは意図的に非決定論的なまま残してあります。その理由は後ほど説明します。
ここから先は、Connect AI経由でAsanaにアクセスします。BLOGタスクテンプレートから新しいタスクを起票し、公開期日を設定します。ドラフトとレビューの期日は営業日ベースで逆算し、サブタスクは適切な担当者にアサインします。最後に、機能するSharePointリンク付きでタスクの説明欄を書き上げます。
ワークフローのこの後半部分は決定論的です。同じ記事の構成案と同じ期日からは、毎回同じ構造のタスクが生成されます。誰が見ていようがいまいが毎月淡々と回る仕事には、まさにこれが求められる性質です。
とはいえ、タスクセットを公開する前には今も必ず自分の目で確認しています。記事の構成案の質の判断が際どいケースでは、やはり人の目でチェックしたいのです。執筆者が3本のドラフトを書き上げてしまう前に、ミスマッチを見つけておきたいからです。
このシステムは作業を加速させてくれますが、その仕事が良いかどうかを判断する力までは代わってくれません。
どう作ったか：試行錯誤のフェーズ
このワークフローは、最初から自動化を目指してスタートしたわけではありません。最初のセッションは、人間とLLMという2人のユーザーによる手探りでした。そもそも何が可能なのかを、一緒に探るところから始まったのです。
ClaudeはConnect AI経由でAsanaのスキーマを探索し、BLOGタスクテンプレートのIDを見つけました。そこからプロジェクトとセクションのIDを突き止めます。私が見守りながら訂正を入れる中で、1件のタスクを最初から最後まで作り切りました。
何が必要なのか、まだ2人とも分かっていませんでした。だからこそ、この最初のセッションのあらゆるステップは、スペクトラムの非決定論的な側に位置していたことになります。結局、接続先システムのモデルを固め、実行すべきタスクを洗い出す必要がありました。そのためにClaudeと私は、およそ2時間を探索と検証に費やしています。
この探索の準備時間が短く済んだのは、各システムがあらかじめConnect AIに接続されていたおかげです。Model Context Protocol（MCP）の設定は最初から用意されていました。こうした探索のために作られたUniversal Toolsも含めてのことです。私がやったのは、各システムにConnect AIからサインインすることだけでした。それだけで、Claudeと私はすぐに作業に取りかかれました。
2回目のセッションで、最も役に立つ失敗の数々が起きました。Claudeは期日の曜日を暗算で求めようとして間違え、しかも同じ会話の中で二度も誤りました。1月21日は本当は水曜日で、私が指摘するまでそれに気づかなかったのです。
タスクの説明欄にSharePointリンクの追記を頼んだところ、Notesフィールド全体が上書きされました。構造化されていたBackground・Resources・Templateのレイアウトが、1行に置き換わってしまったのです。
しかも次のタスクでも同じことが起きました。私がClaudeに伝えた修正が、その場限りの対応にとどまり、背後にあるパターンには届いていなかったからです。
SharePointのドキュメント検索は、正確なファイル名を渡すと失敗しました。いくつかのキーワードに広げて、ようやく成功したのです。また、SharePointのリンクにエンコードされていない半角スペースが含まれていたことがありました。そのせいで、Asana上のハイパーリンクが完全に壊れてしまったのです。
その瞬間ごとに見れば、どれも単発のミスに見えます。しかし8回のセッションを通して積み重ねると、もっと価値のあるものが見えてきました。ワークフローのどこに「判断」ではなく「ルール」が必要かを示す地図です。
曜日の誤りは、必ずbashのdateコマンドで検証する、という譲れないルールになりました。壊れたテンプレートは、更新のたびにClaudeが保持すべき、文書化されたNotes構造になりました。
壊れたリンクは、たった1行のエンコーディングルールになりました。もしAPI連携を最初から設計しようとしていたら、こうした発見はひとつも表に出てこなかったはずです。Claudeが実際にぶつかるまで、失敗のパターンなど私にも分からなかったからです。
この探索は無駄な工程ではなく、設計そのものでした。だからこそスペクトラムのフレームワークは、非決定論的な探索を急いで通り過ぎるべき「フェーズ」だとは考えません。むしろそこにこそ、決定論的なバージョンの形が見えてくるのです。
開発者もAPIドキュメントも使わずに探索できたのは、Connect AIのMCPインターフェースのおかげです。Claudeは、一度認可しておいた接続に対してSQLを投げるだけで、Asanaのスキーマを調べられました。テンプレートにどんなフィールドがあるかを確認し、サブタスクが親タスクとどう紐づいているかも把握できたのです。こうしたSQLベースの探索をエンタープライズ規模までさらに発展させる手法は、MCPとClaudeスキル パート3で解説しています。
エンジニアがAsanaのREST APIドキュメントを読みながら調べれば、丸1日かかるようなスキーマ調査です。それが、Claudeとの数分の会話で済んでしまいました。
探索から実行へ：スペクトラム上の軸の移行
5〜6回目のセッションあたりから、作業の性質が変わり始めました。この頃には、繰り返し起きていた失敗のすべてが、明確な指示に変換されていたのです。
チャット履歴を見ると、6回目のセッションはそのまま「Do the thing」というタイトルになっています。実際に私がそう打ち込んだからで、Claudeは修正なしで5件のタスクを作成しました。
この中間のセッションこそ、きちんと名前をつけておく価値があります。探索から決定論へ一足飛びに移ったわけではないからです。スペクトラムのフレームワークが「ハイブリッドゾーン」と呼ぶ領域に、しばらく留まっていました。
タスクの構造は固まっているものの、その中でClaudeはまだ判断を働かせていました。どの記事の構成案がトピックに最も合うかを決め、指示がまだ想定していなかったエッジケースを拾い上げていたのです。実際のエンジニアリングの大半は、このハイブリッドな期間に、1つずつ修正を重ねる形で起きました。そして最終的には、指示でカバーしきれていない判断はほとんど残らなくなりました。
8回のセッションを通じて起きたのは、自動化が漠然と良くなっていく、という話ではありません。1つ修正するたびに、その場でClaudeが判断し間違える余地のあったステップが、同じ入力から確実に同じ出力を生む決定論的な側へと、具体的に一歩ずつ動いていったのです。これは、このシリーズの前回の記事が抽象的に説明していた「動き」そのものです。このワークフローは、その動きを一歩ずつ実際に目にした現場でした。
このシステムの成熟した姿は、もはやClaudeがMCP経由でAsanaとチャットするものではありません。Claudeがスクリプトを実行し、そのスクリプトがConnect AIのREST APIを直接呼び出しています。そこからAsana・Excel Online・SharePointとやり取りする形になっているのです。
この裏側のアーキテクチャが実際どう機能しているのか、上司のMarieと話した際、彼女は私よりも的確にこう言い表しました。「Connect AI向けのMCPが仕事を可能にしているけれど、実際にそれをやっているのはAPI経由のConnect AIだ。その段階まで来ると、どのスキルも結局はただのAPI呼び出しに過ぎないから」。
これは、Claude Skills vs MCP, Better Togetherで書いた関係性とまったく同じです。このワークフローは、それが本番環境で実際に動いている、私が持っている中で最も分かりやすい例です。ワークフローを組み立てたのはMCPでした。そして今、毎月それを動かしているのはMCPサーバーとAPIです。スキルとMCPツールのどちらにどこまでの責務を持たせるべきかという設計判断は、スキルとMCPツールの責務分担を考える設計戦略でさらに掘り下げています。
重要なのは、この2つのインターフェースがどちらも同じ接続の上に乗っている、という点です。同じ認可済みの認証情報、AsanaとSharePointへの同じガバナンスの効いたアクセスを共有しています。コネクタ単位でアクセス権限のスコープを絞り込めます。誰が何にアクセスしたかは監査ログに残り、SSOにも対応しています。そのため、MCP経由の探索であってもAPI経由の本番実行であっても、統制のレベルが緩むことはありません。Connect AIが全体を通じて提供する数百規模のデータソース接続性も、この2つのインターフェースで変わらず共有されています。
これこそ、スペクトラムの記事が「どのステップにいようと、あらゆるAIエージェントのワークフローに必要だ」と主張していた接続性とコントロールです。探索フェーズから本番フェーズへ移る間、プラットフォーム自体は何も変わっていません。変わったのは、Claudeがそこにアクセスするために使うインターフェースだけです。
今もLLMが必要な理由
ワークフローの大部分が、今ではAPIを呼び出す決定論的なコードになっているのだとすれば、Claudeはまだループの中で何をしているのでしょうか。そう聞かれても当然でしょう。答えは2つあり、どちらも意図的にスペクトラムの非決定論的な側に置いたままにしています。どちらも動かすつもりはありません。
1つ目は、記事の構成案の質を判断することです。ある記事の構成案がCDataのブログの土台として十分強いか、ポジショニングが刺さっているか、記事を支えるだけの製品訴求が前面に出ているかを見極めます。これには読解力と編集者としての目が必要です。コンテンツ記事の構成案の質をスコアで返してくれる関数など存在しません。
この評価はまさに、スペクトラムのフレームワークが「LLMが担うべき」としている種類の仕事です。インプットが非構造化で、多少の見落としがあってもコストが低く（私が出力をレビューするため）、固定ルールよりも判断力が本当に役立つタスクだからです。
2つ目は、競合の引用を置き換えることです。記事の構成案の中から競合製品へのリンクを見つけ出し、その引用がどんな論点を裏づけているのかを理解します。そのうえで、競合名を出さずに同じ論点を裏づける第三者ソースを特定するのです。これは毎回文脈に依存する、非構造化コンテンツに対するパターンマッチングです。
単純な置換問題ではありません。置換の姿をしていますが、実質は推論の問題です。これをルール化しようとすれば、実質的な信頼性はほとんど上がらないまま、置き換えの質だけが落ちてしまいます。
目指したのは、Claudeをワークフローから排除することではありませんでした。むしろ、何も失わずに決定論的な側へ動かせるステップを見極めることです。日付計算やリンクの整形、タスク作成がそれにあたります。それ以外は、判断が今も必要な場所にそのまま残しました。
これが、スペクトラムの記事が説明していた「ハイブリッドの規律」です。すべてのステップをどちらかの極へ押しやるのではなく、各ステップを本来あるべき場所に置きます。そして、そのすべての位置を同時に支えるインフラを構築します。
これから始める人に伝えたいこと
同じように骨の折れる手作業のプロセスを抱えている方もいるのではないでしょうか。コンテンツオペレーションのリーダーやマーケティングオペレーションのマネージャーであれば、このプロジェクトから持ち帰れることが4つあります。
まずAPIではなくMCPから始めよう。実際のデータをLLMに触らせる前に統合を設計したくなる気持ちは分かりますが、それでは推測にもとづいた設計になってしまいます。3回分の探索セッションは、どんな計画書よりも雄弁に、このワークフローがどこで壊れるかを教えてくれました。
すべてのエラーを、その場しのぎの修正ではなく仕様として扱おう。Claudeが曜日を間違えたとき、役に立ったのはその1件を訂正することではなく、「今後この間違いが構造的に起こり得なくなるルールは何か」を問うことでした。探索フェーズで起きる失敗はすべて、ガードレールをどこに置くべきか、どのステップが決定論的な側へ移る準備ができているかを、正確に教えてくれます。
他をすべてルール化する前に、非決定論的な側に残すべきものを見極よう。あるステップをスクリプトに変換する前に、それが完全には予測しきれない内容に対する推論を本当に必要としているかを問いましょう。必要としているなら、そのステップは守るべきです。そこはLLMがその存在価値を発揮している場所であり、すべてを決定論的にしようと急ぐあまり、うっかり設計上消してしまいやすい部分でもあります。
スペクトラム全体をカバーする連携基盤を選ぼう。MCPインターフェースとAPIインターフェースが、同じ認証情報・同じガバナンスのもとで同じ基盤データにアクセスできるなら、あるステップを探索から本番へ移すのは単なるコード変更で済みます。そうでなければ、本番移行のたびに一大移行プロジェクトが発生し、終わったと思った矢先にアクセス権限を巡る調整をまたやり直すことになります。本番運用まで見据えたエージェント設計の具体的な指針は、Production-readyなエージェント設計のリファレンスアーキテクチャにまとめてあります。
よくある質問
セットアップに手間がかかりそうですが、コンテンツチームにとって本当に見合うものですか？
セットアップにかかったコストは確かに実在します。6週間で8回のセッション、その過程で意味のあるエラー修正も何度も発生しました。しかし見返りは積み重なっていきます。1つ修正するたびに、以降のすべてのセッションを速く、より確実にする指示が生まれるからです。最終的には、正しい期日と機能するリンク、レビュー済みの記事の構成案を備えた5件の完全なタスクが完成しました。エラーなしで1回のセッションで完了するようになったのです。月に15〜20件のブログタスクを抱えるチームであれば、数週間で元は取れます。四半期を待つ必要はありません。
Connect AIのセットアップには開発者の関与が必要でしたか？
いいえ。Asana・Excel Online・SharePointをConnect AI経由で認可する作業は、開発者を交えずに一度行っただけです。その後は、SQLベースのアクセスレイヤーのおかげで、Claudeが何が使えるかを探索し、私はAPIドキュメントを読む代わりに会話を通じてワークフローを組み立てることができました。この探索フェーズを、IT部門を通さずに自分ひとりで進められたのは、まさにこの仕組みのおかげです。
ワークフローが壊れたときは何が起きますか、誰が直すのですか？
壊れ方は2種類あります。1つ目は上流の変更です。SharePointのファイルが移動した、記事の構成案のフォーマットが変わった、Asanaに新しいフィールドが追加された、といったケースで、これらはタスクセットを提出前にレビューする際に私が見つけ、修正内容を指示書に反映します。2つ目は、ルール化されたルールでカバーしきれない、本当に新しいケースです。この場合は、一時的にでも非決定論的な側に戻すべきケースということになります。Claudeは会話インターフェースを通じてこれに対処し、繰り返し起きるケースだと分かれば、それも指示書に追加されます。このシステムは、修正を吸収するように作られているのであって、修正のたびに壊れるようには作られていません。
ClaudeがAsanaやExcel以外のワークフローでも同じことはできますか？
重要なのは個別のツールではありません。「MCPで探索して何があるかを把握し、パターンが分かったらAPI経由で実行する」というこのパターンは、データソースがConnect AI経由でアクセスできるワークフローであれば、どれにでも当てはまります。400以上のコネクタに対応しているため、コンテンツチームやマーケティングオペレーションチームがアクセスしたいと考えるであろう主要な業務データソースの大半には、すでにサポートされた経路があります。たとえば、経費精算データをNetSuiteへ転記する、請求書PDFの内容をSalesforceの商談情報と紐づける、CRMデータを集計して週次レポートを自動作成する、といった業務も同じパターンで実現できます。このワークフローは、私が使った特定のツールに縛られた設計図ではなく、テンプレートです。
このプラットフォームの現在地
ここで紹介したワークフローは、それを構築した探索フェーズも、毎月それを動かしている本番フェーズも、どちらもCData Connect AIの上で動いています。The Autonomy Spectrumがフレームワークを示したのだとすれば、これは、そのフレームワークが実際の、雑然とした、6週間がかりの構築プロセスの中で動いているところです。
Claude CoworkやChatGPT Agentとの違いが気になる方は、オープンソースのMCPを自前で構築するか、マネージド型のConnect AIに乗せるかで迷うこともあるでしょう。機能・セキュリティ・コストを比較した各種MCPの徹底比較が判断材料になります。業務データに対してAIワークフローを構築しようとしていて、同じガバナンスの効いた接続を通じてスペクトラムのあらゆる地点をサポートするプラットフォームを探しているなら、Connect AIは無料トライアルを試す価値があります。トライアル画面では料金プランも確認できます。
記事の構成案評価とタスク登録を自動化する
CData Connect AIを使えば、Asana・Excel Online・SharePointに同じ接続でアクセスできます。記事の構成案評価のような判断が必要な工程と、タスク登録のような決定論的に自動化できる工程を、1つのワークフローとしてまとめて構築できます。SDKの実装やAPI認証まわりの管理を自分たちで行う必要はありません。
Connect AIの無料トライアルを今すぐ始めて、チーム全体の反復業務がどこまで自動化できるか試してみてください。
AIによる業務自動化をMCP連携で加速する
CData Connect AIを使えば、Asana・Excel Online・SharePointを含む300以上のシステムにアクセスし、記事構成案評価のような判断が必要な工程と、タスク登録のような決定論的に自動化できる工程を、1つのワークフローとしてまとめて構築できます。SDKの実装やAPI認証まわりの管理を自分たちで行う必要はありません。
