Expert AX - Level1（Claude Code） / 全4回研修第3回

並行処理と継続的改善

Git Worktreeによるコンテキスト隔離と、reflectionによる経験の資産化

講師: 村田篤郎

前半パート

01

Git Worktreeによる並行処理

02

Agent Teamsの協調開発

03

前半まとめ

前半パート

01

Git Worktreeによる並行処理

02

Agent Teamsの協調開発

03

前半まとめ

Git Worktreeとは？

1つのリポジトリから複数の作業ディレクトリを作る Git標準機能

Git Worktree

ブランチごとに別ディレクトリ

物理的にファイルが分離される

claude --worktree

別のClaudeセッションが起動

各ディレクトリで独立したセッション

結果

コンテキスト完全隔離

タスクAの記憶がタスクBに混ざらない

5分、ここまで11分

「Git Worktreeについて説明します。まず土台になるのはGitの標準機能です」

（上のカードを指して）「Git Worktreeは、1つのリポジトリから複数の作業ディレクトリを作るGit標準機能です。2015年にGit 2.5で追加された、実は古くからある機能なんですが、AI開発で改めて脚光を浴びています。ブランチごとに物理的に別のディレクトリができるんですね」

（真ん中のカードを指して）「ただ、ディレクトリが分かれただけでは並行処理にはなりません。ここでClaude Codeの出番です。claude --worktree というオプションをつけて起動すると、そのWorktreeディレクトリの中で別のClaudeセッションが立ち上がります。つまり、Gitがディレクトリを分けて、Claude Codeがセッションを分ける。この2つの組み合わせがポイントです」

（下のカードを指して）「結果として、コンテキストが完全に隔離されます。タスクAの記憶がタスクBに混ざらない。Claudeが1つのタスクに取り組んでいる間に、別のClaudeに次のタスクを任せられるんです。タスクの大小は関係ありません。独立したタスクなら何でも並行実行できます」

【用語: Git Worktree — 1つのリポジトリから複数の作業ディレクトリを作るGit標準機能。「1つのプロジェクトに複数の作業スペースを同時に開けるイメージです。ブランチ切り替えなしに並行作業できます」と説明】

【質問対応: 「git switch / checkout じゃダメなんですか？」→ 「switchはファイルを切り替えるだけで、Claudeのセッションは同じまま。前のタスクの記憶が残るのでコンテキスト汚染のリスクがあります。Worktree + claude -w なら物理的に別ディレクトリ・別セッションなので完全隔離です」】

並行処理の2つの条件

条件 1

依存関係がない

✅ Header にダークモードボタン追加
＋タイトル横に赤丸アイコン追加

❌ 新しいAPIエンドポイント作成
＋そのAPIを使うフロントエンド実装

条件 2

ファイル競合しない

✅ Header コンポーネント修正
＋ Footer コンポーネント修正

❌ Header にボタン追加
＋ Header にユーザー名表示追加

4分、ここまで15分

「ただし、どんなタスクでも並行処理できるわけではありません。条件は2つです」

「1つ目、依存関係がない。良い例は、『Headerにダークモードボタン追加』と『タイトル横に赤丸アイコンを追加』。完全に独立しています。悪い例は、『新しいAPIエンドポイント作成』と『そのAPIを使うフロントエンド実装』。APIが完成しないとフロントエンドが作れません」

「2つ目、ファイル競合しない。良い例は、『Headerコンポーネント修正』と『Footerコンポーネント修正』。異なるファイルを編集するので問題ありません。悪い例は、『Headerにボタン追加』と『Headerにユーザー名表示追加』。同じHeader.tsxを編集するため競合してしまいます」

claude --worktree ネイティブフラグ

2026年2月のアップデートでビルトインのWorktreeサポートが追加

# 名前なし
claude --worktree
# 名前を指定
claude --worktree my-feature
# ショートハンド: claude -w my-feature

配置先

.claude/worktrees/

自動クリーンアップ

