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

AIエージェントを
"設計する"ための
第一歩

"部下"としてのAIエージェント — その実力

講師: 村田篤郎

Part 1: "部下"としてのAIエージェント — その実力

01

オープニング

02

ライブデモ — Issue → PR 一気通貫

03

講義 — AIエージェント時代の現実

04

環境構築

05

実習① — InsightLog を派手にする

06

デモ成果確認 + まとめ

Part 1: "部下"としてのAIエージェント — その実力

01

オープニング

02

ライブデモ — Issue → PR 一気通貫

03

講義 — AIエージェント時代の現実

04

環境構築

05

実習① — InsightLog を派手にする

06

デモ成果確認 + まとめ

この研修のゴール

Claude Code を軸にして、
AIエージェントを使いこなす技術と知識を獲得する

AIエージェントとは — 指示を出して、知識を与えて、ルールで縛る。
いわば部下のようなもの

2分、ここまで4分

「結論から言います。Claude Code を軸にして、AI を使いこなす技術を身につけてもらいます」

「AI エージェントとは何か。一言で言うと、指示を出して、知識を与えて、ルールで縛る。いわば部下のようなものです」

【講師ノート】"部下" の比喩は研修全体で使い続ける。ここで植え付ける

【メタメッセージ】「Claude Code を使いこなす」がゴールではない。「AI が正しく動く環境を作れるエンジニアになる」がゴール

【リアクション】「研修のゴールはイメージできましたか？わかってきた人はグッドボタン、まだちょっとピンとこない人はハートボタンを押してみてください」

Claude Code とは？

Anthropic が作ったターミナルで動く AI エージェント

ChatGPT 等との違い

指示 → 実行

ChatGPT は「会話して提案を返す」。Claude Code は「指示を受けて、ファイルを読み書きし、コマンドまで実行する」

起動方法

ターミナルから

claude コマンド1つで起動。あとは日本語で指示を出すだけ

「読んで・考えて・実行する」を自律的にやってくれるのがエージェント

2分、ここまで6分

「さっきから Claude Code と言ってますが、そもそも何者なのか、ここで確認しておきます」

「ChatGPT とか Copilot は、会話して提案を返してくれます。一方 Claude Code は、ターミナルで起動して、指示を出すと、自分でファイルを読んで、コードを書いて、コマンドまで実行します」

「この "自律的に読んで考えて実行する" というのが "エージェント" の意味です。今日の研修を通して、これが実際にどういうものか体感してもらいます」

【補足】「AIアシスタント」と「AIエージェント」の違いを聞かれたら: アシスタントは提案するだけ、エージェントは実際に動く

研修全4回の全体像

段階的にスキルを積み上げる設計

01

第1回 — 基礎

AIエージェントの実力を体感
指示の設計を学ぶ
← 今回はここ

02

第2回 — 設計

仕様駆動開発
継続改善サイクル

03

第3回 — 自動化

Skill・Hook・SubAgent で
任せる仕組みを作る

04

第4回 — 運用

多層防御と
ROI 可視化

自己紹介

村田篤郎 Expert AX 講師

AI 導入支援・伴走 / AI 開発支援・エンジニア
趣味は登山・トレイルラン。健康管理や運動計画にも AI を活用しています。

2分、ここまで7分

「30秒だけ自己紹介させてください。村田です」

仕事: AI 導入支援・伴走、AI 開発支援。「AI 導入の現場って、成果よりコストが高くついてるケースがほとんどです。ツールは進化してる。でも使い方が追いついてない」

趣味: 登山・トレイルラン。写真は富士山山頂。「健康管理や運動計画にも AI を使ってます」程度に留める

【具体例トーク】「例えば Notion に書いた日記を、Claude Code との週次振り返りに使っています。目標に対する進捗を AI と一緒に確認して、次の週のアクションを決める、という感じです。仕事でも個人でも同じやり方をしています」

【講師ノート】趣味トークは深追いしない。突っ込まれた時に答えられる範囲で

研修を始める前に

リアクション

リアクションのお作法

👍 わかった・OK

❤️ わからない・ついていけていない

✋ 質問がある → 挙手 or チャット投稿

開発環境

Codespaces を使う理由

受講者ごとに OS や環境が異なるため、
全員同じクラウド開発環境で揃えます

Windows / Mac / WSL / PowerShell …
差分を気にせず研修に集中できます

3分、ここまで10分

「研修を始める前に、2つお作法をお伝えします」

「1つ目はリアクションのルールです。講義の途中で『わかりましたか？』と聞くことがあります。そのときは 👍 か ❤️ をお願いします。👍 はわかった・OK。❤️ はわからない・ついていけていない。遠慮なく ❤️ を押してください。ペースを調整します」

「質問があるときは挙手ボタンを押すか、チャットに書き込んでください。どちらでも構いません。チャットのほうが講義の流れを止めずに済むので、タイミングを選ばず質問できます」

「2つ目は開発環境です。今日は GitHub Codespaces を使います。理由はシンプルで、皆さんの環境がバラバラだからです。Windows の方もいれば Mac の方もいる。WSL を使っている方、PowerShell の方、ターミナルの種類もさまざま。その差分を吸収して、全員同じ環境で動かすために Codespaces を使います」

「Codespaces はブラウザ上で動くクラウドの開発環境です。VS Code がそのままブラウザで開きます。ローカルに何もインストールする必要はありません」

Part 1: "部下"としてのAIエージェント — その実力

01

オープニング

02

ライブデモ — Issue → PR 一気通貫

03

講義 — AIエージェント時代の現実

04

環境構築

05

実習① — InsightLog を派手にする

06

デモ成果確認 + まとめ

ライブデモ — Issue から PR まで一気通貫

予め設計した AIエージェントワークフローをコマンド1つで走らせる

Issue

概要・背景
受け入れ条件

▶

実装計画

エージェント
チームで設計

▶

実装

コード
+ テスト

