🤣

【DevFest参加記】Gemini CLIを触って分かった「AIがコード修正に戸惑う理由」

に公開

こんにちは、新卒2年目のはよちゃんです。初投稿になります!

最近参加したハッカソンで初めて GCP(Vertex AI) に触れたのをきっかけに、
勢いそのままに Google Developer Group(GDG)主催の DevFest に参加してきました。

せっかくなので、その流れでブログも書いてみることに。
今回は Gemini CLI まわりを中心に、GPTと一緒にまとめてみました。
(もし内容に誤りがあれば、そっと教えてもらえると助かります!)

🏁 DevFestとは

Google Developer Group(GDG)が世界中で展開する人気技術イベント!

ハンズオンやLTが初学者にも理解できるよう工夫されており、
幅広い分野を横断する超ビッグイベントです。
Google技術に限らず「新ロボット3原則」「デジタル証拠と技術者・法律家の関係性」など、
興味深い登壇が多数ありました。

そして、自分にとって最も印象に残ったのが「Gemini CLI ハンズオン」。
ここで出た“ある質問”が、この記事を書くきっかけになりました。

🎯 なぜこの記事を書いたか

ハンズオン中、こんな質問が出ました。

「Gemini CLIでコード修正中に、手動でファイルを変更するとどうなるんですか?」

講師の方の答えは「エラーになります」。
…が、なぜそうなるのかが気になって、調べていたら1日が溶けました...

調査の過程で、Gemini CLIの構造と動作原理が見えてきたので、
この記事では「Gemini CLIの仕組み」と「本当に手動修正でエラーが起きるのか?」を、
実際の検証結果を交えてまとめます。

🧭 目次

  1. Gemini CLIとは
  2. 生成プロセスの流れ
  3. コアの役割
  4. 会話履歴の管理方法
  5. 総括:手動修正でエラーが起きるのか(挙動確認を含めて)

0. Gemini CLIとは

Gemini CLI は、Google の生成AI「Gemini」をターミナルから直接操作できる開発支援ツールです。
いわば、Gemini Code Assist(IDE版) の “コマンドライン版” にあたります。

📘 公式ドキュメント:
https://developers.google.com/gemini-code-assist/docs/gemini-cli?hl=ja

Gemini Code Assist 全体には以下の利用形態があります:

  • IDE(VS Code / IntelliJ)拡張機能
  • GitHub連携機能
  • Firebase統合機能
  • そして CLI(ターミナル版)

CLIはこれらと並ぶ一つの「実行形態」です。
特徴的なのは、プロジェクト直下に自動生成される設定ファイル Gemini.md の存在です。

# Gemini.md
context:
  include: ["src/", "package.json"]
style:
  tone: "friendly"

このファイルはプロジェクト単位の会話コンテキストを定義し、
Geminiは起動時にカレントディレクトリから最上位のGemini.mdを読み込み、
指示トーンや参照範囲を決定します。

また、CLIは安全のため「上位ディレクトリ」へのアクセスをロックしており、
誤ってプロジェクト外のファイルを操作することはできません。

1. 生成プロセスの流れ

Gemini CLIは単なる「AIチャット」ではなく、
裏では CLI → Core → Gemini API という多層構造で動作しています。

理解のポイントは、「CLIは実際にAIと通信していない」という点です。
実際にGemini APIとやり取りしているのは「コア(Core)」です。

処理ステップ

  1. ユーザーがCLIにプロンプトを入力

  2. CLIがプロンプトを「コア」に送信

  3. コアが以下をまとめてGemini APIへ送る

    • 会話履歴
    • ツール情報(file ops, web fetchなど)
    • 構造化されたプロンプト
  4. Geminiモデルがツール実行を要求(例:検索やファイル操作)

  5. コアが要求を検証・実行し、結果を再送

  6. モデルが最終回答を生成し、CLIへ返す

この流れの中心にいるのが「コア」です。
次章で、その役割を詳しく見ていきます。

2. コアの役割

Gemini CLI の “コア” は、裏方として4つの重要な仕事を担っています。

機能 役割概要
1. Gemini APIインタフェース プロンプト送信/レスポンス受信を安全に実行
2. プロンプト構築 Gemini.md・会話履歴・ツール定義を統合して最適化
3. ツール管理 外部コマンド(file ops, shell等)を登録・実行
4. 状態管理 セッション・会話履歴・文脈の整合性を維持

つまり、コアは「翻訳」と「整合性維持」を行う層です。
CLIの入力を構造化し、Gemini APIが理解できる形式に変換。
さらに過去ログやツール状態を追跡し、矛盾が生じないように履歴を統一します。

