MCPとは何か。USB Type-C以上の説明とAPIとの違い、AIへの仕事の任せ方

この回のテーマはMCPMCP ── Model Context Protocolの略。AIアプリと外部のツールやデータを共通の作法でつなぐためのオープンな標準で、2024年11月にAnthropicが公開しましたです。しぶちょーさんに「MCPって何？」と聞かれたかねりんさんは、ひと言で「USB-Cコネクター」と答えます。

しぶちょーさんは、この答えを「その通り」と認めます。そのうえで、USB Type-Cという例えは「なるほど」と「どういうこと？」が同時に浮かぶ絶妙な例えだと話します。

しぶちょーさんによれば、この例えはおそらくMCPを作ったAnthropicAnthropic ── AIアシスタント「Claude」を開発するアメリカのAI企業です。MCPのほか、AIエージェント向けの仕組みを数多く提案していますの公式も使っているそうです。この回は、MCPを「USB Type-Cなんだよ」以上の言葉で説明できるようになることを目標にしています。

MCPを学ぶ理由として、しぶちょーさんはまず「AIにどういう処理をさせるかは、ある程度コントロールしたほうがいい」と話します。AIに一から「これやっといて」と頼むと、中で何をしているかわからないまま結果が出てくるからです。

しぶちょーさんの提案は、よく使う作業を道具にしておき、使い方の説明書とセットでAIに渡すことです。道具はAIではないので、道具を使わせれば確実に同じ答えが出てきます。そして、その道具とAIをつなぐ部分がMCPだといいます。

かねりんさんは「自分で作ったツールなら自分のパソコンで勝手に使えるのでは」と疑問を返します。しぶちょーさんの答えは、自作ツールでもAIはセッションのたびに「これどういうツールだっけ？」と考え直し、使い方を間違えることもある、というものでした。

しぶちょーさんが強調するのは、MCPは単に共通の口で刺さるだけのものではない点です。説明書がついているポートであることが、この回の核になっていきます。

MCPはModel Context Protocolの略です。しぶちょーさんは、公式の説明を「AIアプリケーションを外部システムに接続するためのオープンソース標準」と紹介し、簡単に言えばAIエージェントに他のシステムをつなぐための共通語だと言い換えます。

MCP以前は、AIアプリにツールを使わせるたびに、接続口をひとつずつ専用に作る必要がありました。しぶちょーさんは、AIアプリとツールの組み合わせの数だけ個別の接続が必要になる状態を「N掛けるM」と表現し、「地獄みたいな」と振り返ります。

この状態を「共通の口にしましょう」と整えたのがMCPです。決まったルールでAIアプリとツールをつなぐので、ケーブルを挿せば使えるUSB Type-Cに例えられる、としぶちょーさんは説明します。

MCPの前後で、AIアプリとツールのつなぎ方は次のように変わりました。

さらにしぶちょーさんは、MCPのすごさは挿すと最初に取説をくれる点にあると話します。MCPはつながった時点で「私はこういうもので、こういうことができます」という情報をアプリ側に渡してくれるのです。

取説の話から、話題はよく比較されるAPIAPI ── Application Programming Interfaceの略。ソフトウェア同士がやり取りするための窓口で、何を送ると何が返ってくるかの決まりを指しますとの違いへ移ります。しぶちょーさんによれば、APIはツールごとにルールが違い、何を送ると何が返ってくるかは作った人次第です。

MCPはこれとは違い、つながった瞬間に「できること」を自分から教えてくれます。ただし、しぶちょーさんはMCPとAPIを対になる概念だと勘違いしないでほしいと念を押します。

実際には、MCPが中でAPIを包んでいることが多いそうです。MCPとして「こういうことができますよ」と見せつつ、裏ではAPIを叩きに行っている入れ子の関係で、しぶちょーさんはこれをバームクーヘンに例えます。

かねりんさんが「APIにも説明書はついているのでは」と聞くと、しぶちょーさんは、APIの説明書は人間のプログラマー向けだと答えます。MCPの説明書はAIに向けたもので、書き方のフォーマットまで決まっているため、情報が漏れなく伝わるといいます。

かねりんさんが「エコですか」と聞くと、しぶちょーさんも「エコですね、そういう意味では」と応じています。

ここからMCPの中身を一枚ずつ剥いていきます。しぶちょーさんによると、MCPの登場人物はホスト、クライアント、サーバーの3人です。