▶

PR

レビュー
チームが確認

これら全部を、たった 1コマンドで。

$ ./demo/run.sh

所要時間: 約40分 / コスト: 約7ドル / 結果は後で確認します

7分、ここまで15分

「これからデモを走らせます。やることはこの1つのコマンドだけ」

「Issue を読んで、実装計画を出して、実装して、テストを書いて、PR を作って、レビューチームがレビューする。これを全部、コマンド1つで」

「裏で 40分くらいかかります。なので、走らせ始めて、その間に講義・環境構築・実習を進めます。デモの結果は後でまとめて確認します」

（実際にコマンドを打って、起動を見せる）

【講師ノート】この時点で「Skill」「Sub-Agent」「Agent Teams」「hook」等の用語は概念として名前だけ出す。深掘りは不要。後の回で詳細にやる

【補足トーク: なぜ run.sh を使うのか（質問対応用）】「これ、なんで普通の Claude Code コマンドじゃなくてシェルスクリプトなの？って思うかもしれません。役割の違いです。スキルやスラッシュコマンドは Claude Code の "中で" 動く指示書。一方 run.sh は Claude Code を "外側から" 起動する launcher。worktree でブランチを分離したり、stream-json 形式でログを取ったり、進捗を tail で追ったり——こういう "外側の設定" はスキル側からはできない。デモでは何があっても同じように動いてほしいので、外側はシェルで固めて決定論的にして、中身のワークフローだけ /ship-from-issue というスラッシュコマンドに任せる、という設計」

【講師ノート】スキル・スラッシュコマンドの話は第3回でがっつりやる。ここでは深掘りしない

【進行ノート】run.sh の起動だけ見せれば OK。完走を待つ必要はない

【デモ環境】基本は Codespace 上でデモを走らせる。受講生と同じ環境なので、「皆さんの環境でも同じことが動く」というリアリティが出る。ローカル or VSCode 上でも動くが、受講生との足並みを揃えるために Codespace を優先

Part 1: "部下"としてのAIエージェント — その実力

01

オープニング

02

ライブデモ — Issue → PR 一気通貫

03

講義 — AIエージェント時代の現実

04

環境構築

05

実習① — InsightLog を派手にする

06

デモ成果確認 + まとめ

生成AIの理想と現実

「AI 使えば何とかなる」は幻想。これが2026年の現実です。

個人レベル

84%が AI ツール使用

そのうち 46% が精度を信用していない

「使ってはいるけど信用してない」が現実

企業レベル

95%が損益に直結していない

成功している Top 5% の共通点 — 現場にパワーユーザーがいた

※ 出典: MIT NANDA「The GenAI Divide: State of AI in Business 2025」（2025年8月）

3分、ここまで18分

「結論から言います。95% は ROI ゼロです」

「個人レベルでは、開発者の 84% が AI ツールを使ってる。でも 46% が精度を信用してない。"使ってはいるけど信用してない" これが現実です」

「企業レベルでは、AI 試験導入の 95% が損益に直結していない。MIT の調査です」

「成功している Top 5% に共通していたのは——現場にパワーユーザーがいて、ボトムアップで広がった。これだけです」

「この研修を通して、皆さんには パワーユーザー になってもらいます」

【講師ノート: AI ROI 最新データ（質問対応用）】MIT NANDA(2025/8): 95%, BCG(2025/9): 5%/35%/60%, Deloitte(2026/1): 66%生産性向上, IBM(2025): 25%のみROI達成。二極化進行中（BCG「Widening Gap」）

【エピソードトーク枠】Vibe Coding 失敗談（2-3分）— ここで挟む。スライド送らずにこのスライドのまま話す。

「パワーユーザーになる、なんて言うと『この人最初からできたんだろ』って思われるかもしれないですけど、全然そんなことないんです。僕が AI コーディングやり始めたのは Claude 3 の頃で、Vibe Coding でやってて、何回もキレてました。AI が全然指示を理解しなくて、同じミスを繰り返して、ひどい時は『何でお前こんなこともできないんだ』って罵倒の言葉を何分も考え続けたことすらあります（笑）。画面の向こうの AI に本気で腹立ててるんですよ。でも、罵倒しても何も変わらないから、プロンプトの書き方を工夫するようになって。ルールを書いて渡すとか、コンテキストを整えるとか、それこそ『指示と仕組みで制御する』ってことをやり始めました。で、今なんですけど、Claude Code とかを触ると、当時自分が苦労して作ってた仕組みが、もうデフォルトで全部入ってる。感心します。モデルの性能も全然違う。今始める皆さんは、正直幸せだと思います」

【メタメッセージ】「昔は大変、今は楽」→ 希望 / 「指示と仕組みで制御」→ 研修テーマへの橋渡し / 講師も最初は素人 → 心理的ハードルを下げる

コードを書く時代から、設計する時代へ

OpenAI の某チーム — 3人のエンジニアが 100万行のコードベースを管理し、1日 3.5個の PR を処理している。彼らがやっているのはコードを書くことじゃない

Anthropic の主張 — モデル性能はもう十分。問題は AI にどんな情報を渡すか。コンテキストの設計のほうが生産性を左右する

この研修で教えるのは、
AI が正しく動く環境を設計する技術

ハーネスエンジニアリング / エージェンティックエンジニアリングなどと呼ばれる

3分、ここまで21分

「結論: コードを書く時代から、AI が正しく動く環境を設計する時代に変わりました」

「OpenAI のあるチームでは、たった3人のエンジニアが100万行のコードベースを管理して、1日3.5個の PR を処理してます。彼らがやってるのは『コードを書くこと』じゃない。エージェントが正しく動く環境を設計することです」

「Anthropic も同じことを言ってます。モデル性能はもう十分。問題は AI にどんな情報を渡すか。コンテキストの設計のほうが生産性を左右する、と」

「この研修で教えるのはコードを速く書く技術じゃないです。AI が正しく動く環境を設計する技術 です」

