Entire CLIで会話ログを共有する前に。記録・確認・伏せ字設定の手順

Entire CLIでAIとの会話を共有するなら、最初はチェックポイントの自動pushを止め、手元で1件作って全文を読もう。記録にはプロンプトや回答だけでなく、ツールが読み取ったファイルの内容なども入り得る。秘密情報を伏せる機能はあるが、画像に写った文字を読み取って隠す機能はない。v0.11.4の記録範囲と保護の説明（英語）

この記事は、GitとAIコーディングツールを使っていて、変更の経緯をチームに残したい人向けだ。2026年10月12日時点の最新安定版v0.11.4と公開資料を照合した。編集部によるインストール、記録、共有の実行テストではない。v0.11.4の公開情報（英語）

まず1件を手元に記録する

Entireは、AIエージェントとの作業をGitのコミットに結び付けるツールだ。一連の会話が「セッション」、コミットとその背景をたどるための記録が「チェックポイント」に当たる。後から「何を頼み、どのファイルを読み、なぜこの変更になったか」を確認できる。

動画：Entire「Introducing Checkpoints」（2026年2月10日、英語）。コミットから会話をたどる仕組みの公式デモ。公開当時の画面のため、現在のコマンドと保存方式は以下の手順を参照。YouTubeで見る

導入先は、機密情報のない練習用リポジトリから

必要なのはGit、対応するAIエージェント、Entire CLIだ。macOS・Linux・Windowsに対応する。CLIが未導入なら公式インストール手順（英語）でOS別のstable版を選ぶ。会社のリポジトリでは、会話の保存と共有が認められているかも先に確認しておきたい。

インストール後、機密情報や過去の会話を含まない、今回専用のGitリポジトリを用意する。この記事の操作範囲は、ブランチ1本・会話1件・子エージェントなし。既存の業務リポジトリの送信を再開する手順ではない。リポジトリのルートで次を実行する。

entire version
entire enable
entire configure --local --skip-push-sessions
entire status --detailed

entire enableでは利用するエージェントを選ぶ。Gitとエージェントのフック、つまり作業の節目でEntireを呼び出す設定が入る。過去の会話の取り込みを聞かれても、今回は新しい1件で試すため選ばない。続く--skip-push-sessionsは、チェックポイントを自動で外部へ送らない設定だ。自分のクローン用の.entire/settings.local.jsonへpush_sessions: falseが書かれる。コード本体のgit pushや、AIサービス本体への通信を止める設定ではない。有効化の流れ（英語）、チェックポイントを手元に保つ設定（英語）

設定ができたら、同じリポジトリで新しいエージェントの会話を始め、「hello-entire.mdを作り、練習用の記録であることを1文で書いて」と頼む。顧客名、社内資料、実際の鍵や個人情報は使わない。

出来上がったファイルを読み、狙いどおりなら、そのファイルだけをコミットする。

git add hello-entire.md
git commit -m "Add first Entire checkpoint"
entire checkpoint list

コミット時にセッションとの関連付けを聞かれたら、今回分を許可する。最初から今後すべての関連付けを承認せず、1件の中身を見てから運用を決めればよい。最初のチェックポイントを作る手順（英語）

コミットの差分と、保存された会話データを並べて読む

一覧で対象のIDを確認し、次のCHECKPOINT_IDをそのIDに置き換える。

git show --stat HEAD
git show HEAD -- hello-entire.md
entire checkpoint explain CHECKPOINT_ID --full
entire checkpoint explain CHECKPOINT_ID --raw-transcript

前の二つでコードの変更を、--fullで会話の流れを読む。ただし、名前に「full」とあっても保存データの全文ではない。v0.11.4では、ファイルを読む操作はパスだけに整形され、ツールが返した本文などは省かれる。共有前には、最後の--raw-transcriptで保存されたJSONL形式のログも必ず確認する。外部モデルに要約を依頼する--generateは、ここでは使わない。表示コマンドの公式手順（英語）、v0.11.4の整形処理（英語）