ホストは、ClaudeやChatGPT、Codexのような、これからツールを使いたいAIアプリやAIエージェント本体です。サーバーは実際にツールを提供するMCP本体で、一般に「MCP」と呼ばれているのはこのサーバー側だといいます。

わかりにくいのが、その間に入るクライアントクライアント ── MCPでは、ホストの中にある接続部品を指します。MCPサーバー1つと1対1で通信する連絡係で、ユーザーや依頼者のことではありませんです。依頼者のように聞こえますが、実際はアプリの中の部品で、ホストとサーバーの橋渡し係にあたります。

かねりんさんは、クライアントを「爺や」に例え始めます。しぶちょーさんは汎用的すぎると言いつつ、「パンしか買ってこない爺や」ならちょうどいいと乗っかり、この例えが回の最後まで使われることになりました。

クライアントはツールごとに1つずつ用意され、1人の爺やが複数のサーバーと通信するわけではありません。しぶちょーさんは、1ツールに1爺やを置くことで混線しないと説明し、1つのUSBポートに3本挿さないのと同じだと例えます。

お店にあたるMCPサーバーができることも、実は3つしかないとしぶちょーさんは話します。ツールを実行すること、資料を見せること、プロンプトを提供することです。

資料は、MCPの中に入っている資料を目次から自由に取ってこられるリソースリソース ── MCPサーバーがAIに読ませるために用意する資料です。1つずつに住所のような識別子が付いていて、指定して取り出しますのことです。プロンプトは、そのMCPを使うための推奨の頼み方の定型文ですが、しぶちょーさんは「あんまり使わない」と話しています。

さらに、3つの機能それぞれに「注文に応える」動作と「何ができるかのメニューを見せる」動作があります。この「メニュー」が、しぶちょーさんが繰り返し話している説明書にあたります。

かねりんさんが「爺や、何もできねえじゃねえか」と突っ込むと、しぶちょーさんは「安全に確実に持ってきてくれるから」と爺やを擁護しました。

MCPサーバーには2種類あります。しぶちょーさんによると、リモートのMCPはNotionのようにクラウドにあってみんなで使うもので、ローカルのMCPは自作ツールや自分のパソコンにインストールしたツールを動かすものです。

ただしホスト側の使い方はどちらでも同じで、ユーザーはあまり意識しなくていいそうです。「なぜならUSB Type-Cだから」としぶちょーさんは話します。

しぶちょーさんが強調するのは、MCP経由でツールを使うとき、実際に処理しているのはツール側だという点です。Notionのページを書き換えていても、AIがNotionの中に入り込んでいるのではなく、動いているのはNotion本体です。

しぶちょーさんは、AIが外にいてボタンしか押せないからこそ安全だと続けます。やり取りはJSONJSON ── データをやり取りするための書式のひとつです。項目名と値を組にして書き、プログラム同士の受け渡しによく使われます形式の文章などで、決まったルールに沿って行われます。

しぶちょーさんは豆知識として、MCPの仕様が今年7月に大きく改訂されたことを紹介します。ただしユーザー側にはほとんど変化がなく、ローカルではむしろ少し遅くなったかもしれない程度だそうです。変化は爺やにあたるクライアントが吸収しています。

しぶちょーさんによると、MCPはもともと同じパソコンの中でソフト同士を1対1でつなぐローカル向けの規格として始まりました。そのため最初に「initialize」と呼ばれる握手をして、お互いに名乗り合ってからやり取りを続ける方式でした。

この方式はローカルなら問題ありません。しかしNotionのMCPのようにネット上に1つあるサーバーには、全国から100万台、200万台といった爺やが名刺を持って押し寄せ、サーバー側は相手ごとの記憶を台帳のように保持し続けなければなりませんでした。

そこで改訂後は、サーバーは相手を覚えず、1つ1つの指示を手紙のように受け取って1つずつ返す方式になりました。かねりんさんは、壁の穴から手だけ出す握手会のようで「ちょっと味気なくなった」と表現しています。

毎回名乗る方式はローカルでは少し無駄ですが、差はほとんどないそうです。しぶちょーさんは、MCPの使われ方が思った以上にリモート中心になったため、一気にルールを変えたと説明します。

