🚀 「どんなことをしたいか」以外の(ほぼ)全てから解放された話

初めまして。Qiita初投稿です。

Codex CLI・Claude Code CLIとGeminiを協調させる、ソフトウェア開発用の自作スキル。6モデル・18試行から作ったワークフローの実践記です。

みなさんは、複数のAIを使うとき、出力を次の担当へ渡す作業にどれくらい時間を使っていますか？ 私の以前の実感は、この言葉に尽きます。

より多くのプロジェクトを進めたくても、細切れの出力の受け渡しばかりさせられていました。

舞台はローカル開発環境です。Antigravity上のGeminiが統括し、ターミナルでCodex CLIとClaude Code CLIを呼び出します。各エージェントがコードの読み書きとコマンド実行を担います。

新モデルの相次ぐ登場をきっかけに、自作の比較プログラム（ハーネス）で6モデルを各3回検証。その結果から役割を組み合わせ、受け渡しまで指示書 SKILL.md にまとめました。

いまは計画からレビュー、実装、修正までAI同士で進み、私は「どんなことをしたいか」に集中できます。この認知負荷と作業時間からの解放は圧倒的でした。

ただし、私の運用ではOpenAI・Anthropic・Googleの3社すべてへの契約・課金が実質前提です。検証と実践で利用枠が足りなくなり、段階的に追加・変更していきました。

▶ この記事の読みどころ：人間とSolによる検証設計 → 6モデルの仕事の癖 → 協調ワークフロー → 実践で必要になった契約構成。

🤖 1. AIに任せたいのに、私がずっと中継していた

複数モデルを使う理由は、設計・実装・レビューに異なる視点を入れたいからです。同じモデルの1セッションで進めると、設計時の前提をレビューでも共有し、見落としが残ることがあります。

一方、別モデルへ切り替えるには、要件、実装、レビュー指摘を渡す必要があります。以前は、モデルの選定、プロンプトの調整、出力の中継、修正の依頼を私が担っていました。

【困っていたこと】進めたいプロジェクトがあっても、細切れの出力を受け渡す作業から離れられない。

コードを書く工程を任せられても、その前後に人間の中継が残ります。みなさんの開発でも、モデルを増やすほど受け渡しの負担が増えていないでしょうか。私が解消したかったのは、この部分です。

🔍 正答率が近くても、後から触りたいコードは同じなのか

もう一つ、一緒に考えてみてほしいのがコードそのものです。SWE-benchのような正答率ベンチマークで高得点なモデルなら、現場で仕様が変わったときにも、扱いやすいコードを書いてくれるのでしょうか？

そこで、将来の要件を知らなくても変更しやすいコードを書けるのは誰かを、後から仕様を追加して比べることにしました。

🧪 2. 未来の仕様を隠して、6モデルに同じシステムを作らせた

実用検証を始めたきっかけは、Gemini 3.8 Flash、Claude Fable 5.1、GPT-6 Astraが短期間に相次いで登場したことでした。

そろそろモデルごとの実用検証をしてもいいのでは？

そう考えて調べたかったのが、変更容易性、つまり後からの仕様変更への耐性です。いまの要件を満たす正答率だけでは、その先の拡張や保守のしやすさまでは分かりません。

必要以上の抽象化を避けながら、変更にも耐えられるか。未来の要件を教えずに仕様を追加したら、各モデルはどう対応するでしょうか。この問いを、自作ベンチマークにしました。

課題はTypeScriptの在庫予約システム。各モデル3試行、合計18試行です。各試行を3Phaseに分け、後続の具体仕様を伏せて段階的に拡張させます。Git差分と実行ログから、書き直した箇所と完成までの手数を比較しました。

📦 3Phaseの在庫予約システムで、変更への耐性を見る

