Gemini CLI ↔ KUDO-Vault Integration Test 結果¶
検証目的¶
Phase 2-A で配置した ~/KUDO-Vault/GEMINI.md が Gemini CLI から正しく階層メモリとしてロードされ、
GEMINI.md → CLAUDE.md（cross-reference 経由）→ memory/decisions/ ADR の参照経路が end-to-end で
動作することを実機で確認する。
前提¶
~/KUDO-Vault/GEMINI.mdv1.0 配置済（commita0c051e、push 済）~/.gemini/trustedFolders.jsonに/users/kudotakuma=TRUST_FOLDER登録済（macOS case-insensitive で~/KUDO-Vaultも再帰的 trusted）- Gemini CLI 0.42.0 / OAuth 認証完了済
実行コマンド¶
cd ~/KUDO-Vault && gemini --approval-mode plan -p "あなたはこの作業ディレクトリ (~/KUDO-Vault) に配置された GEMINI.md および CLAUDE.md を必ず読んだ上で回答してください。次の3つを順番に答えてください：(1) GEMINI.md (本ファイル) と CLAUDE.md の関係を1〜2行で説明 (2) GEMINI.md §1 が CLAUDE.md のどのセクションに cross-reference しているか3つだけ列挙 (3) memory/decisions/2026-05-22-stage-2-phase1-complete.md を読んで、Stage 2 Phase 1 の完遂状況を3〜5行で要約。日本語で簡潔に。"
Gemini CLI 応答（verbatim）¶
Warning: 256-color support not detected. Using a terminal with at least 256-color support is recommended for a better visual experience.
Ripgrep is not available. Falling back to GrepTool.
(1) **GEMINI.md と CLAUDE.md の関係**
CLAUDE.md はVault全体の構造やルールの基本となる正本（SSOT）であり、GEMINI.md はそれに並列する上位SSOTとして、Gemini CLI固有の差分や運用手順のみを担う補完関係にあります。
(2) **GEMINI.md §1 から CLAUDE.md への参照（3つ）**
- ボルト構造 → [[CLAUDE#2. ボルト構造]]
- 命名規則 → [[CLAUDE#3. ファイル命名規則]]
- YAML frontmatter → [[CLAUDE#4. YAML frontmatter 規則]]
(3) **Stage 2 Phase 1 の完遂状況**
WorkFlowy単独運用からVault優先の「dual-write（並行書込）体制」への移行作業（Phase 1）が全て完了し、正式にクローズされました。過去ログのVault取込や夜間バッチの改訂が完了し、新規ログが両方に書き込まれる実機検証も成功しています。今後はこの並行運用を1〜2週間観察した上で、WorkFlowyを完全廃止するPhase 2へ進むかの判定が行われます。
Shell cwd was reset to /Users/kudotakuma/Library/CloudStorage/GoogleDrive-kudotakuma421@gmail.com/マイドライブ/working
検証項目と結果¶
| # | 検証項目 | 期待 | 実際 | 判定 |
|---|---|---|---|---|
| 1 | GEMINI.md が階層メモリにロードされる | 起動時に ~/KUDO-Vault/GEMINI.md を自動読込 |
(1) で GEMINI.md の §1 内容を正しく要約 | ✅ PASS |
| 2 | GEMINI.md の cross-reference が認識される | §1 リストの wikilink を Gemini が解釈 | (2) で [[CLAUDE#2. ボルト構造]] 等を verbatim で列挙 | ✅ PASS |
| 3 | CLAUDE.md が並列でロードされる | 階層メモリで両方読込 | (1) で「Vault全体の構造やルールの基本となる正本（SSOT）」と CLAUDE.md の役割を正確に把握 | ✅ PASS |
| 4 | memory/decisions/ 配下が読込可能 | 指定パスの ADR を読める | (3) で 2026-05-22-stage-2-phase1-complete.md の内容を要約 |
✅ PASS |
| 5 | ADR 内容に幻覚がない | 原文と完全整合 | 下記「原文照合」の通り全要素一致 | ✅ PASS |
| 6 | --approval-mode plan が機能する |
読み取り専用で書込なし | Vault に書込なし。コミット差分も発生せず | ✅ PASS |
原文照合（Gemini 応答 vs ADR 原文）¶
| Gemini 応答 | ADR 原文（line） | 整合 |
|---|---|---|
| 「WorkFlowy単独運用からVault優先のdual-write体制への移行」 | line 22「WorkFlowy 単独運用(Phase 0)から dual-write + Vault 優先化(Phase 1)」 | ✅ |
| 「過去ログのVault取込」 | line 41「19 件 を Vault logs/2026/04/ + logs/2026/05/ に複製完了」 | ✅ |
| 「夜間バッチの改訂が完了」 | line 27「Cowork 夜間バッチの prompt を dual-write 対応版に書き換え」 | ✅ |
| 「新規ログが両方に書き込まれる実機検証も成功」 | line 8「dual-write 期間開始」 | ✅ |
| 「1〜2週間観察した上で、WorkFlowyを完全廃止するPhase 2へ進むかの判定」 | line 33「Phase 2(WorkFlowy 完全廃止)判定は dual-write 期間 1-2 週間後の運用観察を経て実施」 | ✅ |
→ 幻覚なし。Gemini は ADR を実際に読んで要約している。
重要な観察¶
O-1：GEMINI.md と CLAUDE.md の両方が自動ロードされた¶
Gemini CLI は cd ~/KUDO-Vault && gemini ... で 両ファイルを階層メモリとして同時にロードした。
(1)/(2)/(3) の回答内容から、両ファイルへのアクセスが確認できる。
Phase 1 §4「GEMINI.md と CLAUDE.md は階層メモリで並走」の仮説が実証された。
O-2：wikilink が verbatim で保持される¶
(2) の応答で [[CLAUDE#2. ボルト構造]] 形式の wikilink が文字通り再現された。
これは Gemini が「リンクを解釈して別ファイルに飛ぶ」のではなく、GEMINI.md §1 の本文をそのまま返していることを意味する。
→ CLAUDE.md の本体内容は (3) の応答時点で別途読まれた（おそらく Gemini が ADR を読む過程で参照）。
→ 設計通りの挙動：GEMINI.md は索引役、CLAUDE.md は実体。
O-3：headless モードでも完全動作¶
Phase 1 §11.2 の懸念「初回 headless で OAuth 失敗の可能性」は再現せず。
既に OAuth 確立済のため、-p フラグで一発実行できた。
O-4：再現される運用ノイズ（GEMINI.md §6 に既記載）¶
Warning: 256-color support not detected.← Terminal の TERM 変数依存Ripgrep is not available. Falling back to GrepTool.← rg 未導入Shell cwd was reset to ...← Gemini CLI の cwd 仕様
3 件とも GEMINI.md §6「既知の運用ノイズ・ハマりポイント」テーブルに既記載。実機の挙動が GEMINI.md と一致。
O-5：応答時間¶
体感 ~30 秒程度で完了。2M context モデルにも関わらず実用的なレスポンス時間。
Phase 2 完遂判定¶
| Phase | 内容 | 状態 |
|---|---|---|
| Phase 2-A | GEMINI.md 起草・配置 | ✅ 完了（commit a0c051e） |
| Phase 2-B | Vault git commit + push | ✅ 完了（origin/master 85da1f0..a0c051e） |
| Phase 2-C | trustedFolders.json への Vault 登録 | ✅ 完了（既存登録が再帰的に有効、追加変更不要） |
| Phase 2-D | 実機検証 | ✅ 完了（本レポート） |
Phase 3 への申し送り¶
実機検証で得た知見を kudo-cowork-code-handoff-protocol v1.15 §16-3 に反映する際の論点：
- 「2M context での Vault 全読」の判定基準
- 単一 ADR の要約レベルでは Claude Code でも十分（Vault 内 file read で同等）
- 複数 ADR を横断する分析（例：Stage 1 系列 vs Stage 2 系列の対比、insights/ 配下 N 件の傾向分析）で Gemini の 2M context が決定的に効く
-
判定基準案：「対象ファイル合計が ~100K tokens を超える、または PARA 配下複数フォルダにまたがる」なら Gemini
-
wikilink 解釈の差分（O-2 起点）
- Gemini は wikilink を索引として保持する（自動展開しない）
- Claude Code は wikilink を読まずにファイル内容を要求した時点で展開
-
→ クロスリンクが多い分析では、Gemini に「リンク先も読んで」と明示する指示テンプレートが必要
-
Phase 4（オプション）への布石
gemini skills link ~/KUDO-Vault/.claude/skills/kudo/で Vault スキルを Gemini からも読めるか検証する余地- GEMINI.md §8 の「★仮説」項目を実証する Phase
結論¶
Stage 3-A Phase 2 は完全成功。GEMINI.md は階層メモリとして機能し、CLAUDE.md cross-reference 経由で ADR まで辿れることを実機で確認した。Stage 2 §16-3 環境非対称性見落とし（Entry #20）と同種の 「思い込みで起草」リスクは再発せず、Phase 1 調査 → Phase 2-A 起草 → Phase 2-D 実機検証の 3 段ワークフローが正しく機能した。
Phase 3（kudo-cowork-code-handoff-protocol v1.15 拡張）の指示書を待機。