長いセッションを動かしていると、いずれこんな瞬間が来ます。

1時間後（または翌日）に戻ってきて、単純な問いに答えられません。

何が変わった？

トランスクリプトは長い。

ツール呼び出しはあちこちに散らばっている。

そしてスマホだと、スクロールそのものが失敗の原因になります。

だから「全部読もう」とするのはやめましょう。

代わりに、差分とツールのタイムラインを中心に小さなレビューループを作ります。

このガイドがそのループです。

要点

1. トランスクリプト全体を読み直さないこと。「何が変わったか」がわかる画面から始めます:
   • 変更されたファイル
   • 差分
   • ツール呼び出し
2. ツールが対応していれば、Claude Code/Codex/OpenCode のツール呼び出しを統一して表示するツールのタイムラインを使います。
3. ターン終了時のループを使います:
   • ツールのタイムラインの行をざっと見る
   • 差分にジャンプする
   • 決める: 残す / 戻す / 分割する
4. Happier はモバイルでこれをしやすくする選択肢の1つです。トランスクリプトでツール呼び出しを専用の表示（カードまたはアクティビティフィード）で描画し、タップするとファイル/差分の画面に直接移動できます。

課題

避けたいのは作業ではありません。

終わりのないレビューです。

「何が変わったか」をすぐに見られないと、次のどちらかになります。

• レビューしていない変更を信じる
• コンテキストを導き直すのに時間を無駄にする

レビューループには終わりが必要です。

よくある方法とトレードオフ

• トランスクリプトを上から下まで読む: 短い実行なら問題ありませんが、長い実行にはまったく向きません。
• git diff だけを見る: 良い方法ですが、変更がなぜ起きたかを見落とします。
• モデルに要約を頼む: 役立ちますが、それでも本物の差分は見たいものです。

Happier を初めて使う場合

Happier を初めて見る方へ。Happier はコーディングセッション向けのオープンソースのコンパニオンアプリ（モバイル/Web/デスクトップ）です。

このガイドで関係するのは、UI のレビューループです。

• ツール呼び出しはタイムラインの行（またはツールカード）として表示される
• タイムラインの行をタップすると詳細にジャンプできる
• ツール呼び出しから差分/ファイルに直接移動できる

セットアップ:

• スマホから Happier を使う方法
• GitHub: https://github.com/happier-dev/happier
• インストール/ダウンロード: https://github.com/happier-dev/happier#how-it-works
• Discord（コミュニティとサポート）: https://discord.gg/W6Pb8KuHfg

動くレビューループ

2分版（スマホ）

スマホでは「完全なレビュー」をしようとしないこと。

範囲を決めて1回だけ見ます。

1. ツールのタイムラインの行をざっと見る。
2. リスクが高そうな差分を1つ開く。
3. 決める: 残す / 戻す / 要約を頼む。

そこでやめます。

10分版（キーボード）

キーボードの前に戻ったら、もっと深く見ます。

1. 変更ファイルの一覧を確認する。
2. 差分をまとまりごとに確認する。
3. 変更をコミットに分ける。
4. そのまま残すものとやり直すものを決める。

このガイドの残りで、どちらの確認も予測しやすくします。

1) ターン終了時の「差分サマリー」ツールを使う（表示されたとき）

Claude Code、Codex、OpenCode のセッションでは、Happier はターンの終わりに直前のターンの差分サマリーツールを表示できます。

表示されていれば、それが情報の多い出発点です。すでに次の範囲に絞られているからです。

• 「直前のターンでどのファイルが変わったか」
• 「エージェントが実際に何を編集したか」

良い既定の手順:

1. 直前のターンの差分サマリーをタップする。
2. まず、リスクが高そうなファイルを1つ開く。
3. 問題なさそうなら続ける。
4. おかしければ止まって、ファイルごとの理由を求める（またはそのファイルだけ戻す）。

2) バージョン管理から直前のターンを確認する（「本物の差分」の画面）

ざっと見るだけでなくきちんとレビューしたいなら、バージョン管理（Source Control）に移動します。

デスクトップ/横幅の広いレイアウトでは:

1. セッションを開く。
2. 右サイドバー → バージョン管理（Source Control）を開く。
3. 変更ファイルの一覧で、気になるファイルを開く。
4. 差分を確認する。

変えてほしい点が見つかったけれど、チャットで指示を書き直したくないなら、差分に直接行単位のレビューコメントを追加します。

コメントを実行に移す準備ができたら:

• コンポーザーの レビューコメント（N）（Review comments (N)）チップをタップする
• 必要ならコンテキストを1文添える（「これを適用してテストを再実行して」）
• 送信する

曖昧なやり取りではなく、「まさにこの変更を適用して」という構造化されたメッセージになります。

スマホ/横幅の狭いレイアウトでも流れは同じです。ドッキングしたサイドバーの代わりに全画面表示を使うだけです。

「終わりのないレビュー」にせず「直前のターンだけ」に保つには:

• 直前のターンの差分サマリーツールから始めて、ファイルを1〜3個選び、その同じファイルをバージョン管理で確認する。
• セッションが複数ターン続いているなら、現在コミットされていないものすべてをレビューしようとしない。

