Claude Code コーディネーターに任せても忙しいなら、終点を持つ人を決める

出典: いまにゅさんの Claude Code Projects 解説（いまにゅのAIプログラミング塾）

冒頭でJ君は、プロジェクトならずっと前からある、と返します。いまにゅさんは、事実そうだけれど、そのプロジェクトとは違う、と答えます。聞き役が指すのはチャット側、いまにゅさんが指すのは Claude Code の機能。これまで無かったんですね、と返る声に、答えは、そうよ、の一言です。

Cursor など他のコードエディターにはあった概念で、いまにゅさんも使っていたそうです。Claude Code では、ウェイトリストで待たれていた機能がデスクトップアプリに載りました。

冒頭の説明で、この機能は載ったばかりだと伝えられます。

いまにゅさん（動画の中で・2:57〜）

時代ならではようなスピードです。本当さっき搭載されたばっかです。

仕組みの説明は、人間と実行役の間に立つ1人から始まります。

いまにゅさん（動画の中で・3:27〜）

コーディネーターというあの僕とま、そのいわゆる仕事の実行役との間にコーディネーターと呼ばれるようなクロードが1人立ちますと。

画面では、報告はコーディネーターから受けます。リーダーと実行部隊のような形で、両者に別々のモデルを最初に設定する画面もあります。

いまにゅさん（動画の中で・3:42〜）

僕と会話しながら必要に応じていわゆるスレッドを立てるサブエージェントのようなものを立ち上げてポンポンポンポン実行を作ってくれる。

人間が話す相手は、窓口のコーディネーター1つです。実行は、立ち上がったスレッドが受け持つ。報告は、窓口に集まる。

説明の途中で、コーディネーターは司令塔と呼ばれます。

6月30日の朝LIVEで、私は記事づくりの流れを話しました。「記事を設定作るのはクロードにして、執筆するのは誰にしようかな」と続け、「役割分担を決めて」とも言いました。書き手を、自分の分身のAIにするか、全く別のAIを作るかも、選べる形で話しました。「具体的なペルソナ設定をして」、「この記事を誰が何をどのように書いていくのかというのを設定していく」と重ね、そうして作る記事は、人間の自分一人が考えて作るより、はるかに価値が高いものになる、と言いました。「ここはもうAIに委ねていく」とも話し、AIが作れないのは自分の原液の部分だとも続けました。

役割を先に分け、書き手は後で選ぶ。窓口と実行を分ける動画の形は、この順に近いと私は見ます。

窓口を任せたあとの忙しさは、速さより、終点まで引き受ける一人が誰かで決まる、と私は見ています。速さは、その次です。

何を同時に頼み、何を順に頼むかで、窓口への渡し方は変わります。その分け方は、同時に頼む仕事と順番を守る仕事の分け方に書きました。

私なら、窓口を1人に決め、一つのボールをその1人が全管轄し、やり切る形にします。複数人の共同責任にはしない。所有者は、一人にする。

プロジェクトを作る時に渡すのは、目標とコンテキストの2つです。中身しだいで、作業が動く場所まで変わります。例題は、図をひたすら作るプロジェクト。

講義資料・動画編集・LPの量産も、1つの括りとして作れます。続く説明では、目標を決め、完了したらアーカイブする流れで、期間が決まっている仕事に向き、半永久的に使ってもよいそうです。

いまにゅさん（動画の中で・6:03〜）

このコンテキストのところにはリポジトリーファイルフォルダーGoogleドライブを追加できます。

リポジトリは GitHub のフォルダで、フォルダとファイルは手元のPCの物です。クラウドで作業させられるのは、GitHub を紐づけた場合に限られます。

この回は、図解を作る時は図解のスキルを使うよう伝えてあります。ただ、そのスキルは手元のPCにあり、クラウド側には入っていませんでした。

いまにゅさん（動画の中で・11:15〜）

ローカルのファイルを紐付けてないからローカル上にあるつまり自分のPC上にあるスキルが多分読み込めない。

コンテキストの欄は、必要な物を選んで足す。同じスキルのファイルでも、手元のPCに置くか、GitHub につないだ所に置くかで、動く場所が変わります。

画面でスラッシュを開く。並ぶのは、初期のスキルだけだ。図解のスキルの名は、そこにない。

いまにゅさんは、手元にある図解のスキルをプロジェクトに上げれば、使える形になるかな、と試します。

途中から、アカウント全体で常時使うなら、Claude.ai の設定のスキルからアップロードするのが確実、という説明が入ります。実際に設定のスキルからアップロードし、使えるかどうかは、その場では一旦置いたままです。

後の画面で、いまにゅさんは、図解のスキルが使われていると確かめます。

どのスキルを使わせるかを書き、そのスキルを置く場所も合わせます。この両方がそろって、ようやく動く。

目標の欄に目的・ゴールだけを書かず、終点と、背景文脈と意図まで渡すと動く、と私は見ます。AIへ渡すのは、目的・ゴールだけでは足りません。

