AIスキルのブラックボックス化｜7項目分解と業務の棚卸しで見える仕事に戻す

家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくんです。

自分がAIに任せた仕事、いま頭の中で数えてみてください。中身を1分で説明できるものと、「なんかいい感じにやってくれてる」としか言えないもの——正直、私自身、後者のほうが多いなと気づいて、背筋が冷えたんですよね。これ、また抱え込みOSが戻ってきてる合図だから。 説明できないスキルが増えると、結局「念のため全部チェック」に戻る。任せてるつもりで、任せてません。

実際、ブログ記事づくりを任せてるスキルが「いい感じ」の下書きを返してくる度に、同じことが起きます。なぜこの引用を選んだのか、なぜこの語尾なのか——聞かれたら、私はAIに聞き返すしかない。委ねる練習をしてるつもりで、中身を説明できないまま受け取ってるだけの日が、正直まだあるんですよね。

そんな時に読んだのが、Jinba（@jinbaflow_JP）が8月18日に出したX Article「ブラックボックス化したSkillsを、Jinba Flowで可視化してCodexへつなぐ方法」でした。中身はJinba Flowという新しいツールの紹介記事。でも私が食いついたのは、そのツールの機能じゃありません。SKILL.mdを7項目——発火条件、入力、固定処理、AI判断、外部連携、人間承認、出力と完了条件——へ分解するという、その「分解の型」。この型が、さっきの背筋の冷えに、そのまま答えをくれたんです。

Claude CodeのCLIから実行すると、公開直前のhuman_approval（WAIT_FOR_APPROVAL）で必ず止まり、承認を送るまで先へ進みませんでした。画面には「AI採点: 93点 / 100点・文字数1380・下書き保存済み（Post ID: MOCK-DRAFT-0001）・承認すると公開されます」の表示。こっちが「approve」を送って、はじめて最後まで走った。勝手に公開しない、必ず人間の一言を待つ。この挙動こそ、今日の本題なんですよね。

安全のために、下書き保存はMOCK-DRAFT-0001、公開処理はMOCK-PUBLISHED-0001というダミーに差し替えてあり、実際のWordPressには一度も接続していません。つまり、外に出たものはゼロ。それでも「下書き保存 → 停止 → 承認 → 公開処理」の流れは、モックのまま最後まで通りました。

できあがったフローは、そのままAIエージェント用の道具（MCPツール）としても登録できた。下がその画面。tools/listにちゃんと1件出て、Claude CodeみたいなAIから「このフローを呼んで」が効く状態。ちなみに接続に使う鍵は、個人用のAPIキーじゃ弾かれて、ワークスペース専用のトークンが要りました。ここは公式ドキュメントにも書いてなくて、触ってみて初めて分かったところ。

気になるコストも見ておきました。このCLI1回の実行で減ったのはCopilot Requestsの3回（100→97）だけで、Jinba Creditsは1000のまま変わりませんでした。無料プランのまま、ここまで試せる。地味にありがたい話なんだよね。

スキルを作った瞬間は「これで任せられる」って思うんだけど、3ヶ月経つと自分でも「あれ、これ何してたっけ……」ってなる。地味に、何度も繰り返してます。Claude CodeやCodexで動くSkillは、SKILL.mdを開けば誰でも読める。でも実行される場所は、スクリプトだったり、MCPだったり、AIとの会話の中だったりへ、勝手に散らばっていく。読める。でも、見えていない。

Jinba公式も、同じ場所を見てました。

「Skillの中身は、Markdownを開けば読めます。しかし実際の処理は、Skillの指示、スクリプト、MCP、ローカルファイル、AIとの会話へ分散しやすい。」

【公式】Jinba | AIエージェント開発（@jinbaflow_JP）

これ、AIスキルのブラックボックス化の典型パターン。説明できないスキルが増えると、結局「念のため全部チェック」に戻ります。冒頭で書いた、あの強迫観念そのもの。AIを入れても、形を変えて戻ってきます。皮肉なんだけど。

