Jinba MCPをJinba公式が解説
Claude Code・CodexのSkillsを中身ごと渡さず届ける方法

家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくん（@passion_tanaka）です。今回は【公式】Jinba｜AIエージェント開発さんの「Skillsを配りたい。でも、中身は見せたくない。Jinba MCPという共有方法」という記事を解説するね。

【公式】Jinba｜AIエージェント開発（@jinbaflow_JP・Skill共有の悩み）

便利なSkillを他の人にも使ってほしい。でも、`SKILL.md`やプロンプト、処理ロジックまでは見せたくない。

Claude CodeやCodexでSkillsを作り込むほど、この悩みにぶつかります。地味に厄介です。

「どの情報を先に調べるか」「どの条件で分岐するか」「どこで人間の確認を挟むか」。Skillにはそういう判断基準が積み上がっています。だからファイルで配ると、便利さと一緒にノウハウまで渡ってしまうんです。

これは、ひろくんが「型は磨いて残す。実行のボールは委ねる」と言い続けていることと同じ構造なんです！

本人にしかできない最後の一手は、できあがった型の温度を身体で確かめること。出す・止める・任せるの境界を決めることです。判断軸を磨くところは自分に残し、実行のボールだけを一人へ委ねます。

Jinbaが言う「配布物として渡すか、サービスとして提供するか」の分かれ目も、まさにこの境界線の話です。ファイルごと渡すのは、境界を引かずに全部渡してしまってる状態に近いということですね。

記事にはこう書かれていました。「Skillの価値が、プロンプトや分岐、調査順、評価基準にある場合、ファイル配布はソースコードの受け渡しに近くなります」。的確な指摘です。ここに気づけるかどうかで、Skillを配って終わりにするか、事業として育てるかが分かれます！

納得の指摘です。実は、これはコンサルの現場でもよく見る話です。ノウハウを資料1枚に固めて渡した瞬間、相手はもう自分のところに相談しなくなります。渡し方ひとつで、その後の関係まで変わってしまうんですよね。

大事な一手間です。だからこそ、配る前に立ち止まって考える価値があります。このSkillは何を渡せば十分で、何を渡すと相談される理由まで消えてしまうのか。そこを言語化しておくだけで、後から後悔せずに済みます。少しの手間で、後の関係の質がまるごと変わってきます。

【公式】Jinba｜AIエージェント開発（@jinbaflow_JP・MCP型への転換）

そこで考えたいのが、Skillそのものを配るのではなく、Skillが実行する能力だけをMCPツールとして提供する方法です。

通常のSkill共有は、ファイル一式を相手の環境へコピーします。シンプルですよね。手軽です。

でも相手はSkillの中身をそのまま読めてしまいます。しかも元データを更新しても、相手には反映されません。

Jinba Flow×MCPで組み替えると、業務ロジックはFlow側に残ります。Codexからでも、Claude Codeからでも、MCPツールを呼び出して実行結果だけを受け取る構成になるわけです。

この「渡すものを絞る」考え方は、ひろくんの委ね方の原則とも重なります。構造が同じです。

委ねる時は、一つのボールを人・AI・システムの誰か一人が全管轄してやり切ります。所有者は一人。採否・次工程・期限管理は、その所有者が持ち続けます。

Jinba Flow側にロジックを一本化して、利用者にはツール名・入力・結果だけを渡す構成。これは「所有者を一人に決めて渡すものを絞る」考え方を、そのままエンジニアリングにした形に見えます。

大事な注意点です。記事にもある通り、これはSKILL.mdをボタン一つでMCPへ変換する話ではありません。業務ロジックをJinba Flow上へ実装し直し、外部へ見せるツール名・入力・出力を設計し直す必要があります。手間はかかります。でもその手間の分だけ、渡すものと残すものの境界がはっきりするんです！

Claude Codeを日常的に使ってる方なら、この「呼び出す側は結果だけ受け取る」という感覚、意外としっくりくるはずです。普段からツール呼び出しの結果だけを見て、中身のAPI実装までは意識しませんよね。それと同じ距離感がMCPにもあるということです。

