ひとつのモデルに、全部を任せる必要はありません。リサーチ、長文の統合、コード生成、文章の最終判断——それぞれ得意なモデルが違います。このサイトの開発では、タスクごとに向いたモデルへ薄く委譲して、最終責任だけを一箇所に残す形にしています。

正直に前置きしておきます。2026 のいまは、むしろ逆の流れのほうが優勢です。ひとつの強いモデルに道具（ツール接続やサブエージェント）を持たせて、外部を呼ばずに内部で完結させる。外部モデルへ薄く振り分けるやり方は、少し前の作法になりつつあります。それでもジャムチがこの委譲を残しているのには理由があって、本稿はその型と、残している理由、そして揺れている線を、実際の構成のまま記録します。

役割を分ける

委譲は、CLI ラッパー三本（ask-grok / ask-gemini / ask-codex）に閉じています。呼び出す側は「このタスクは誰が得意か」だけを決め、返ってきた出力は助言として受け取る。採用するかどうかは、最終の担い手が判断します。

タスク既定の委譲先理由
最新の仕様・モデル更新・事例の調査grokライブ Web 検索が効く
多ソースの統合・長文の要約gemini長いコンテキストを畳める
図やコードの生成・複雑なデバッグcodexサンドボックスで安全に書かせられる
執筆・最終判断・差分レビュー・git 操作Claude一貫した声と責任の所在
タスクと既定の委譲先です。これは固定の真実ではなく、迷いを減らすための出発点にすぎません。

念のため付け加えると、この割り当ては「このタスクはこのモデル一択」という強い主張ではありません。実際、モデルの実力は動いていて、いまは Claude がリサーチも長文もコードもかなりの水準までこなします。だから、はっきり振り分けられる場面はむしろ減ってきました。それでも既定を置いておくのは、毎回悩まないためです。合わなければ、その場で本線（Claude）に戻します。

外部のモデルには、コミットも PR もさせません。git を触るのは最後の担い手だけ、と決めています。というのも、外部モデルの出力は速くて助かるのですが、そのまま正解として飲み込むと危ういからです。差分を全数見て、検査を通し、確定させる——この一点だけは、一箇所に固定する。「grok がそう言っていた」を、採用の免罪符にはしない。そう決めておくと、速さと一貫性が両立します。

一筆書きの流れ

記事でもコードでも、流れはだいたい同じです。調べる、畳む、組む、確かめる、出す。各段でだけ得意なモデルに寄り道して、本線は崩さない。

委譲を挟んでも、本線は一本です。各ノードでだけ得意なモデルに寄ります。

この型が効くのは、段ごとの切り替えコストが小さいからです。CLI は薄いラッパーなので、向かない委譲先だと分かれば、その場で本線に戻せる。導入していない、あるいは認証していない委譲先があっても、本線の担い手がそのまま引き取れるように、フォールバックを前提に組んであります。完走を、外部ツールの有無に賭けない。ここは実際に何度も助けられました。手元に無いモデルがあっても、パイプラインは止まらずに最後まで走ります。

潮流は「単一モデル＋道具」。それでも薄く振り分ける理由

ここまで書いておいて何ですが、いまの潮流は「単一モデル＋道具」です。ひとつの強いモデルに、標準化されたツール接続（MCP のようなもの）やサブエージェントを持たせて、外部を呼ばずに内部で分業する。手を出すモデルを一つに寄せたほうが、途中でコンテキストが途切れず、体験も速い。多くの現場が、そちらへ動いています。

それでも外部委譲を残しているのは、ふたつの理由からです。ひとつは、本当に外がまだ勝つ場面があること。たとえば最新の仕様や事例のリサーチは、ライブでウェブや X を検索できる grok が、いまも素直に強い。もうひとつは、差し替えのしやすさです。薄いラッパー越しの委譲なら、より良い先が出たときに、そこ一本だけ差し替えればいい。特定のモデルに深く結びつけないぶん、乗り換えが軽くなります。

とはいえ、この線引きが揺れている自覚はあります。モデルが汎化するほど、外へ振り分ける必然は薄れていく。近いうちに、いくつかの委譲は単一モデルの内側へ畳むことになるかもしれません。畳んだら、その結果もここに書きます。

守るべき一線

便利さの裏で崩しやすいのが、声と事実の扱いです。外部モデルの出力をそのまま載せると、誇張や受け売りが混ざりやすい。そこで、採用前のチェックを機械にやらせています。禁止した言い回しや、機微な情報が混ざっていないか——このあたりは、テストとして書いておいて、継続的に検査する。人の目は、その先のニュアンスに集中させます。論はきちんと通っているか。声は、ジャムチのものになっているか。

結果として、少人数でも「広く調べて、速く組んで、一貫して出す」が続けられます。中継網のように、得意なノードを結んで、荷物を先へ運ぶ。レバレッジは規模ではなく、振り分けの設計から出てくる。そして、どこまで振り分け、どこで一つに畳むか——その線を動かし続けることも、たぶん設計のうちです。

参考: Grok CLI、Gemini CLI、Codex。単一モデルに道具を持たせる標準としては Model Context Protocol がある。委譲ルールは、自社リポジトリ内のルールファイルに正本として置いています。