正直、私もClaude Codeのチームで委ねるOSを実践できつつあるって感覚を持てたのは、最近です。 未完成でも出す。作業を委任する。その第一歩を、恐る恐る踏み出してる最中。7項目分解みたいな「見える化の型」がないと、委ねる練習すらできません。見えないものは、怖くて手放せません。

今日、自分がAIに任せた仕事を3つ書き出してみて。その中で「1分で説明できる」のは、何個ある？

試しに、いま私がこの記事を1本書いてる作業そのものに、7項目を当てはめてみます。発火条件は、ブックマークの中から「これは書きたい」と思う記事が見つかった瞬間。入力は、元記事と過去の合格記事。固定処理は、文字数を数えたり、リンクカードの形式を整えたりする部分。AI判断は、どの章にどの話を置くか、語尾をどう崩すか。外部連携は、公開先のブログ。人間承認は——ここだけは、私がAIに渡しません。最後の味見だけは、卒業しないと決めてるので。出力と完了条件は、採点AIが90点未満ならやり直しになる、あの門番を通ること。1個1個手でこねてスキル化する、講座で語ったあの話そのもの。

元記事も、同じ発想でこう言ってます。

この分解ができると、長いSkillも「工程の集まり」として見えるようになります。

【公式】Jinba | AIエージェント開発（@jinbaflow_JP）

長いSKILL.mdを7項目へ分解すると、どこがAIで、どこが固定処理で、どこが人の承認かがバラバラに見えてくる。何が作られどの状態なら成功なのか、ファイルや通知やログの形で最後まで明確になる。これ、AIの機能紹介として読むと「便利なツールだな」で終わるんだけど、経営者として読むと全然違う顔になります。

私はこれ、業務の棚卸しシートだと思って読んだ。AIツールの話じゃないんです。自社の仕事を7項目に分けて紙に書き出す作業そのものが、経営の言語化になる。書き出す過程で「あれ、この判断だけはAIに渡せない」って部分が浮かび上がってくる。それが、あなたの会社のUSPの肝。

実はこの入口、私はもう半年、AIハーネス入門シリーズ全6回でずっと書いてきました。あのシリーズは「AIに何をどこまで任せるか」の入門編で、今回のJinba Flow記事は、その続編。7項目分解は、ハーネス設計の第一歩そのもの。派手な新技術に見えて、中身は「自分の仕事を、自分の言葉で説明できるようにする」という、地味で地道な作業。でも——この地道さこそが、AIに安心して仕事を渡せるかどうかの分かれ目です。

一番よく繰り返す業務、あなたなら何を選びますか。まず紙に、7項目の見出しだけ。

実家の惣菜屋で育った私にとって、味見は最終チェックであって、卒業するものじゃない。 ただし味見の粒度は固定しない。個々の成果物はAIが判断・実行・修正まで完走して、人間は一段上から、AIの判断軸そのものを味見する。 私はこの「最後に座る椅子」を、味見の椅子って呼んでます。7項目のうち、経営者が一番先に決めるべきなのが「人間承認」だと思うのは、この椅子があるから。

元記事も、同じ場所を指してました。

「公開、送信、削除、決済、権限変更など、人間が最終判断すべき工程です。自動化するのではなく、必ず止まる位置を決めます。」

【公式】Jinba | AIエージェント開発（@jinbaflow_JP）

全部自動化するんじゃなくて、必ず止まる位置を先に決めます。自動化してから止める場所を探すんじゃなくて、止まる場所を先に決めて、その手前を全部委ねる。だから安心して任せられます。

いやー、正直、最初は「全部自分でチェックしないと」ってなりがちなんですけど、公開・送信・削除・決済・権限変更、この5つだけ人間承認に固定すれば、それ以外は思い切って委ねていい。私も分身AIに仕事を委ねてみて、1歳と3歳の横にいられる時間が増えました。止まる位置を決めるのは、自由を増やす作業。

自分の業務で「ここだけは自分が最終判断する」を1つ決めて、7項目シートの人間承認欄に先に書いておくといいかもしれない。

この記事のもう一つの核心が、役割の分け方です。