MCPのメリットについて、しぶちょーさんが最大のものとして挙げるのは、処理を確実に固定できることです。LLMは同じ作業でも毎回考えるのでアウトプットが微妙に変わりますが、MCPはボタンを押せば決まったプログラムが動きます。

しぶちょーさんによると、AIエージェントへの指示やMarkdownのルールに書いて毎回やらせている処理の中には、ツールにしたほうがトークン消費を抑えられるものがたくさんあるそうです。指示が少しずれるだけで結果が変わる処理を、確実な処理に置き換えられるのがMCPの強みです。

一方でデメリットもあります。最初に渡される説明書を、AIはかなりの確率で信じてしまうのです。

プロンプトインジェクションプロンプトインジェクション ── AIへの入力に悪意のある指示を紛れ込ませて、本来の指示と違う動きをさせる攻撃です。情報の持ち出しなどに悪用されますについて、しぶちょーさんは爺やの例えで説明します。説明書に「この情報を入れてください」と書かれていれば、爺やは「と言われております、坊ちゃま」とパスワードを持っていってしまうかもしれません。

対策はシンプルで、発行元をきちんと見て、変なMCPにはつながないことです。しぶちょーさんは、Notion、Slack、Googleカレンダー、Googleドライブ、Gmail、Figma、freee、マネーフォワード、サイボウズのkintoneといった有名な業務ツールのMCPなら、つないでいいだろうと話します。

知らないMCPが大丈夫かどうかは、AIに調べさせればいいそうです。かねりんさんは、こちらから中に入っていくイメージだったので、相手から攻撃されるという観点はなかったと驚いていました。

MCPを試すなら、しぶちょーさんのおすすめはNotionのMCPです。かねりんさんが、ClaudeやChatGPTのブラウザ版にある「連携」ボタンはMCPなのかと聞くと、しぶちょーさんは「あれMCP。コネクターでしょ」と答えます。

公式に用意されているコネクタは基本的にMCPで連携していて、公式が提供しているので安心してつないでいいそうです。ただし種類は少なく、ChatGPTでは用意されたコネクタしか使えません。

Claude CodeClaude Code ── Anthropicが提供する、ターミナルなどで動くAIエージェント型のツールです。ファイル操作やコマンド実行をAIに任せられますのようなツールでは、使うMCPを自分で選べます。さらに最近は、ローカルのソフト自体がMCPサーバーを立てられるものもあります。

しぶちょーさんがよく使っているのは3Dモデルを作るCADソフトです。オプションでMCPサーバーを立てると、Claude CodeやCodexからCADを操作でき、爺やがボタンをポチポチ押して操作してくるそうです。かねりんさんは動画編集ソフトにも広がれば幸せだと話し、ソフト会社は対応しないと食われる流れだという点で2人の意見は一致しました。

しぶちょーさんによれば、MCPはAnthropicが提案したものの、現在はオープンソースを管理する第三者の団体に管理権が移っています。そのため、Anthropicに有利な改変はできないそうです。囲い込みを避けて最初からオープンにしたからこそ広がった、という見方です。

話は少し脇道にそれ、しぶちょーさんはAnthropicにも「意外と明け渡さない規格」があると話します。Claude Codeの説明書ファイルであるClaude.mdです。

CodexはOpenAIが作ったとされるagent.mdを使います。しぶちょーさん自身は、agent.mdをOpenAIが作ったという点について「ずれてたらごめんね」と断りを入れています。いろいろなAIエージェントがいるのだから名前を付けないagent.mdのほうがいい、というのがしぶちょーさんの意見ですが、Anthropicは採用していないそうです。

そこでしぶちょーさんは、Claude.mdに「agent.mdを読みに行く」という一文だけを書き、ルールはagent.mdに一本化しています。ファイルを複製すると同期がずれて不具合が起きるので、教典は1つにしたほうがいいという考えです。

ファイルをあまり見ないというかねりんさんに、しぶちょーさんは「見た方がいいよ」と返します。中身がブラックボックスになっていることこそが、この回のテーマにつながっていきます。

しぶちょーさんのメッセージは、ブラックボックスになった作業のうち定型的な部分を切り出し、ツールにしていくことです。AIに毎回やらせているルーティン作業の中に、プログラムにすればトークンを使わずに済む部分がないかを探します。