Claude Code コーディネーターの推論量を、なぜローにするのでしょうか。人間と直接話す窓口だからこそ、いちばん賢いモデルを置きたくなるのに、設定の初期値はローになっています。

設定の画面の説明では、設定にコーディネーターのモデルと推論量、スレッドのモデルとエフォートが並び、コーディネーターは初めからローです。

いまにゅさん（動画の中で・8:12〜）

コーディネーターってあくまでスレッドの管理と作成を行う仲介役なんだよな。めちゃくちゃ賢い設計を行うやつは別にスレッドに立てればいいじゃん。

続けて、コーディネーターが一番動き、スレッドも次々立つので、トークンの減りが速いと説明されます。Anthropic の話として、ローで十分とも伝えます。

いまにゅさん（動画の中で・23:43〜）

だからこそエフォートはさっき言ったようにコーディネーターはローで、え、スレッドはミディアムかハイにしてあげるってのが大事です。

窓口に求められるのは、深く考えることより、スレッドを立てて回し、報告を受ける動きです。考える深さは、スレッドの側に置く。

設計や実行をするスレッドは、エフォートを深めにします。複雑な仕事ほど上げる。窓口とは、逆の設定だ。窓口を軽く、実行を深くする組み合わせが、動画の設定の形です。

実演そのものは、初期設定のまま進みます。コーディネーターもスレッドも、同じです。同じ画面には、一時停止や再起動、アーカイブと削除の欄もあります。

この役には、オペレーターやオーケストレーター（指揮する人）の呼び名もあります。Claude Code の画面での名前は、コーディネーターです。

9月7日のLIVEで、私は、このLIVEのブログは Fable 5.1 で設計し、その設計に基づいて Sonnet 5 が執筆をする流れを話しました。グラレコは Codex で作る、とも続けました。「ほぼノーミスでやってくれています」とも言いました。

設計の役と書く役が、別のモデルに分かれた流れです。グラレコを作る役も別です。重いモデルの置き場は、役ごとに分かれます。窓口を軽くして実行側を深くする動画の形と、役ごとにモデルの重さを分ける点では同じです。

ことわざの図解のあと、続けて別のテーマを3本投げる場面があります。違うテーマが4本。スレッドはこの4本をどう受け持って動くのか。

画面では、ことわざの図で「作業中」と「解決済み」のスレッドが立ちます。そこへ続けて、別のテーマの図解が投げられる場面です。

いまにゅさん（動画の中で・17:19〜）

ここにさ、ポンと投げたらさ、こんなさ、全然違うものってさ、なんか並走できたイメージあるって。

勝手に開くのかとJ君が聞くと、コーディネーターが勝手に動いて作業のスレッドを立てる、と返ってきます。位置づけは「サブエージェントの上位互換」なんです。

そのあとは、研修A・B・Cの資料を頼む場合も並走できる、という話に移ります。今までは、関係のない物を1つのチャットに入れない方がよかった、といまにゅさんは言います。

いまにゅさん（動画の中で・20:04〜）

PMにポンポンポンポンパスしてるので優秀なAIを使える部下にポンポンポンポン丸投げしてる

スレッドは、テーマごとに立ちます。4本を受け持つのはスレッドで、窓口は報告を受ける側です。人間に残るのは、出すか止めるかの判断だと私は見ます。

5月8日の朝LIVEで、私は、ブログ・画像・リンク切れチェックのAIがチームを組み、記事とグラレコ画像をワードプレスへ投稿するまで進むと話しました。チェックを通ったものが私に来て、OKなら「公開して」と言うと公開してくれる、とも続けました。

5月のLIVEの話は、チェックを通ったものが手元に来る形です。動画の形は、窓口に渡せば裏側でさばかれる形で、終点の置き方が違います。

私は、横に広げる側はAIの持ち場だと見ます。「人間は縦に掘る。AIは横に広げる」で言えば、テーマの違う図を並べて進めるのは横の仕事です。

最後の一手は、できあがった型の温度を身体で確かめ、出す・止める・任せるの境界を決めること。ここは人間が持つ、と私は見る。スレッドが何本並走しても、この一手は人間の側に残ります。

並走の前に決める1行は、人間が受け持つ所そのものです。人間が持つ役割と完了条件については、ループの中で人間が持つ役割と完了条件にも書きました。条件が先にあれば、スレッドが何本立っても、止めどころは決まっています。

私なら、並走させる前に、1件ごとに完成の条件と任せる範囲を1行で書きます。動画の例題で言えば、ことわざの図解1本の完成の条件は、図解のスキルで1枚の図に仕上がること。任せる範囲は、その1枚を作るところまでです。最後に出す・止める・任せるを決める人も、走らせる前に1人決めておきたいところです。

ライブラリとメモリーには、使うたびに何が積もっていくのか。プロジェクトのチャットが1つだけ、という作りは、チャットを毎回立て直す今までの使い方から、何を変えるのか。

ここの説明では、プロジェクトのチャットは1つだけです。毎回チャットを立てて記事作成のスキルを使う、聞き役のいつもの形とは別物。

いまにゅさん（動画の中で・14:09〜）

