🧰 Codex/AI開発術 2026.07.26 更新

AIコーディングの引継ぎメモ|長いセッションを安全に再開する型

Codexなどを使う長い開発作業を中断するときに、実行済み・未実行・変更ファイル・検証結果を混ぜず、次のセッションへ安全に渡すMarkdownテンプレートを紹介します。

AIコーディングの引継ぎで大切なのは、会話を丸ごと保存することではありません。次の担当が「どこから確認し、何を変え、何をもって完了とするか」を判断できる状態を残すことです。この記事では、実行済みと予定を混ぜずに、次のセッションへ安全に渡すMarkdownの型を紹介します。

引継ぎメモが必要になる理由

引継ぎメモが要るのは、作業を翌日に回すとき、別のセッションへ移すとき、担当を替えるとき、エラー調査の途中で止めるときです。共通するのは「今の頭の中が、次の再開時には消えている」ことです。

Codexでは、会話が続くほど入力も長くなります。OpenAIはCodexのエージェントループの解説で、新しいメッセージを送るたびに過去のメッセージやツール実行結果が丸ごとプロンプトへ入り、上限に近づくと会話を自動で圧縮して処理を続ける、と説明しています。

ただし、この圧縮は「会話を続けるための仕組み」です。長い電話の録音を短い要約に置き換えるようなもので、要約からあなたの机の上(=作業ツリーの実際の状態)までは復元できません。完了条件、未検証の箇所、ローカルの変更は、メモと実ファイルの側に残す必要があります。なお、圧縮のしきい値などの内部動作は製品の実装として変わることがあります。細部は公開時点の公式案内で確認してください。また、これはCodexについての説明であり、すべてのAIコーディング製品が同じ動作をするとは限りません。

長い指示そのものを整理したい場合は、AIへの指示が長すぎるときの整理法も先に読むと、引継ぎへ残す情報を減らせます。Codexが止まったように見える場合は、引継ぎを書く前にCodexが途中で止まる原因と対処法で待機・失敗・権限確認を切り分けてください。

引継ぎメモに残す7項目

引継ぎメモに書くのは、次の7項目です。

  1. 引継ぎ日時と基準位置(作業ディレクトリ・ブランチ・基準コミット)
  2. 目的と完了条件
  3. 実行済みの作業と、その確認結果
  4. 未実行の作業と、止めた理由
  5. 変更したファイルと、触ってはいけない範囲
  6. 検証に使ったコマンドと結果
  7. 再開時の最初の一手と、残っているリスク

以前の5項目の型に、1番の「基準位置」を加えるのがポイントです。基準位置がないと、メモを書いたあとに何が変わったのかを、再開側が見分けられません。

記入済みの短い例を見ると、粒度がつかめます。

# 引継ぎメモ 2026-07-26 21:00
- 作業ディレクトリ: D:\repo\example-app
- ブランチ: main / 基準コミット: a1b2c3d

## 目的と完了条件
- 目的: ログイン画面のエラー文言を修正する
- 完了条件: `npm test -- login` が終了コード0

## 実行済み
- `src/pages/Login.tsx` の文言を修正
- `npm test -- login` を実行し、終了コード0

## 未実行
- 全体テスト(実行時間が長く、時間切れのため)

## ファイル
- 変更済み: src/pages/Login.tsx
- 変更禁止: src/config/ 以下

## 再開
- 最初に実行する確認: `git status --short` で変更が1ファイルだけか照合
- 残リスク: 文言変更がスクリーンショットテストに影響する可能性

「いい感じに直す」ではなく、「対象テストが終了コード0になる」のように、観察できる条件へ置き換えます。検討した全案や長いログは貼らず、判断した結論と、再現に必要な証拠だけを残します。

実行済み・未実行・確認不能を混ぜない

最も危険なのは、「対応する」と書いた予定が、対応済みに見えることです。引継ぎでは、状態を3つに分けます。

状態書く内容
実行済み操作、対象、観察できた結果npm test -- example を実行し、終了コード0
未実行次の操作と、止めた理由全体テストは時間が足りず未実行
確認不能確認に足りない条件外部サービスの認証が必要なため未確認

「対応済み」「テスト済み」だけでは、次の担当は再現できません。「何のコマンドを、どのファイルに、結果はどうだったか」をセットにします。復旧時間や失敗件数のような数値も、実測のログがないものは書きません。未実行のコマンドを、実行済みの欄へ先回りして書くのは禁止です。

停止前にGitで現在地を固定する

作業を止める直前に、読み取り中心(=何も書き換えない)のコマンドで現在地を確認し、出力の要点をメモへ写します。

git rev-parse --show-toplevel
git status --short
git diff
git diff --cached
git log -1 --oneline

それぞれの役割は分かれています。

コマンド何が分かるか注意
git rev-parse --show-toplevel作業ツリー最上位の絶対パス似た名前の別リポジトリとの取り違えを防ぐ
git status --short変更・ステージ・未追跡の一覧未追跡ファイルは ?? と表示される
git diff未ステージの差分ステージ済みの差分は含まれない
git diff --cachedステージ済みの差分比較の基準は省略すると通常HEAD
git log -1 --oneline基準コミットのIDと件名-1 で先頭1件だけに絞る

Git公式の git-status の説明にあるとおり、git status はHEADとインデックス(=ステージ)、インデックスと作業ツリーの差、未追跡ファイルをまとめて表示します。一方、git-diff の説明では、引数なしの git diff は作業ツリーとインデックスの差だけを表示し、ステージ済みの内容は git diff --cached で別に確認する、と整理されています。つまり git diff だけでは全部の変更を確認できません。3つを役割別に使います。