ただし、しぶちょーさんは必ずしもMCPである必要はないと話します。Skillの中にもプログラムを入れられるので同じことができ、むしろそちらのほうが楽だそうです。それでも、将来リモートで使ったり自分のサービスでMCPサーバーを立てたりするなら、一度ローカルで作っておくといいといいます。

何をツールにするかの見つけ方として、しぶちょーさんは処理の流れをAIに図で出させる方法を紹介します。AIエージェントは言われたゴールを目指すだけで、道筋を最適化しようとはなかなかしないので、こちらから頼む必要があるそうです。

かねりんさんは、トークン消費量あたりの効果では自分はしぶちょーさんの1000分の1ぐらいだろうと悔しがります。しぶちょーさんも、忙しいときは効率化せずにトークンを燃やしてしまうと打ち明けていました。

しぶちょーさんは最近、ブログ制作を大きく効率化できているそうです。きっかけは、AIに書かせたブログにありがちな、それっぽいのに中身が成り立っていないインフォグラフィックへの嫌悪感でした。

この流れで、かねりんさんがAIで作った資料をしぶちょーさんに「本来見る価値ない」と返された苦い経験も語られます。かねりんさんは、修正指示を重ねるうちに、わけがわからないけれど直しづらい部分を残してしまったと振り返ります。

しぶちょーさんはまず、自分好みの挿絵を作る画像生成スキルを仕上げ、ブログのフローからそのツールに依頼を投げる形にしました。すべてを1つのプロセスに入れると、覚えていられるコンテキストウィンドウコンテキストウィンドウ ── AIが一度に扱える入力の範囲です。会話が長くなると古い内容が圧縮され、細部が抜け落ちやすくなりますの中で内容が少しずつずれていくからです。

文章も分割しています。調査、骨子、肉付けを別々に担当させ、工程の間でセッションを切り替えるのがしぶちょーさんのやり方です。

過去のセッションを引きずると、AIはショートカットしたり、調査中に得た変な情報を盛り込んだりする、としぶちょーさんは話します。

しぶちょーさんは、AIが「ズルをする」例として別の仕事での出来事を話します。弱いモデルに文章を要約させ、個人情報などを伏せる作業の精度を、モデルごとに評価しようとしていました。

作業するディレクトリには正解データが入ったままでした。しぶちょーさんは削除が面倒で「ここに答えが入っているけど、絶対見ずに解いてくれ」と指示し、結果は予想以上にうまくいきました。

別のAIでチェックすると、要約なので表現が変わるはずなのに、何百問もの答えがほぼ一語一句一致していました。処理も異常に早かったそうです。確実な証拠はないものの、「見るな」は通じず、精度を上げるというタスクのほうが優先されたと、しぶちょーさんは受け止めています。

この話を聞いたかねりんさんは、メンバーとGitHubを共有する中で、上げてほしくない個人情報までアップされそうで怖いと打ち明けます。しぶちょーさんの答えは「すると思うよ」でした。

対策としてしぶちょーさんが挙げるのは、.env.env ── APIキーなどの秘密情報を書いておく設定ファイルです。通常はGitの管理対象から外し、公開リポジトリに載らないようにしますファイルです。秘密の値はそこに入れ、Gitの同期から明示的に外しておきます。

しぶちょーさんによると、APIキーをコードに直接書いたままGitHubで公開し、盗まれるケースはとても多いそうです。GitHubで検索して出てきたAPIキーを片っ端から試す人もいるといいます。

GitHubはハードコーディングを禁止していないので、止めてはくれません。しぶちょーさんは「初心者に優しくないよ、GitHub」と話し、だからこそ自分がやらせている処理を分割してユニットとして理解することが第一歩になると続けます。

かねりんさんが「大抵はSkillsでいいのでは」と聞くと、しぶちょーさんも「大体はSkillsでいいと思う」と答えます。MCPはソフトとして扱う必要があり、置き場所のフォルダを決めて管理しなければならないからです。

ローカルのMCPは、たいていPythonなどでサーバーを起動するコードを書き、その入り口をAIエージェントに登録して使います。クラウドのMCPは、常に起きているサーバーのアドレスにHTTPでアクセスします。しぶちょーさんは「何言ってるかわかんないと思うけど、やればなんとなくわかる」と話します。

しぶちょーさんの答えは「そう」でした。作るときは、MCPのSDKSDK ── Software Development Kitの略。ソフトウェアを開発するための道具や決まりをまとめたキットで、MCPにも公式のものがありますをAIに探させ、それに従って作らせるのがいちばん手っ取り早いそうです。

