MCPでAIに記事公開を任せたら、15分の作業が1分になった
アウン・ピエAIエンジニア結論から書く。自社サイトに公開用のAPIを作り、MCP経由でAIに記事公開を任せました。1本あたり10〜15分かかっていた公開作業は、1〜2分になりました。 ただ、速くなったこと自体は本題ではありません。効いたのは、AIに「できないこと」を先に決めたことと、自分以外のメンバーが使える形にしたことの2つです。この記事では、その経緯と判断を順に書きます。
以前の公開手順：1本に10〜15分
自社サイトに記事を1本公開するまでの流れはこうでした。管理画面にログインして、エディタを開き、書き終えた原稿を貼り付ける。見出しを設定し直して、公開ボタンを押す。
この中でいちばん時間がかかるのは画像でした。画像は別の管理画面で扱う仕組みになっていて、1枚使いたいだけでも、まずそこにアップロードし、URLをコピーして、記事本文に戻って貼り付ける。画像が3枚あれば、この往復を3回繰り返します。
記事の内容によって、10分から15分ほどかかっていました。1回や2回なら気にならない作業ですが、回数が増えると手間が積み上がってきます。
原稿を書く時間ではありません。公開するだけでこれだけかかっていました。
記事公開の手順の比較。以前は8ステップで10〜15分、今は2ステップで1〜2分
APIで自動化しようとして、できなかった
この作業を楽にしたいと思っていました。自社サイトにはAPIがあります。
APIというのは、あるプログラムから別のプログラムを呼び出せるように用意された窓口のようなものです。スマートフォンの天気アプリを思い浮かべてください。あのアプリ自体が天気を知っているわけではありません。別の場所に問い合わせて、返ってきた内容を表示しています。その問い合わせ口がAPIです。
今のサービスの多くにはこれが用意されています。画面には見えませんが、裏側でいつも動いています。APIについては別の記事で書いているので、ここではこのくらいの理解で十分です。
自社サイトにAPIがあるなら、プログラムを1つ書いて記事を公開させればいい、という話になります。
できませんでした。
自社サイトのAPIは読み取り専用でした。データを取り出す部分しかなく、新規作成、編集、削除にあたる部分は用意されていません。
珍しいことではありません。多くのサイトがこうなっています。サイトは見せるために作るものなので、読み取りの部分だけで足りていたのです。記事の公開は人が管理画面から行う、という前提です。つまり自動で公開したいなら、まず公開できる窓口を自分で作る必要がありました。
公開用のAPIを、プログラムではなくAIに使わせる
作ることは決めましたが、作り始める前に決めることが1つありました。誰が使うのか、です。
選択肢は2つありました。1つは、プログラムを書いてしまうこと。「このファイルを読んで、画像をここに保存して、公開する」という手順を書いておく方法です。一度動かせば、あとはボタンひとつで終わります。
もう1つは、AIに使わせること。「この記事を公開して」と伝えるだけです。
前者のほうが単純で、速く、間違いも起きにくい。それでも選びませんでした。
プログラムを書くには、何をするのかを先に決めておく必要があります。記事を公開する作業は、そうではありませんでした。
この記事には画像が2枚。次の記事では5枚。ある記事では画像の位置が本文の途中でなければいけない。別の記事では新しいタグが必要になる。キャプションを入れたい記事もあります。こうしたことは原稿を書きながら決まっていきます。
プログラムで対応するなら、起こりうる状況を全部先に想像して書いておくことになります。想像しきれなかったものが出てきたら、また書き直しです。それなら自分でやったほうが早い、というのが正直な見立てでした。
AIが違うのはこの点です。作業の途中で判断できます。
MCPでAIに自社サイトの使い方を教える
AIに「公開して」と伝えるだけでは動きません。自社サイトをどう呼び出すのか、何を渡す必要があるのかを、あらかじめ伝えておく必要があります。
その伝え方を標準として決めたものがMCPです。Model Context Protocolの略で、2024年11月にAnthropicが公開した仕組みです。
やっていることは単純で、道具をAIが読める形で紹介しているだけです。こんな内容を書いておきます。
- ここに「記事を公開する」という機能がある
- 使うにはタイトル、本文、タグが必要
- 成功したら記事のURLが返る
これだけです。AIはこれを読んで、記事を公開したいときはこれを使えばいいと分かります。大事なのは、いつ呼び出すかを指定していないところです。AIが会話の流れの中で判断します。
コンセントの規格に近いかもしれません。照明器具も電気もそろっているのに、差込口の形が合わなければつながりません。標準になっているぶん、もう1つ利点があります。一度作っておけば、MCPに対応している別のAIツールからも同じものを使えます。
公開用の窓口を作るときは、MCPにつなぐ前提で作りました。人が使うためではなく、AIが使うためのものです。
1つ付け加えておくと、MCPはAPIを置き換えるものではありません。下で動いているのはAPIです。差込口の形が揃っただけで、部品そのものは変わっていません。
AIからMCP、公開用の窓口、自社サイトAPIまでの関係
結果：公開作業が15分から1〜2分に
公開用の窓口を作り、MCPに必要な部分も作りました。どちらもClaude Codeに書かせたものです。自分のパソコンの中に置いています。
今は記事をファイルとして保存しています。「この記事を公開して」と伝えるだけで済みます。AIが画像を保存し、URLを取得して本文の正しい位置に貼り付けてくれます。手でコピーする作業はなくなりました。
15分が1〜2分になりました。短くなったこと自体は、そこまで重要ではありません。
以前は「原稿を書く」と「記事を公開する」という2つの作業がありました。書き終わっても一息つけない。まだ次の段階が残っているからです。今は書き終われば終わりです。
チームの他のメンバーが使えるようにする
ここまでで終わったと思っていました。終わっていませんでした。
チームの他のメンバーも使える状態になって、はじめて意味が出てきます。その段階で問題が出ました。
この仕組みを使うには、パソコンの中にあるファイルを探して、中に数行を手で書き足す必要があります。ファイルの場所はOSによって違う。書き足した内容が1か所でも間違っていると、エラーも出さずに静かに動かなくなります。なぜ動かないのか、自分でもすぐには分かりません。
これをエンジニアではない人に頼むことはできません。そこで、この手順を自動でやってくれる小さなプログラムを別に書きました。実行すれば終わります。
この段階がなければ、これは自分専用の道具のままです。会社にとっての価値は出てきません。技術が社内に入るかどうかを決めるのは、この段階だと思っています。動かせるかどうかではなく、他の人が使えるかどうかです。
AIにできないことを先に決めておく
AIが「公開できる」ということは、たいてい「削除できる」ということでもあります。ここは、窓口を自分で作ったことが幸いしました。何ができるかを、自分で決められたからです。作る時点でこう決めています。
- 公開済みの記事は削除も編集もできない
- タグと著者は削除できない
後から制限を足したわけではありません。最初からその部分を作っていないだけです。最悪の場合でも、下書き1本が壊れるだけで済みます。公開済みの記事には手が届きません。
自分のパソコンの中に置いているのも意図的です。オンラインに置けばどこからでも使えて便利ですが、誰が何をできるのかを管理するのが難しくなります。今の段階で必要なものではありません。
AIに仕事を任せるときは、何をやらせるかより、何をできないようにしておくかを先に決めるほうが重要です。そのほうが、結果として安心して任せられました。
自動化する作業をどう見つけるか
この方法がいつでもいいわけではありません。やることが毎回同じ形なら、ここまでのものは必要ありません。普通のプログラムで足ります。そのほうが速く、間違いも起きにくい。
自社サイトの場合に必要になったのは、記事ごとに形が違ったからです。画像の枚数も、構成も、必要なものも毎回変わります。
振り返ってみて、1つ気づいたことがあります。この作業を一度も「問題」だと思っていませんでした。
1回15分です。会議で報告するような話ではありません。誰かに文句を言うような話でもない。やってしまえば終わる作業です。けっこう長いあいだ、そのまま続けていました。
どの会社にもこういう作業があります。難しくはないけれど、何度も繰り返す。1回ずつ見れば小さく、1か月分を足すとかなりの量になります。
こういう作業は、自分で探さないと出てきません。誰も言ってこない。自分でも大変だとは思っていない。
この記事を読んでMCPを試す必要はありません。かわりに1つやってみてください。先週、同じ作業を何回やったか書き出してみる。1回あたりどれくらいかかっているか。
思っていたより多いことに気づくはずです。そこではじめて、自動化すべきかどうかを考えられます。数えないまま自動化してしまうと、いちばん時間を使っているものとは別のものを解決していることもあります。