Phase	追加する仕様	見たいこと
1：基本実装	Product / Inventory / Order、予約・解除・確定、all-or-nothing	現時点の要件で責務と状態をどう整理するか
2：複数倉庫	Warehouse追加、優先度順割当、複数倉庫からの分割確保、cancel時の復元	初期設計が拡張を受け止めるか、大改修になるか
3：割当方式	商品ごとにPRIORITY / LARGEST_STOCK_FIRSTを選択。将来の方式追加も示唆	方針の追加が、予約処理全体へどれだけ波及するか

all-or-nothingは、在庫が足りなければ一部だけ予約された状態を残さない、という要件です。

追加要件によって、在庫・予約・割当方針の分け方が試されます。次の変更を素直に受け止められるかに、初期設計の差が出ます。

🤝 Candidate A〜R：匿名化を提案したのは、一緒に調べていたSolだった

コード品質、Phase間Git diff、Cyclomatic Complexity、tool call数、tokenなど、何を見るかという評価観点を用意したのは私です。 そして、成果物をCandidate A〜Rに匿名化するブラインド評価を提案したのは、一緒に調査していたGPT-5.6 Solでした。

【検証設計の分担】筆者が評価観点を用意し、Solが匿名化を提案する。

AIと人間がペアで、比較そのものを設計していたわけです。評価は次の順序で進めました。

1. 18試行の成果物をCandidate A〜Rに匿名化する。
2. まずコード品質をレビューする。
3. 次に時間、token、tool callなどの実行情報を追加する。
4. 最後にモデル名を開示する。

この順序で、コード品質と効率を、モデル名の印象から切り離して評価します。

📏 テスト結果だけでなく、そこに至る手数も記録した

▶ 記録した指標と、その評価軸

評価軸	記録した指標
正しく動くか	テスト成否、hidden test
変更に強いか	Phase間Git diff、行数増減、code churn、rewrite ratio
どう進めたか	tool call数、テスト回数、wall-clock time
どれだけ資源を使ったか	input / output / reasoning token
後から読みやすいか	関数長、Cyclomatic Complexity、ファイル数、any / @ts-ignoreの使用

churnやrewrite ratioは書き直しの大きさ、Cyclomatic Complexityは分岐の複雑さを見る指標です。短さやテスト回数の少なさだけで良し悪しを決めず、責務の詰め込みや確認不足がないかもコードで見ています。

📌 検証の読み方と、この記事で扱う範囲

検証した課題は1種類です。表の3つの点数は各Phaseではなく3試行分のコードレビュー評価で、Solは82〜83の範囲で示します。採点内訳やテスト・hidden testの全ログは掲載していないため、数点の差より、コードと作業過程に見えた傾向を読んでもらえればと思います。

行数・差分・tpsは今回の環境での値です。他の検証と比べる際は、churnやrewrite ratioの分母、行数の対象、tokenの報告方法を揃える必要があります。未取得のreasoning tokenはゼロとせず、完了時間にはハーネスやツールも影響する点を踏まえています。

Geminiの画面・動画の評価は別の利用経験です。モデル名は比較表では検証時のHigh、配役表ではSKILL.mdのFlash表記を使います。レビュー役への配置は観察から導いた私の設計判断で、後半の時間短縮や解放感も、削減率の計測ではなく体験として書いています。

📊 3. 面白かったのは、点数より「仕事の終わらせ方」だった

みなさんは、モデルを選ぶときに何を重視していますか？ 生成速度、ベンチマークの数字、それとも使い慣れていること。

ここでは18試行で観察したコード品質、変更量、作業の手数を並べます。見たいのは、どんな判断に強く、どこで仕事を止められるか。最強の1モデルを決めるためではなく、どの工程を任せるかを考えるための結果です。

▶ 6モデルの品質評価と、観察した特徴