メモリーとかコンテキストとかそういったのがどんどんどんどん溜まっていくような仕組みになってね。

育てるのはハーネスで、メモリー・コンテキスト・ファイルを含む環境全体がプロジェクトに溜まります。「使えば使うほど良さが分かってくる」機能だと話します。

設定の画面では、メモリーの memory.md に、アップロードした図解のスキルを使うと書かれていました。動画では、さっきアップロードしたので、それを認識してくれているのだと思う、と話されます。そのあと、AIの記憶をこのプロジェクト単位で積み上げていける、と説明が続きます。

いまにゅさん（動画の中で・26:03〜）

AIの記憶の部分をどんどんどんどんこのプロジェクト単位で積み上げていくことができると

ライブラリの図のフォルダには、スレッドが作ったプレビューの画像が勝手に入ります。人間が並べ直す手間はない。定期実行のルーティンも入る。

あとで説明されるプロジェクトの指示は、作成した指示やルールを全ての新しいスレッドが読み込んで従う欄です。新しいスレッドのたびに共通して読んでほしい物は、ここに入れます。無くても動くけれど、あった方がよい扱いだと動画は添えます。

memory.md は、AIの記憶の置き場です。新しいスレッドが全部読むのは指示の欄の方で、memory.md はそれとは別に、記憶として積み上がっていきます。

チャットを立て直すたびに、積もる先が散る。メモリーもファイルも、同じです。積もる場所が1つなら、育てる相手もはっきりします。

6月23日の朝LIVEで、私は、AIが出したものに「あなたにとって良しとするんですか」と問われるのを人間がチェックするのは、「人間がチェックする限界を超えている」と話しました。続けて「自分自身のAIを育ててAIに委ねていかないと、自分はいつまで経っても忙しくて、AIを使えば使うほど、なぜか忙しい」と言いました。分身のAIを育てて委ねることが、自分の成長にも、ビジネスにも、「家庭や暮らしのゆとり」や余白にもなる、と重ね、AIは使う道具であると話しながら、一方で育てていく発想で付き合うのだと続け、「使うから育てる」「AIとの関係を変えていく」とも言いました。

使うほど忙しくなる側から、育てる側へ移るとき、育てる場所がプロジェクト1つにまとまる作りは、助けになると私は見ます。

私なら、委ねる目的を効率化だけにしません。手放し委ねて余白をつくり、その余白を遊び探求して自分を満たします。

設定の使用量の画面には、スレッドごとに使ったトークンが並びます。コーディネーターの分も、図解ごとの分も、1行ずつ出ます。実演の表で、この数字はどう見えるのでしょうか。

使用量の表では、世界情勢の図解が3.7Mでいちばん多い行です。次がAIエージェントの図解の2.3M。ローカルLLMの図解は1.6Mでした。

いまにゅさん（動画の中で・27:27〜）

消費量はやっぱり大きいなっていう感じはするので、ま、ここはあの見ながらこれ結構こういう処理したら食うんだなとか

画面を見たいまにゅさんは、思ったよりも使ったと話します。どれぐらい消費するのか分からない部分はあると断ったうえで、使うことをすすめています。

表の数字は、動画の中で4本の図解を並走させた、1回の実演の分です。そのまま普段の目安にはならない。

別の場面の説明では、消費が早くなる点がデメリットとして挙げられます。窓口がいて、各スレッドが動く。その分だけ、減りが速くなる。

表では、コーディネーターの2Mが、ことわざの図解の1.9Mより多い行です。一方で世界情勢の図解は、3.7Mあります。窓口より重い図解の行も、あるわけです。

窓口もトークンを使っていて、コーディネーターの2Mは窓口ひとつの分です。図解ごとの行とは別に、1行で出ます。

使用量は、設定の画面へ見に行って確かめる物です。見に行く手間を減らす置き方は、使用量をチャット入力欄の上に置く方法に書きました。数字が手元にあれば、並走の本数を決める時に迷いが減ります。

使える範囲は、Pro と Max に順次開放されていて、Teams と Enterprise は適用外です。来ていなければ待ってほしい、と動画は伝えます。

動画の形は、人間が話す相手をコーディネーター1つにまとめるものです。窓口の推論量はローにします。設計や実行をするスレッドは、エフォートを上げて並走します。

ライブラリとメモリーには、作った図と記憶がプロジェクトごとに積もります。トークンの減りは速い。その速さは、使用量の画面に出ます。

私の見方は、ここで一つです。窓口を任せても忙しいなら、終点まで引き受ける一人が決まっていません。忙しくなるのは人間のままだ。速さは二番目です。

並べる数を決める前に、その1件の終点は誰が引き受けるのでしょうか。動画の例題で言えば、ことわざの図解1本について、完成の条件は図解のスキルで1枚の図に仕上がること、任せる範囲はその1枚まで、と1行で書き、終点を引き受ける人を走らせる前に決めておきます。

AIに委ねて、人は積み減らして生き直す。私はその入口を、1件ごとに引き受ける人を決める所に置きます。