読む順番は「自分の指示→ツールの入力と出力→AIの回答→変更ファイル」。例えば、練習用ファイルだけを変えたつもりでも、AIが別ファイルを読んでいれば、その内容が会話側に残る可能性がある。差分に出ていない情報も共有対象になる、という点をここで確かめよう。

なお、複数の会話を同じチェックポイントに含めると、セッション番号を省いた表示は最新の1件になる。実運用では、まずentire checkpoint explain CHECKPOINT_ID --jsonでsessionsとtasksを調べる。このJSONは一覧用の情報で、会話本文ではない。各sessions[].indexを指定した--raw-transcript --session-index 0などの表示と、各tasks[].tool_use_idを指定した--transcript --task TOOL_USE_IDの表示が別々に必要になる。エラーや未保存のログがあれば、「全部確認できた」と判断せず、送信を止めたまま原因を調べる。セッション・子作業の確認コマンド（英語）

伏せたい文字と画像は、記録前に扱いを決める

図を拡大して読む

図の中は縦・横にスクロールできます。

図を別タブで開く →

文字列の検出は設定や保存箇所により異なり、画像内の文字は解析されない。この図はv0.11.4の公式仕様を基に、確認範囲を整理したものだ。

秘密の鍵などの検出と、個人情報の検出は設定が分かれている。通常の秘密情報の検出は有効だが、PII、つまりメールアドレスや電話番号などの個人情報を伏せる追加処理は初期状態では無効だ。

自分の環境でPII処理を使う場合は、既存の.entire/settings.local.jsonを丸ごと置き換えず、次の項目を追加・統合する。最初に設定したstrategy_options.push_sessions: falseも残す。

{
  "redaction": {
    "pii": {
      "enabled": true
    }
  }
}

日本語の顧客名や社内の呼び名など、組み込みの処理で扱えない会話中の文字列には追加ルールを使う。ただし、ファイル名・パス・IDなどの構造化された情報は、この文字列検出の対象外だ。名前をファイル名へ入れないことも大切になる。例えば、説明用の架空名SAMPLE-CUSTOMER-ALPHAを残したくないなら、同じredactionの下にcustom_redactionsを加える。これは設定例であり、個人情報全般を検出するルールではない。

{
  "redaction": {
    "pii": {
      "enabled": true
    },
    "custom_redactions": {
      "sample_customer": "SAMPLE-CUSTOMER-ALPHA"
    }
  }
}

追加ルールはGoのRE2形式の正規表現で書く。記号を含む実際の名称ではエスケープも必要になる。設定後は架空の文字列を使った新しい記録で置換結果を読み、.entire/logs/entire.logにルールのエラーがないか確認する。不正なルールは読み飛ばされるため、JSONを保存できただけでは確認は終わらない。追加・変更した設定が、すでに保存されたチェックポイントを自動で書き換えるわけではない。過去に共有した記録の回収まで、この設定で済んだと考えないようにしたい。ルールと確認方法（英語）

電話番号は、日本向けに自動対応すると考えない

GitHubではjasonmx氏が2026年8月6日、CLI 0.9.0・macOS・Claude Codeで、PII処理を有効にしても英国などの例示用電話番号が残ったと、保存されたデータを読んだ結果を報告している。本人の再現報告であり、本稿の実測ではない。報告と実行条件（英語）

v0.11.4の文書も、組み込みの電話番号処理は北米のNANP形式に限ると説明している。phone: trueだけで日本の番号まで伏せられると判断せず、そもそも会話へ入れないか、組織で確認した追加ルールを使おう。住所の処理はPII全体を有効にするだけではオンにならず、個別に有効化が必要だ。有効にしても米国の番地を中心とした処理で、住所全体が消える保証はない。v0.11.4のPIIの制約（英語）

画像は、貼る前の処理が必要