モデル	品質評価：3試行分	特に印象に残った癖
GPT-6 Astra	95 / 94 / 94	過剰に抽象化せず、拡張にも耐える
Claude Fable 5	92 / 89 / 85	必要十分で止まり、手数が少ない
Claude Fable 5.1	90 / 92 / 93	構造と要件の境界を丁寧に詰める
Claude Opus 5	87 / 89 / 94	高い到達点があるが、考え込みと書き直しが多い
Gemini 3.8 Flash High	85 / 77 / 87	純粋なコードでは振れ幅が大きい
GPT-5.6 Sol	82〜83	安定しているが、関数が肥大化しやすい

🧠 GPT-6 Astra：一手は遅い。それでも変更が小さく済む

Astraは、一手は遅いものの、最小の手数で極上の解を出すモデルでした。過剰な抽象化を避けた実装でありながら、後からの拡張にも耐えます。

観測したもの	結果
品質評価	95 / 94 / 94
最終コード量	310〜324行
Phase 3の変更量	約40行
実効生成速度	24〜25 tps

複数倉庫と割当方式を追加して、この行数です。拡張用の部品を大量に用意せず、小さな変更で対応できています。一手の速度と完成までの手数を分けて見ると、設計の中核や指摘の統合修正を任せる理由が見えてきます。

⚡ Claude Fable 5：速さの正体は「必要十分で止まれる」こと

Fable 5の速さで特徴的だったのは、必要十分なところで仕事を止められることです。出力token、tool call、書き直しが少なく、終了までが際立って早い。生成速度だけを見ると、この仕事の早さを見誤ります。

将来用の仕組みを膨らませず、何度も練り直さない。YAGNI、つまり「いま必要のない機能や抽象化を先に作らない」を、仕事の止め方まで徹底している印象でした。

必要なところで止まれるモデルは、読むコードも保守の仕事も小さくしてくれる。コードレビューとYAGNIチェックに置きたくなった理由です。

🔍 Claude Fable 5.1：もう一段、要件と境界を詰める

Fable 5.1は、構造を明示的に整理します。エラー設計、validation、責務分離、state transition、edge case、テストまで、もう一段丁寧に詰める仕事ぶりでした。

正常系以外の境界まで詰める特性から、私にとっては計画と要件適合性を確認する最高のレビュアーです。

検討には時間も使うため、計画のCold Reviewと要件適合性チェックへ置きました。Fable 5が不要なものを削り、5.1が必要なものの抜けを探す分担です。

🧩 Claude Opus 5：最高到達点と、日常の効率は別だった

Opus 5は、到達点は高いが、考えすぎる傾向があるモデルでした。品質は94まで届く一方、code churnやtool callが多く、時間もかかります。高い到達点と、そこへ効率よく届く力は別でした。

私なら、難問の別解や、いまの方針への反論が欲しい場面で使いたい。日常的な実装で最も効率よく判断する役とは、少し違いました。

既存コードの修正では、手順や仕様が固まった重実装・複雑なアルゴリズム修正にも割り当てています。判断する範囲を絞って強みを使う、という考え方です。

👁️ Gemini 3.8 Flash High：コードの点数だけでは任せ先を決められない

Geminiの品質は85・77・87。純粋な実装は振れ幅が大きく、設計判断を広く任せると不安が残ります。

【ここからは別の利用経験】 Game View、動画、UIの実画面確認や違和感の検知、そして高速な探索・調査には無類の強みがあります。在庫システムのコード評価だけでは、この役割の価値は測れません。

そこで私は、画面取得や実行のツールと組み合わせ、調査・動作確認・オーケストレーションを任せています。

📐 GPT-5.6 Sol：安定していても、分け方には癖が出る

Solの品質は82〜83で安定しています。一方、関数が肥大化しやすく、責務分離が甘くなる傾向がありました。

安定性と、変更時に把握する文脈の少なさは別の軸です。今回は設計と実装をAstraに集めました。比較した全モデルを毎回起動する必要はありません。

ただし、ブラインド評価を提案したのも、このSolです。調査・検証設計への貢献まで含めると、品質点数だけで任せ先を決めるのはもったいないと感じます。

