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

役割を分ける

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

タスク既定の委譲先理由
最新の仕様・モデル更新・事例の調査grokライブ Web 検索が効く
多ソースの統合・長文の要約gemini長いコンテキストを畳める
図やコードの生成・複雑なデバッグcodexコード生成に強い
執筆・最終判断・差分レビュー・git 操作Claude一貫した声と責任の所在
タスクと既定の委譲先。出力はいずれも助言で、採否と統合は最終の担い手が握る。

外部モデルはコミットも PR も作らない。差分を全数見て、検査を通し、確定させるのは一箇所に固定する。これで「速さ」と「一貫性」を両立させる。

一筆書きの流れ

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

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

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

守るべき一線

便利さの裏で崩しやすいのが、声と事実の扱いだ。外部モデルの出力をそのまま載せると、誇張や受け売りが混ざりやすい。そこで、採用前のチェックを機械化している。禁止表現や機微情報が混ざっていないかは、テストとして書いて継続的に検査する。人の目は、機械で測れないニュアンス — 論の通り方や図の収まり — に集中させる。

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

参考: Grok CLI、Gemini CLI、Codex。委譲ルールは、自社リポジトリ内の一枚のルールファイルに正本として置いている。