元記事はこう整理してる。

Skill
＝いつ使うかを判断し、必要な入力と安全条件を確認する受付
Jinba Flow
＝決められた工程を、再現可能な形で実行する業務本体
MCP
＝Flowを複数のAIから呼び出すための共通接続口

【公式】Jinba | AIエージェント開発（@jinbaflow_JP）

Skillは受付、Flowは業務本体、MCPは共通の接続口。この3つに役割を分けるだけで、同じ処理をAIごとに作り直す必要がなくなります。私はこれを読んで、7項目のうちの「固定処理」と「AI判断」を分ける作業と同じ話だなと思いました。

人間は縦に掘る。AIは横に広げる。 これ、私が何度も言ってる役割分担の話です。固定処理——毎回同じルールで動く部分——はAIに横へ広げてもらう。判断が要る部分、特に「その人にしか分からない例外」は、人間が縦に掘る。この線引きさえできれば、怖さの正体は消えます。

たとえば、いまこの記事を書いている作業でも同じです。文字数を数える、リンクカードの体裁を整える、引用元のリンクを確認する——これは固定処理。AIに渡して大丈夫。どの原液をどの章に置くか、語尾をどう崩すか——これはAI判断。私がやり方だけ決めて、あとはAIに預けてます。人間承認だけは別枠。原稿を最後に読んで「これでいく」と決めるのは、いまも私です。この線引きがあるから、Claude Codeのチームに安心して仕事を預けられる。

同じ線引きは、メルマガを1通配信する業務にもそのまま使えます。宛先リストを整える、配信予約を入れる——これは固定処理。件名や本文の言い回しを考えるのは、AI判断。でも「送信」ボタンを押す最後の一手だけは、人間承認のまま動かしません。ここを自動化すると、取り返しのつかない事故になるので。

正直、これがちゃんと分かってなかった頃の私は、AIに任せていいものと自分で判断すべきものが、頭の中でぐちゃぐちゃに混ざってました。だから毎回、全工程を自分でやり直す羽目になる。7項目シートの「固定処理」と「AI判断」の欄を分けて書くだけで、この混線がほどけるんだよね。毎回同じ処理と、毎回違う判断。この2つを混ぜたまま渡すから、AIも人間も疲れる。分けて渡すと、両方が楽になる。

7項目シートの固定処理とAI判断の欄へ、実業務の作業名を1つずつ入れてみて。

ここは、他の章と少し書き方を変えます。時系列で、そのまま話します。

2026年7月17日。分身AI講座のグルコン第1回。受講生から「AIをどう仕事に取り入れたらいいですか」と聞かれて、私はこう答えました。いきなり自動化はできない。まず自分の言語化から。1個1個、チャットでやり取りしながら手でこねてスキルにする。できたスキルを組み合わせてワークフローにする。採点AIを門番として置いて、90点未満ならやり直させる。AIはサボるし嘘もつく。だから門番と検証を仕組みに組み込む——これがハーネスエンジニアリング、ループエンジニアリングです。あの場では、そう答えるのが精一杯だった。

それから1ヶ月。8月18日、Jinba（@jinbaflow_JP）のX Articleを読んで、手が止まった瞬間がありました。元記事はこう締めくくっていました。「組織の業務能力として再利用するSkillsを作って終わりにしない。見える、直せる、つなげられる状態へ進める。これが、次のSkills運用です。」

作って終わりにしない。見える、直せる、つなげられる——あの日グルコンで答えた順番と、骨組みがそっくり同じだったんです。正直、あの時は自分の経験則を話しただけでした。でも1ヶ月後、Jinba Flowという他社のツールが、ほぼ同じ骨組みを実装して記事にしてる。これ、流行りのツールの話じゃなくて、AI業務運用の型が、他社の実装によって物証になったってことなんだよね。自説が裏付けられた瞬間って、なかなか無いです。

最近「うまくできたAIとのやり取り」、1つありますか。あるなら、メモに残しておいて。次のスキル化の種です。

全部のSkillsを一気にFlow化する必要はない、と元記事は釘を刺してます。