変更がなければ自動削除

Subagent の Worktree 隔離

SKILL.md のフロントマターに1行追加するだけ

---
isolation: worktree
---

子エージェントが自動的に専用worktreeで動く
完了後、変更がなければ自動削除。変更があればレビュー用に残る
ライブラリの破壊的変更に伴う大量書き換えで威力を発揮

例: ライブラリのメジャーアップデートで100箇所の書き換えが必要 → 10個のsubagentに分散させて並行処理

2分、ここまで21分

「さらに、Subagent（子エージェント）にもworktree隔離が使えます」

「SKILL.mdのフロントマターに isolation: worktree と書くだけなんですよ。これだけで子エージェントが自動的に専用worktreeで動きます」

「完了後、変更がなければ自動削除されますし、変更があればレビュー用にそのまま残ってくれるんですね」

「どういう場面で使うかというと、例えばライブラリのメジャーバージョンアップで破壊的変更が入ったとき。APIの名前が変わったとか、書き方が変わったとかで、100箇所書き換えないといけない。各ファイルの修正自体は機械的なんだけど量が多い。これを10個のsubagentに分散させて並行で書き換える、ということが可能です」

【質問確認】「Git Worktreeの概念、ここまでで質問ある方いますか？」挙手がなければ「では実際に手を動かしてみましょう」と続行。

実習: 並行処理の実践（SDD + Worktree）

docs/plans/ に2つのplanファイルを用意

タスクA — Worktree

TaskForm UI改善

docs/plans/taskform-ui-improvement.plan.md

10〜15分

タスクB — 元ターミナル

タイトルアイコン追加

docs/plans/title-icon.plan.md

3〜5分

main

→

dev/自分の名前

個人の開発ブランチ

→