なぜ Claude Code なのか？

結論: 業界標準を作っている側を押さえるのが一番効率がいい

理由 1

標準を作る側

MCP、Skills、CLAUDE.md など、Anthropic は次々に業界標準を提唱

理由 2

市場 1位

AI コーディングツール市場で 30% 強。現時点で1位

理由 3

急成長

企業の 4社に1社が Anthropic を採用、1年で 4倍

設計思想は、どのツールにも通用する

3分、ここまで24分

「次に、なぜ Claude Code なのか？という話をします。AI コーディングツールは群雄割拠ですが、結論から言うと、業界標準を作っている側を押さえるのが一番効率がいいです」

「理由は3つ。1つ目: Anthropic は次々に業界標準を提唱してる。MCP、Skills、CLAUDE.md。これらは全部 Anthropic 発祥です。標準を作ってる側を押さえれば、他のツールにも知識が流用できます」

「2つ目: 現時点で Claude Code は AI コーディングツール市場の 30% 強で1位です。次のスライドで Ramp の調査データを見せます」

「3つ目: 企業の4社に1社が Anthropic を採用してて、1年で4倍に成長してます。これも次のスライドで」

「大事なのは、コマンドや UI はツールごとに違うんですけど、この研修で学ぶ 仕様駆動開発、コンテキスト管理、最小権限の設計思想 は考え方のレベルなので、どのツールに行っても通用します」

【補足トーク】料金プランの質問が来たら B-8 を参照

Anthropic は急成長中（採用率）

企業の4社に1社が Anthropic を採用（2026年）

※ 出典: Ramp AI Index（2026年3月）

初回 AI 購入は Anthropic が優勢

Companies' first AI check is going to Claude

初回 AI 購入で Anthropic が OpenAI を逆転し、約70% を占める

※ 出典: Ramp Economics Lab（2026年）

Part 1: "部下"としてのAIエージェント — その実力

01

オープニング

02

ライブデモ — Issue → PR 一気通貫

03

講義 — AIエージェント時代の現実

04

環境構築

05

実習① — InsightLog を派手にする

06

デモ成果確認 + まとめ

環境構築

事前に配布された Codespace URL からアクセス

配布された Codespace URL をブラウザで開く
Codespace が起動するのを待つ（初回は1〜2分）
ターミナルで claude コマンドを起動 → API キー認証
Claude Code のプロンプトが出れば準備完了

10分、ここまで42分

「事前に配布された Codespace URL を開いてください。GitHub アカウント・API キーは事前に発行済みです」

「Codespace が起動したら、ターミナルで claude コマンドを起動して、API キーを入れてください」

【進行ノート】実測の構築時間は約5分。質問対応込みで10分確保。つまずきポイント: Codespace 起動が遅い → ページ再読み込み / API キー認証エラー → 配布鍵の再確認

【1画面の方へ】「スライドと Codespace を同時に見るのが難しい方は、スライドをタブに残してこまめに切り替えてください。コマンドは全部スライドに書いてあるので、手元のスライドを参照しながら進めてOKです」

【リアクション】「環境が立ち上がって claude コマンドのプロンプトが出た方は、グッドボタンを押してください。まだ作業中の方はハートボタンで」

【早く終わった人向け】「早く終わった方は、Claude Code に『このプロジェクトは何のアプリですか？』と聞いてみてください。プロジェクトのファイルを読んで回答が返ってきたら、環境構築は成功です」

Part 1: "部下"としてのAIエージェント — その実力

01

オープニング

02

ライブデモ — Issue → PR 一気通貫

03

講義 — AIエージェント時代の現実

04

環境構築

05

実習① — InsightLog を派手にする

06

デモ成果確認 + まとめ

InsightLog — AI 作業の記録ツール

https://insightlog.pages.dev

AI タスクを記録して KPI を可視化
所要時間・AI なし推定・手戻り回数
ブラウザで動く。インストール不要

開発サーバーを立ち上げる

Claude Code に指示を出す前に、変化をリアルタイムで確認できる状態にしておく

ターミナルで新しいタブを開く（Codespace 上のターミナル）
以下のコマンドを入力して Enter

$ npm run dev

ターミナルに URL が表示されたら起動成功
ブラウザでその URL を開くと InsightLog が表示される

Claude Code のプロンプトが出ているタブとは 別のタブ でコマンドを実行してください

3分、ここまで50分

「実習前の準備です。Claude Code に指示を出すと、InsightLog のコードが変更されます。変化をリアルタイムで確認できる状態にしておきたいので、開発サーバーを立ち上げます」

「ターミナルで新しいタブを開いて、npm run dev と入力してください」

「ポイントは、Claude Code が動いているタブとは別のタブで実行することです。Claude Code のプロンプトがあるところで打つと Claude Code への指示と混ざってしまいます」

「URL が表示されたら、ブラウザでその URL を開いてください。InsightLog が表示されます」

【1画面の方へ】「1画面の方は、Codespace のタブと InsightLog のタブを行き来する形になります。指示を出したあと、InsightLog のタブに切り替えて確認、という流れです」

【リアクション】「開発サーバーが立ち上がって InsightLog が表示された方は、グッドボタンを押してください」

実習① — InsightLog を派手にする

お題: InsightLog の見た目を、可能な限り派手な色合いに変える

まず、以下のプロンプトをそのまま Claude Code に貼り付けてみてください：

        InsightLog の配色を大胆に変えて、インパクトのある見た目にしてください。
      

慣れてきたら「ダークに」「サイバーパンク風に」など自分の言葉で追加してOKです

📄 手元で手順を開く: /training coloring

進め方

01 指示を出す

Claude Code に派手化を指示

▶

02 確認

気に入ったらスクショを撮る

▶

03 共有

スクショをチャットに投稿

▶

04 記録

InsightLog にタスク記録

1分、ここまで47分