3) ファイルタブを「範囲を絞ったナビゲーター」として使う（変更ファイルのみの絞り込み）

ファイル（Files）タブは、Git の意味を考えずに、変更されたものの短い一覧が欲しいときに便利です。

1. セッションを開く。
2. 右サイドバー → ファイル（Files）を開く。
3. 変更ファイルのみの絞り込みをオンにする。
4. 絞り込んだツリーでファイル間を移動する。

本格的な差分レビューでは、最後の「残す/戻す？」の判断は バージョン管理 で行います。ファイルタブは迷わないための手段です。

これで、トランスクリプトをスクロールしなくてよい、すっきりしたレビュー画面が手に入ります。

4) （任意）ツールのタイムラインを「なぜこうなった？」の索引として使う

何かがなぜ変わったのかまだわからないなら、ツールのタイムラインが次の問いに答える補助の画面になります。

• どんなコマンドが実行された？
• インストールやテストの出力は？
• どんな流れでその差分になった？

ただしこれは任意です。ほとんどのレビューは、差分サマリーとバージョン管理の差分で足ります。

5) ツールの詳細をどこまで見るか決める（ざっと / じっくり）

ツールの詳細はズームレンズのように扱います。

• ざっと見るモード: 「どのツールが動いたか」がわかり、リスクのある手順に気づける程度。
• じっくり見るモード: 正確なコマンドや出力が必要なときに、ツール呼び出しを1つ開く。

大事なのは、「ツールの詳細」を延々と読み直す第2のトランスクリプトにしないことです。

6) 長いターンは必ず判断で終える（残す / 戻す / 分割）

ターン終了時のレビューの判断は、必ず次のどれかです。

• すべて残す
• ファイルを1つ戻す
• 変更を2つのコミットに分ける

大事なのは、意図して決めることです。

もう1つ、とても役立つ選択肢があります（特にスマホで）。「その場で直そう」とせず、レビューコメントを残すことです。

ほぼ正しいけれど、ピンポイントの変更をいくつか入れたいなら、次のほうが速いことがよくあります。

1. 差分に直接、行単位のレビューコメントをいくつか追加する
2. レビューコメント（N） チップで、1つの構造化されたメッセージとして送る

エージェントには、気にしていた正確な行に紐づいた、変更すべき点の文字どおりのチェックリストが渡ります。

7) 使い回せる「何が変わった？」チェックリスト

チェックリストを1つだけ覚えるなら、これにしましょう。

• どのファイルが変わった？
• 設定/認証/マイグレーションに触れた？
• テストは実行された？
• 依存関係は変わった？
• コミットすべきでない生成物はある？

8) 適切な種類の要約を求める（差分が大きすぎるとき）

差分が大きすぎてスマホでレビューできないなら、「要約して」とは頼まないこと。

構造化されたレビューの手がかりを求めます。

• 「変更したファイルとその理由を、それぞれ1文ですべて挙げて。」
• 「機械的な変更と概念的な変更はどれ？」
• 「ビルドを壊さずに戻せる変更はどれ？」

次にキーボードでレビューするときが、ずっと速くなります。

便利なワークフロー: インラインのレビューコメント → 1つの構造化された「この変更を適用して」メッセージ

スマホでレビューするとき、または何を正確に変えるべきかを明示したいときに便利です。

「差分を直して」のような曖昧なメッセージを送る代わりに、差分/ファイルに直接行単位のレビューコメントを残し、それを1つの構造化されたメッセージとしてエージェントに送れます。

大まかな流れ:

1. 設定（Settings）→ 機能（Features） で ファイルレビューコメント（File review comments）を有効にする（実験的）。
2. 差分を開く（バージョン管理 または任意の差分画面から）。
3. 変えてほしい正確な行に、レビューコメントをいくつか追加する。
4. コンポーザーの レビューコメント チップ（Review comments (N) と表示）をタップし、必要なら1文添えて送信する。

エージェントは、ファイルパス、行のアンカー、抜粋を含む構造化された「Review comments:」ブロックを受け取ります。そのため、関係ないコードを書き直さず、ピンポイントで変更を適用する可能性がずっと高くなります。

「GitHub の PR レビューコメントを、セッションの中で使う」ように感じたなら、まさにそれが狙いです。

トラブルシューティング

何が変わったのかわからない

• ツールのタイムラインから始める
• 次に差分にジャンプする
• 差分が使えなければ、ファイルごとの一覧と理由を求める

タイムラインがうるさい

ざっと見るモード（コンパクト）に切り替えて、次を探します。

• 編集/書き込みのツール
• Git のツール
• インストール

リスクのある変更を見落としていないか心配

「リスクフィルター」で確認します。

• マイグレーション
• 認証
• パッケージマネージャーのファイル
• CI の設定

ほかを全部無視しても、これらはレビューしましょう。

よくある質問

毎ターンレビューすべきですか？

毎ターンではありません。

ただ、ターンで意味のあるファイル変更があったなら、少なくとも2分版はやりましょう。

レビューで陥りがちな大きな間違いは？

レビューを終わりのないものにすることです。

差分サマリーのワークフローの目的は、レビューに始まりと終わりを作ることです。

関連ガイド

• スマホからコードをコミットする方法
• スマホから差分（diff）をレビューする方法