「Skills群を一気にすべて移す必要はありません。まず、次の条件を満たす一つを選びます。」

【公式】Jinba | AIエージェント開発（@jinbaflow_JP）

条件は、利用頻度の高さ・入出力の分かりやすさ・成功失敗を判定できるか・危険な操作の少なさ・複数人での再利用可否、の5つ。満たす一つを選んで、最後まで動かしてから型を広げます。地味だけど、正しい順番。ちなみにMCPは、この記事のあと工程——完成したFlowを複数のAIから呼べるようにする接続口の話——として1割くらい触れられてます。正直な評価を言うと、MCPの価値は「同じFlowを、CodexからもClaude Codeからも同じ入口で呼べる」の一点に尽きると私は見てる。推測ですが、7項目分解をやらずにMCPだけ整えても、呼び出す中身が空っぽのままです。技術の主役はそこじゃない。

でね。私が繰り返し言ってる「1本完璧に作って仕組み化で質高く量産できる」って、これとまったく同じ話です。 最初の1本で残すのは表面の文体じゃなくて、なぜその判断をしたのかという判断軸です。ここが雑だと、量産した瞬間に全部薄まる。

いきなり自動化はガチャです。言語化→最適化→最大化→自動化、この順番を飛ばすと、AIが出す結果もあなたの業務理解も、再現性のないおままごとになる。1本入魂→スキル化→量産→磨き→全員進化、この流れを、 今回はJinba Flowという道具の上でやるか、紙とペンでやるかの違いでしかない。道具はどっちでもいい。順番を守れるかどうかが、経営者としての勝負どころなんだよね。

7項目シートを書いたその業務、「利用頻度が高い・入出力が明確・成功失敗を判定できる」の3つ、満たしてますか？

最後に、この記事のいちばん大事な一文を持ってきます。

元記事はこう締めくくってる。

Jinba Flowへ移すことで、Skillsは「個人のAI環境に置かれた手順書」から、「組織で再利用できる業務能力」へ変わります。

【公式】Jinba | AIエージェント開発（@jinbaflow_JP）

個人のAI環境に置かれた手順書から、組織で再利用できる業務能力へ変わります。ここ、Jinba Flowという道具の話として読むと薄いんだけど、経営の話として読むと重いんですよね。

ここから先は、実演ガイドです。今すぐ紙とペンを用意して、一緒にやってみてください。

Step1、一番よく繰り返す業務を1つ選ぶ。
Step2、7項目の見出しを紙に書く。発火条件・入力・固定処理・AI判断・外部連携・人間承認・出力と完了条件。
Step3、埋められる欄から埋める。空欄があっても、そこで止まらない。
Step4、人間承認の欄に、あなたが最後に判断する一言を書く。

正直、道具を導入する前にやることがある。書けなかった欄こそ宝です。そこがあなたにしか説明できない暗黙知——つまりUSPの正体。終了条件を決めてないと、成果物が出てこないという話を以前書いたけど、7項目シートの「出力と完了条件」欄も同じです。何が完成なのかを先に決めてないと、AIに投げても中途半端で終わります。

所要時間、15分から30分。紙とペンだけ。

冒頭で「説明できない」と気づいたあの仕事、あのままにはしません。今夜、7項目のシートに書き出します。埋まらない欄が出たら、それがきっと、私のUSPの肝。全部チェックに戻る癖が、これで出なくなるとは言い切れない。でも、次に戻ってきた時、どこで気づけばいいかは、もう分かりました。

この記事は、AIハーネス入門シリーズ全6回の続編として書きました。7項目分解は入口。1本入魂→スキル化→量産→磨き→全員進化——この流れの最初の1本を、いまこの記事を書く業務で埋めてます。人間承認の欄に書くのは、たった一言。「最後の味見」。ここだけは、AIに渡しません。それ以外は、もう渡してる。次にあなたが7項目へ分解するのは、どの業務ですか。祖父の鶏チャーシューを味見してた小さな私も、たぶん同じことをしてたんだと思います。