通しでやってみる：頼むところから取り込むまで

01 / 22

この章では、小さな作業を1つ、頼むところから取り込むまで通して見ます。流れは5つの段階です。

ここまでの章の言葉が、どこで出てくるかを順に見ます。（第N章）は、その言葉をくわしく説明した章です。章へのリンクは、ページの下のまとめに並べました。

会話では：「Issue を立てて、ブランチを切って、プランモードで計画させて、テストが通ったら PR にして」——この章では、この一言の中身を順に見ていきます。

02 / 22

まず、やることを Issue に書きます。題材は架空の「買い物メモ」のページで、同じ品物を二重に足せてしまう困りごとです。

Issue は、GitHub にやることを書いておく場所です（第11章）。目的・やること・終わりの条件を書いておくと、そのまま AI への頼み方になります（第7章）。

会話では：「Issue #12 に書いておいたので、それをやって」のように、番号で頼めるようになります。

03 / 22

作業フォルダーには、AI への指示ファイル CLAUDE.md を置いてあります。テストのコマンドや、決まりごとが書いてあります。

Claude Code は起動のたびに CLAUDE.md を読むので、同じことを毎回頼まずに済みます（第12章）。Codex や Antigravity CLI では AGENTS.md などです。

会話では：「テストは npm test って CLAUDE.md に書いてあるから、言わなくても通じるよ」

04 / 22

ターミナルに移ります。git status で、まだ記録していない変更が無いことを確かめました。

「nothing to commit, working tree clean」は、最後のコミットから何も変わっていない、という意味です。記録が残っているので、AI の変更がだめでも戻れます（第11章）。

会話では：「AI に触らせる前に、コミット済みか確かめておいて」のように言います。

05 / 22

git switch -c で新しいブランチ（枝）を切ります。名前は CLAUDE.md の決まりどおり、Issue の番号から付けました。

これで main をそのままにして、枝の上で作業できます（第11章）。この操作も AI に頼めますが、ここでは自分で打ちました。

会話では：「ブランチを切ってから任せる」——うまくいかなければ、この枝を使わずに捨てられます。

06 / 22

claude と打って、Claude Code を起動します。いま居るフォルダーが、AI の作業場所になります（第5章・第6章）。

初めてのフォルダーなら、ここで「信頼しますか」と聞かれます（第6章）。答えはフォルダーごとに覚えられるので、前に答えたこのフォルダーでは聞かれません。

会話では：「プロジェクトのフォルダーで claude を起動して」のように言います。

07 / 22

Claude Code の画面です。このとき CLAUDE.md の中身はもう読み込まれていて、AI に送る中身に入っています。

指示ファイルは、コンテキスト（AI が一度に見ている中身）に最初から入ります（第9章）。画面は Claude Code 2.1.301（2026年10月時点）を写したもので、モデルの名前などは省きました。

会話では：「CLAUDE.md、ちゃんと読まれてる？」——/context と打つと確かめられます（第9章）。

08 / 22

Shift + Tab を3回押して plan mode on にします。プランモードの AI は、調べて計画を立てるだけで、書き換えません。

押すたびに auto → manual → accept edits → plan と変わります（第10章）。頼む文の頭に /plan を付けても、その1回だけプランモードで頼めます（第8章）。

会話では：「まずプランモードで計画を出させて」——いくつものファイルを変える作業や、やり方に迷う作業で使います。

09 / 22

入力欄に頼みます。やってほしいこと・条件（テストも足す）・終わりの条件（npm test が通ったら完成）を入れました。

終わりの条件があると、AI は自分で確かめてから「終わった」と言えます。Claude Code の手引きも、テストのような確かめる手段を渡すことを最初に挙げています（第7章）。

会話では：「終わりの条件を決めて頼む」「npm test が通るまでやって」のように使います。

10 / 22

AI はファイルを3つ読んで計画を立て、「Ready to code?」（作り始めてよいか）と聞いてきます。点線のあいだが計画です。

ここまで、ファイルは1つも書き換わっていません。読んだファイルの中身は、コンテキストに積まれます（第9章）。計画がずれていたら、作り始める前のここで直します（第10章）。

会話では：「計画を読んでから承認して」——作り始める前に、向かう方向が合っているかを確かめます。

11 / 22

計画どおりでよいので、2. の「Yes, manually approve edits」を選びます。書き換えを1つずつ確かめる進め方です。

1. は承認して auto モードで進める、3. は直してほしいことを伝える、です。ここでは、書き換えを1つずつ見るために 2. を選びました（第10章）。

会話では：「計画を承認して、manual で進めて」——承認するときに、そのあとの進め方も選びます。

12 / 22

Enter で決めると、AI が書き換えに取りかかり、書き換える前に許可を求めます。+ の行が、足される行です。