基準位置の記録には、git rev-parse --show-toplevelgit log -1 --onelineを使います。前者は作業ツリー最上位のパスを既定で絶対パスとして表示し、後者は短縮コミットIDと件名を1行で出します。この2行がメモにあるだけで、「別のフォルダで再開してしまった」「基準のコミットが違った」という事故に早く気づけます。

コマンド出力や引継ぎメモへ、秘密情報・トークン・個人情報をそのまま貼らないでください。共有が必要なら値を伏せ、何を伏せたかだけ記録します。ログを共有する前の確認は、AI開発で秘密を漏らさないための確認リストも参考にしてください。

引継ぎメモと恒久ルールを分ける

引継ぎメモには「今回だけの情報」を書きます。毎回守るルールは、別の置き場に分けます。

Codexには、プロジェクトの恒久ルールを毎回読み込ませる仕組みがあります。AGENTS.mdの公式ガイドによると、Codexは作業前にAGENTS.mdを読み、グローバル→プロジェクト→現在の作業ディレクトリの順に指示を重ねます。近いディレクトリの指示ほど後から結合され、既定の合計上限は32 KiBです(上限などの仕様は公開時点の公式案内で確認してください)。

役割分担はこうなります。

  • AGENTS.mdなどのプロジェクト規則: 毎回守るテスト手順、変更禁止の範囲、コーディング規約
  • 引継ぎメモ: 今回の進捗、残件、基準コミット、一時的な危険

同じ規則を毎回のメモへ複写してはいけません。複写すると、規則を直したときに古いコピーが残り、どちらが正しいか分からなくなります。メモには「規約の正本は AGENTS.md」のようにパスだけ示します。

引継ぎメモは永続的な仕様書でもありません。完了条件を満たし、残件がIssueなどへ移った時点で役目を終えます。対象ブランチ、依存関係、設計方針がメモ作成時から変わった場合も失効です。古いメモへ継ぎ足さず、「失効日」「失効理由」「後継の記録先」を書いて切り替え、有効な引継ぎを常に1つに保ちます。

安全に再開する5段階

再開直後は、編集せずに照合から始めます。

  1. 作業ディレクトリと対象リポジトリが、メモの基準位置と一致するか確認する
  2. git status --short の結果を、メモの変更ファイル一覧と照合する
  3. メモにある対象ファイルを開き、差分の意図を確認する
  4. 実行済みと書かれた最小の検証(例: 対象テスト1本)を再実行できるか判断する
  5. 未実行の先頭1件だけを、次の作業として固定する

途中で次のどれかに当たったら、追加の編集を止めます。

  • メモと実ファイルの差分が食い違う
  • 基準コミットがメモと違う
  • メモにない、知らない変更がある

このとき、知らない変更を「正しいはず」と決めつけたり、いきなり破棄したりしてはいけません。メモが古いのか、別のセッションが変更を加えたのか、作業ディレクトリを取り違えたのかを先に切り分けます。AIへ再開を依頼するときも、メモ全文のあとに「まず状態確認だけを行い、変更はまだしない」と書くと、古い前提のまま編集が進むのを防ぎやすくなります。

よくある質問

AIとの会話を再開できれば、引継ぎメモは不要ですか

不要にはなりません。会話の圧縮や再開は、会話を続けるための仕組みです。作業ツリーの差分、未検証の箇所、最新の完了条件を保証するものではありません。作業状態の正本は、メモと実ファイルとGitの側に置きます。

git statusとgit diffは両方必要ですか

両方必要です。git status --short は変更・未追跡・ステージ状態の一覧を見る道具で、git diff は未ステージの中身を見る道具です。ステージ済みの中身は git diff --cached で別に確認します。1つのコマンドで全部は確認できません。

AGENTS.mdと引継ぎメモには何を分けて書きますか

毎回守る規約やテスト手順はAGENTS.mdへ、今回だけの進捗・残件・基準コミットは引継ぎメモへ書きます。恒久ルールをメモへ複写せず、正本のパスを参照します。

メモと実際のファイルが食い違うときはどうしますか

追加の編集を始めず、リポジトリ最上位、変更一覧、差分、基準コミットを読み取り専用コマンドで確認します。知らない変更を破棄せず、メモが古いのか、別の作業が加わったのか、フォルダを取り違えたのかを切り分けます。

Gitを使っていない場合はどう引き継ぎますか

対象フォルダ、変更したファイル、変更前後を比べられるバックアップの場所、実行した確認、未検証の箇所を記録します。差分を自動で追えないため、「どのコピーが正本か」を必ず明示します。

まとめ

安全な引継ぎを決めるのは会話の量ではありません。目的、実績、差分、検証、次の一手を再現できるかどうかです。短いメモでも、実行済みと未実行が分かれ、Gitの現在地が固定されていれば、古い前提のまま編集を始める危険を大きく減らせます。次にやることは3つです。

  • 今日の作業を止める前に、この記事の7項目テンプレートをコピーして埋める
  • 停止直前に読み取り専用のGitコマンド(rev-parse / status / diff / diff --cached / log -1)を実行し、要点をメモへ写す
  • 再開したら編集より先に5段階の照合を行い、食い違いがあれば編集を止めて切り分ける

公式一次情報

確認日: 2026-07-26

続き(結論と実データ)はnoteに置いています

ここでは手順のところまで書きました。実際に出た数字、うまくいかなかった条件、そのまま使える設定ファイルは、 note の記事にまとめてあります。

noteで続きを読む Xをフォローする