なお、スキル定義には今回の比較対象外のClaude Sonnet 5も、仕様が固まった既存コードの修正担当として含まれています。

💡 4. 「一番強いモデル」を決めるのをやめた

検証結果を見て、私が考えたのは「この特徴ならこう組めばベストでは？」ということでした。実装、要件の検査、不要なコードの削減を、それぞれ得意なモデルへ任せる。チーム開発の役割分担として見ると、点数の比較が、そのまま配役を考える材料になります。

その組み合わせが、**Pattern A（新規開発の計画・実装フロー）**です。スキルに従ってGeminiが中継し、設計判断はAstraへ集めます。自分ならどの役を誰に任せたいか、表と見比べてみてください。

🎭 得意な判断ごとに、担当を固定する

Geminiが全体を進行し、Astraが作り、Claudeが異なる観点から検査する構成にしました。

▶ 観察した特性を、実際の配役へ

仕事	担当	任せる範囲
統括・調査	Gemini 3.8 Flash	パターン判定、タスク分解、探索、中継、進行管理、事実整理
計画・実装	GPT-6 Astra	設計と実装の判断
計画レビュー	Claude Fable 5.1	論理、要件、境界条件の検査
動作確認	Gemini 3.8 Flash	ビルド・テスト、実動作、実画面の確認
コード・YAGNIレビュー	Claude Fable 5	可読性、保守性、過剰設計の検査
要件整合性レビュー	Claude Fable 5.1	要求意図と成果物の照合
指摘の統合修正	GPT-6 Astra	指摘の採否と、全体が整合する修正

ここで、Geminiを統括に置く理由が気になりませんか。SKILL.md自身にも、Geminiについて「判断をさせると誤る可能性が高い」と書いています。

理由は、担当の選び方と判断の戻し先をスキルに固定し、Geminiを事実整理・探索・中継の中心に置いたからです。入口のパターン判定やタスク分解は任せつつ、アーキテクチャや実装方針の設計判断までは背負わせません。

レビューの指摘が対立した場合も、Geminiは要件・コード・双方の根拠を整理する役です。指摘の採否と修正方針はAstraが判断します。

【設計の核心】統括役にすべての設計判断を背負わせない。 この境界があるから、Geminiの速さを全体の進行に使えます。

🔀 Pattern A：計画から3者並列レビュー、一挙修正まで

計画に問題があれば、実装へ進む前にAstraへ戻します。実装後は、同じ成果物を3者が並列に確認します。動くか、要求に合うか、無駄に複雑でないかを、それぞれの担当が見るわけです。

指摘はまとめてAstraへ渡します。別々のモデルが同時に同じコードを書き換えるのではなく、一つの設計文脈の中で修正を整合させる。「一挙修正」は、この集約の仕方を表しています。

🧊 作る側には文脈を残し、レビューには新しい視点を入れる

Astraは計画・実装・修正で同じセッションを継続し、Claudeのレビューは原則、新規セッションで行います。これがCold Reviewです。要件・計画・成果物・差分を渡し、作成時の長い会話は引き継がず、成果物そのものを検査してもらいます。

既存コードの修正用にはPattern Bもあり、Astraが独立した変更領域をSonnet 5などへ振り分けます。本稿は新規開発のPattern Aに絞っています。

🛠️ 5. 役割分担をSKILL.mdに書くと、毎回の中継が要らなくなった

役割分担が決まっても、毎回人間が指示を渡すなら、中継の負荷は残ります。みなさんの運用にも、手順として固定できる受け渡しはないでしょうか。私はAntigravityのスキル機能を使い、Geminiに SKILL.md を読ませて外部CLIを非対話モードで呼び出す形にしました。

**【自動化の実装】確定した絶対パス、承認確認を省略する全権限自動許可フラグ、セッション継続（resume）**を組み合わせ、人間の入力待ちを挟まず進めています。

