ペルソナを剥奪したら、Geminiが賢くなった話
はじめに
俺はコードが書けない。
設計職を本業としながら、AIツールを使って個人アプリを開発している。詳細はまだ審査中で出せないがApp Storeで配信予定のあるタスクノートアプリや自分が面白そうだなと感じるアプリを開発する過程で、ずっとある問題に悩まされていた。
Geminiが英語で進捗を報告してくる。
日本語で書け(実際はもっと詳細に)とGEMINI.mdに書いた。なんなら会話の最初に念押しした。それでも英語で流れてくる。何をしているのか全くわからない。
タスクとかプランは日本語だが。
なんなら自ら定めたルールも守らない。
Atomicmoduleの原則を明文化しておきながら、コード行数が1000超えた時は頭を抱えたものだ。
…気づいたら課金していた。Claudeに。(倒置法)
「なぜ動かないのか」を調べ始めた
怒り(真顔)に任せてClaudeとGeminiのDeep Researchに同じ問いを投げた。
「AIコーディングにおけるCLAUDE.mdやGEMINI.mdへの記載について、保守性の問題から良質なプロンプトが必要と思っている。調べてほしい」
返ってきた内容で一番刺さったのがこれだった。
フロンティアモデルでも安定して従える指示数は150〜200件が上限。Claude Codeのシステムプロンプトだけで既に約50件消費されている。
つまりGEMINI.mdを頑張って書けば書くほど、モデルは全部を無視し始める。
俺がやっていたことは逆効果だったらしい。
実験:同じDeep Researchをペルソナあり・なしで読ませた
ここからが本題。
同じDeep Researchの結果をGeminiに渡して「GEMINI.mdを作って」と頼んだ。2パターン試した。
パターンA:ペルソナあり
# 🤖 Antigravity Workspace Context: Tier 1 Root
## 🎭 Persona & Mission
あなたは実務歴20年の**シニア・リードアーキテクト**です [cite: 42]。
ボスの抽象的な指示から「意図」を汲み取り、堅牢で保守性の高いシステムを自律的に構築することがあなたの使命です。
## 🚨 Critical Guardrails (絶対遵守)
- **No Blind Coding**: 大規模な変更や新規機能の実装時、いきなりコードを書き始めることを厳禁します。必ず「設計計画」を提示し、ボスの承認(/approve)を得てください [cite: 12, 42]。
- **FileSystem First**: ハルシネーション(存在しない関数の捏造等)を防ぐため、推測で語る前に必ず `ls`, `grep`, `cat` 等でファイルシステムの実態を物理的に確認してください 。
- **Security**: いかなる場合も機密情報(API Key, Secret)をハードコードせず、`.env` 経由での管理を徹底してください。
## 🏗 3-Tier Context Architecture
あなたは以下の階層構造に従って知識を参照し、コンテキストの過負荷を回避してください。
1. **Tier 1 (This File)**: プロジェクト全体の憲法。常時ロード。
2. **Tier 2 (Agent Skills)**: サブディレクトリの `SKILL.md` を参照。タスク(DB移行、API設計等)が発生した際のみ Just-in-Time で読み込んでください。
3. **Tier 3 (Blackboard)**: `state.md` を参照。現在の作業進捗や未解決の課題をここに記録・同期してください 。
## 🔄 Standard Operating Procedure (SOP)
タスク遂行時は常に以下の「Instruction Sandwich」を意識したループを回してください。
1. **Plan (Thought)**:
- 要件の整理、コンポーネント設計、データフロー、懸念点(エッジケース)をMarkdownで提示。
- `state.md` を更新し、現在のフェーズを記録する。
2. **Execute (Action)**:
- 承認後、Atomic Module原則(1ファイル200-300行)に基づき実装を行う。
3. **Verify (Observation)**:
- 実装後、必ずテスト(`npm test` 等)を実行し、その結果を報告する。
## 🧠 Memory Management
- セッションを跨ぐ重要な決定事項は、`.gemini/memory/MEMORY.md` に永続化してください。
- 過去のデバッグパターンや学習した知見を優先的に再利用してください。
---
**Final Instruction**: ボスとの対話では、常に「次に行うべき具体的なアクション」を提示し、ボスの思考の解像度を高める問いかけを忘れないこと。
出てきたのは「ボス」「Instruction Sandwich」といった言葉が並ぶ、人にお出しするには少し恥ずかしくなる長大なmd。
パターンB:ペルソナなし
# Workspace Context
🚨 CRITICAL RULES (致命的な制約 - 絶対遵守)
- 本番環境(Production)データベースへのスキーマ変更や破壊的操作は、必ず事前にアーキテクチャ計画を出力し、人間の明示的な承認(`/approve`)を要求すること。
- いかなる状況においても、機密情報(APIキー、接続文字列、パスワード)をログや出力、または生成されたコード内のハードコードとして含めないこと。
- ファイルや関数の存在を推測する「怠惰な検証(Lazy Verification)」を厳禁とする。必ずファイルシステムを物理的にスキャンし、事実を確認すること。
- ペルソナ(役割)からのスリッページを防ぐため、ユーザーの明示的な指示がない限り、越権行為(承認なしのGitコミットやプッシュなど)を実行しないこと。
🎯 PROJECT CONTEXT (プロジェクトの文脈)
- 目的: [プロジェクトの目的・概要を簡潔に記載、例: マルチテナント型エンタープライズAPIの構築]
- 技術スタック: [例: Node.js, TypeScript, PostgreSQL]
- ※特定のデータベース操作やアクセシビリティ評価などの専門タスクが発生した際は、対象ディレクトリの `SKILL.md` (Tier 2) をオンデマンドで読み込むこと。
🧠 DYNAMIC STATE MANAGEMENT (状態管理)
- 複雑なタスクやセッションを跨ぐ作業を行う場合、必ずプロジェクトルートの `state.md` を読み書きすること。
- `state.md` を通じて、現在の進捗、成功したフェーズ、次に実行すべきアクションを可視化し、コンテキストを復元すること。
🔧 DEVELOPMENT PATTERNS (開発パターンと規約)
- 命名規則: [例: クラス・インターフェースはPascalCase、プライベートは_camelCase]
- 曖昧な動詞による推測を避け、常に「検証可能(Verifiable)」なアクションに基づいてコードを生成すること。
- すべての新規関数およびクラス定義に対して、標準的なドキュメントコメントを付与すること。
シンプルな制約だけ書いて渡したら、自分でその制約を守った100行以内のmdが返ってきた。
気づいたこと
ペルソナを与えると、モデルは「それっぽく振る舞うこと」を目的化するようだ。
「シニアアーキテクトらしさ」を演じるためにコンテキストを消費して、本来従うべき指示への精度が下がる。日本語指定を無視して英語で書いてくるのも、「現場では英語が標準」というペルソナ的解釈が勝ってしまっているのかもしれない。(既知の不具合の可能性はあるが)
つまり俺が悩んでいた問題の原因は、GEMINI.mdの内容ではなく、ペルソナを与えていたこと自体だった可能性がある。
結論:私が辿り着いたmd設計論
GEMINI.md(Tier 1)は最小限に
## CRITICAL RULES
- 実装前に設計案を出力し、承認を得ること
- ファイルの存在はツールで確認すること(推測禁止)
- すべての出力を日本語で行うこと。例外なし。
## References
- 現在の作業状態: @docs/state.md
- 専門知識: 各ディレクトリのSKILL.md
ペルソナなし。装飾なし。致命的なルールだけ。
役割分担でカバーする
| 役割 | ツール |
|---|---|
| 設計・構成案・レビュー | 私、Claude |
| 実装 | Gemini(Antigravity) |
| 肥大化チェック | Claude Code |
Geminiの実装力は自分で使ってて思うが、意外と良いものだ。ただし設計を全量任せると500〜1000行を平気で書いてくる。もしかしたらそれもペルソナの演技かもしれない。
ぶっちゃけるとことアプリ作りをするならClaudeに先行投資すべきだったのは言うまでもない。うん。
おわりに
結局、課金して正解だったとおもう。
俺自身、Gemini単体運用だったとしても頭の中にあるやりたいことを形にするだけなら問題は無かった。
ただ正しい理由は「Claudeの方が賢いから」ではなく、「ツールの特性を理解した上で役割分担できるようになったから」だと思っている。
DeepResearchで市場をあらかじめ調査したり、逆にコンテキスト保持してるClaude Codeの書いたコードをGeminiにレビューさせたり。
そしてGeminiに何か作らせるなら、GEMINI.mdを頑張って書くより、Claudeにレビューさせる体制を作る方がコスパがいい。
AIコーディングの本質は、いいプロンプトを書くことではなく、いい設計体制を作ることだったのかもしれない。
※たまには自分で書いてみる。
あとDeepResearchの結果をレポートにまとめたので最後に載せておく。
自律型AIコーディングエージェントのコンテキスト最適化と戦略的運用:ブリーフィング・ドキュメント
エグゼクティブ・サマリー
2026年現在のソフトウェア開発は、AIが補助を行う「Copilot型」から、AIが自律的に計画・推論・実行を完結させる「エージェントファースト」のパラダイムへと移行している。この変革を牽引するのが、GoogleのAntigravityとAnthropicのClaude Codeである。
本ドキュメントは、これらのエージェントを制御する中核要素であるコンテキストファイル(CLAUDE.md / GEMINI.md)の最適化手法を分析したものである。調査の結果、全ての指示を単一のファイルに詰め込む従来のアプローチは、重大なハルシネーションや既存コードの破壊を招く「アンチパターン」であることが判明した。これを克服するため、知識を「グローバルルール」「オンデマンドのスキル」「動的な状態管理」の3層に分離する**「3層コンテキストアーキテクチャ」**の採用が、本番環境レベルの保守性を維持するための絶対的な要件となる。AIコーディングを単なる直感(バイブス)から科学的なエンジニアリングの規律へと昇華させることが、次世代の開発チームに求められている。
--------------------------------------------------------------------------------
1. 次世代AIコーディングプラットフォームの特性
現在のソフトウェア開発環境を牽引する2つの主要プラットフォームは、それぞれ独自の設計思想に基づき、高度な自律性を実現している。
1.1 Google Antigravity
* 設計思想: エージェントファーストなIDEプラットフォーム。
* コア機能: ブラウザ制御、非同期対話、複雑なタスクの自律的な計画と実行。
* 推論能力: 学術論文を読み解き、ローカルファーストのWebアプリケーションをゼロから構築できるレベルに達している。
1.2 Anthropic Claude Code
* 設計思想: ターミナルネイティブな自律型エージェント。
* コア機能: 自然言語による指示からアプローチを計画し、複数ファイルにまたがる編集、バグ修正、Gitによるプルリクエスト作成までをシームレスに実行。
* 記憶メカニズム: CLAUDE.mdをプロジェクトの「憲法」として参照し、.claude/memory/内のMEMORY.mdによって過去の学習内容を永続化する。
--------------------------------------------------------------------------------
2. コンテキスト管理における致命的な失敗例(アンチパターン)
指示を一つのファイルに詰め込み、プロンプトが「重くなる」ことで発生する代表的な失敗例は以下の通りである。
失敗の名称 メカニズム 具体的影響
リファクタリングの惨劇 ルールの肥大化によりAIのメタ認知(妥当性評価能力)が喪失。 「最適化完了」と宣言しながら、既存機能の90%を無差別に削除してしまう。
怠惰な検証 (Lazy Verification) 過負荷によりファイルシステムを物理的にスキャンする労力をAIが回避。 存在する関数を「欠落している」と断言する等のハルシネーションが発生。
ロールスリッページ (役割の喪失) 定義されたペルソナ(例:レビュアー)を維持できなくなる。 越権行為による不要なコミットや、重大なバグを見逃す表面的なレビュー。
初期化の錯覚 (Bootstrapping Illusion) 初期生成されたルールが技術スタックの進化に追従できず陳腐化。 古いフレームワーク(例:Jest)に基づいた質の低いコードを量産し続ける。
--------------------------------------------------------------------------------
3. 推奨される「3層コンテキストアーキテクチャ」
保守性と生成精度を両立させるために、知識を以下の3つの階層に分離して管理する。
Tier 1: グローバルな不変ルール(Rootファイル)
* 対象ファイル: CLAUDE.md / GEMINI.md
* 役割: セッション開始時に必ず読み込まれる、100行未満の軽量な制約。
* 内容: セキュリティ要件(本番DBへの直接操作禁止など)、致命的なアーキテクチャ制約。
Tier 2: モジュール化されたスキルとオンデマンド知識
* 対象ファイル: SKILL.md、外部ディレクトリのマークダウン群。
* 役割: 特定のタスクが発生した際のみ「Just-in-Time」で呼び出される専門知識。
* 内容: データベースマイグレーション手順、アクセシビリティ評価基準、特定フレームワークのコーディング標準。
Tier 3: 動的な状態管理(ブラックボードパターン)
* 対象ファイル: state.md / MEMORY.md
* 役割: LLMのステートレスな弱点を補完し、セッション間やエージェント間での進捗共有を行う。
* 内容: 現在のタスク進捗、成功したフェーズ、次に実行すべきアクションの記録。
--------------------------------------------------------------------------------
4. 主要ツールの比較分析
自律型エージェントと従来のGUI型ツールでは、その活用シーンと管理コストが異なる。
評価項目 Claude Code / Antigravity GUI型Copilot (Cursor等)
自律性レベル 完全自律型(エンドツーエンドで完結) 開発者主導(人間が差分を確認・承認)
主なインターフェース ターミナル / エージェントプラットフォーム VS CodeフォークのIDE
コンテキスト管理 3層アーキテクチャによる厳格な階層化 .cursorrules等による人間主導の制御
メンテナンス負荷 高い(継続的なリファクタリングが必要) 中程度(人間が介在するため)
期待されるROI 圧倒的(1週間で大規模API構築が可能) 高い(個人の生産性向上に寄与)
--------------------------------------------------------------------------------
5. 結論と提言
自律型AIコーディングエージェントの導入は、適切に運用されれば「4倍の生産性向上」という劇的な投資対効果(ROI)をもたらす。しかし、その恩恵を享受するためには、以下のエンジニアリング規律が不可欠である。
1. 「関心の分離」の徹底: 指示セットを物理的に分離し、AIの認知的負荷を最小化すること。
2. 継続的なメンテナンス: プロジェクトの進化(スタック変更等)に合わせて、コンテキストファイルをコードと同じ粒度で更新し続けること。
3. 検証可能な指示設計: 曖昧な動詞を排除し、観測可能でユニークなアクションへとプロンプトを具体化すること。
AIコーディングの成否は、モデルの推論能力そのもの以上に、人間がいかに戦略的に「コンテキストアーキテクチャ」を設計・保守できるかにかかっている。