「進め方は4ステップです。指示を出す、結果を確認してスクショ、チャットに共有、最後に InsightLog に記録」

「共有は"お互いに見せ合うだけ"で、投票などはしません。完璧を求めなくて大丈夫。動いて、見た目が変わったら成功です」

「気に入った派手な見た目はそのままでOK。元に戻したい人は Claude Code に『元の配色に戻してください』と指示してください」

【リアクション】実習完了したらグッドボタン、まだ作業中はハートボタン、詰まってる場合は挙手ボタンで知らせてもらう

【進行ノート】完璧を求めない / 迷ったら Claude Code に「どういう指示を出せばいい？」と聞かせる / ハマっている人がいたら講師がチャットでフォロー

InsightLog に記録する

https://insightlog.pages.dev/ を開いて、各自のブラウザに記録

タスク名: Claude Code 初体験 — InsightLog 派手化
AIツール: Claude
所要時間 / AI 未利用時の推定
手戻り回数: 指示のやり直し回数
カテゴリ: 実装 / デザイン等
振り返りメモ: うまくいった点・気づき

Part 1: "部下"としてのAIエージェント — その実力

01

オープニング

02

ライブデモ — Issue → PR 一気通貫

03

講義 — AIエージェント時代の現実

04

環境構築

05

実習① — InsightLog を派手にする

06

デモ成果確認 + まとめ

デモの成果

最初に起動したデモが完走しています

Issue → PR が完成
ユニットテスト・E2Eテストも書かれている
レビューチームによるレビューコメント付き

裏で動いていたのは Sub-Agent + command + Skill + Agent Teams — これら全部、これからの研修で詳しくやる

2分、ここまで73分

「動画で見たとおり、Issue を渡して、ここまで全部自動で出来ました。実装、テスト、PR 作成、レビューまで」

「裏では Sub-Agent が複数立ち上がって、それぞれが役割分担して動いてました。command、Skill、Agent Teams という仕組みが連携してます」

【挿入候補】分身の術の比喩: 「エージェントが同時にいくつも動いてましたよね。あれ、分身の術ですよ。分身は完全なコピーなので、設計の穴も完全にコピーされる。1つの設計図が10倍にレバレッジされる構造です。だからこそ設計（手綱）が大事 → 第3-4回への伏線」

「皆さんの環境にも demo/ ディレクトリがあって、同じものを後で試せます。大体7ドルくらい。興味があったら触ってみてください」

【補足トーク: なぜ run.sh を使うのか（質問対応用）】「これ、なんで普通の Claude Code コマンドじゃなくてシェルスクリプトなの？って思ったかもしれません。役割の違いです。スキルやスラッシュコマンドは Claude Code の "中で" 動く指示書。一方 run.sh は Claude Code を "外側から" 起動する launcher。worktree でブランチを分離したり、stream-json 形式でログを取ったり、進捗を tail で追ったり——こういう "外側の設定" はスキル側からはできない。デモでは何があっても同じように動いてほしいので、外側はシェルで固めて決定論的にして、中身のワークフローだけ /ship-from-issue というスラッシュコマンドに任せる、という設計です」

【講師ノート】スキル・スラッシュコマンドの話は第3回でがっつりやる。ここでは深掘りしない

Part 1 まとめ — 覚えてほしい3つ

01

AI は "部下"

指示を出して、知識を与えて、ルールで縛る存在。"ユーザー" として使うのではなく、"マネージャー" として向き合う

02

Top 5% の成功要因は
パワーユーザー

95% は ROI ゼロ。成功しているのは現場のパワーユーザーがいる組織。皆さんがその担い手になる

03

「使う」から
「設計する」へ

研修全体で学ぶのはこのパラダイムシフト

Part 1
質疑応答

Expert AX - Level1（Claude Code） / 全4回研修第1回 Part 2

その部下をマネジメントできるか？

記憶と指示の設計

講師: 村田篤郎

1分、ここまで91分

「ここから Part 2 に入ります。タイトルは『その部下をマネジメントできるか？』。サブタイトルは『記憶と指示の設計』です」

「Part 2 のテーマは一言で言うと、AI という部下をマネジメントする力を身につけること。具体的には、AI の記憶の仕組みを理解して、どうやって恒常的な指示を渡すか、どうやって曖昧な要望を具体的な指示に変換するか。これを講義・ハンズオン・実習の3段階で押さえていきます」

【講師ノート】"マネジメントできるか？" は煽り気味のタイトルだが、「AI の不調は指示の設計の問題」という認識転換を促す狙い。"部下" メタファーを継続して使っていく。

Part 2: その部下をマネジメントできるか？ — 記憶と指示の設計

01

講義 — 記憶と指示

02

ハンズオン — CLAUDE.md の有無で比較

03

実習② — 曖昧な要望を具体化する

Part 2 のゴール

AI が扱える情報の仕組みを理解し、
成果物の質を安定させる設定を自分で整備できるようになる

1

コンテキストの理解

AI の作業記憶の仕組みと上限を知り、
セッション内外での情報管理を身につける

2

CLAUDE.md の整備

プロジェクトのルールを書いておけば
毎セッション自動で AI に読み込まれる

AI のリソース消費を常時確認しよう

コンテキストとコストをステータスバーに常時表示する

/statusline コストも表示してください。

コンテキスト

AI の作業記憶の使用率

会話・コード・ファイルが
どれだけ記憶を使っているか

コスト

API の累積利用料金

やり取りが増えるほど課金が発生。
無駄な試行錯誤は直接コストになる

この2つの数字の意味を、これから詳しく学んでいきます

Part 2: その部下をマネジメントできるか？ — 記憶と指示の設計

01

講義 — 記憶と指示

02

ハンズオン — CLAUDE.md の有無で比較

03

実習② — 曖昧な要望を具体化する

コンテキスト — AI の作業記憶

AI が一度に扱えるのはコンテキストウィンドウ分のトークンまで
セッションを閉じるとすべて破棄される