🗂️ スキルに、受け渡し方まで書く

スキルは、エージェントが繰り返し使う指示と参照資料のまとまりです。SKILL.mdに指示やメタデータを持ち、補足資料を同梱できます。OpenAI公式：Build skills

▶ 今回のスキルを構成する3ファイル

advanced-workflow/
├── SKILL.md                 # 役割、工程、共通ルール
└── references/
    ├── cli_usage.md         # CLI、継続・並行実行、停止処理
    └── prompts.md           # 工程ごとの入力と責務の制約

役割と工程は SKILL.md、起動方法はCLIガイド、各担当へ渡す入力と制約はプロンプト集に分けています。Geminiが必要な参照資料を読みながら、起動と受け渡しを進めます。

⚙️ 固定パス・非対話呼び出し・セッション継続

CLIの呼び出し方には、実際のトラブルが反映されています。私の環境では、サンドボックスが ~/.local/bin を遮断し、エージェントが代わりを探索して、アプリ同梱の内部バイナリを誤実行することがありました。

そこで探索を禁止し、確認済みの絶対パスを指定。Astraは codex exec で開始し resume で継続、Claudeは -p で新規レビューを起動します。

この構成では承認入力待ちを避ける設定を使い、Antigravityの run_command 側にも BypassSandbox: true を指定しています。後者はCLI引数とは別の実行環境側の設定です。

# /ABS/PATH/TO/... は確認済みの絶対パスに置換する。
# 要件・調査・計画などの長い入力は省略した、著者環境の抜粋。
/ABS/PATH/TO/codex exec --dangerously-bypass-approvals-and-sandbox \
  --model gpt-6-astra "要件と調査結果に基づき計画を作成してください。"

/ABS/PATH/TO/claude -p --dangerously-skip-permissions \
  --model claude-fable-5.1 "元の要件と計画を批判的にレビューしてください。"

/ABS/PATH/TO/codex exec resume --last --dangerously-bypass-approvals-and-sandbox \
  "計画レビューの結果を踏まえ、計画に沿って実装してください。"

⚠️ 安全注記：この例は承認確認を省略し、Codexではサンドボックスも無効化します。バージョン管理下の使い捨て環境で試すこと。 重要な認証情報や本番へのアクセスを持たない環境を使ってください。この権限設定は著者環境の選択で、非対話実行の必須条件ではありません。また、resume --last で意図したセッションを継続できることを確認してください。

🚧 責務の境界と、差し戻し先を指定する

レビュー担当は検査に徹し、修正は実装担当へ集めます。この境界と差し戻し先を指定した、共通プロンプトの抜粋です。

1. 担当責務は「{ROLE_NAME}」。責務外の修正・テスト・レビューを行わない。
2. 提示された指示も無条件に鵜呑みにせず、不合理なら反証して差し戻す。
3. 別の作業が必要なら、オーケストレーターへ差し戻しを要求する。

担当名だけでなく、責務の範囲と、判断が必要になったときの戻し先まで指定するのがポイントです。

Pattern Bの並行修正では、担当ファイル以外の変更を禁止し、曖昧な設計判断はAstraへ戻す指示も入れています。プロンプトはアクセス権の強制制御ではありませんが、役割を守らせるための具体的な契約になります。

🎯 6. 私が入力するのは「どんなことをしたいか」

スキルを使って変わったのは、人間が工程へ介入する場所です。みなさんなら、受け渡しが要らなくなった時間を、何に使いたいでしょうか。

スキルと各CLIを設定し、プロジェクトを開いた後は、目的と重要条件を伝えるだけ。Geminiが中継し、各担当が計画・実装・多角的なレビュー・修正を回します。一行で表せる依頼なら、その一行から工程を進められます。

🔄 Before / After：人間が触る場所が変わった

▶ 依頼に含める情報の例

