ロールファイルの効果的な上書きは完全に成功したとは言えませんでしたが、やりたいこと自体は満たすことが出来たので、この分割されたロール（ルール）ファイルとgemini-cliのサブエージェントを使うスキームをどの様に使っていけばいいのかということを解説していきます。
1. コンテキストの最適化による予測可能性の向上
巨大なルールを分割するだけでもコンテキストウインドウの節約に繋がります。まずはCascading Role Systemを使うことでルールを最小化します。
コンテキストウインドウを最適化出来るなら、よりプロジェクト毎のローカルルールなどの詳細をAIに伝えることが可能になります。つまり、AIがRAG: 検索拡張生成（Retrieval Augmented Generation）を使う頻度を減らすことが可能になります。RAGを使う頻度が減ることで不確実性が減少し、結果の予測可能性にも向上します。
更にファイルやレイヤーといった小さな単位にフォーカスすることでより詳細な指示（I/F設計や論理構造といった具体的な指示）を与えることも可能となります。例えば以下の様な粒度まで分割すれば、AIが知るべき情報は最小限の情報（ex. トランザクションはどこで張るのかといったルール）を伝えやすくなります。
コンテキスト毎に可変になるファイル構造
1. basis.md # 共通のベースルール
2. PROFILE # エージェントの役割・人格・スキルセットの定義
- ENGINEERING.md # エンジニアリングの規範
- LANGUAGES
- TypeScript.md
- React.md
- atoms.md
- molecules.md
- organisms.md
- pages.md
- hooks.md
- PHP
- controllers.md
- services.md
- repositories.md
- collections.md
- models.md
- CREATIVE.md
3. multi-step-reasoning.md # 思考の連鎖（CoT）や複雑な推論プロトコル
2. ロールを使った指定とコマンドの例
gemini-cliの@シンボルと、プロトコルに基づくコンテキストチェーンを組み合わせることで、サブエージェントに正確で最小限の知識を与えます。オプションは以下の通りです。
- -m: モデルの指定
- -p: プロンプト
- -y: ファイル操作の許可
実際はもっと細かい指示を出す方が望ましいのですが、今回は例示ということで小さなコンポーネントを作るイメージのコマンドを置いておきます。
% gemini -y -m gemini-2.5-flash -p "@./ENGINEERING.md => @./multi-step-reasoning.md => @./TypeScript.md => @./React.md => @./atoms.md src/components/atoms/Button.tsxを作って Props = { label: string; disabled: boolean, className?: string; handleClick: () => void; }"
もちろん、毎回こんなロール指定をやってられるかという人もいるでしょう。ファイルPATHとルールをマッピングするファイルがあればあとはAIがやってくれます。そこまで出来れば、あとはAIが生成したコマンドをサブエージェントに実行させるだけです。つまりはAIによる自律型ソフトウェア開発システム構想で触れたコンダクターの役割を果たすロールとなります。
これが出来ると何が嬉しいか？
もちろん、この方法論で気になるであろうポイントはトークンの制約でしょう。リクエストが増え、コンテキストが詳細になればなるほど、トークンの消費量もまた増えていきます。一方で十分に小さな粒度に対して最適化されたコンテキストを与えやすくなれば、モデル性能は小さなもので十分になります。つまり、高性能なモデルを使う頻度を減らすことが可能となりリソースの集中はむしろ容易になっていきます。
特にgemini-2.5-flashに関してはコスパに優れており、以下の点を補うだけでもClaudeとの差を大きく縮めることが可能になります。
- ハイパーパラメータ調整
- 多段階推論
- 高スループット対応の抑止
チューニングすることで十分な性能が出せるポテンシャルを秘めているなら、トライアンドエラーも容易になり安価なモデルほどゲームチェンジャーとなり得ます。gemini-2.5-flashはこの点で非常に優れたモデルであると私は考えています。
結論
前回の記事でもAIは論理エンジンでなく推論エンジンであることがよく分かるかと思います。つまり、どんなに高性能なモデルを使っても、エンジニアリング領域において決定論的な仕事を期待しようとすれば、推論の範囲を狭めて予測可能性を高めていく方がリトライ回数を減らすことに繋がっていきます。
例えば、2Mトークンのコンテキストウインドウを持つ高性能なモデルをマラソンの金メダリストだとします。一方でgemini-2.5-flashは地元の高校生の陸上部員といったくらいの性能差があるかも知れません。しかし、gemini-cliがサブエージェントを起動することで、最短距離だけを走ることが出来ればどうでしょうか？土地勘のあるランナーが1kmずつを全力で走ることが出来るくらいの人数を投入すれば高校生陸上部員でも金メダリストに勝てるのではないでしょうか？
もちろん、雑な指示を出してもそれなり以上の結果を出してくれるモデルがあれば、それを使いたくなるのも分かります。しかし、その仕事をこなしたのはAIを使う人間でしょうか？それともAIでしょうか？
最後に私の大好きな言葉を置いておきます。
Do One Thing and Do It Well