避けて通れません。逆に言えば、渡す側は「呼び出す側が何を知っていれば十分か」を先に決める作業から逃げられません。ここを曖昧にしたまま公開すると、後からツールの説明文だけを継ぎ足すことになり、かえって内部事情が漏れやすくなります。

【公式】Jinba｜AIエージェント開発（@jinbaflow_JP・公開範囲の設計）

つまり、隠せるのは「何ができるか」ではなく、主にどう実現しているかです。

MCP化しても、存在そのものは隠せません。ここは誤解しやすい点です。

利用者側のAIはツール名・説明・入力項目と型を見ます。実行時に渡したデータや結果、エラー情報も見えます。逆にFlow側へ残せるのは、SKILL.mdの中身、分岐条件、評価ロジック、認証情報、改善履歴です。「何ができるか」は見せて、「どう実現しているか」だけを残す線引きなんです。

この感覚、小学生の頃にドミノやピタゴラスイッチにハマってた原体験ともつながる話だと思います。

階段のような段差へドミノを置いて連鎖させる。木製パチンコを作る。惹かれた核心は、自分が仕掛けた一つの動きが次々と別の動きを生み、全体が自走する生命のような連鎖でした。

見てる人には「玉が転がって次々に動く」という結果だけが見えます。裏の配線や仕掛けの作り方は見えません。あの面白さと、Jinbaが言う「隠せるのは実現方法」という話は、実はかなり近いところにあるんですよね。

見落としがちです。ただし記事も明言しています。Flowの共有リンクや公開テンプレートまで有効にすると、MCPとは別の経路で閲覧範囲が広がる可能性があるって。MCP提供とFlow共有は、設計上ちゃんと分けて考える必要があるんです。

これ、意外と見落としがちなポイントです。「MCPで公開したから安全」と思い込んで、裏のFlow自体を誰でも見られる設定のまま放置してしまうケースは十分あり得ます。公開範囲は、経路ごとに個別に確認する必要があるということですね。

継続的な見直しが必要です。公開設定は一度決めたら終わりではありません。チームのメンバーが増えたり、外部と連携するタイミングで、共有範囲を見直す機会をあらかじめ決めておくと安心です。

【公式】Jinba｜AIエージェント開発（@jinbaflow_JP・秘匿の限界）

MCP化は、DRMでも魔法のブラックボックスでもありません。

正直に限界を書いてる。ここがこの記事の信頼できるところです！好感が持てます。

利用者は入力と出力を何度も試すことで、処理の一部を推測できる場合があります。ツール説明に内部事情を書きすぎると設計思想が見えてしまいます。エラーにプロンプトや内部スタックを含めると、意図せず情報を返してしまいます。

確認すべきは5点です。①ツール説明が内部ロジックを書きすぎていないか②入力項目から秘密の判断基準が推測されないか③出力やエラーに内部URLが混ざらないか④OAuthの許可範囲が広すぎないか⑤ログの閲覧者が限定されているか。

「作った本人が、自分で限界を明記する」姿勢は、ひろくんが実践で大事にしていることとも重なります。

合格の印は、事実であるだけでなく感覚が今にフィットして「自分っぽい」こと。量産工程の最後に本人の身体ゲートを残します。「これは自分が語って違和感がないか」と問い直すんです。

完全に自動化したつもりでも、最後にもう一度人間が確認するゲートを残す。Jinbaが確認すべき5点を具体的に挙げているのは、まさにこの「最後のゲートを消さない」姿勢そのものなんですよね。

ちなみにこの5点、Skillだけでなく普段の業務マニュアルにもそのまま応用できます。マニュアルの説明文が詳しすぎて、逆に社外秘の判断基準まで書いてしまっている、というのはよくある話ですから。

【公式】Jinba｜AIエージェント開発（@jinbaflow_JP・導入の一歩目）

いきなり複雑なSkill全体を移す必要はありません。

最初の移行対象に向いてるのは、この5条件を満たす1つです。数を絞るのが大事です。

入力と出力を短く定義できる。成功と失敗を判定できる。実行結果に顧客情報を含まない。危険な外部操作が少ない。複数人が繰り返し使う。記事では「競合記事を整理するSkill」「文章を指定形式へ変換するSkill」が例に挙がっていました。