だから、恒常的な指示は毎セッションで自動的に渡す仕組みが必要になる

3分、ここまで98分

「まず AI の記憶の特性を押さえます。ここでは **コンテキストウィンドウ** という言葉を覚えてください。これは AI が1セッションで扱えるトークンの上限のことです」

「システムプロンプト、読み込んだファイル、これまでの会話履歴、ぜんぶがこのコンテキストウィンドウの枠に収まらないといけません。Claude Code も例外ではなく、扱える量には上限があります」

「そしてセッションを閉じると、このコンテキストは丸ごと破棄されます。次に起動したときは空っぽ。前回の会話も、読み込んだファイルの記憶も、実行結果も、一切引き継がれません」

「これをたとえるなら、バイトの記憶です。スキルはある。でもシフトが終わったら全部忘れる。次に来たときはまた白紙の状態」

【問いかけ】「毎日違うバイトが来る飲食店を想像してください。毎朝、メニューの作り方と接客ルールを口頭で全部説明する。地獄ですよね？マニュアルを用意しますよね。AI に対しても同じことが起きています。だから、恒常的な指示を自動で渡す仕組みが必要なんです」

【用語: コンテキストウィンドウ = AI が1セッションで扱えるトークンの上限。モデルごとに上限が決まっている】

【用語: トークン = AI が文字列を処理する最小単位。日本語だとおおよそ1文字 ≒ 1〜2トークン】

コンテキストウィンドウの構造 — システムプロンプト・ファイル・会話履歴が上に積み重なる公式図

セッション中のコンテキスト管理

普段は ステータスラインの % で常時確認。以下の2つを使い分ける

要約

/compact

会話を要約して圧縮。
文脈を保ったまま容量を空ける

→ 「ここまでの要点をメモにまとめて。
細かいやり取りは忘れていいから続けて」

履歴クリア

/clear

会話履歴を完全クリア。
新しいタスクに切り替えるときに使う

→ 今のバイトのシフト終了。
次のバイトがまっさらな状態で来る

作業を続けるなら /compact（要約して圧縮）
タスクを切り替えるなら /clear（履歴を全消去）

💡 /context — 消費量の内訳を詳細表示する診断コマンド。statusline の % が異常に増えたときに使う

3分、ここまで101分

「セッション中のコンテキスト管理です。普段はステータスラインの % を見ていれば十分です。コマンドの出番は、容量が足りなくなったときです」

「2つのコマンドを覚えてください。/compact と /clear です」

「/compact は引き継ぎメモです。バイトに『ここまでの要点をメモにまとめて、細かいやり取りは忘れていいから続けて』と言うイメージ。会話を要約して圧縮しますが、文脈は保ったまま。続きの作業をそのまま進められます」

「/clear はシフト交代です。今のバイトのシフトが終わり、次のバイトがまっさらな状態で来る。会話履歴を全部捨てて、ゼロから始めます。使うタイミングは、今のタスクが終わって別の作業に切り替えるとき。前の文脈が残っていると判断がブレるので、きれいに流します」

「もう1つ、/context という診断コマンドもあります。これは statusline の % が異常に増えたとき — たとえば変な MCP が大量のデータを読み込んでいるとか — に内訳を確認するためのものです。日常的には使いません」

CLAUDE.md — 毎セッション自動で渡されるルールブック

Claude Code はセッション開始時に CLAUDE.md を自動でコンテキストに読み込む

CLAUDE.md なし

ルールを知らない状態で開始

プロジェクト規約や禁止事項を知らず、既存コードからの推測で書くしかない

→ 毎回来るバイトに
何も説明せず作業させる状態

CLAUDE.md あり

ルールを踏まえた状態で開始

規約・ワークフロー・方針を踏まえた状態で作業を始められる

→ バイトに毎シフト渡す
マニュアルを用意してある状態

AI の成果物の質は、あなたが書く CLAUDE.md の質で決まる

3分、ここまで106分

「その仕組みが CLAUDE.md です。プロジェクトルートに置く Markdown ファイルで、Claude Code はセッション開始時にこれを自動でコンテキストに読み込みます。毎回手で貼る必要がない」

「左側、CLAUDE.md がない場合。AI はプロジェクトのルールを知りません。コードを読んで推測するしかない。これはたとえるなら、毎回来るバイトに何も説明せず『適当にやって』と言うようなものです。スキルはあるけど、この現場のルールは知らない」

「右側、CLAUDE.md がある場合。セッション開始と同時にルールが読み込まれるので、最初から規約を踏まえた状態で動けます。バイトに毎シフト渡すマニュアルを用意してある状態です」

「大事なのは、AI の成果物の質は CLAUDE.md の質で決まるということ。マニュアルが薄ければ推測で動かれる。しっかり書けば、期待通りの成果物が返ってきます」

実際に見てみましょう

InsightLog プロジェクトの CLAUDE.md を開いてください

テックスタック・開発コマンド
ディレクトリ構成
アーキテクチャ判断（設計ルール）

これが毎セッション自動で AI に読み込まれる

3分、ここまで106分

「百聞は一見にしかず、実際に見てみましょう。CLAUDE.md を開いてください」

「上から見ていきます。まずテックスタック — React 19、TypeScript、Zustand、Dexie.js。これが書いてあるおかげで、AI は最初から『このプロジェクトは Zustand で状態管理する』と分かります」

「次にディレクトリ構成。src/components/ui/ には何があるか、src/store/ は何か、src/lib/ は何か。AI がファイルを探し回らなくても、ここを見れば一発です。さっき話した "地図" がまさにこれです」

「そしてアーキテクチャ判断。関数コンポーネントのみ、Zustand 以外の状態管理禁止、パスエイリアス @/ を使う。こういう『コードを見ただけでは分からない設計判断』が書いてあります」