💡 この「整合性維持」の仕組みが、次章で紹介する“会話履歴の管理方法”にも深く関わっています。

引用: 公式GitHub – gemini-cli/core

3. 会話履歴の管理方法

Gemini CLIでは、会話履歴がプロジェクト単位でJSON形式に保存されます。

  • 形式: JSON
  • 保存場所: 一時ディレクトリ(getProjectTempDir()が決定)
  • 命名規則: checkpoint-<name>.json
  • 保存方法: 明示的に /chat save コマンドを実行したタイミング

参考: GitHub Discussions #4974

この仕組みを理解していないと、「あれ、セッション消えた?」という現象に遭遇します。
CLIを再起動しても履歴が復元されるのは、このチェックポイントが存在するときだけです。

✅ 実務Tips
長めのセッションでは、/chat save <name> を定期的に実行するのがおすすめ。
保存しないままCLIを落とすと、履歴が揮発する可能性があります。

4. 総括:手動修正でエラーが起きるのか(挙動確認を含めて)

実際に挙動を確認したところ、以前の想定とは一部異なる結果が得られました。
現在(2025年10月時点)のGemini CLIは、より柔軟で自己修復的な動作に進化しています。

🧩 異なる点

実際の動作では、手動修正によって整合性が崩れてもすぐには停止せず、
複数回のエラー検出後に自動的にファイルを再読み込みし、再試行を行うようになっていました。
以下のような出力から、CLIが自己修復的に動作していることが確認できます。

✦ replaceツールが失敗し、「old_stringの出現回数が0」と表示されました。
これは、read_fileで確認できた文字列と実際のファイル内容に差異があるためです。
...
✦ 再度ファイルを読み込み、末尾付近の内容を再取得します。
...
✦ popup.htmlの全内容を確認しました。不適切な文字列は</html>の後に存在します。
✦ 不適切な文字列を除去した内容でpopup.htmlを上書きします。
 ╭──────────────────────────────────────────────────────────────────────╮
 │ ?  WriteFile Writing to src\popup.html ←                             │
 │ Apply this change?                                                   │
 │ ● 1. Yes, allow once                                                 │
 │   2. Yes, allow always                                               │
 │   3. Modify with external editor                                     │
 │   4. No, suggest changes (esc)                                       │
 ╰──────────────────────────────────────────────────────────────────────╯

このように、CLIは
1. エラー検知 → 2. 原因推定 → 3. read_fileによる再同期 → 4. 再試行 → 5. ユーザー確認
という手順を自動的に繰り返すことで、単純なエラーで停止しない構造になっています。

✅ 同じ点

一方で、基本原理としては以前の説明と変わりません。
Gemini CLIは内部で会話履歴とローカルファイルの整合性を前提に動作しており、
修正途中の状態でファイル内容が外部から変わると、履歴との差異を検知します。
この整合性チェックがあるため、意図しない上書きや不一致を防げるという点は同じです。

⚠️ 気を付けること

自己修復が入ったとはいえ、フォールバック処理はあくまで一時的な補正です。
内部的には、履歴とファイル内容を突き合わせて再同期しているだけであり、
会話履歴そのものが確実に保持されるわけではありません。
したがって、挙動として改善された一方で、履歴の明示的な管理を怠ると整合性の破綻が再発する可能性は残っています。

🧩 対策と学び

ここまでの検証を踏まえると、より安定してCLIを扱うために意識すべき点が見えてきます。

  1. Gemini.mdで設定を行う
    → 起動時に常にプロジェクト全体を再スキャンさせ、最新状態を参照可能にする。
  2. 手動修正する場合は一度セッションを閉じる
    /chat save → CLI再起動 → /chat load の順で安全に復帰できる。
  3. 履歴管理を理解して使うとCLIが安定する
    → 仕組みを理解すると、Gemini CLIを「壊れにくいAIコーディング環境」として使える。

✨ まとめ

  • Gemini CLIは、Gemini Code Assistのターミナル版であり、AIによる自動修正やツール実行を行う強力なインターフェース。
  • その中核には「コア」があり、会話履歴とファイル状態の整合性を厳密に管理している。
  • 手動修正によるエラーは、この整合性チェック機構が正しく働いている結果でもある。

💬 感想

  • 初めて巨大なGitHubリポジトリを読み解く貴重な経験になりました。
  • 次は「Gemini CLI × Next.js プロジェクト」で、よりエージェント的な開発補助を検証してみたいと思います。

🔗 参考資料

X

良ければXのフォローもお願いします!!
https://x.com/hayochan_man/

Discussion