逆に、ローカルファイルを大量に読み、毎回まったく違う対話に深く依存するSkillは向かないと、はっきり書かれています。

「1本を完璧に仕上げてから仕組み化する」という順番は、ひろくんの制作の型そのものなんです！

1本完璧に作って、仕組み化で質高く量産します。最初の1本で残すのは表面の文体ではありません。なぜ？とその判断軸、価値観、紐づく体験ストーリーです。

いきなり全部のSkillをMCP化しようとせず、条件に合う1本を選んで丁寧に移行する。そこで「見えてよいものだけが見えるか」を確かめてから広げる。Jinbaが勧めてる進め方も、この順番と同じ形をしてるんですね。

確認は接続前、ツール一覧、実行、ログ、接続解除後の5段階です。移行してから気づくのではなく、設計段階でこの5段階を先に決めておくのがポイントですよ。

地味に効きます。Codexでコードを書いてる方なら、テストを書く順番に近い感覚かもしれません。全部を一気にカバーしようとせず、一番リスクの低いところから小さく検証していく。あの進め方と同じなんですよね。

【公式】Jinba｜AIエージェント開発（@jinbaflow_JP・更新の一元化）

業務本体をFlowへ置き、各AI側のSkillは「いつ呼ぶか」「呼ぶ前に何を確認するか」という部分だけを担当させる構成です。

ファイル配布だと、利用者ごとに古いバージョンのSkillが残りやすいです。よくある事故です。誰かが更新しても、コピーを持ってる相手には反映されません。

MCP型なら、Flow側に処理を集約しています。改善を一箇所へ反映するだけで済みます。Codex専用、Claude Code専用として同じ処理を別々に持つ必要もなくなるんです！

一つのFlowを更新すれば、同じMCPへ接続してる複数のAIが、次の実行から同じ改善を利用できます。Basic Memoryの使い方の回で扱った「Cursor・Claude Code・Codexで記憶を共有する」話と、狙いは近いですね。

この「1箇所を磨けば繋がってる全部に反映される」設計は、規模は違いますが凛ちゃん（AI秘書）の仕組みとも同じ形をしています。

新体験・学びを投げる。凛ちゃん（AI秘書）が整理する。分身AIも共進化する。量産品の質が上がる。味見で新たな気づきがあり、ひろくんがさらに磨かれる。

中心の1つを磨けば、そこに繋がってる全部の出力が良くなります。ファイルをコピーして配る方式だと、この循環は起きません。中心を一箇所に保つ設計だからこそ、改善が全体に波及するんですよ。

実務的な利点です。利用停止や共有範囲の変更がしやすいのも実務上のメリットです。ファイルは一度配ると回収が難しいですが、MCP接続なら接続を止めるだけで済みますから！

応用範囲は広いです。この一元化の発想、チーム運用にもそのまま使えます。誰かが業務マニュアルを個人フォルダにコピーして使い続けている状態を、共通の窓口に一本化するだけで、更新漏れという事故そのものが起きなくなるんです。

窓口を一本化するのは、実は難しい判断ではありません。まず今使っている処理を1つ棚卸しし、それをFlow側へ移す。次に、呼び出す側のSkillからは呼び出し方だけを残して、細かいロジックを削る。この2ステップだけで、更新漏れのリスクはかなり減らせます。

Jinba MCPの話をひとことでまとめると、ファイルを配るから利用口を渡すへの転換です。見せるのはツール名・入力・出力・結果だけ。分岐条件や評価ロジック、認証情報はFlow側に残します。

シンプルな話です。この線引きさえ意識すれば、AIエージェント開発で積み上げたノウハウを、丸ごと渡さずに人へ届けられます。完全な秘匿はできないという正直な前提つきで読むと、実務にそのまま使える設計図になっていますね。まずは自分のSkillsの中から、入出力が明確な1つを選ぶところから始めてみてください！

今日から真似できる最初の一歩をもう一度まとめておきます。①配りたいSkillを1つ選ぶ②入力・出力・成否判定を1行ずつ書き出す③ツール説明文に内部ロジックの語が混ざっていないか読み返す④公開範囲を接続前・実行・接続解除後の3点で確認する。この4つだけで、今日から始められます。