「これが毎セッション自動で読み込まれる。だからセッションを閉じて開き直しても、AI は最初からルールを知っている状態で始まります」

CLAUDE.md に何を書くか、何を書かないか

Anthropic 公式の用途: コーディング規約 / ワークフロー / アーキテクチャ

書くべき

アーキテクチャ方針

層の責務・状態管理・依存方向

ワークフロー

テスト・ビルド・デプロイの手順

暗黙のルール

命名の意図・禁止事項の背景

書かなくていい

ツールで補える規則

linter / formatter の仕事

コードから読めること

依存関係・既存のファイル構成

一時的な情報

今日のタスク・進捗・TODO

ツールでできることはツールに任せる — AI への指示は AI じゃないとできないことに集中させる

3分、ここまで105分

「CLAUDE.md に何を書くか — Anthropic 公式のガイドではコーディング規約、ワークフロー、アーキテクチャの3つが示されています。ただ、今日皆さんに本当に持ち帰ってほしいのは、**書くべきもの** より **書かないでいいもの** の方です。だからアクセントは右側の "書かないでいい" に置いています」

「先に左側、書くべき方を簡単に。アーキテクチャ方針、ワークフロー、暗黙のルール。これらは **コードからは読めない** ものです。だから AI に手渡しで教える必要がある。これだけ覚えればOKです」

【ここからが本題】「右側、書かないでいいものを丁寧に話します。これが分からないと CLAUDE.md がすぐ膨れあがって、結局守られなくなります」

「1つ目、ツールで補える規則。any 禁止、インデント、命名のフォーマット系。これは linter や formatter の仕事です。CLAUDE.md に書いてもバグります。**ツールでできることはツールに任せる**。2つ目、コードから読めること。package.json で分かる依存関係、ls で分かるファイル構成。これは AI が必要なときに自分で読めます。3つ目、一時的な情報。今日のタスク、進捗、TODO。これは CLAUDE.md ではなく Issue や Plan に書く場所です」

【エピソードトーク】「CLAUDE.md って、書けば一瞬で部下が言うこと聞くようになる、みたいな魔法じゃないです。僕自身、年単位でめちゃくちゃ試行錯誤してきました。強い口調がいいのか、丁寧な説明がいいのか、リスト形式がいいのか、Markdown 構造がいいのか…全部試しました。**たどり着いた今のスタイルは、CLAUDE.md 本体には最小限のことしか書かない**。代わりに、別ファイルに細かいルールを書いて、CLAUDE.md からリンクで読み込ませる方式です」

「一番大事な原則を繰り返します。**ツールでできることはツールに任せる。AI への指示は AI じゃないとできないことに集中させる**。これが学んだ一番の教訓です。何を書くかの3項目より、この原則の方が圧倒的に重要です」

【用語: CLAUDE.md = プロジェクトルートに配置する Claude Code 向けのマニュアル。セッション開始時に自動で読み込まれる】

Part 2: その部下をマネジメントできるか？ — 記憶と指示の設計

01

講義 — 記憶と指示

02

ハンズオン — CLAUDE.md の有無で比較

03

実習② — 曖昧な要望を具体化する

ハンズオン — CLAUDE.md の有無で比較

InsightLog プロジェクトで、
CLAUDE.md の有無で AI の回答がどう変わるかを体感する

⓪ まずこのスライドで 全体の手順 を紹介 — 実際の作業は次のスライドから

CLAUDE.md を削除

質問を投げて
回答を記録

▶

git restore で復元

まったく同じ質問を
もう一度投げる

▶

2つの回答を並べる

情報源と回答の
差を観察する

📄 手元で開く: /training compare（Claude Code で実行）

Phase 1 — 削除して質問する

ターミナルで CLAUDE.md を削除

$ rm CLAUDE.md

/clear で CLAUDE.md の変更を反映
以下の質問を投げる

新しい計測フィールドを追加するにはどのディレクトリに追加すればよいですか？簡潔に答えてください

追加で「その回答のために、どのファイルを読みましたか？」と聞く

5分、ここまで116分

「Phase 1 からやりましょう。まず CLAUDE.md を削除します。ターミナルで rm CLAUDE.md と実行してください。git で管理されているので後で簡単に戻せます」

「削除したら /clear コマンドを実行してください。これで Claude Code が CLAUDE.md の削除を認識します」

「準備できたら、以下の質問を投げてください。『新しい計測フィールドを追加するにはどのディレクトリに追加すればよいですか？簡潔に答えてください』」

「回答が返ってきたら、追加で『その回答のために、どのファイルを読みましたか？』と聞いてください。どこから情報を得たかが大事です」

【予想回答（スライドには出さない）】CLAUDE.md がないので find コマンドなどで関連ファイルを検索し、既存コードから推測で回答する。読んだファイルは src/ 配下の複数のコンポーネントやストア。推測ベースの回答になる。

Phase 2 — 復元して同じ質問

CLAUDE.md を git restore で復元

$ git restore CLAUDE.md

/clear で CLAUDE.md の復元を反映
Phase 1 と まったく同じ質問 を投げる
同じく「その回答のために、どのファイルを読みましたか？」と聞く

回答の具体度と情報源に注目

5分、ここまで121分

「Phase 2 です。CLAUDE.md を戻します。git restore CLAUDE.md と実行してください。git で管理されているので一発で元に戻ります」

「復元したら /clear を実行して、Phase 1 とまったく同じ質問を投げます。同じ質問です。比較のポイントになります」

「同じく『どのファイルを読みましたか？』と追加で聞いてください」

「注目してほしいのは、回答の具体度と情報源の2つです。CLAUDE.md を読んだかどうかが特に重要です」

【予想回答（スライドには出さない）】CLAUDE.md を最優先で読み、ディレクトリ構成セクションから具体的に回答する。情報源は CLAUDE.md のみ。find コマンドでの探索は行わない。

Phase 3 — 2つの回答を並べて比較

注目すべきは情報源の違いと回答に到達するまでの行動の違い