feature/*

claude --worktree が自動作成

3分、ここまで24分

「では実習に入ります。今日の実習では、SDD（仕様駆動開発）と組み合わせます」

「InsightLogの docs/plans/ に、2つのplanファイルを用意しています」

「タスクA: TaskForm UI改善で、10〜15分をWorktreeで進めます。タスクB: タイトルアイコン追加で、3〜5分を元のセッションで実行するかたちですね」

「ブランチ戦略を説明します。まず main から自分の名前の開発ブランチ dev/自分の名前を切ってもらいます。そこで claude --worktree を実行すると、dev ブランチをベースにfeatureブランチが自動で作成されて、そのfeatureブランチ上で開発が始まります。つまり main → dev → feature の3段階です」

実習手順

# Step 0: devブランチを作成
git checkout -b dev/自分の名前 main

ターミナルを2つ開いて、ヨーイドンで同時に走らせる

ターミナル A — Worktree

claude --worktree taskform-ui-fix

→ planファイルを参照して実装

ターミナル B — devブランチ

claude

→ @docs/plans/title-icon.plan.md を実装

完了確認・マージ・クリーンアップ

ターミナル A — 差分確認

git diff dev/自分の名前

Worktree側で何が変わったか確認する

ターミナル B — マージ

git merge --no-ff feature-branch

devブランチにWorktreeの成果を取り込む

ターミナル B — クリーンアップ

worktreeを削除して

Claudeに頼むだけでOK
変更なしなら自動削除される

5分、ここまで50分

「両方のタスクが完了したら、まずターミナルA — Worktree側で git diff dev/自分の名前を実行して差分を確認してください」

「確認できたら、ターミナルB — devブランチ側で git merge --no-ff でWorktreeのfeatureブランチをマージします。クリーンアップはClaudeに『worktreeを削除して』と頼むだけでOKです」

📌 バッファ: うまくいった方、お疲れ様でした。ここで実務のTipsを少し。Worktreeの名前、皆さんどう付けました？おすすめは `claude -w fix-header-layout` みたいに、何をやってるか一目でわかる名前にすることですね。`claude -w test1` みたいなのはやめましょうね、後で何のWorktreeかわからなくなります。あと、マージでコンフリクト起きたらどうするか。ここがWorktreeのいいところなんですけど、devブランチは汚れてないんですよ。だから、コンフリクトが複雑なら、Worktreeごと消してやり直せる。リスクが低いんです

📌 バッファ: もう一つだけ、実務パターンを紹介させてください。朝一でその日のタスクを2〜3個に分解して、依存関係がないものを並行で走らせるんです。コーヒーを淹れて戻ったら、2つとも終わってる。1日のスタートが劇的に変わりますよ。ただし、これは大事なんですけど、必ず各タスクのplanファイルを先に作ってください。計画なしの並行処理は、混乱の元ですから

Git Worktreeによる並行処理

claude --worktree で1コマンド起動、コンテキストを完全隔離して独立タスクを並行実行。Subagentも isolation: worktree で同様に隔離可能。

質問があればお気軽にどうぞ

前半パート

01

Git Worktreeによる並行処理

02

Agent Teamsの協調開発

03

前半まとめ

Agent Teamsとは？

2026年2月 Opus 4.6リリースと同時に追加された実験的機能

1セッション内の論理的な分離と協調
リードが複数のチームメイトを率いる
各チームメイトが独立コンテキストで作業
エージェント同士がメッセージを交換

4分、ここまで56分

「2026年2月のOpus 4.6リリースと同時に追加された実験的機能なんですよ」

「Worktreeが『物理的な分離』なら、Agent Teamsは『1セッション内の論理的な分離と協調』になります」

「1人のリードが複数のチームメイトを率いて、各チームメイトが独立したコンテキストウィンドウで作業します。そして最大の特徴は、エージェント同士がメッセージを交換できることです」

【用語: Agent Teams — Claude Code v2.0+の実験的機能。1つのセッション内で複数のAIエージェントがチームとして協調作業する仕組み。リードが指示を出し、チームメイトが各自のコンテキストで作業する】

Agent Teams コミュニケーション

Direct Message

1対1で送信

特定のチームメイトに指示

Broadcast

全員に一斉送信

全員のコンテキストを消費
コスト面で注意

Shared Task List でタスク状態を共有
Idle通知で手持ち無沙汰を検知
Shift+Down でメッセージ切り替え

Shared Task List — 自律的な進行管理

タスク間の依存関係を設定
先行タスク完了まで後続は自動ブロック
完了 → 即アンブロック → 次が動く
人間のPMによる進捗管理が不要

依存関係を設定するだけで、AIが自律的に進行管理

5分、ここまで65分

「Shared Task Listは、Agent Teamsの隠れた強力機能です。右の図を見てください」

「仕組みはシンプルです。リードがタスクを登録して、タスク間の依存関係を設定します。例えば、Task AがバックエンドAPI実装、Task BがフロントエンドUI実装、Task Cがテスト作成だとします」

「Task BはTask Aに依存している — つまりAPIが完成しないとフロントエンドが作れない。なので、Task Aが完了するまでTask Bは自動的にブロック状態になります。チームメイト2は待機しているんですね」

「チームメイト1がAPI実装を完了した瞬間に、Task Bが自動でアンブロックされて、チームメイト2がフロントエンド実装を開始します。そしてTask AとTask Bの両方が完了した時点で、チームメイト3がテスト作成を開始する」

「ポイントは、この進行管理を人間がやる必要がないということです。依存関係をリードに伝えるだけで、あとはAIが『Aが終わった、じゃあBを開始しよう』と自律的にやってくれる。人間のPMの代わりにリードエージェントが進捗管理をしている、というイメージです」

【デモ】「では、先ほどのTaskForm UI改善タスクを、Agent Teamsでやってみましょう」→ 講師がデモ実行

実習: /team で Agent Teams 体験

/team InsightLogのコードを調査し、ユーザビリティ改善点を3つ提案してください

スキルは .claude/skills/team/ に配置済み

観察 1

チーム編成

PMがどんなメンバーを選び、タスクをどう分解するか

観察 2

コード探索

Searcherがどうコードを探索するか

観察 3

チーム対話

複数エージェントがどう対話して結論を出すか

前半まとめ

Git Worktree

コンテキスト完全隔離

claude --worktree でネイティブサポート
Subagentも isolation: worktree で隔離
独立した長時間タスク向き

Agent Teams

協調的並行処理

Direct Message と Broadcast
Shared Task List で依存関係管理
議論・レビューで威力を発揮

独立タスクは Worktree、協調タスクは Agent Teams、組み合わせもできる

4分、ここまで79分

「前半のまとめです。2つの並行処理手法を学びました」

「Git Worktreeは、コンテキストの完全隔離による並行処理です。claude --worktree でネイティブにサポートされていて、Subagentも isolation: worktree で隔離できます」

「Agent Teamsは、1セッション内での協調的並行処理です。Direct MessageとBroadcastでコミュニケーションし、Shared Task Listで依存関係を管理します」

「ちなみに、この2つは排他的じゃありません。Worktreeの中でAgent Teamsを立ち上げることもできます。例えば、Worktreeで隔離した環境の中で、Agent Teamsを使ってレビューチームを編成する、といった組み合わせも可能です」

「ここで10分間の質問タイムを設けます」

Agent Teamsの協調開発

1セッション内でリードと複数のチームメイトが独立コンテキストで協調作業。Direct Message・Broadcast・Shared Task Listで依存関係まで自律管理できる。

質疑応答

前半パートの内容について、質問があればどうぞ

後半パート

01

AIコードレビュー

02

経験の資産化

03

まとめ

後半パート

01

AIコードレビュー

02

経験の資産化

03

まとめ

ボトルネックは移動する

速度を上げると、次はレビューが詰まる

レビューボトルネック問題

AIが書いたコードは一見動くが、微妙なバグや仕様違反を含んでいることがある
AIで10本PRを出しても、レビュアーが1人なら処理しきれない
並行処理で上げた速度が、レビュー待ちで相殺

解決策: AIにレビューの一次スクリーニングをさせる

5分、ここまで99分

「前半では、並行処理によって複数のタスクを効率的に進める技術を学びました。しかし、開発速度が上がったことで、新たな問題が起きています。『レビューボトルネック問題』です」

「AIが書いたコードは一見動きますが、微妙なバグや仕様違反を含んでいることがあります。これを人間が全て見ていたら、結局そこで詰まり、生産性が上がりません」

「AIで10本PRを出しても、レビュアーが1人なら処理しきれません。並行処理で速度を上げた効果が、レビュー待ちで相殺されてしまいます」

「解決策は、AIにレビューの一次スクリーニングをさせることです」

実習: AIにコードレビューさせてみよう

sample-feature.plan.md の実装を、AIにレビューさせてください

どう頼むかは自分で考える。レビューの質はプロンプトの質で決まる

何を基準にレビューさせるか？
AIにどこまで見せるか？
指摘が出たら、次にどうするか？

最大10分

19分、ここまで118分

「ここからは手順を出しません。皆さん自身で考えてください。sample-feature.plan.md の実装を、AIにレビューさせてください。どう頼むかは自由です」

「ヒントは3つ出します。1つ目、何を基準にレビューさせるか。ただ『レビューして』と頼むのか、planファイルの受け入れ基準を使うのか。2つ目、AIにどこまで見せるか。差分だけ見せるのか、コードベース全体を見せるのか。3つ目、指摘が出たら次にどうするか。自分で直すのか、AIに直させるのか」

「どうしてもわからなくなったら聞いてください。最大10分で、皆さん終わったら切り上げます。正解は1つじゃありません。いろいろ試してみてください」

【講師巡回ポイント】受講者のアプローチを観察して、終了後に全体共有する。「ただレビューしてと頼んだ人」「planファイルを参照させた人」「コードベース全体のパターンまで見させた人」の差を見せると、レビュー品質の違いが体感できる

【まとめで伝えること】単に「レビューして」→ 一般的で浅い指摘。planファイルを参照させる → 受け入れ基準に基づいた具体的な指摘。コードベース全体を見させる → パターンとの整合性まで見る。段階が上がるほどレビューの質が上がる

📌 バッファ: ハンズオンが進んだ方、仕様準拠チェックの応用を一つ試してみませんか？ planファイルの受け入れ基準にテストケースを書いておくと、AIがテストも自動生成してくれるんですよ。『このバリデーションのテストケースを作って』と指示するだけで、受け入れ基準に対応したテストが出てきます。あと、これも便利なんですけど、複数のplanファイルをまたいだ整合性チェックもできるんです。例えばAPIのplanとフロントのplanを両方読ませて、『この2つの仕様に矛盾ないか確認して』って聞く。仕様間の不整合を早い段階で見つけられますよ

📌 バッファ: AIレビューの結果に納得できない時ってありませんか？そんなときは、こう聞いてみてください。『その指摘の根拠になるコードベースの箇所を見せてくれる？』と。AIがちゃんと根拠を出せなかったら、その指摘はハルシネーションかもしれない。こうやって根拠を求める癖をつけると、AIレビューの精度がどんどん上がっていきますよ

planファイルでレビューさせる

planファイルの受け入れ基準と実装を自動比較

出力は絞る

報告は差分だけ

「仕様と異なる部分のみ指摘して」

入力は絞らない

参照範囲は制限しない

依存ファイル・共通関数まで見せる

実務でのAIレビュー設計

ルールを定義する

.claude/rules/

コーディング規約・レビュー基準を配置

フロントマターで適用範囲を絞れる

観点別にスキル化

Skill / Subagent

セキュリティ、アクセシビリティ等を専門レビュアーとして分離

3分、ここまで124分

「さっきの実習で、プロンプトの質でレビューの質が変わることを体感してもらいました。実務ではこれを仕組みにしていきます」

「まず .claude/rules/ ディレクトリ。ここにチームのコーディング規約やレビュー基準を配置します。AIがこのルールを読み込んで、チームの文化に沿ったレビューをしてくれるようになります」

「モノレポのように複数の機能が1つのリポジトリに集約されている場合は、rulesファイルのフロントマターで適用範囲を絞れます。例えば『このルールはsrc/frontend/以下にのみ適用』のように書ける。レビューだけでなく実装時にも同じ仕組みが使えます」

「さらに、レビュー観点ごとにSkillやSubagentとして分離する設計もあります。例えばセキュリティ観点のレビュースキル、アクセシビリティ観点のレビュースキルを別々に作って、必要な時に呼び出す。『セキュリティの観点で指摘して』と毎回書く代わりに、/security-review と打つだけで専門レビュアーが起動する」

「ポイントは、毎回プロンプトで頑張るのではなく、ルールとスキルに知識を蓄積していくことです。使えば使うほどレビューの質が上がっていく仕組みを作る。これが設計です」

最も重要なこと

AIの指摘を「学びの起点」にする

AIの出力を鵜呑みにするリスク — OWASP LLM Top 10: #9 Overreliance

2分、ここまで126分

「さて、ここからが最も重要です」

「AIやレビュアーが『ここを直すべき』と言ったとき、『なぜそれが問題なのか？』を自分で考えてください」

「ちなみに /btw っていうコマンドがあって、これを使うと今の会話の流れを汚さずにサイドクエスチョンができます。『/btw なぜこの修正が必要なのか、具体例を交えて説明して』みたいに使う。本筋の作業を中断せずに疑問を解消できるんで、便利です」

「受動的に指摘を受け入れるだけでは成長しません。AIの指摘を『学びの起点』にすることで、レビューが最高の学習機会になります」

【質問確認】「AIコードレビューの進め方、ここまでで質問ある方いますか？」

【用語メモ: OWASP = Open Worldwide Application Security Project。Webアプリケーションのセキュリティリスクを整理・公開している国際的な非営利団体。AI向けにも「OWASP Top 10 for LLM Applications」を公開しており、#9 Overreliance（過信）はAIの出力を鵜呑みにして判断を誤るリスクを指す】

AIコードレビュー

planファイルの受け入れ基準を使った仕様準拠チェックで、AIが一次スクリーニングを担う。出力は差分だけに絞り、入力の参照範囲は制限しないのがポイント。

質問があればお気軽にどうぞ

後半パート

01

AIコードレビュー

02

経験の資産化

03

まとめ

経験の資産化

AIパワーユーザーとの一番の違い: 経験を資産化しているかどうか

暗黙知を形式知に変換する — 「どう指示したらうまくいったか」を構造化して残す
3つのカスタムスキルで改善サイクルを仕組み化する

/reflection

振り返りを生成

→

/heartbeat

摩擦を検出・提案

→

/kaizen

人間が判断・適用

OpenClawの改善サイクルをベースにした設計

4分、ここまで132分

「今日のメインテーマに入りましょう」

「AIパワーユーザーとそうでない人の一番の違いは、経験を資産化しているかどうかです。暗黙知 — なんとなくこうやったらうまくいく — を形式知に変える。つまり構造化して記録に残す力です」

「この研修では、3つのカスタムスキルで改善サイクルを仕組み化しています。/reflection で振り返り、/heartbeat で摩擦を検出して改善提案、/kaizen で人間がレビューして適用する。この3ステップです」

「この設計はOpenClawというOSSプロジェクトの改善PDCAサイクルをベースにしています。AIに自己改善させるのではなく、AIが提案して人間が判断する。この役割分担が大事です」

【用語: 暗黙知 / 形式知 — 暗黙知は言語化されていない経験・勘・ノウハウ。形式知は文書化・共有可能な知識。「『なんとなくこうやったらうまくいく』が暗黙知で、それをドキュメントに書き起こしたものが形式知です」と説明】

/reflection — セッションの振り返り

Handshake — やったこと・結果・詰まり・次回の懸念を4行で要約
摩擦ポイント — 何に時間がかかったか。原因を6分類で特定
得られた知見 — 技術・プロセスの学び
刺さった指示パターン — うまくいったプロンプトを再利用可能な形で記録

保存先: .claude/memory/reflection/ — 完了後に自動で /heartbeat が走る

4分、ここまで136分

「/reflection の出力構造を見てみましょう。まずHandshake。セッションで何をやって何が起きたかを4行で要約します。これが振り返り全体の起点です」

「次に摩擦ポイント。何に時間がかかったか、何が噛み合わなかったかを事実ベースで記述します。原因はconfig、prompt、procedure、permission、tool、externalの6分類で特定する。この分類が /heartbeat のRoot Cause分析と連動しています」

「得られた知見には技術的な発見やプロセスの発見を記録。刺さった指示パターンには『この言い方で一発で伝わった』というプロンプトを残す。次に同じタスクがあったときに再利用できます」

「/reflection が完了すると、自動で /heartbeat が走ります」

/heartbeat → /kaizen

/heartbeat（コーチ）

摩擦を検出して提案

同じエラーの繰り返し
曖昧なプロンプト
リスクの高い操作
手順の抜け漏れ

1回1件だけ。提案のみ。変更しない

/kaizen（人間の判断）

提案をレビューして適用

採用 → diff案を提示 → 適用
却下 → 理由を記録
保留 → 次回に持ち越し

最終判断は必ず人間

4分、ここまで140分

「/heartbeat はコーチ役です。振り返りの内容を読み込んで、6つの観点で摩擦を検出します。同じエラーの繰り返し、前提条件の欠落、曖昧なプロンプト、リスクの高い操作、過度な冗長性、手順の抜け漏れ」

「見つけた改善点は improvements.md に記録します。1回のheartbeatで最大1件だけ。一度に大量の改善を出すと消化しきれないので、最もインパクトが大きい1件だけを選ぶ設計です」

「そして /heartbeat は絶対にファイルを変更しません。タスク実行も設定変更もしない。提案のみです」

「/kaizen を実行すると、溜まった改善提案が一覧で出てきます。1件ずつ採用・却下・保留を判断する。採用したらdiff案が出てきて、承認すれば適用。却下なら理由を記録して終わり」

「AIが勝手に環境を変えることはない。提案する係（heartbeat）と判断する係（人間+kaizen）が分かれている。この設計が安心して回せるポイントです」

実習: 改善サイクル体験

/reflection

振り返り生成

→

自動

/heartbeat が走る

→

/kaizen

提案をレビュー

/reflection を実行 → 結果を確認 → /kaizen で改善を判断

15分、ここまで155分

「では実際にサイクルを回してみましょう。/reflection を実行してください」

「Claudeが今回のセッションを分析して振り返りを生成します。完了すると自動で /heartbeat が走って、改善点があれば1件記録されます」

「heartbeat が完了したら、/kaizen を実行してください。改善提案が出てくるので、採用するか却下するか判断してみてください」

「このサイクルを毎セッション末に回すだけで、AIとの協働品質がどんどん上がっていきます。実体験に基づく改善は、一般的なプロンプトガイドよりもはるかに価値があります」

【質問確認】「改善サイクルについて、質問ある方いますか？」

📌 バッファ: /reflectionが完了した方、ちょっとおすすめの活用法があるんですけど。`docs/_reflection/` に溜まったファイル、月に一度でいいので読み返してみてください。1ヶ月前の自分が何に苦労してたか、どう解決したか。この推移を見るだけでも、成長が実感できるんですよ。あと、これをチームでやると面白いんです。週次のスタンドアップで『今週うまくいったAI活用事例』を一つだけ共有する。たったそれだけで、チーム全体のAI活用スキルが底上げされていきます

📌 バッファ: もう一つ、振り返りを次に活かす具体的な方法なんですけど。/reflectionの出力を見て、『これは次も使えるな』っていうアクションを見つけたら、CLAUDE.mdに追記するんです。たとえば『TypeScriptの型定義は先に書かせた方がうまくいった』っていう知見が出てきたら、CLAUDE.mdのコーディング規約セクションにそのルールを足す。そうすると、AIが次回から自動的にそのルールに従ってくれるようになるんですよ

経験の資産化

/reflection → /heartbeat → /kaizen の3ステップで暗黙知を形式知に変換。SKILL・Hooks・CLAUDE.mdに落とし込むことでツール自体が賢くなり続ける。

本日のまとめ

AIスケールの2つのボトルネックを突破

前半: 速度

並行処理

Git Worktree — コンテキスト隔離
Agent Teams — 協調的並行処理
組み合わせもできる

後半: 品質と成長

継続的改善

AIコードレビュー — ボトルネック解消
改善サイクル — reflection → heartbeat → kaizen

このサイクルを回し続けることで、AI活用スキルが資産として積み上がっていく

7分、ここまで163分

「本日は、AIスケールのボトルネックを2つ突破する手法を学びました」

「前半で学んだことは2つです。1つ目はGit Worktreeで、コンテキスト隔離とclaude --worktreeによる速度のボトルネック突破。2つ目はAgent Teamsで、メッセージングと共有タスクリストを使った協調的並行処理」

「後半で学んだことは2つです。まずAIコードレビューとして、レビューのボトルネック解消。次に改善サイクルとして、/reflection → /heartbeat → /kaizen の3つのスキルで経験を資産に変える仕組みを体験しました」

「このサイクルを回し続けることで、皆さんのAI活用スキルが資産として積み上がっていきます。では本日は以上です」

質疑応答

第3回の内容について、質問があればどうぞ

第3回終了

お疲れ様でした

Expert AX - Level1（Claude Code） / 村田篤郎