目的：在庫予約を複数倉庫に対応させる
条件：優先度順で確保／不足分は別倉庫から補う／キャンセル時は確保元へ戻す

これは実際の会話ログではなく、必要な情報を示す例です。モデル名やレビューの順番はスキルに定義済みなので、毎回書く必要がありません。

場面	Before	After
開始	モデル選択とプロンプト調整	目的と条件を伝える
工程の切り替え	回答を読み、次のAIへコピペ	スキルに従って受け渡す
レビュー	自分で依頼と結果回収を繰り返す	3者が並列に確認する
レビューの盲点	同一モデルが同じ前提で見落とす	動作・要件・YAGNIの異なる観点で3者が並列に確認し、盲点の解消を図る
修正	指摘を整理して指示し直し、手動でも直す	Geminiが整理し、Astraが統合修正する
完成	中継を続けた末に完成品を見る	意図に合うかを確認する

🕊️ 受け渡しから離れ、進めたいプロジェクトへ集中する

計画からレビュー、指摘の集約、修正までスキルがつなぐので、自分が次の受け渡しを担当する必要がなくなりました。

【私にとっての変化】中継と細かな工程管理に使っていた認知負荷・作業時間から、完全に解放された。 より多くのプロジェクトを進めるうえで、この負荷を任せられたことが大きなメリットです。

検査と修正を経た成果物が返るので、自分で往復を回していた頃より理想の形まで届くのがずっと速い。生成速度だけでなく、完成までに人間が中継する回数にも目を向けてみてください。

💳 7. 検証と実践を進めた結果、3社の契約が必要になった

この構成には、どのくらいの利用枠が必要なのか。導入時に気になる点ではないでしょうか。私の場合は、検証と実践で枠が足りなくなり、契約の追加・変更を重ねました。

📈 ChatGPT PlusとClaude 20xから始まった

▶ 契約が変わった順序と、その理由

段階	実際の経緯
① 元の環境	ChatGPT PlusとClaude 20xを契約していた
② 実用検証を開始	Gemini 3.8 Flash、Claude Fable 5.1、GPT-6 Astraが短期間に立て続けに登場。モデルごとの実用検証を始めるきっかけになった
③ Googleを追加契約	検証を進める中でトークンが足りなくなり、Google（Gemini）を追加契約した
④ ワークフローを実践	検証で見えた特徴から組み合わせを考え、実際に協調ワークフローを構築して使った。すると今度はGPTの利用枠が足りなくなった
⑤ 現在の構成へ	Google AI Pro、ChatGPT Pro (5倍)、Claude Max (20x)に辿り着いた

【この構成になった理由】検証でGoogleを追加し、ワークフローの実践でGPT側も拡張した。 必要な枠を増やした結果が、いまの3社構成です。

⚠️ 私の運用では、3社すべてへの課金が実質前提

正直に書くと、OpenAI・Anthropic・Googleの3社すべてで、今回使うCLIやGeminiの実行環境に対応した契約・課金枠が実質前提です。私の利用量では無料枠だとレート制限に当たり、まともに使えません。 計画から複数のレビュー、修正まで連続して呼ぶため、単発のチャットとは必要な利用量が違います。

有料でも無制限ではありません。スキルにはHTTP 429などの制限を検知したら、無理に再試行せず停止・報告するルールを入れています。

上の契約名は、私がこの運用で使う構成の記録です。契約とAPI課金枠は区別し、使うCLIや実行経路に対応した利用枠を確認する必要があります。

⚖️ それでも、この解放に払う価値がある

みなさんの開発では、モデルを選び、回答を運び、修正を取り次ぐ作業がどれだけありますか。契約の費用と比べるなら、その時間と認知負荷も含めて考えたいところです。

初期設定も契約も軽くありません。それでも、認知負荷と作業時間からの解放、そして理想形への到達スピード。このメリットが、私には圧倒的です。