観点	CLAUDE.md なし	CLAUDE.md あり
情報源	find コマンドで探索 → 複数ファイルから推測	CLAUDE.md のみで即答
読むファイル数	多い（コードベースを横断的に確認）	1ファイル（CLAUDE.md で完結）
回答の根拠	「既存コードを見たところ〜」（推測）	「CLAUDE.md に記載のとおり〜」（明文化された規約）
消費トークン・時間	多い	少ない

CLAUDE.md = AI にとっての地図。地図がなければ手探りで歩く、あれば一直線

3分、ここまで124分

「2つの回答を並べて、比較していきましょう」

「**情報源**: CLAUDE.md がない場合、find コマンドで探索して、複数のファイルを読んで推測ベースで回答してきたはずです。CLAUDE.md がある場合は、CLAUDE.md だけ読んで即答する」

「**読むファイル数**: なしだと多い。ありだと CLAUDE.md 1ファイルで完結」

「**回答の根拠**: なしだと『既存コードを見たところ〜』という推測。ありだと『CLAUDE.md に記載のとおり〜』という明文化された規約に基づく回答」

「**消費トークン・時間**: なしの方が圧倒的に多い。読むファイルが多い分、時間もかかる」

「CLAUDE.md は AI にとっての地図です。地図がなければ手探りで歩く、地図があれば一直線。今見ていただいた差がまさにそれです」

【質問確認】ハンズオンが一区切り。「CLAUDE.md の有無で違いを感じられましたか？」と聞く。1〜2分。

ハンズオンで見えたこと

CLAUDE.md があれば AI は地図を見て即答
なければ手探りで探索してから推測

プロジェクトが大きくなるほど探索コストは膨らむ。
巨大モノレポやチームごとに規約が違う構成では差が決定的になる

Part 2: その部下をマネジメントできるか？ — 記憶と指示の設計

01

講義 — 記憶と指示

02

ハンズオン — CLAUDE.md の有無で比較

03

実習② — 曖昧な要望を具体化する

実習 — 曖昧な要望を具体化する

私からの要望があります — この要望を叶えるために指示を具体化してください

タスクの記録をもっと簡単にしてください。

大事なこと

完成が目的ではない。具体化する過程 が学び。ハマってもそこまでを記録する

📄 手元で手順を開く: /training simplify

3分、ここまで128分

「今日の要望はこれです。ざっくりですが、こんなことを思いました。『タスクの記録をもっと簡単にしてください』」

「非常にふわっとしてますよね。このまま Claude Code に渡したらどうなるか想像してみてください。何が簡単じゃないのか、どう簡単にするのか、AI は迷います」

「皆さんにやってもらいたいのは、この曖昧な要望を **具体的な指示に変換してから** Claude Code に渡すことです。何が不便なのか、どうなれば嬉しいのか、自分で考えて言語化する。それが指示の設計です」

【講師メモ: 理想の完成形（実習後の振り返りで使う）】前回選択した AI ツールとカテゴリが、次のタスク記録時に初期値として再表示される。実習後に「ここまで具体化できていれば理想」として口頭で示す。事前に見せると答え合わせになるので、実習中は見せない

「一つ大事なことを先に言っておきます。完成が目的じゃないです。具体化する過程そのものが学びです。うまく動かなくても、そこまでを記録してください」

実習 — 進め方

01 具体化

7分 / 各自

▶

02 実装

20分 / Claude Code

▶

03 記録

5分 / InsightLog

01 で考えること

何が面倒なのか
どう改善するのか
プロンプトに書き出す

※解釈が異なっても OK

02 でやること

具体化した指示を渡す
npm run dev で確認
違えば指示を追加

03 で記録すること

最初の曖昧指示
具体化した指示
差分と気づき

32分、ここまで160分

「進め方は3フェーズで35分です」

【Phase 01 具体化 — 7分】

「最初の7分は、手は動かさないで考える時間です。3つ考えてください。1つ目、何が面倒なのか具体的に想像する。カテゴリを毎回選ぶのが面倒？AI ツール選択が面倒？時間入力が面倒？」

「2つ目、どう改善するのか解決策を具体化する。前回の値を保持する？よく使うプリセットを作る？フォーム項目を減らす？」

「3つ目、プロンプトとして書き出してみる。Claude Code に渡せる粒度の文章にする。『タスク記録後、前回選択したカテゴリと AI ツールを次回の初期値にしてほしい』のように、対象と動作を明確に」

【進行ノート】「完璧な解決案じゃなくていい。"何が面倒で、どうしたいか" を1文で言えれば OK」と声をかける。「わからない」という人には講師がいくつか例を出して誘導する。どのファイルを変更するかは Claude Code が見つけてくれるので、受講者に考えさせない。

【Phase 02 実装 — 20分】

「具体化した指示を Claude Code に渡してください。変更が入ったら、npm run dev が動いているブラウザで確認。思った通りじゃなければ、さらに指示を追加します」

【Phase 03 記録 — 5分】

「InsightLog に記録してください。特に大事なのは振り返りメモです。最初の曖昧な指示、具体化した指示、その差分と気づき。これを書き残してください」

【進行ノート】15分過ぎても実装が終わらない人はそのままで OK。ハマっている人には「最初の曖昧な指示と今の指示の差」を振り返るよう促す。

【リアクション】実習中はグッドボタンで完了、ハートボタンで作業中、挙手ボタンで詰まった、を周知する

【質問確認】実習が終わったら、まとめに入る前に少し時間を取る。「具体化で詰まった点はありましたか？」「こういう要望だったらどう変換するか悩んだ人はいますか？」と声をかけ、全体に共有できる学びがあれば広げる。1〜2分。時間が押しているときは省略可能。

成果物の質を左右する2つの要素

❌ 悪い

曖昧

プロンプト

「タスクの記録をもっと簡単に入力できるようにして」