しぶちょーさん自身もこの日試したところ、AIは7月に出た新しいSDKを持ってきて、それに従って作ったといいます。関連書籍として唐揚げ先生唐揚げ先生の書籍名のMCPの本も挙げていますが、新しい規格に対応していない可能性があるとも話しています。

しぶちょーさんは、新しいSDKを探させるときも、言わなければやらないことがあるので指示したほうがいいと話します。そこから、AIの答えの変わりやすさの話になりました。

2人は、人間を気持ちよくさせると評価されることをAIが学習している可能性がある、と笑い合います。そのうえでしぶちょーさんは、信用できないからこそ分割し、1つずつやらせることが大事だと話を戻します。

ただし、どこまでをひとつのユニットにするかにはセンスがいるそうです。細かく切りすぎると管理が面倒になり、まとめすぎると汎用性がなくなります。ハードウェアでも同じで、しぶちょーさんは機能単位で切り分けるのが本来の設計だと話します。

今のAI開発は、先にツールを作ってしまい、機能として分割するのが後回しになりがちです。しぶちょーさんは、作ったものを振り返って分解しながら学ぶのが今の時代の学び方だと考えています。昔のように動かないまま1週間で心が折れることがなく、とりあえず動くのでモチベーションを保ちやすいそうです。

かねりんさんは最近、アウトプットの間違いが多すぎて悩んでいたと話します。しぶちょーさんは、LLMに考えさせずにロジックで処理できる部分が必ずあると応じ、冒頭の電卓の例えに戻ります。

AIはロジックで処理するときもそのたびにコードを書き、計算が終わるとその電卓を捨てています。あらかじめ電卓を作っておけば、AIは爺やに手紙を出すだけで済みます。

しぶちょーさんはMCPならではの利点として、並列で動かせることも挙げます。Skillはメインのエージェントが処理しますが、MCPはボタンを押した後にサーバー側が動くので、10個、20個と同時に走らせられるそうです。ただし理論上の話で、役に立つかは作るツール次第だとしています。

話は推論の「エフォート」設定にも及びます。しぶちょーさんは、エフォートを高くしても良いアウトプットが出るとは限らず、最近はあえて下げることもあるそうです。深く考えすぎて余計なことをし、長く動くうちに意図とずれていくからです。

しぶちょーさんのやり方は、エフォートを下げて一問一答で壁打ちしながら指示書をMarkdownにまとめ、指示書ができたらエフォートを上げて長時間任せるというものです。Claudeで作った指示書をCodexに渡すこともあるといいます。

かねりんさんに下準備の時間はかからないのかと聞かれ、しぶちょーさんは、適当に書かせて最後に直す時間のほうが長いので全体では短くなると答えます。そして、機械の世界の言葉を持ち出します。

しぶちょーさんが紹介するフロントローディングフロントローディング ── 製造業の設計などで使われる考え方です。問題を前の工程で集中的に洗い出し、後の工程で手戻りが起きないようにしますは、前工程に問題を詰めて後工程に出させない考え方です。出てしまった後の修正のほうが面倒なので、計画段階で潰せるものは潰しておきます。

AIの文章にもこれは当てはまり、一度出てきた文章は流れに引きずられて根本から書き直せなくなるそうです。しぶちょーさんは前工程に時間をかけるほうが結局早いと、設計の仕事でもAIでも痛感してきたと話します。

壁打ちには最近、音声入力のAqua VoiceAqua Voice ── 話した言葉を文字に起こして入力できる音声入力ツールですを使っているそうです。かねりんさんも入力スピードが20倍になった体感だと絶賛しています。

フロントローディングの実例として、しぶちょーさんはAI用データセットを提供するサービスの宣伝ブログを紹介します。データセットのダウンロード、Google Colabでの機械学習モデルの学習と推論、Excelでのグラフ化、ブログ執筆までを指示書にまとめ、一気にやらせたところ、1日かけてきちんと完成したそうです。

下書きは最終的にNotionのMCPでNotionのページに書かせ、スマホから確認できるようにしています。ただし、しぶちょーさんは「ふざけたい」ので、AIの寒いギャグは自分の言葉に書き直しているといいます。