スクリーンショットの中の氏名や鍵をEntireが見つけて隠すことはない。記録のされ方はエージェントによって違い、Claude Codeでは画像がそのまま残る。Codexでは初期設定で画像データが失われる場合があるが、これは秘匿用の保護ではない。画像をassets/へ分けるredaction.externalize_imagesを有効にすると、対応する画像は加工されずに保存される。画像に対する動作（英語）

操作画面をAIに見せたいときは、テスト用アカウントを使い、不要な領域を除き、秘密情報のない画像を用意してから渡す。全文表示だけで画像の中身まで確認したことにはならないため、記録に画像が含まれる会話は元の画像も確認する。

共有先を選び、相手が見える範囲を確かめる

Entireを使う目的は、コードの背景を次の作業に生かすことだ。SUDESH CHANDRA氏は2026年9月6日のX投稿で、Bengaluru Tech Weekの開発イベント中にチェックポイントを開き、保存された意図をAIに読み直させて修正したと報告している。イベントでの一例だが、成果物だけでなく依頼の経緯を残す使い方が分かる。本人の投稿（英語）

動画：Entire「Why is our code like this? Agentic Search on Entire」（2026年9月3日、英語）。保存したコードと会話を探す公式デモ。秘密情報を伏せる処理の実演ではない。YouTubeで見る

共有前には、次の三つから保存先を選ぶ。

• 自分だけで振り返る：push_sessions: falseのまま手元に保つ
• コードと会話を同じメンバーへ渡す：そのメンバーが読めるリポジトリにチェックポイントを送る
• コードを公開し、会話は社内に残す：チェックポイント用に別の非公開リポジトリを用意する

新しい保存方式のrefs/entire/checkpoints/…は、通常のブランチ一覧に見えにくくても秘密の領域ではない。コードと同じ公開リポジトリへ送れば、チェックポイントも第三者が読める。保存方式と閲覧範囲（英語）

別の保存先を使う場合は、コードのリポジトリと同じ所有者・組織に空の非公開リポジトリを作り、権限を確認する。そのうえで、OWNER/PRIVATE_CHECKPOINT_REPOを実際の名前へ置き換えて設定する。

entire configure --checkpoint-remote github:OWNER/PRIVATE_CHECKPOINT_REPO
entire status --detailed

この設定はチームで共有する.entire/settings.jsonへ書かれる。設定ファイルを共有する場合も、保存先名と対象メンバーを確かめる。なお、チェックポイントの同期が失敗してもコードのpushは成功することがある。コードが届いたことと、会話が届いたことを別々に確認しよう。別リポジトリへ保存する手順（英語）

自動pushを戻すのは、中身と送信先を確認した後

今回の専用リポジトリで、この練習中に作成したすべてのチェックポイントをrawで読み、送信待ちの件数・送信先と照合できたら、ローカル設定のstrategy_options.push_sessionsをtrueへ変更する。entire status --detailedで宛先と送信待ちの件数を確かめ、通常のGit操作へ戻る。再開の設定（英語）

既存のリポジトリへこの手順をそのまま当てはめてはいけない。entire checkpoint listは現在のブランチの一覧だが、v0.11.4のgit-refs方式ではpush時にリポジトリ共通の送信待ちを処理する。別ブランチの未送信分まで送られる可能性がある。送信待ち全体の中身と権限を確認できない場合は、push_sessions: falseを保ち、管理者と確認してから再開しよう。一覧の範囲（英語）、送信待ちの処理（英語）

entire.ioで確認する場合は、対象コミットのチェックポイントを開き、セッション一覧から会話を選ぶ。タイムラインでプロンプト、回答、展開可能なツール呼び出しを読み、必要な箇所で表示を絞る。別のメンバーへリンクを渡す前に、相手の閲覧権限も確かめたい。Web画面での見方（英語）

最初の運用確認は、「コードの差分を読める」「それを生んだ会話を読める」「伏せたい内容が残っていない」「想定した相手だけが読める」の4点でよい。ここまでを練習用の1件で確かめてから、実際のチーム作業へ広げよう。