「User approved Claude's plan」は、計画を承認した印です。差分では、addItem に「同じ名前の品物があれば、そのまま返す」1行が足されます（第6章・第11章）。

会話では：「差分を見てから Yes して」——頼んでいないところまで変わっていないかも、ここで見ます。

13 / 22

1. Yes で許可すると app.js が書き換わります。続く app.test.js（テストのファイル）も、差分を読んで許可しました。

「Added 1 line」は1行足した、という意味です。実物では、この下にもう一度差分が出ます（図では省いています）。おかしな書き換えなら、No で止めて直し方を伝えます（第6章）。

会話では：「Update の丸が緑になった」は、書き換えが済んだ合図です。

14 / 22

次に AI はテストを動かそうとして、コマンドの前にも許可を求めます。点線のあいだが、これから動かすコマンドです。

npm test は、このプロジェクトのテストを動かすコマンドです。CLAUDE.md に書いておいたものを、AI が使っています。コマンドの許可で何を読むかは第10章で見ました。

会話では：「コマンドを読んでから Yes して」——知らないコマンドなら、何をするのかを AI に聞いてから決めます。

15 / 22

Yes にするとテストが動き、AI が結果を報告します。テストが2つとも通った、という報告です。

テストが落ちていたら、AI は結果を読んで直し、もう一度動かします（エージェントのループ。第4章）。「Ran 1 shell command」の中身は、ctrl+o で詳しい表示に切り替えると見られます。

会話では：「テストの結果を見せて」——終わったという言葉だけでなく、動かした証拠を見ます。

16 / 22

AI の報告で終わりにせず、自分でも確かめます。ページで牛乳をもう一度足して1行のままかを試し、差分も読み直します。

テストが通っても、頼んだとおりかを決めるのは人です（第7章）。/diff で変わったところを見たり、別の AI（サブエージェント）にまっさらな目で見直させたりもできます（第16章）。

会話では：「動作確認までやった？」「サブエージェントに差分を見直させて」のように言います。

17 / 22

ターミナルで「コミットして、PR を作って」と頼みました。AI はコミットを済ませ、プッシュと PR づくりの許可を求めています。

コミットの前にも許可を求められました（図では省略）。gh pr create は PR を作るコマンド、説明の「Closes #12」はマージで Issue #12 を閉じる書き方です（第11章）。

会話では：「コミットして PR を作って」「PR の説明に Closes #12 を入れて」のように頼みます。

18 / 22

Yes で許可すると、GitHub に Pull Request（PR）ができます。説明・変わったファイル・差分が1か所にまとまります。

PR は「この枝の変更を main に取り込んでください」という提案です（第11章）。AI が作った PR は読み直し、気になる点を AI に挙げさせるよう、Claude Code の手引きは勧めています。

会話では：「PR の差分を見てからマージ」「この PR の気になる点を挙げて」のように使います。

19 / 22

確かめ終わったら、main にマージします。説明に書いた「Closes #12」で、Issue #12 が自動で閉じます。

これで1つの作業が終わりです。次の別の作業は、/clear で会話を空にしてから始めると、前の作業の話が混ざりません（第9章）。

会話では：「確かめたのでマージして」「次の作業は /clear してから」のように言います。

20 / 22

ここまでは、指示ファイルのほかは基本の道具だけで進めました。第13〜16章の仕掛けを足すと、同じ流れの決まった場所を、楽に・確実にできます。

Issue を読んで直し PR を作るまでをスキルにして /fix-issue 12 で呼ぶ例が、Claude Code の手引きにあります（第13章）。仕掛けの組み合わせ方は第17章、事故を防ぐしくみは第18章で見ました。

会話では：「この流れ、スキルにしておこう」「チェックはフックで必ず動かす」のように言います。

21 / 22

Codex や Antigravity CLI でも、同じ流れで進められます。指示ファイル・計画・書き換えの前の確認・確かめる手段が、どれにもあります。

名前は少しずつ違います（指示ファイルは Codex が AGENTS.md、Antigravity CLI が AGENTS.md か GEMINI.md）。コミット・ブランチ・PR は Git と GitHub のしくみなので、どのツールで作業しても同じように残ります。

会話では：「Codex でも Antigravity CLI でも、/plan で計画から始められる」

22 / 22

これで、頼むところから取り込むまでの1周です。実際の作業では、この流れを Issue ごとにくり返します。

この先は、各社の公式の文書（ページの下）や、Git と GitHub を手を動かして覚える GitHubをはじめよう（外部サイト・新しいタブで開きます） で学べます。複数の AI のセッションに分けて同時に進めるやり方は第20章で見ます。

会話では：「Issue を立てて、ブランチを切って、プランモードで計画させて、テストが通ったら PR にして」——この一言が、もう通じるはずです。