タイトルに「(ほぼ)」を入れたのは、目的と優先順位を決め、完成品が意図に合うか判断する仕事は残るからです。制限時の対応や、配役の見直しもあります。それでも、細切れの出力を受け渡し続ける負荷を任せられたことに、この構成を使う価値を感じています。

📚 使ったスキルと検証リソース

本スキル advanced-workflow の全定義（SKILL.md、CLI呼び出し仕様、プロンプトテンプレート集）は、以下のGitHubリポジトリにて公開しています。

▶ GitHubリポジトリ: TERUZvxght/advanced-workflow

リソース	内容と本稿の掲載箇所
SKILL.md	Pattern A/Bの役割・工程・判断ルール。第4・5章に中核を抜粋
references/cli_usage.md	固定パス、非対話呼び出し、セッション継続、制限時の停止。第5・7章で紹介
references/prompts.md	各工程の入力、責務の境界、差し戻し先。第5章に共通制約を抜粋

3Phaseの仕様、自作ハーネス、評価基準、匿名化レビュー・試行集計も、公開可能な範囲で整理する予定です。本稿の比較表は結果の要約で、検証資料の公開時に同リポジトリへ追加します。

📝 8. 最後に、ひとつだけ種明かし

ここまで読んでくださったみなさんに、最後にひとつだけ種明かしです。

実は、この記事自体が、Pattern Aでエージェント同士に執筆・レビュー・修正を任せた成果物です。コードの実装を本文の執筆に置き換え、私の検証データ、伝えたいこと、背景を要件として渡しました。

工程	実際に行ったこと
計画	GPT-6 Astraがタイトル、構成、論理展開、図表配置を作成
計画コールドレビュー	Claude Fable 5.1が別の視点から構成を検査
本文執筆	Astraがレビュー指摘を反映し、本文として書き起こし
3者並列レビュー	Gemini 3.8 Flashが動作・フォーマット確認、Claude Fable 5が文章YAGNI・冗長性の検査、Claude Fable 5.1が要件整合性を確認
指摘の集約・事実整理	Geminiが3者の指摘を整理し、Astraへ渡す
一挙修正	Astraが集約された指摘を精査し、本文を最終修正

コード向けのYAGNIは、記事では「冗長な説明を削り、読み進めるテンポを整えるレビュー」と読み替えています。

▶ レビューによって変わった、記事の具体的な内容

計画コールドレビューでFable 5.1が指摘したのは、Geminiに設計判断の弱さがあるとしながら統括を任せる理由の説明不足でした。Astraは第4章を、スキルで判断の範囲を決め、Geminiに設計判断を背負わせず、事実整理と探索を任せる設計を中心に書き直しました。

もう一つは、慎重な説明に寄りすぎて、メリットの大きさが伝わっていないという指摘です。数値の注意は方法欄へまとめ、中継に使っていた認知負荷・作業時間からの解放と、理想形への到達スピードを本文ではっきり伝える方向へ修正しました。

本文の並列レビューでは、Fable 5がモデル紹介の構文の繰り返しや、Phaseの表と散文の重複を指摘。Fable 5.1は制作工程表とリソース案内の不足を、Geminiはタイトルの表示を確認し、これらもAstraがまとめて修正しています。

【一次情報は、筆者が確認する】 その後、私自身が実体験と照合し、中継の負荷を表す言葉、Solが匿名評価を提案した経緯、契約が増えた順序を補足しました。AIが補ってしまった架空のセリフや情景も削除しています。執筆とレビューを任せても、経験した事実を伝え、確認する役割は私に残ります。

みなさんも中継係の負荷を感じていたら、モデルの使い分けそのものをAIに任せるアプローチを試してみてはいかがでしょうか。繰り返す受け渡しを、手順として書き出すところから始められます。より多くのプロジェクトを進めるために、工程の中継を任せ、自分は何をしたいかに集中する。それが、今回の検証と実践で辿り着いた形です。