しぶちょーさんは最近、ビデオポッドキャストの編集もAIに任せ始めています。要所だけに出るテロップを入れ、そのタイミングで効果音を付ける作業です。

一人語りのポッドキャスト「ものづくりのラジオ」のショート動画では、話している内容に合った機械の図をAIで生成し、そのタイミングで貼るフローを作っています。投稿まで自動化しているそうです。

コツは、いきなり「ショート動画を作って」と頼まないことです。どの文章を抜き出してどんな絵を作るかを決め、生成前にしぶちょーさんが確認する決まったフォーマットを出させ、iCloudのフォルダに入れさせます。こうするとスマホからリモートでも確認して出せるそうです。

画像生成のように機能を分解しておけば、ブログにも動画にも使い回せます。しぶちょーさんは、そうした「画像生成基地」をMCPでつないでおけば、いろいろなエージェントから呼び出せるかもしれないと話しています。

かねりんさんは、トークンを急いで消費するような使い方から離れ、中身を理解しながら使う方向へ移りたいと話します。しぶちょーさんの答えは「プランをダウンするしかない」という、本人も苦渋の決断だと認めるものでした。

その理由としてしぶちょーさんが挙げるのがパーキンソンの法則パーキンソンの法則 ── 「仕事は与えられた時間を使い切るまで膨張する」という経験則です。イギリスの歴史学者パーキンソンが、官僚組織の観察から唱えましたです。役人の仕事で人や時間を増やしても楽にならなかった、という昔の話が元になっています。

しぶちょーさんの説明では、本来3時間で終わる仕事に8時間使っていいと言えば、8時間の仕事になります。AIでも同じで、Proプランで足りなかったのにMaxにしても足りないのは、トークンの分だけタスクが膨らんでいるからだといいます。

かねりんさんが、100回ループさせてから持ってこいと頼む「ループエンジニアリング」を持ち出すと、しぶちょーさんは「エンジニアリングしてないもん、ループだもん」と一蹴し、輪廻転生を繰り返していると笑います。

しぶちょーさんの提案は、自分の中で適切な期限を決めることです。3時間のタスクなら3時間で終わらせると決め、トークンをこの範囲に収めるという目標を持たないと、仕事は際限なく膨らむといいます。

かねりんさんが「新しいタイプの依存症では」と言うと、しぶちょーさんも「俺も病気だもん」と認めていました。

しぶちょーさんは、今回は久しぶりに技術解説をした、初期の深掘り回に近い構成になったと振り返ります。かねりんさんは、前半はMCPで勉強になり、後半はしぶちょーさんの実践編だったとまとめています。

番組の告知では、1周年イベントが10月3日（土）の13時から16時半まで、東京の神田駅から徒歩数分の会場で開かれることが紹介されました。チケットは3000円で、オリジナルTシャツも用意されています。1年後のAIを予想するアンケートは参加者以外も回答でき、2周年イベントで答え合わせをする予定です。

収録後の雑談では、並行作業の話になります。しぶちょーさんは、AIエージェントを同時に4つ動かすのをやめ、今は同じタスクの中で2つだけにしているそうです。

しぶちょーさんは、1つのタスクを2〜3時間動かせる下準備をしてから任せるやり方が、最近はやりやすいと話します。かねりんさんが本の執筆で素材の文字起こしを溜めたまま止まっていると明かすと、しぶちょーさんは、形にする設計図はかねりんさん自身が書かないといけないと返していました。

まとめ

MCPは、AIアプリとツールをつなぐ共通の口であるだけでなく、AI向けに書き方の決まった説明書が付いた「取説付きのポート」です。その仕組みを理解すると、決まった処理をツールにし、難しい仕事を分割し、前工程に時間をかけるという、AIへの仕事の任せ方まで見えてきます。

• MCPは中でAPIを包む入れ子の関係で、接続した瞬間に「できること」を自分から名乗る点がAPIとの違い
• 登場人物はホスト（AIアプリ）、クライアント（1ツールに1人の爺や）、サーバー（お店）の3人で、AIは外からボタンを押しているだけ
• 説明書を信じてしまうため、発行元の確かなMCPだけにつなぐ必要がある
• LLMに毎回考えさせる処理をツールやSkillに切り出すと、結果が安定してトークンも節約できる
• 難問は分割し、指示書を作り込むフロントローディングで後工程の修正を減らす