→ 何が面倒で、どう簡単にするか AI が迷う。結果は中途半端

⭕ 良い

対象と動作が明確

プロンプト

「タスク記録後、次の記録時に前回の AI ツールとカテゴリを初期値として再表示してほしい。所要時間とメモは毎回クリア」

→ 対象・保持する値・クリアする値が具体的

⭕⭕ さらに良い

実装方針まで指定

プロンプト

「上記に加えて、保持先は既存の Zustand ストア settingsStore.lastTaskInput。useTasks から読み出す」

→ プロジェクトの一貫性も保たれる

成果物の質を左右する 2大要素: 毎回のプロンプトと CLAUDE.md に書かれた前提

5分

「ハンズオンと実習を通じて、CLAUDE.md の有無で結果が変わること、指示の具体さで成果物が変わることを体験してもらいました。ここで整理します」

「悪い例。『タスクの記録をもっと簡単に入力できるようにして』。さっきの実習で最初に考えた曖昧な要望に近いですよね。これだと AI は迷います」

「良い例。対象と動作が明確。さらに良い例は実装方針まで指定。ここまで書くとプロジェクトの一貫性も保たれます」

「そしてさらに良い例は、プロジェクトの規約や構造を知らないと書けません。でも CLAUDE.md にそれが書いてあれば、AI が勝手にこのレベルで動いてくれる。それがハンズオンで体験したことです」

「つまり、成果物の質を左右する2大要素は『毎回のプロンプト』と『CLAUDE.md に書かれた前提』です」

Part 2 まとめ — 覚えてほしい3つ

01

コンテキストは
有限

"部下の記憶" は毎回リセット。
だから CLAUDE.md に書く

02

CLAUDE.md で
ルールを自動適用

ルールを知った "部下" を
毎セッション自動でロードする

03

指示の具体化は
あなたの仕事

曖昧な要望をそのまま渡さない。
あなたが具体化する

成果物の質を左右する 2大要素:
毎回のプロンプトと CLAUDE.md に書かれた前提

10分、ここまで170分

「Part 2 のまとめです。覚えてほしいのは3つ」

「1つ目、コンテキストは有限。部下の記憶は毎セッションでリセットされます。だから恒常的なルールは CLAUDE.md に書いておく必要があります」

「2つ目、CLAUDE.md でルールを自動適用。CLAUDE.md があると、ルールを知った部下を毎セッション自動でロードできます。コーディング規約・ワークフロー・アーキテクチャ、全部書く場所です」

「3つ目、指示の具体化はあなたの仕事。曖昧な要望をそのまま AI に渡さない。あなた自身が具体化してから渡す。それが成果物の質を決めます」

「そして、一言でまとめると、成果物の質を左右する2大要素は『毎回のプロンプト』と『CLAUDE.md に書かれた前提』です」

AIエージェントを"設計する"ための第一歩

Part 1: "部下"としてのAIエージェント — その実力

オープニング

ライブデモ — Issue → PR 一気通貫

講義 — AIエージェント時代の現実

環境構築

実習① — InsightLog を派手にする

デモ成果確認 + まとめ

Part 1: "部下"としてのAIエージェント — その実力

オープニング

ライブデモ — Issue → PR 一気通貫

講義 — AIエージェント時代の現実

環境構築

実習① — InsightLog を派手にする

デモ成果確認 + まとめ

この研修のゴール

Claude Code とは？

指示 → 実行

ターミナルから

研修全4回の全体像

第1回 — 基礎

第2回 — 設計

第3回 — 自動化

第4回 — 運用

自己紹介

研修を始める前に

リアクションのお作法

Codespaces を使う理由

Part 1: "部下"としてのAIエージェント — その実力

オープニング

ライブデモ — Issue → PR 一気通貫

講義 — AIエージェント時代の現実

環境構築

実習① — InsightLog を派手にする

デモ成果確認 + まとめ

ライブデモ — Issue から PR まで一気通貫

Issue

実装計画

実装

PR

Part 1: "部下"としてのAIエージェント — その実力

オープニング

ライブデモ — Issue → PR 一気通貫

講義 — AIエージェント時代の現実

環境構築

実習① — InsightLog を派手にする

デモ成果確認 + まとめ

生成AIの理想と現実

コードを書く時代から、設計する時代へ

なぜ Claude Code なのか？

標準を作る側

市場 1位

急成長

Anthropic は急成長中（採用率）

初回 AI 購入は Anthropic が優勢

Part 1: "部下"としてのAIエージェント — その実力

オープニング

ライブデモ — Issue → PR 一気通貫

講義 — AIエージェント時代の現実

環境構築

実習① — InsightLog を派手にする

デモ成果確認 + まとめ

環境構築

Part 1: "部下"としてのAIエージェント — その実力

オープニング

ライブデモ — Issue → PR 一気通貫

講義 — AIエージェント時代の現実

環境構築

実習① — InsightLog を派手にする

デモ成果確認 + まとめ

InsightLog — AI 作業の記録ツール

開発サーバーを立ち上げる

実習① — InsightLog を派手にする

進め方

01 指示を出す

02 確認

03 共有

04 記録

InsightLog に記録する

Part 1: "部下"としてのAIエージェント — その実力

AIエージェントを
"設計する"ための
第一歩

Top 5% の成功要因は
パワーユーザー

「使う」から
「設計する」へ

Part 1
質疑応答

Part 2 のゴール

AI のリソース消費を常時確認しよう

CLAUDE.md — 毎セッション自動で渡されるルールブック

実際に見てみましょう

CLAUDE.md に何を書くか、何を書かないか

Phase 1 — 削除して質問する

Phase 2 — 復元して同じ質問

Phase 3 — 2つの回答を並べて比較

ハンズオンで見えたこと

成果物の質を左右する2つの要素

コンテキストは
有限

CLAUDE.md で
ルールを自動適用

指示の具体化は
あなたの仕事

Part 2
質疑応答