.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

目次

概要

Week 1

Vibe Coding for fun and profit(バイブ・コーディング)

Day 1

1-7日

  1. コースへようこそ:Cursor AIを使った3Dゲーム制作:
    • Cursorで「矢印キーで移動し、スペースキーで発砲して、1台のコンピュータ対戦相手とアリーナで戦う、3D一人称視点シューティングゲームのウェブサイトを構築してください。」と入力
    • すると自動でコード(index.html)を生成(Cursorは以前サインアップしたアカウントで試したらモデル選択が「Auto」からできなかった)
    • ポイントは単純なコード作成に留まらず、ファイル生成や、Node.jsのインストールから、起動(npx serve .)などの作業も行われる点。
  2. Cursor AI Agentで一人称視点シューティングゲームを構築する:
    • 生成物を分析・動作確認し、プロンプトを修正し得て動作を改善することを行う。
    • その中で「Zero-shot(ゼロ・ショット)」「Ralph Loop(ラルフ・ループ)」と呼ばれる手法(単語レベル)を紹介する。
  3. Agentic Coding(エージェント型コーディング)のための欠かせないマニュアル:
    • コース誕生のきっかけ(カルパシー氏のポスト)、
    • 対象となる受講者
      • すべての人向け、意欲あるエンジニア・初心者~シニア・ベテランエンジニア
      • コース修了後に得られる成果
      • コースのスタンス(誇大広告(ハイプ)への警戒)について解説。
  4. 講師紹介&3週間AI Coderコースのロードマップ:
    • 講師(Ed Donner)の経歴と実績
    • 本コースの位置づけ「AI(エージェント)を使ってコードを書く」「幅(Breadth)」「深さ(Depth)」の両立。
    • 3週間のカリキュラム構造。
  5. Vibe Coding、Agentic Coder、そしてClaude Codeのようなコーディング・エージェント:
    • 「バイブ・コーディング(Vibe Coding)」の誕生とこれまでの歩み。
    • 曖昧な用語の整理(Vibe Coder、Vibe Engineer、Agentic Coder、Coding Agent。
    • 3つの対話I/F(IDE型、エディタ拡張型、CLI型。
    • 結論と心構え(この分野の進化スピードは凄まじく、毎日膨大な情報(津波)が押し寄せている)
  6. AIコーディングの8段階:ChatGPTからAgent Orchestrationまで:(Steve Yegge氏の説)
    1. AIをコーディングに活用するレベルは、初級から上級まで以下の8つのステージに分類される。
      • ステージ1:インテリセンス的スニペット生成:ChatGPTとの対話や、AIによるコードの自動補完を参考程度に使う。
      • ステージ2:ChatUIを用いたコード生成:IDEのサイドバーにコーディング・エージェントを配置し、承認を得ながらコードを修正。
      • ステージ3:YOLOモード(エージェントの結果を一括受け入れ):エージェントを全面的に信頼し、すべての変更を未確認で即座に承認。
      • ステージ4:エージェントへの委託&検収1:意識の対象がコードからエージェントへと移る。エージェントに集中し、コードの変更履歴はたまに眺める程度。
      • ステージ5:エージェントへの委託&検収2:IDEからCLIに移行。Claude Codeなどを使用し、人間は画面のスクロールをただ眺めるか、席を外して完了を待つ。
      • ステージ6:マルチ・エージェント1:CLI上で複数のエージェント(3〜5体)を同時に起動し、チームとして並行してプロジェクトを進めさせる。
      • ステージ7:マルチ・エージェント2:10体以上のエージェントをCLI上で稼働させ、人間がそれらの進捗や連携を自ら管理・調整する。
      • ステージ8:マルチ・エージェント3:役割を持ったマルチ・エージェント・ネットワークが自動で機能する最上級ステージ
    2. ステージとアウトラインのマッピング
      1. 第1週:ステージ2〜4
      2. 第2週:ステージ5
      3. 第3週:ステージ6〜8
      4. 企業の開発における最適解はステージ5〜6
    3. 利用コスト
      1. コース自体は無料で完結可能
      2. 推奨されるプラン:初期はCursorの無料期間を利用し、第2週・第3週に向けてClaude Code(月額20ドルプラン)に加入。
      3. 自己責任の原則:費用の管理や解約の判断は必ず受講生自身が行う必要があります。
  7. まとめ:これから始まる、あなただけのAgentic Coding Journey
    1. 変化の激しい環境への心構え
    2. 本コースha、全員が同じコードを実行して同じ結果を得るわけではない。
    3. 講師によるサポートとコミュニティへの参加(Q&Aやメール、LinkedIn?

Day 2

8-13

  1. LLMの仕組み:トークン、メモリ、推論を解説:
    • 大規模言語モデル(LLM)の基本
    • LLM単体 と LLMを組込んだAIアプリケーションの違い
    • AIアプリケーションでインテリジェンスを疑似体験させるトリック
      • トリック1:記憶の錯覚(Ilusi Memori):チャット履歴
      • トリック2:推論・思考(Penalaran / Pemikiran):Few-shot
  2. ツール、ループ、そしてAI Agentの定義:
    • AIアプリケーションでインテリジェンスを疑似体験させるトリック
      • トリック3:ツール(Tools / Tool Calling)
      • トリック4:ループ(Loop)
    • AIエージェントの最新の定義
      「目標を達成するために、ループ(繰り返し)の中でツールを実行するLLMシステム」
  3. Context Engineering:System Prompt、Context Window、AGENTS.md:
    • コンテキストエンジニアリングとは以前は「プロンプトエンジニアリング」と呼ばれていたが、最適な出力を得るための全技術を指す「コンテキストエンジニアリング」へと概念が拡張された。
    • 入力コンテキストを構成する主要要素:システム・プロンプト、ツールの説明、メモリ、会話履歴、など
    • Contextウィンドウには最大サイズがあるのでコンパクション(圧縮、要約)技術もあるが信頼性に課題もある。
  4. AGENTS.mdを極める:コーディング・エージェントのためのContextウィンドウ戦略
    • AGENTS.md とはコーディング・エージェント用のシステム、プロジェクトに沿ったプロンプトを記載したMarkdown形式のファイル。
    • 配置ルールは、ルートとサブ・ディレクトリに配置できる。ルートはプロジェクト全体に適用され、サブはサブ・プロジェクトに適用される。
    • 効果的な記述のコツ:
      • 簡潔、明確、断定的に、プロジェクト全体目標と成功基準、肯定文に集中、強調は大文字の 「IMPORTANT(重要)」 を使う。
      • 長文で冗長、過剰、防御的(数多くの例外ケース)
    • 2025年型アプローチ vs 2026年型アプローチ
      • 2026年型の思想(自律・手放し):研究分野ではプログレッシブなコチラが重視されている。
      • 2025年型の思想(管理・最適化 ※推奨):実用的な大規模プロジェクトにおいてはコチラの方が成果が出る。
  5. AIコーディング・ワークフローの進化:YOLOからRalph Loopsへ:
    • 2025年のマインドセット(低い〜中程度の信頼度):マイクロマネジメント、計画・実行・レビュー・テスト、仕様ベース開発 / 信頼するが検証する
    • 2026年のマインドセット(高い信頼度・自律駆動):YOLO、ラルフ・ループ(Ralph Loops)、マルチ・エージェント(Multi-agent / Swarm)
    • YOLOは元々は英語の古い格言的な表現(「人生は一度きり」)でAIの文脈では「一度きりだから大胆に試せ」「失敗を恐れず全力で行動せよ」の意味(マーケっぽいな)
    • 賢く見えないシンプソンズのキャラクター(Ralph Wiggum)に因んで「しつこく繰り返せば最終的に成功する」と言うAIの運用哲学。
  6. ハイプ(過度な期待)を超えてLLM(現在の主要モデル)を比較する
    • AI Coding Agentsのハイプ(過度な期待)に流されないこと。一時急上昇した単体LLM性能の成長曲線は、今後、緩やかになる予測。
    • (Artificial Analysis(生成AI比較サイト))で冷静に主要モデルGPT 5.2 Codex、Claude Opus 4.5、Gemini 3 Pro、GLM-4を比較(コレを記載している時点でも既に陳腐化)
    • LLMエージェントのブレイクスルーは
      • 推論技術(Reasoning techniques)をベースにしたツール使用・計画立案・自己修正の機能に依存しており、
      • 人手のChain of Thought(CoT)等のPEを参考にした教師あり学習(SFT)ベースの強化学習(RL)によって段階的思考能力を獲得したため。

Day 3

14-20

  1. Cursor、GitHub Copilot、Codex、そしてAgentic Vibe Codingの実践:
    • 講義の目的と心構え(バイブ・コーディングの原則)
      • ツールの選択は自由: 紹介するツールをすべて使う必要はありません。見るだけでも1つ選んで使い続けるでも。
      • 結果は人それぞれ: 使用するモデル(無料版や安価な版など)によって講師と異なる結果が出ることがある。
      • イライラしない(最も重要): 的外れな出力には「焦らず、フィードバックを与え、問題を極限までシンプルにする」
    • ハンズオン:環境構築とプロジェクトの準備
      • Cursorの起動とNode.jsのインストール
      • GitHubからのプロジェクト複製(Gitクローン)と切り替え
  2. AGENTS.mdファイルとVibe CodingのためのCursor設定を探索:
    • Cursorの基本操作(ショートカットキー)
      • 左サイドバー(ファイルシステム)の開閉:Mac:Command + B / Windows:Ctrl + B
      • 右サイドバー(エージェントチャット)の開閉:Mac:Command + Option + B / Windows:Ctrl + Alt + B
    • AGENTS.md(要件定義書)ファイルの役割と構成
      • ビジネス要件(Business Requirements)セクション
        ・Webアプリとして動作するカンバンボードのMVP(最小限の試作品)を作る。
        ・機能はシンプルに洗練された美しいUIを最優先し、起動時にはダミーデータを表示。
      • 技術的詳細(Technical Details)セクション
        ・技術スタック:Next.js(frontend サブ・ディレクトリ内)。
        ・データの永続化(保存)やユーザーログインは実装しない。
      • カラースキーム(Color Scheme):デザインに使用する好みの配色を指定(AIに任せてもOK)。
      • 戦略(Strategy):フェーズごとの計画策定、環境構築、UT/CU/ST、不具合修正という一連の標準的な開発フローを指定。
      • コーディング標準(Coding Standards)
        ・最新バージョンのライブラリ使用、過剰な設計の禁止(シンプルさの徹底)。
        ・「絵文字は一切使用禁止(No emojis ever)」(エラーの原因になることがあり、不要なため)。
    • AGENTS.md を作成・運用するコツ
      • 曖昧さを排除し、正確かつ肯定的な表現で明確に指示を出す。
      • 重要なポイント(「シンプルにする」など)は、複数のセクションで重複して書いても問題ない。
      • 最初は最小限の記述で実行し、AIの出力結果を見ながら、失敗した部分を修正・追記していく「反復的なアプローチ」が有効。
    • Cursorのエージェント設定(実行モードの選択)
      設定メニュー(Mac:Command + Shift + J / Windows:Ctrl + Shift + J)の「agents」>「auto run」セクションから、エージェントの実行モードを個人のリスク許容度に合わせて選択。
      • YOLOモード(Run everything unsandboxed):すべての処理を承認なしで自動実行する。リスクを理解している人向け(講師はこのモードを推奨・選択)。
      • 安全モード(Auto run in sandbox / Ask every time):ファイル作成などのステップごとにユーザーの承認を求める。何が起きているかを確認しながら進めたい初心者向け。
  3. YOLOモードでCursor AI Agentを使ってKanbanアプリを構築:
    • 開発の準備とプランニング
      • 画面配置とモデル設定:作業スペースを広く確保するためエージェント画面を左に広げ、使用モデルはCursorに最適化を任せる「auto(自動選択)」モードに設定。
      • プランニングの実行:エージェントを「plan(計画)」モード(コード・ファイルに出力せず、MDファイルに出力する)に切り替え「Go ahead and plan.」と指示を出す。
      • デフォルトで読み込まれる設定ファイル AGENTS.md を基に、AIが自動で「kanban mvp implementation plan(実装計画書)」やアーキテクチャの概要を生成。
    • 自動ビルドの実行(YOLOモード)
      • 自動開発の開始:生成された計画書のレビューをスキップし、「build」ボタンを押して開発を開始。
      • 自律的な開発プロセス:AIがファイルの作成(.gitignore やフロントエンド用ディレクトリ)、テストの実行と失敗時の自動修正を自律的に繰り返す。
      • ユーザーはコンテキスト(メモリ)使用量が徐々に増えていく様子や、AIが自ら思考・修正するプロセスを確認。
    • アプリケーションの動作確認
      • 自動起動と初期機能:ビルド完了後、アプリ(Next.jsベース)が自動起動し、ローカルサーバー(localhost:3000)でかんばんボードが立ち上がる。
      • 初期状態の評価:タスクカードの追加、削除、列名の変更、列をまたぐドラッグ&ドロップなどの基本機能は初回から動作。
      • ただし、画面下部にNode関連のエラー(赤アイコン)が表示され、列内でのカードの並び替えができないなどの課題が残った。
    • フィードバックによる反復改善
      • 追加指示の提示:AIに対し、「エラーの修正」「ドラッグ&ドロップの挙動のスムーズ化」「列内での並び替え機能の追加」「画面への紫と黄色の配色追加」をフィードバックとして指示。
      • 改善結果の確認:デザインに指定通りの紫と黄色が取り入れられ、列内でのカードの並び替えも可能になった。一方で、エラー表示の赤アイコンは完全には解消されなかった。
  4. VS CodeでGitHub Copilotを使ってKanbanボードを構築:
    • プロジェクトの準備とディレクトリの変更(既存の Kanban ディレクトリの名前を Cursor_Kanban に変更し、再度Gitクローン)
    • GitHub Copilot と VS Code の導入GitHub Copilotは無料プランでも一定回数利用可能。今回は Cursor のベースでもある VS Code(オープンソースのコードエディタ)に拡張機能としてインストールして使用。
    • GitHub アカウントと連携し、ショートカットキー(Mac:Command + Shift + I / PC:Ctrl + Shift + I)またはメニューから「Chat」を起動して、使い慣れたサイドバー形式の「Build With」エージェントを表示。
    • 実装の開始と進行:エージェントを「常に許可(YOLOモード)」「Plan(計画)モード」に設定し、AGENTS.md を読み込ませてタスクの計画を作成、計画完了後、「Start implementation(実装開始)」を実行。
    • 途中でサーバー起動のディレクトリを間違えるなどのバグが発生し、最終的にエージェントはサーバー起動コマンドの待機状態でフリーズしたため、手動で処理を停止(キャンセル)。
    • 手動でローカルサーバーを起動(npm run dev)してブラウザで確認したところ、デザインやドラッグ&ドロップの挙動は非常によく、エラーも出ていなかった(Claude Haiku という小型モデルが使用されたと推測)。
      • しかし、「カードの削除(Delete)機能」が動作しないというバグが見つかった。バグを指摘すると、エージェントは「推測」で修正コードを書き「修正が完了した」と主張したが、実際には直っていなかった。
      • コーディング・エージェントの「原因を検証せず、勝手に推測して勝利宣言をする」対策として、エージェントに対して以下の規律あるステップを明確に指示
      • 「最初に問題を再現」「再現できたことを証明」「根本原因を見つける」「修正し、直ったことを実証」この具体的な指示を与えて再度実行させた結果、エージェントは見事に削除機能を修正することに成功。
      • AIエージェントにデバッグを依頼する際は、「直した」という言葉を鵜呑みにせず、人間がボスとしてプロセスを管理し、「再現・原因特定・修正・実証」のステップを厳密に指示することが成功への近道。
  5. OpenAI Codex VS Code拡張:ゼロショットでKanbanアプリを構築:
    • OpenAI CodexはCLIツールとしての側面を持つが、今回はIDE(VS Code)の拡張機能として使用する。利用にはOpenAIのアカウント(ChatGPTのサブスクリプションプラン)が必要となる。
    • 「agent full access」(YOLOモード)、「GPT 5.5」、「reasoning effort」を「High」に設定(※思考させすぎると逆効果になることもある)。
    • 同様に、アプリケーションの動作確認(自動起動と初期機能、初期状態の評価)を実施し、必要に応じてフィードバックによる反復改善(追加指示の提示、改善結果の確認)を行う。
  6. Antigravity IDEとGeminiでKanbanアプリを構築:
    • 開発環境の移行と準備:4つ目のツールである「Antigravity」へと移行。既存のKanbanフォルダを Codex_Kanban にリネームし、git clone を用いてまっさらな状態のKanbanプロジェクトを再配置。
    • Antigravityの概要と特徴:antigravity.google からダウンロード可能。Cursorと同様に VS Codeのフォーク(クローン) であり、部分ウィンドウの構成もほぼ同じ
    • 利用モデル:デフォルトでは Gemini が提示されるが、AnthropicのモデルやGPT-OSSも選択可能。今回は最高ティアの Gemini 3.5 Flash (High) を使用。
    • 設定:Lintエラーの自動修正機能(Agent Autofix lints)を有効化。また、確認なしで処理を続行させる「YOLOモード(Always proceed)」に設定。
    • 設定ファイルの配置:Antigravityは業界標準になりつつある AGENTS.md を読み込まないため、プロジェクトルートに .agent/rules/ という専用のディレクトリを作成。
    • ルールの移行:その中に strategy.md を作成し、中身のコンテキストを常に読み込ませる「Always on(常時有効)」に設定。元あった AGENTS.md は削除。
    • 実行結果と検証:AIはブラウザ自動化ツールの Playwright を起動し、自身で画面の見た目をチェックしたりテストを実行したりして、エラーがあればその場で修正。
    • 成果物の評価:完成したKanbanアプリは、デザインが新鮮かつクリーンで動作もスムーズだったが、一部の機能がシンプルすぎる(不十分な)ため、今後の改善の余地あり。
  7. Cursor vs GitHub Copilot vs Codex vs Antigravity:最終評価:
    • カード作成機能の改善をGemini(Google Antigravity環境下)指示した結果、JSのプロンプトからモーダル表示されるようになり成果に満足。
    • 「Codex」(Codex IDEで動作するモデル)をトップ(勝者)としつつも、Antigravityで動作する「Gemini 3.5 Flash (High)」や「GPT 5.5」との差は僅差であり、どれを選ぶかはユーザーの好みや環境次第。
    • 主要なAIコードエディタ(エージェント)の共通点はどれもUI(左右のサイドバー、プランモードや実行モードなど)や動作の仕組み(AGENTS.md や .agent ルールによる駆動)が非常によく似ている。

Day 4

21-26

  1. YOLOモード:IDEでのAgentic Codingに適したLLMの選び方:
    • ツールそのもの(IDE)と、裏側で動くAIモデル(LLM)を区別することが重要
    • 各IDEはプランに応じてモデルを切り替えることが可能(推奨は頻繁に変わる)
    • Cursor:AnySphere?/Composer、GitHub Copilot:Claude Haiku、Codex:GPT 5.5、Antigravity:Gemini 3.5 Flash
    • ツール(IDE)の使い心地の差はわずかであり「どのLLMに意思決定をさせるか」
    • ただ、実際ヤッてみると既定のLLMも(頻繁に)更新されていることが解る(都度確認)。
    • 小型モデルでのYOLOは破綻リスクが高い。ステップ毎に差分(Diff)を目で確認しながら進める。
  2. Vibe Codingを成功させる5つの原則:
    • 「5大原則(Be the Boss)」:AIを自律的な意思決定者として扱うのではなく、優秀だが助手として扱うマインドセット
      • AGENTS.md(指示書)の充実:「要件(仕様)」「スタイル」「成功基準」の3要素を、簡潔かつ明確に記述。
      • 小さく始める:最初から複雑なアプリを狙わず、まずは最も基本的なMVP(最小限の製品)の構築からスタート。
      • 段階的に進める(インクリメンタル):各ステップで常にテストと検証を繰り返し、規律を持ってマイルストーンを達成。
      • 油断しない(怠けない):初期にうまくいくとAIを過信しがちだが、AIが過去のステップで致命的な勘違いをしているケースがある。常に警戒。
      • 泥臭く検証する(異議申し立てと証拠の要求):AIが「修正した」と自信満々に言っても鵜呑みにせず、根本原因、テストの結果、証拠を厳しく求める。
    • 混乱や失敗:「フラストレーションや壁にぶつかることもプロセスの一部」だと受け入れ、それを管理・回避する方法を学ぶことが成功への鍵。
      • AIに仕事を丸投げするとスキルが身につかず、将来のフラストレーションに繋がる。
      • AIに質問を投げかけ、何が起きているかを理解してシニアへのステップアップに活かす。
      • AIは時に的外れで、自信満々に間違え、根本解決ではなくパッチを当てようとする。常にチェックする。
      • コードを書く喜びは減るが、苦手分野を克服し、システム全体を高速に構築する新しいパワーを手に入れたと捉える。
  3. 責任あるYOLOコーディング:OpenRouter?でAIプロジェクトをセットアップ:
    • YOLOモードには楽しさがある反面、大きなリスクやトレードオフが存在
      • ジュニア開発者の学習への悪影響(Anthropicの調査):AI不使用のグループの方が、AI使用グループよりも技術の理解度が有意に高かった。
      • OSSコミュニティ(Jellyfin)のAI利用ポリシー:会話におけるLLM出力の直接使用は禁止、Pull Request(PR)は小さくまとめ自身の言葉で説明できないコードは拒否。
      • AIをアシスタントとして使うのは自由だが、最終的なコードの所有権と責任は人間(自分)にある("We own the code")。
    • 制作プロジェクトの概要
      • 目標:AIエージェントを活用し、自分自身のキャリアに関する質問に答えるAIチャットボット(デジタルツイン)を組み込んだ「個人ポートフォリオウェブサイト」を構築する。
      • 開発のコツ:問題に直面した場合は、機能を削ぎ落として「極限までシンプルにする」こと。
    • OpenRouter?(APIプラットフォーム)のセットアップ
      • 複数のLLM APIを一つのアカウントで一元管理できるOpenRouter?(またはOpenAI)を使用
      • アカウント作成後、「Keys」メニューからAPIキーを発行、(sk-or-v1-...で始まる文字列)が1文字でも間違っていると動作しない。
      • 無料:「https://openrouter.ai/settings/privacy」→「から、入出力の学習・公開の利用を許可する必要がある。
      • 有料:「Credits」からチャージが可能。OpenRouter?は最低2ドルから入金できるため、初心者にも優しい仕様となっている。
  4. YOLOモード:CursorでGPT Codexを使ってNext.jsウェブサイトを構築:
    CursorのYOLOモードを使用し、プロンプト一つでローカル環境に個人のポートフォリオサイトを構築する実践的なチュートリアル
    • プロジェクトの初期設定
      • フォルダ作成:Site という名前の新規プロジェクトフォルダを作成し、Cursorで開く。
      • 環境変数ファイルの作成:.env ファイルを作成し、OpenRouter?(またはOpenAI)のAPIキーを正確に記述して保存する。
      • (このOpenRouter?(またはOpenAI)は、Cursorのエージェントではなく後述のアプリのAI Digital Twinチャット機能で使用)
      • Git対策:.gitignore ファイルを作成し、セキュリティのために .env を指定してリポジトリに含まれないようにする。
    • ソースデータの準備
      • 自身のLinkedIn?のプロフィールページをPDF(LinkedIn?.pdf)として保存し
      • プロジェクト・ディレクトリに配置する(PDF化できない場合はテキストのコピペや履歴書で代用)。
    • Cursorの設定変更(YOLOモードの設定)
      • Usage Summary:常に表示(Always)に設定し、モデルの使用量を把握できるようにする。
      • Auto Run (YOLO設定):ステップごとの承認を省くため、Run Everything、Un-Sandboxedに変更。
      • モデルの選択:高品質な出力を得るため、より強力なモデルである GPT 5.2 Codex High を選択。
    • エージェントへの指示とサイト構築
      • 以下の要件をプロンプトで指示し、エージェントに自動構築させる。エージェントは自動的に web というサブフォルダを作成し、Next.jsサイトを構築する。
        「Next.jsを使用し、LinkedIn.pdfを元に、エンタープライズ感とエッジの効いたスタイリッシュなローカルWebサイトを作って欲しい。自己紹介、経歴、将来のポートフォリオへのリンクを含め、洗練されたデザインにブラッシュアップして完成したら教えて欲しい。」
        Please build me a Professional Website running locally. My linkedin profile is in linkedin.pdf. Make the website stunning:enterprise meets edgy. It should include about me, my career journey, links to a portfolio (for future). Iterate to make it as slick and professional as possible and let me know only when complete. Use NextJS.
    • エラー対応と完成したサイトの確認
      • エラー発生と修正:
        ・ターミナルで npm run dev を実行し、ブラウザ(localhost:3000)で開いたところエラーが発生。
        ・エラー文をそのまま解説なしでCursorにペーストして再投入したところ、即座に修正された。
      • 完成したサイトのレビュー:
        ・デザインは「エンタープライズ×エッジ」のテーマに沿った、ダークモードを取り入れた美しい仕上がり。
        LinkedIn?から抽出された自己紹介や経歴タイムライン、ポートフォリオ用のセクションが綺麗に配置されている。
        ・プロフィールから自動取得した本物のメールアドレスへのリンクや、自身の既存ウェブサイトへのリンクも正しく機能している。
        ・エージェントへのシンプルな指示(と1回のエラー修正)だけで、LinkedIn?のPDFから情報を読み取り、デザイン性の高い機能的なNext.jsサイトが短時間で完成。
  5. OpenRouter?とVibe CodingでAI Digital Twinチャットを追加:
    • バックアップとバージョン管理の重要性
      • 新たな機能実装(YOLOコーディング)を行う前に、進捗を失わないためのチェックポイント(バックアップ)作成を推奨。
      • 本来は Git を使用して適切なcommitを行うべきであり、Gitに不慣れな場合の代替案として、フォルダごとのコピペを提案。
    • AIエージェントへの機能追加指示
      • AIエージェントに対し、経歴について回答できる「デジタルツイン(AIチャット)」機能の追加を指示。
      • 技術的な仕様として、OpenRouter? のAPI(APIキーは .env ファイルに格納)および同プラットフォーム上の有料版モデルの指定。
    • 実装結果の検証と「バイブコーディング」の課題
      • npm run dev でローカルサーバー(Localhost 3000)を起動し、動作確認
      • UIは一般的なチャット画面とは異なるユニークなデザインで生成され、経歴に関する質問(「最も誇りに思っていることは?」など)に対して適切な回答を返した。
      • 一方で、画面起動時に不自然にスクロールする挙動や、一部のボタンが反応しないといった「バイブコーディング」特有の粗さ(バグ)も見つかった。
    • 今後のステップ(リファクタリングと改善)
      • 検証なしで進めるMVP(最小限の試作品)開発としては機能しているものの、今後はテストを徹底し、繰り返し改善(イテレーション)していく必要がある。
      • ソースコード(src/app/api/chat/route.ts)から、現状のシステムプロンプトは非常にシンプルであるため、プロフィール情報などをプロンプトに組み込むといった改善を検討。
  6. チュートリアル、Opusによるコードレビュー、クロスモデルコラボレーション:
    • チャットUIの改善とトラブルシューティング
      • 課題と解決策:チャットのスクロール問題やプロンプトの修正をAI(Codex)に指示。UI色の不具合修正で4〜5回往復したため、細かい指示をやめ「再構築する」というアプローチを取り、成功させた。
        いいえ、うまくいきません。別の方向性で進めませんか?このデザイン要素は削除してください。2026年現在、見た目も使い勝手も優れた、モダンなチャットウィジェットを使ってみませんか?別のモダンなチャットウィジェットで再度試してみてください。
        No it's not working. Please can we go a different direction - please take out this style stuff. Can we use a different Chat widget, something modern as of 2026, with a really great look at feel. Try again with a different, modern chat widget.
      • 教訓:AI開発で泥沼にハマった(同じミスを繰り返す)時は、原因究明に時間をかけるより、別のアプローチで作り直させた方が早い場合がある。
    • AIによるチュートリアル作成と学習
      • ローカル環境(npm run dev)での動作確認後、初心者向けの包括的なチュートリアル(Markdown形式)の作成をAIに指示。
        それでは、フロントエンドコーディングの完全な初心者向けに、ここであなたがやったことを順を追って説明する、包括的なMarkdown形式のチュートリアル(tutorial.mdというファイル名)を作成してください。技術の概要、概要説明、詳細なコードレビューを含めてください。
        Please now write me a comprehensive tutorial in markdown called tutorial.md that is suitable for a complete beginner in frontend coding, to walk me through what you have done here. Include a summary of the technology, a high level walk through, and a detailed code review...
      • AI自身にコードを客観的に評価させると同時に、人間の開発者がコードの構造やフロントエンド・バックエンドの仕組みを深く理解するための学習教材として活用できる。
    • 異なる複数のLLM(AIモデル)によるクロスレビュー
      • アプローチ:開発を担当したCodexから、より強力なモデルであるAnthropicのOpus 4.5へと切り替え、コードレビュー(review.mdの作成)を指示。
      • メリット:環境変数(.env)の扱いに関する潜在的なリスクなど、客観的で高精度な改善点(アクションプラン)を洗い出し、レビュー結果を再びCodexに読み込ませて修正させる、といったAI同士の連携が可能。
    • 総括と次のステップ
      • 今回の手法は「YOLOコーディング(vibe coding)」に「チュートリアル作成」と「別モデルによるコードレビュー・修正」を組み合わせることで品質を担保する開発サイクルと言える。
      • 開発がうまくいかない時は「徹底的にシンプルにする(simplify)」ことがコツであり、本番環境へのデプロイ(Vercelなど)を希望する場合は、それもAIに手順(ToDo?リスト)を出させると良い。

Day 5

27-33

  1. Karpathyが語るVibe Codingと商用MVP構築のルール:
    • 「バイブコーディング(Vibe Coding)」をビジネスに活かし、収益化が可能な商業用MVP(実用最小限の製品)を構築。今回はルールを厳格に守ることで成功へと導く手法を実践。
    • 元OpenAIの著名な研究者アンドレイ・カーパシー(Andrej Karpathy)の時系列のツイート(https://x.com/karpathy/status/2015883857489522876)を基に、本質と現状(2026年現在)を考察。
      • バイブコーディング誕生:LLM(Cursor Composer や Claude 3.5 Sonnetなど)の進化により、コードの存在を忘れて「ノリ(Vibes)」で開発する新しい手法が生まれた。
      • 急激な進化への困惑:エージェント、プロンプト、MCP(Model Context Protocol)、ワークフローなどの技術が乱立し、プログラマーですら圧倒される時代になっています。
      • カーパシー自身の開発スタイルも、かつての「手動補完80%:エージェント20%」から、現在は「エージェント80%:手動修正20%」へと逆転。
    • エージェント開発における重要な気づき
      • 過剰なハイプへの警戒(Watch it like a hawk):「IDEは不要」「エージェントの群れ(Swarm)がすべて解決する」といった過度な期待。モデルは確実に間違えるため常に挙動を監視。
      • 不屈の精神と生産性の「拡大」:エージェントは疲弊せず、働き続ける。その恩恵は単なる「生産速度」というより「生産量」として現れる。
      • 面倒な定型業務やエラーの泥沼から解放されるため、コードを書くこと自体よりも「モノを組み立てる(ビルドする)こと」に喜びを感じる人にとって、刺激的で楽しいものになる。
      • スキルの退化(Atrophy)と粗悪なコード(Slop)の氾濫に対する懸念もある。今後は、絵文字だらけの冗長なコードではなく、簡潔で洗練されたコードが強く求められる。
    • バイブコーディングを成功させるための実践ルール
      • 開発者がジュニアであれシニアであれ、成功のために共通する鉄則は「自分がボス(主導権を握る存在)になる」こと。
      • 事前準備の徹底:AGENTS.md などのファイルに、仕様、開発スタイル、成功基準を簡潔かつ明確に言語化して投資する。
      • 段階的な開発と検証:常にシンプルに始め、少しずつ機能を追加(インクリメンタル開発)し、毎回テストを行って検証。
      • 怠惰にならない:AIの出力を鵜呑みにせず、常に根拠(エビデンス)を求める。
      • フラストレーションの管理:AIが同じエラーを繰り返すなど、壁にぶつかった時は一歩引いて、アプローチを変える柔軟性を持つ。
    • 開発者の役割
      • ジュニアエンジニア:AIを「知識はあるが先走って失敗する熱意ある部下」と見立て「マネージャー」として振る舞うことが学びと成功につながる。
      • シニアエンジニア:コーディングから解放された分、より大きな価値構築に集中し、自身の専門知識をAIへの挑戦やクオリティコントロールに活かす。
    • 結論
      • YOLOに対する過度な期待は捨て、メリットとデメリットを正しく理解した現実的なマインドセットを持つことが重要。
      • タカのように監視し(Watch it like a hawk)、一歩一歩着実にビルドしていく姿勢で、この新しい開発体験を心から楽しむ。
  2. Webアプリ基礎:フロントエンド、バックエンド、API、Dockerセットアップ:
    • フロントエンドとバックエンドの基本
      • フロントエンド:
        ・ユーザーのブラウザ(ChromeやSafariなど)側で動作する部分。HTML/CSS/JavaScript、React、Vue、Angular、SvelteなどSPAフレームワーク。上位フレームワークとしてNext.jsがある。
        ・LLMやコーディングエージェントはフロントエンド構築が得意だが、出力が画一的になりがち。そのため、UX/UIの整理や差別化において人間のスキルが価値を発揮。
      • バックエンド:
        ・サーバー側で動作する部分。ビジネスロジック、データアクセス、実行
        ・LLM(大規模言語モデル)の呼び出し、API連携、パスワード(.envファイルなど)の管理を行う。
      • 本日のプロジェクトでは、
        ・フロントエンドにJavaScript、バックエンドにはLLM連携で最も一般的なPythonを使用。
        ・ユーザーの操作結果を処理するフロントエンドはAPIコールを介してバックエンドとデータの送受信を行う。
    • Dockerの基礎
      • Dockerは、PCの内部に隔離された仮想的なコンピュータ(環境)を構築する軽量なツール。安全性の確保(外部環境を壊さない)や高いポータビリティ(どこでも同じように動く)というメリットがあり、エージェントを活用したコーディングにも重要。
      • 主要な3つの概念:Dockerは、Dockerfileを使ってDocker Imageをビルドし、そのImageからDocker Containerを起動する。ContainerはImageの読み取り専用レイヤーの上に書き込み可能レイヤーを追加して動作し、その仕組みとしてCopy-on-Writeが利用されている。
      • インストール:公式サイト(docker.com)から「Docker Desktop」をダウンロードしてインストール。WindowsではHyper-VではなくWSL2の利用を推奨だが、VS CodeからWSL拡張(ms-vscode-remote.remote-wsl)を使用して直接Dockerコマンドを実行しても良さそう。
  3. GitHub CopilotとFastAPIでフルスタックプロジェクトをセットアップ:
    • 開発環境の準備(GitHub Copilot と VS Code)
      • GitHub Copilot の利用:前回の「Cursor」に続き、今回は「GitHub Copilot(Proプラン)」を使用。拡張機能の設定や、月ごとのリクエスト使用量(クォータ)の確認方法を解説。
      • ローカル環境のセットアップ:教材リソースにあるリポジトリ「PM」のURL(https://github.com/ed-donner/pm.git)をコピー、
      • VS Codeのターミナルで git clone を実行。Gitクローンした「PM」ディレクトリをVS Codeで開き、開発の準備を整える。
    • 既存リポジトリから開発を始める理由
      • ゼロからの構築(Scaffolding)はAIエージェントにとって容易だが、既存のコードを引き継いで開発・拡張する方が難易度が高く、実践的であるため。
      • 今週前半に構築した「Kanban(カンバンボード)のフロントエンドMVP」を、他チームから引き継いだコードと見立てて拡張していく。
    • プロジェクトの要件と実装ミッション
      • 既存のフロントエンド(純粋なデモ画面)に、バックエンド、データベース、APIを統合し、データが永続化される「本物のプロジェクト管理ツール」へと昇華させる。
      • コーディング・エージェントを活用するだけでなく、アプリ内にも「プロジェクトについて質問・操作できるAIチャット機能」を実装。
      • MVPの制限事項:単一ユーザーのサインイン(ID/パスワードはハードコード、ただし拡張可能なDB設計にする)。ユーザー毎に1カンバンボードのみ。Dockerコンテナ環境で実行。
    • 技術選定とファイル構成
      • フロントエンド:Next.js(既存のカンバンUIを流用)
      • バックエンド:Python (FastAPI)
      • パッケージマネージャー:uv
      • データベース:SQLite(ローカル)
      • AI API:OpenRouter?(.env ファイルにAPIキーと使用モデルを定義)
      • インフラ:すべてをDockerコンテナにパッケージングする。
    • プロジェクトのファイル構造
      • frontend/:既存のKanban MVPが格納されている。
      • backend/:空の状態(agents.mv のみ)。
      • front scripts/:空の状態。
      • .env / .gitignore: 環境変数(APIキー等)とGit除外設定。
      • AGENTS.md:プロジェクトの要件、技術選定、コーディング基準がまとめられた指示書。
      • docs/plan.md: 次のステップで確認する、計画と実行のためのドキュメント。
  4. GitHub Copilotでステップバイステップ構築:計画と足場作り:
    • 全体方針と開発哲学
      • 計画と制約(ガードレール)の重要性:ハイレベルな計画をAIにすべて丸投げすることも可能だが、自分の意見や意図を反映させるために、あらかじめ人間が10個のプロセス(骨子)を用意し、AIの行動に「ガードレール」を設けることを推奨。
      • 段階的なcommitと検証:一気に10ステップを進める(YOLOモード)では高確率で脱線し失敗。そのため、1ステップごとに「テスト」「確認」「Gitコミット」を行い、いつでも戻れる状態を作りながら確実に行うのが、堅牢なシステムを築く最善の方法。
    • プロジェクトの10段階計画(ハイレベルプラン)
      • 計画(Plan):本プランの具体化(チェックリスト、テスト、成功基準の作成)と、既存コードを解説する AGENTS.md の作成。
      • 足場固め(Scaffolding):Docker、FastAPI(バックエンド)のインフラ構築、起動/停止スクリプトの作成、Hello WorldおよびAPI呼出のローカル確認。
      • フロントエンドの追加:デモ用のKanbanボードを表示・サーブする。
      • ダミーのユーザー・サインイン機能の実装。
      • DBモデリング:スキーマの構築、ドキュメント化、ユーザー承認。
      • バックエンドAPIルートの追加:Kanbanの読み書きルート作成、徹底的なテスト、DBの自動生成。
      • フロント・バックエンドの結合: フロントからバックエンドを叩き、カードの移動やログイン状態がDBに反映・保持されることを確認。
      • AI接続:OpenRouter?経由でAIを接続し「2 + 2」のような単純な計算でテスト。
      • AI機能の拡張:Kanbanボードのデータと質問をAIに送り、回答やボードへの変更提案を受け取れるようにする。
      • チャット・ウィジェットの追加:フル機能のAIチャットを搭載し、AIが直接Kanbanボードを操作できるようにする。
    • 実際の進行
      • 計画(Plan)
        ・計画の具体化の実行:AI(GPT 5.2モデル)に対し、「まだ作業は始めず、まずは質問があるか確認してほしい」と指示。
        AGENTS.mdと計画書をよく読んで、ご質問があればお知らせください。まだ作業は始めないでください。
        Please revie AGENTS.md and the plan, and let me know if you have any questions. Do not do any work yet.
        ・AIから確認があり、
        AGENTS.mdとdocs/PLAN.mdを確認しました。作業開始前に質問があります。
        Reviewed AGENTS.md and docs/PLAN.md. Questions before starting:
        1. PLAN.mdに詳細なチェックリスト、テスト、成功基準を追加する作業は、今すぐ行うべきでしょうか、それとも編集前に明確な承認を待つべきでしょうか?
        1. Do you want me to enrich PLAN.md with detailed checklists, tests, and success criteria now, or wait for your explicit approval before any edits?
        2. フロントエンドのAGENTS.mdは、計画の充実化の一環として作成すべきでしょうか、それとも計画承認後に作成すべきでしょうか?
        2. Should I create the frontend AGENTS.md as part of the plan enrichment step, or only after plan approval?
        3. 「包括的なテスト」に関して、最低限のカバレッジ目標や、優先すべき特定のテストタイプはありますか?
        3. For "Comprehensive tests," do you have minimum coverage targets or specific test types you want prioritized?
        ・人間がそれを承認。
        1. はい、PLAN.md を作成してください。
        1. Yes entich PLAN.md
        2. はい、フロントエンド用の AGENTS.md をすぐに作成してください。
        2. Yes create. AGENTS.md for frontend right away
        3. 単体テストのカバレッジは最低 80%、かつ堅牢な統合テストを実施してください。
        3. 80% unit test coverage minimum, and robust integration testing.
        パート 1 に進んでください。
        Go ahead with Part 1
        ・AIは指示通り、各ステップにチェックボックスや成功基準を盛り込んだ詳細な AGENTS.md、PLAN.md を追加
        PLAN.mdには、各ステップ1-10にチェックリスト、テストリスト、成功基準リストが作成されている。
        ・人間がレビューして承認。
        確認済み。承認済み。ステップ2へ進みます。
        confirmed. Approved. On to step 2
      • 足場固め(Scaffolding)
        ・本フェーズの実行を許可したところ、AIは「実装完了」と報告してきたが、実際には自身でのテストを実行していなかった。
        確認後、パート3に進みます。パート2はご自身でテストされましたか?いいえ。まだテストは実行していません。
        Confirm and I'll proceed to Part 3. did you test part 2 yourself? No. I did not run tests yet.
        ・「自分でテストしたのか?」と問い詰め、サーバーを起動して徹底的にテストするよう再指示。
        徹底的にテストを実行してください。サーバーを起動し、正常に動作することを確認し、ルーティングをチェックし、サーバーを停止させてください。問題がないと確信できたら、私に知らせてください。
        please run tests thoroughly. Bring up the server, make sure it works, check the routes, bring it down, let me know when you are confident.
        ・過程で、uvではないPKGマネージャを使用するなど不信感を誘う挙動やテストの失敗が発生。AIが実行するコマンドを1つずつ確認・承認、再指示しながら進めた。
      • 結論(ユーザーへのアドバイス)
        ・AIが提示する「できました」を鵜呑みにせず、立ち止まってテストを実行させ、ログを確認することが重要。
        ・初心者にとっては、AIがどのように工程を進めているか観察・質問すること自体が、最高の学習機会(教材)になる。
  5. GitHub Copilot、Docker、FastAPIでKanbanアプリを構築:
    • パート2の検証と完了
      • 環境構築の確認:AIがPKGマネージャのuvを使用せずpipを使用したが動作するため受け入れた。DockerファイルがPython 3.12を使用していることを確認。
        requirements.txtが必要な理由を説明していただけますか?uvを使用していると思っていたのですが。
        can you explain why you needed a requirements.txt -I thought we were using uv
        uvには依然として依存関係リストが必要です。コンテナ内のuvの最もシンプルなソースとしてrequirements.txtを使用しました(uvはrequirementsまたはpyproject/uv.lockからインストールできます)。ご希望であれば、pyproject.tomlとuv.lockに変更することも可能です。
        uv still needs an input list of dependencies. I used requirements.txt as the simplest source for uv in the container (uv can install from requirements or pyproject/uv.lock). If you prefer, I can switch to pyproject.toml + uv.lock instead.
      • 動作確認:実行スクリプト(start_mac.sh)の権限エラーを貼り付け、コレをAIに修正させ、ローカルサーバー(localhost:8000)を起動。ヘルスチェックとAPIの挙動が正常であることを確認。
        この部分を自分でテストする方法を教えてください
        please tell me how I test this part myself
        (エージェントに依るテスト方法に関する回答)
      • 成功基準の評価:テストカバレッジ80%の達成や他OSでの検証はスキップされているが、全ルートの動作確認ができたため、パート2を完了とした。
        パート2が完了して良かったです。パート2の成功基準はすべて達成されましたか?
        that's good part 2 is done. Are all the success criteria for part 2 achieved?
        完全には達成されていません。コンテナの起動、ルーティング、テストは検証しましたが、80%のカバレッジの測定やPC/Linux上でのスクリプトの検証は行っていません。
        Not fully. We verified container start, routes, and tests, but we did not measure 80% coverage or validate scripts on PC/Linux.
        PC/Linuxについてはスキップしても構いません。すべてのルートをテスト済みであることも確認済みです。これで完了として、パート3に進みましょう。
        I'm good to skip the PC/Linux - and I can confirm I've tested all the routes. Let's mark that complete and proceed with part 3
    • パート3:フロントエンド(カンバンボード)の実装
      • カバレッジの罠:AIは「テストカバレッジ80%」という指示を厳密に守ろうとするあまり、価値の低い複雑なテストの作成に膨大な時間(約10分)を費やした(LLMが規則の文面に囚われすぎる罠)。
      • 画面の確認:カンバンボード(Kanban Studio)の静的フロントエンドが正常に表示され、タスクの移動ができることを確認した。
      • 指示の修正:パート4へ進む際、AIに対し「無意味なテストを避けて価値のあるテストに集中し、カバレッジ80%に達しなくても構わない」と軌道修正(再指示)。
        承認済み - パート4へ進みます。ところで、今後は、テストカバレッジが80%に達するのが妥当な場合のみ、計画を更新してください。80%を達成するためだけに不要なテストを追加することは避けてください。価値のあるテストに集中してください。80%に達しなくても問題ありません。
        approved - move to part 4. By the way, going forwards, please update the plan to only achieve 80% test coverage if it's sensible to do so; avoid adding unnecessary tests just to hit 80%. Focus on valuable tests; not hitting 80% is ok.
    • パート4:認証機能の追加
      • 機能テスト:デモ用のユーザー名とパスワードでサインイン・ログアウトができること、またログイン後のカンバンボードの状態が維持されていることを確認し、成功とみなした。
      • 差分(Diff)の承認:変更された多くのファイル差分(緑と赤の行)について、ユーザーは「すべてを細かくレビューするのではなく、重要なものだけを注視すればよい」と考え、一括で変更を受け入れ。
    • Gitによる進捗の保存と次への準備
      • ローカルcommit:今後データベースを扱うパート5という「リスクの高いフェーズ」に入る前に、これまでの成果(パート1〜4)をGitでローカルリポジトリにcommitし、いつでも復元できる状態にした。
      • 開発者がAIエージェントの過剰なテスト作成癖をコントロールしつつ、バックエンド、フロントエンド、認証機能までを順調に構築・検証し、データベースの実装(パート5)に向けてGitで進捗を保存。
  6. GitHub CopilotでKanbanアプリ構築:ドラッグ&ドロップのデバッグ:
    • データベース設計の承認とPart 5・6の完了
      • Part 5:AIが提案したDB設計(DDL)を確認し、JSON保存より優れたアプローチであると判断して承認。
      • Part 6:バックエンドとフロントエンドの連携前の段階まで実装を終え、Gitコミット(Part 6 done)。
    • フロント・バックエンドの連携と不具合修正(Part 7)
      • 開発における最も重要なフェーズ。AIがテストの失敗とリライトを何度も繰り返しながら、約15分かけて実装を完了。
      • 動作確認とバグ:ローカルサーバー(localhost:8000)を起動してログイン。データの永続化(保存)は成功していたが、ドラッグ&ドロップの挙動にUIのバグを発見。
        サーバーを起動し、ユーザーとしてログインし、ボードにいくつか変更を加えました。その後、新しいブラウザを開いて再度ログインしました。しかし、変更内容が保存されていませんでした。私の理解が間違っているのでしょうか?
        I started the server, I logged in as the user, I made some changes to the board, then I opened a fresh browser and logged in again. My changes were not persisted. Did I misunderstand?
        あなたの理解は間違っていません。現在、フロントエンドはまだインメモリ状態を使用しています。バックエンドの永続化機能は実装されていますが、UIはパート7で初めてそれと連携します。
        You didn't misunderstand. Right now the frontend still uses in-memory state. The backend persistence is in place, but the Ul isn't wired to it until Part 7.
        パーシステンスは機能していますが、ドラッグアンドドロップは時々しか機能しないようです。ほとんどの場合、カードをドラッグすると次の列がハイライト表示されますが、カードを離すと元の位置に戻ってしまいます。問題を再現し、徹底的にテストして修正してください。修正が完了したことを確認させていただきます。
        the persistence is working, but the drag and drop seems to only work occasionally. Most of the time, I drag a card, the next column highlights, but when I release the card goes back to its original position. Please test thoroughly, reproduce the problem, fix it id confirm it is fixed.
      • AIによるデバッグ: バグ修正をAIに指示したところ、AIは30分間にわたりループ状態に陥る。開発者が手動で確認すると、正常に動作していた。ここで「人間の介入」の重要性を再認識。
        今テストしてみましたが、すべて正常に動作しています。素晴らしいです。既に修正していただいているようですね。Playwrightのテストが正しく機能していなかったのではないかと思いますが、今はすべて問題ありません。
        I've just tested it and everything is working. It's working great. You've already fixed it. I suspect your Playwight tests weren't working, but everything is fine.
        承知いたしました。これで作業を終了いたします。ご希望であれば、後ほどPlaywrightのドラッグテストを見直して、より信頼性の高いものにすることも可能です。
        Understood. I'll stop here. If you want, I can review the Playwright drag test later to make it more reliable.
      • ドラッグ&ドロップとデータの永続化が完全に動作することを確認し、Gitコミット(part 7 working)。
    • Contextウィンドウ対策と次への準備(Part 8へ)
      • コンテキストの肥大化問題:開発がPart 7まで進んだことで、AIのContextウィンドウ(記憶容量)が一杯になりつつある。
      • チャットのリセット:効率的な開発を維持するため、現在のチャットを一度終了して新しいチャットで再開する手法をとる。
      • 事前にこれまでの設計方針や進捗を PLAN.md(計画ファイル)に最新状態として書き出すようAIに指示。
        PLAN.mdが、あなたが下した設計上の決定事項を含め、すべての最新情報に更新されていることをご確認ください。準備が整いましたらご連絡ください。
        please confirm that PLAN.md is up to date with all the latest, including any design decisions that you made. Let me know when ready.
      • Gitに最終commitを終えた後、新規チャット(New Chat)を開き、AI連携機能を実装する「Part 8」へと移行した。
  7. AIアシスタントKanbanアプリ完成:GitHub Copilot、OpenRouter?&Week 1 まとめ:
    • 開発プロセスの進捗(パート8〜10)
      • 新しいチャットセッション(コンテキストがクリーンな状態)を立ち上げ、AIモデル(Codex)に指示を出して開発を進めた。
        チャットの会話をリセットしたことで最初はサーバーの起動方法をAIが忘れてしまい、5分ほど手こずるトラブルがあったものの、無事にテストを通過。Gitコミット。
        > パート8を開始する前に、まずAGENTS.mdを読んでからPLAN.mdを読んで、ご質問があればお知らせください。
        Please read AGENTS.md then read the PLAN.md and let me know any questions before we start Part 8.
        AGENTS.mdと計画書を確認しました。パート8の前に質問があります。
        I reviewed. AGENTS.md and the plan. Questions before Part 8:
        1. パート8の「2+2」統合テストでは、完全にモック化(実際のHTTPリクエストなし)するか、OpenRouterクライアントのみをモック化しつつバックエンドエンドポイントにアクセスするか、どちらが良いでしょうか?
        1. For the Part 8 "2+2" integration test, do you want it fully mocked (no real HTTP), or should it hit the backend endpoint while mocking the OpenRouter client only?
        2. 新しいAIエンドポイントは、/api/ai、/api/chat(または別の命名規則)のどちらにすべきでしょうか?
        2. Should the new Al endpoint be under /api/ai or /api/chat (or another naming preference)?
        3. OpenRouterのベースURLは、環境変数などで設定可能にするか、現時点では標準のOpenRouter API URLにハードコードするか、どちらが良いでしょうか?
        3. Do you want the OpenRouter base URL configurable (e.g., via env), or hardcoded to the standard OpenRouter API URL for now?
        > 1. 実際には、モック化せずにOpenRouterまでアクセスし、モデルから応答が得られるかどうかを確認したいです。 2. /api/chat は良いですね。 3. 現時点ではハードコードで問題ありません。
        1. Actually I want it to go all the way to OpenRouter-no mocking - let's check we can get an answer from the model. 2./api/chat sounds great. 3. hardcoded is good for now.
        >サーバーの起動、停止、テストを効果的に行う方法について、詳細を習得されたようですね。今後の参考のために、PLAN.md を更新してください。また、パート 8 のチェックリストも更新してください。
        If seems you learned some details about how to start, stop and test the server effectively. Please update PLAN.md so that this is recorded for the future. Please also update the checklist for Part 8.
        パート8のチェックリストのステータスを更新し、PLAN.mdにテストノートセクションを追加して、使用した開始/停止/テストの流れを記録しました。
        Updated Part 8 checklist status and added a testing notes section in PLAN.md to capture the start/stop/test flow we used.
      • パート8(OpenRouter?の統合):モック(擬似データ)を使わず、外部AI(OpenRouter?)に直接APIリクエストを送信するよう実装。
        この部分の会話の状況は共有されなかった。
      • パート9(リアルデータのテスト):AIが当初モックテストで済ませようとしたため、実際にOpenRouter?経由でテストするよう促して完了。Gitコミット。
        この部分の会話の状況は共有されなかった。
      • パート10(UIの実装と動作確認):AIアシスタントのチャット画面をフロントエンド(画面右側)に実装。
      • 実機デモの成功:(IDEではなくアプリの)チャットで「プロジェクトを要約して」「このカードをBacklogからDoneに移動して」と指示
        画面上のカンバンカードが自動で動き、そのデータがバックエンド(Docker、データベース)を介してディスクに永続化(別ユーザーでのログインでも同期を証明)。
    • 現状の課題と今後の「課題(アサインメント)」
      • アプリの最小限の機能(MVP)は完成したものの、コードの品質や設計には改善の余地があります。
      • メインコード(main.py)の肥大化:モジュール化、スパゲッティ・コード。本来なら別のAIエージェントにコードレビューをさせて指摘を受けるべきレベル。
      • 第1週目の課題: ベースアプリを元に拡張を各自で行う:リファクタリング、UIの改善、DBのBaaS移行、CaaSへのコンテナデプロイ
    • 「バイブ・コーディング」の総括と今後の展望
      • アンドレイ・カルパシー氏の言葉:「2024年12月頃を境に、LLMエージェント(特にClaudeやCodexなど)の能力は一線を越え、ソフトウェアエンジニアリングにパラダイムシフトを起こしている」という言葉を引用し、現在のAI開発の熱量を強調。
      • 第1週目の振り返り:「楽しむためのバイブ・コーディング(Vibe Coding)」をテーマに、FPSゲーム、デジタルツイン付きの個人サイト、そして今回の商用化も狙えるAIアシスタント付きカンバンボード(MVP)の3つを構築。これでコース全体の33%が終了。
      • 第2週目の予告:単に雰囲気で書く「バイブ・コーディング」から、よりプロフェッショナルな「バイブ・エンジニアリング」へとステップアップ。CLIツールの「Claude Code」を本格的に導入し、実践的な開発手法を学んでいく。

Week 2

Vibe Engineering as a professional(バイブ・エンジニアリング:プロフェッショナル向け)

Day 1

34-39

  1. Pro Week へようこそ:Vibe Coding から Vibe Engineering へ
    • プロ向けの2週の幕開けとコアツールの導入
      • 応用・発展フェーズへの移行:基礎的なスキルを習得した第1週を終え、第2週からは、より深く、プロフェッショナルでハードコアな実践を行うプロ週へと移行します。
      • Claude Codeの導入:今週のプラットフォーム・プロダクト(Yellow Day)の目玉として、今後2週間の中心的なツールとなるCLIツール「Claude Code」を導入。あわせてOpenCode?などの他のCLIツールも扱う。
    • AIコーディングの進化と今週のアプローチ
      • 進化のステージ:AIコーディングは、単なるChatGPTの利用(第1週の内容)から、第2週の「ステージ5(CLIツールやエージェントの本格活用)」、そして第3週の「オーケストレーション・プラットフォーム(マルチ・エージェントのスウォームなど)」へと進化。
      • 開発スタイルとマインドセット:ミッションクリティカルな大規模コードや革新的なコードでは「計画・実行・レビュー・テスト」のステップを踏む「信頼せよ、されど確認せよ(Trust but verify)」のマインドセットが不可欠。
      • 一方で、リスク許容度が高いMVP(最小限の試作品)やボイラープレート(定型)的なフロントエンド開発では、より大胆な自動化(YOLOやRalph loops)を取り入れる。
      • どのような手法であれ、コードの品質と動作に対する最終的な責任と説明責任(Accountability)は開発者自身にあるという原則が強調される。
    • 「バイブ・エンジニアリング(Vibe Engineering)」への昇華
      エンジニア・ライターのSimon Willison氏のブログ記事を引き合いに、今週のテーマ「バイブ・エンジニアリング」の概念を説明。
      • バイブ・コーディングとの違い:
        ・「バイブ・コーディング(Vibe Coding)」:プロンプト主導でコードの仕組みを深く考えずに素早く大雑把に作る。
        ・「バイブ・エンジニアリング(Vibe Engineering)」は、熟練のプロがLLMの恩恵を受けて生産性を高めつつ、品質への説明責任を100%保持するスタイル。
      • プロのAIエンジニアリングに求められるスキル:
        ・厳格なプロセス:事前の計画、綿密なドキュメント作成、自動テストの組込、GitやClaude Codeの機能を活用したバージョン管理。
        ・高度なマネジメント・レビュー力:LLMに自身の成果物をレビューさせる文化、手動QA(品質保証)、AIがサボったり誤魔化したりしないように管理する能力。
        ・切り分けの直感:AIに「任せられるタスク(フロントエンドなど)」と「任せられない/注意が必要なタスク(バックエンドやリファクタリング)」を正しく判断する直感。
        ・見積もりの罠への対処:AIはコードを瞬時に生成できる反面、一度壁にぶつかると解決に数時間を要する特有の性質があるため、それを考慮したプロジェクトの見積もりを行う。
  2. Claude Code の台頭:歴史、セットアップ、VS Code へのインストール
    • Claude Codeの歴史と進化
      • 誕生と普及:2024年末にAnthropicのエンジニア(Boris Cherny氏)のサイドプロジェクト「Claude CLI」として始まり、2025年4月に正式リリース(一部には2025年2月)され、CLI型コーディングツールの先駆けとなった。2025年後半には爆発的に普及した。
      • V2へのアップデート(2025年9月):チェックポインティング、サブ・エージェント、フック、スキル、バックグラウンドタスクなどの機能が成熟し、エコシステム内でコードを書くための「Claude Code SDK」も導入された。
      • 性能の転換点(2025年11月):超強力なモデル「Opus 4.5」のリリースにより、LLMコーディングエージェントの信頼性が劇的に向上。差分(diff)を毎回確認しなくても任せられるレベルに達し、エージェントによるコーディングの大きな転換点となった。
      • ビジネスと今後の展開:AnthropicはClaude CodeによりARR(年間経常収益)10億ドルを達成。さらに、汎用タスク向けツール「Cowork」や、オープンソース版の「OpenClaude?」、MCPエコシステムとの連携など、多方面への投資と拡大を続けている。
    • 料金プランと推奨設定
      • プランの種類:無料プラン、Proプラン(月額20ドル)、高級なMaxプラン(月額100ドル/200ドル)が存在。
      • 推奨環境:無料モデルや安価なモデルをClaude Code経由で使う方法もあるが、最高の体験を得るためには「Proプラン(サブスクリプション)」への加入が強く推奨される。
    • インストールとセットアップ
      • 本体のインストール:code.claude.com から各OS(Mac/Windows)用のコマンドをコピーし、VS Code等のターミナルに貼り付けて実行するだけで簡単にインストールできる(動画内ではバージョン 2.1.29)。
      • VS Code拡張機能:Anthropic公式のVS Code拡張機能(Claude Code for VS Code)も提供されており、サイドバーから利用可能。
    • 本コースにおける利用方法(ターミナル重視)
      • Claude CodeをVS Codeで使うには「サイドバー(拡張機能)」と「ターミナル(CLI)」の2種類の方法があり、サイドバーは初心者向けで機能が制限されている。
      • ココではより高度な「バイブエンジニア(Vibe Engineer)」を目指すため、プロ向けの全機能が利用できる「ターミナル(CLI)」での操作をメインに扱う。
  3. Claude Code CLI 入門:Init、Context、Testing
    VS Code上で前週のプロジェクトを開き、ターミナルからAnthropic社の新しいCLIツール「Claude Code」を起動して初期設定とテストを実行する手順を説明。
    • プロジェクトの準備とClaude Codeの起動
      • 前週のプロジェクト(PM)を開き、Gitで未commitの変更をステージング commitして最新状態にした。
      • 新しいターミナルを開き、claude コマンドを入力して Claude Code CLI を起動した。
      • インタフェースは意図的にレトロなCLIスタイル(キャラクターやラインで描画される古い学校のような雰囲気)。
    • ログインと初期設定(/init)
      • 初めて使用する場合は、/login コマンドでAnthropicアカウントにサインイン
      • 従来の拡張機能で使われていた AGENTS.md の代わりに、Claude Codeでは CLAUDE.md を使用する。
      • /init コマンドを実行すると、Claudeがディレクトリ構造を自動分析し、VS Code上で差分(diff)を示しながら CLAUDE.mdを自動生成
      • 注意: 最初はClaudeに下書きをさせても、最終的には人間の監督者が自ら CLAUDE.md を推敲・作成することを強く推奨。
    • 操作方法とUIの特徴
      • Claudeへの命令は通常入力で行い、コマンドを実行する場合はスラッシュ(/)を使用
      • Claudeからの編集提案に対し、ユーザーはテンキーで応答(1:はい、2:はい、かつセッション内の全編集を許可、3:いいえ)。また、Tabキーを押して追加の指示を与えることも可能。
    • コンテキスト管理(/context)
      • /context コマンドを使用することで、20万トークンという限られたContextウィンドウの使用状況を視覚的なメーターで確認できる。
      • メーターには「メモリ(CLAUDE.mdなど)」「メッセージ(対話履歴)」「空き容量」「コンパクション(メモリ圧縮)用のバッファ」が表示され、対話を重ねるごとに消費が進むため、注意深く管理する必要がある。
    • ドキュメントの読み込みとテストの自動実行
      • Claudeに docs/plan.md を読み込ませ、プロジェクトの構造をより深く理解させた。
      • テストの実行を指示した際、PC再起動直後で Docker Desktop が起動していないことを検知しコレを起動(高度な処理能力を称賛)。
      • バックエンドおよびフロントエンドの全テストが走り、すべてパスした結果がターミナル上に表形式で出力。
  4. Claude Code レビュー:ハルシネーションの修正とコードのリファクタリング
    開発者ツール「Claude Code」を使用して、リポジトリ全体の包括的なコードレビューからリファクタリング、バグ修正までを行う一連のプロセスを解説
    • Claude Codeによるコードレビューと「幻覚(ハルシネーション)」
      • Claude Codeの並列エージェント(バックエンド、フロントエンド、インフラ)を走らせ、リポジトリ全体のコードレビューを実施
        リポジトリ全体の包括的なコードレビューを実施し、docsフォルダ内のcode_review.mdにアクションを含むレポートを作成してください。
        Please carry out a comprehensive code review of the entire repo, and write a report with actions to code_review.md in the docs folder
      • レビュー中、Claudeは「.envファイル(機密情報)がGitに公開されている」と指摘したが、実際には.gitignoreに登録されており誤検出(LLMの幻覚)
      • これを指摘すると、Claudeは誤りを認めて謝罪し、レポートを修正「LLMの言うことを盲信せず、人間がチェックすることの重要性」を強調。
        .env は Git でどのように管理されているのでしょうか? .gitignore には確かに含まれていますが、GitHub には含まれていません。
        how is env in git? It's clearly included in .gitignore, and it's not in GitHub.
        おっしゃる通りです。確認してみます。...おっしゃる通りです。.env は git の ls-files.env では何も返されませんでした。ファイルはローカルに存在しますが、正しく gitignore に含まれています。レビューを修正します。
        You're right, let me verify. ... You're correct. .env is not tracked-git ls-files.env returned nothing. The file exists locally but is properly gitignored. I'll correct the review.
    • 指摘事項の修正とリファクタリング
      • 修正されたレポートには、バックエンド依存関係の未固定、Playwrightのハードコーディング、SQLインジェクションのリスク、そして肥大化した「main.py」の可読性の悪さなどが挙げられた。
      • 一括修正の指示:「重大・高・中」の課題の修正と再テストを指示したところ、Claudeは5分ほどで高速に処理し、テストもすべて合格した。
        承知いたしました。ありがとうございます。それでは、クリティカル、高、中優先度の問題すべてに対処し、すべてを再テストしてください。すべての問題が解決され、テストが正常になったらお知らせください。
        OK thank you, please go ahead and address all the Critical, High and Medium priority issues and restest everything and let me know when everything is remediated and tests ok.
      • 自律的な判断と追加指示:ただし、Claudeはコスト対効果を理由に「main.py」の構造変更(リファクタリング)を最初は敢えて見送った。再度を明確に指示したことで、リファクタリングされた。
        これは良いのですが、実際にはモノリシックなPythonモジュールを修正したいので、今すぐ修正して再テストしてください。main.pyをリファクタリングして、適切なモジュールとパッケージに整理してください。すべてをチェックしてテストしてください。
        this is good, but actually I really want to rememdiate the monolithic python module please do fix that now and then retest. Refactor main.py and organize into modules and packages as appropriate. Check and test everything.
    • Gitコミットとコンテキストの整理 (/compact)
      • 変更された大量のファイル(ヘルスチェックが追加されたDockerfileなど)を確認し、Gitコミット。
      • コンテキスト・ウインドウ肥大化の対応として、/context コマンドで、一連の大規模な作業によりClaudeのコンテキスト(記憶容量)が満杯になった事を確認、/compact コマンドで、履歴を要約・圧縮して空き容量を確保。
      • (チャットUIではPLAN.md等を更新してから新しいチャットを開始する運用が一般的だった。一方CLIでは /compact による履歴圧縮ができ、必要に応じてPLAN.md等へ永続化も行えるため、コンテキスト管理の自由度が高い。)
    • 現在のバージョン、使用しているモデル(最上位のOpus 4.5)、およびプランの利用制限枠(デイリー/ウィークリーの消費量)を確認できる/status コマンドについて説明。
  5. Open Code:GLM 4.7 などの無料モデルを Claude Code の代替として使う
    Claude Codeのオープンソースの競合ツールである「Open Code(opencode.ai)」の特徴、インストール方法、および実際の使用感について解説
    • Open Codeの特徴
      • 柔軟なモデル選択:独自の無料モデル(Open Code Zenなど)をはじめ、OpenAI(GPT)、Anthropic(Claude)、Google(Gemini)など、様々なプロバイダーのモデルを接続して利用可能。
      • 2つのモード:Tabキーで、行動を起こす前に思考させる「Plan(計画)モード」と、実際にタスクを実行する「Build(構築)モード」を切り替えられる。
      • 推論レベルの調整:Ctrl+Tで、モデルの推論レベル(Low〜Extra High)を切り替え可能、モデルは /models コマンドで切替られる。
    • インストールとセットアップ
      • Macではcurlコマンド、Windowsではchocoやnpm(Node.js環境)経由で簡単にインストール可能。
      • VS Codeのターミナルから open code コマンドを入力するだけで起動。
      • 起動時に環境内の既存のサブスクリプション(OpenAIなど)を自動検出し、自動で紐付けられる。
    • 無料モデルでのコードレビュー検証
      • 中国のスタートアップZ.aiの「GLM 4.7」(非常に強力なOSSモデル)を使用し、プロジェクト全体のコードレビューを実施(docs/code_review.mdを削除)。
      • Planモードでレビュー内容をじっくり考えさせた後、
        プロジェクト全体をレビューし、コードレビューを実施して、docs ディレクトリ内の code_review.md にフィードバックを記入してください。
        please review the entire project, carry out a code review, and write your feedback to code_review.md in the docs directory
      • Buildモードに切り替えて docs/code_review.md へファイル出力。
        docs/code_review.md にコードレビューを書いてください。ただし、それ以上の作業はまだ始めないでください。
        please go ahead and write the code review to docs/code_review.md but don't start any further work yet
      • 認証の脆弱性、TypeScript?の厳密さ、コードの重複、エラーハンドリングなど、非常に詳細で印象的なレビュー結果を出力。
      • ただし、Claude 4.5 Opusほどの自律性や確実なリファクタリング能力には及ばない印象。
    • プロバイダー接続とローカル実行
      • /connect コマンドを使用することで、Anthropic、GitHub Copilot、Google、Azure、Bedrock、Open Routerなど多数のプロバイダーやAPIキーと接続可能。
      • Ollama等を使ったローカル環境でのモデル実行にも対応しているが、実用的なOSSモデルを動かすには非常にハイスペックなPCが必要、無料枠かOpen Router経由での利用を推奨。
    • プラットフォームの組織力やモデルの安定性から「Claude Code」優れているが、Open Codeはモデルの切替、併用などについて優れた選択肢であり、使い分けが可能。
  6. Open Router と Ollama を使った AMP Code、Claude Code
    • AMP(AMP Code)の概要と特徴
      • 概要:特定のプロバイダーに依存しないエージェント型コーディングツール。ターミナルでの動作に加え、VS Code、Cursor、Windsurfの拡張機能としても利用可能。
      • Freeプラン:画面上部に表示される広告を見ることで、毎日10ドル分のモデル利用クレジットが付与されるシステム。
      • 仕様と機能:
        ・バックグラウンドで最適なAIモデルが自動選択される(文脈長からOpenAI系の上位モデルと推測)。
        ・3つのモード(smart: 標準、deep: じっくり思考、rush: 高速)を Control-S で切り替え可能。
        ・実際にプロジェクトのコードレビューを実行し、ハードコードされた認証情報などの致命的な問題を正確に検出した。
    • Claude Code を Open Router 経由で動かす(Kimi K2の例)
      • 概要:Anthropic公式の推奨環境ではないが、環境変数を書き換えることで、Claude Codeのインターフェースから外部のオープンソースモデルを呼び出す検証。
      • 設定方法:Mac/PCで環境変数を設定し、ベースURLをOpen Routerに、認証トークンをOpen Routerのキーに変更。デフォルトモデルをすべて中国のMoonshot AIの 「Kimi K2」 に指定して起動。
      • 結果: プロジェクトの目的を正しく説明できたが、複雑なコードレビューを実行した際は処理が破綻したため、オープンソースモデルの利用には試行錯誤が必要であると指摘。
    • Claude Code を Ollama でローカル実行する(GPT-OSS)
      • 概要:外部クラウドを使わず、自身のローカル・マシン(GPU)でClaude Codeを動かす検証。
      • 設定方法:環境変数を変更し、接続先をローカルホスト(localhost:11434)のOllamaに、モデルをローカル上の「GPT-OSS」に指定。
      • 結果:PCのGPUに高い負荷がかかり処理に時間は要したものの、「プロジェクト概要の要約」や「ハードコードされたパスワードの検出」を正しく実行できた。
    • AIコーディング環境は、幅広い選択肢と拡張性がある。

Day 2

40-44

  1. Claude Code のコマンド、ショートカット、設定の徹底解説
    • 主要なSlashコマンド
      ツール内のみで実行され、Claudeへのプロンプトとしては送信されない各種コマンド、/x ↵ で開始、ESCで終了。
      • /↓、/help:使用可能なコマンドの一覧や簡単な説明、ショートカットキーの概要を表示
      • /init:プロジェクトを初期化し、CLAUDE.mdファイルを新規作成
      • /model:使用中のモデルを確認・変更(例:上位プランでのOpusなど)
      • /status:ステータス(進行状況)、コンフィグ(各種設定)、Usage(モデルごとのトークン消費量)を表示
      • /context:現在のメモリ(コンテキスト)状況をプリントアウト
      • /compact:会話履歴を圧縮してリセット。残したい情報の要約指示を加えることも可能。
      • /clear:会話履歴を完全に消去し、初期状態(AGENTS.mdなどの読み込み時点)に戻す。
      • /permissions:Claude Codeが持つ実行権限の確認やルールの追加・削除を行う。
    • ショートカットキーとモード
      • Ctrl + O:詳細なトランスクリプト(ログ)モードのオン/オフを切り替え、より詳細な動作情報を表示
      • Shift + Tab:「Plan Mode(計画優先)」「Accept Edits(編集の自動受け入れ)」モードを切り替える
        ただしOpus等の進化により、現在はモデル自身が判断するためPlan Modeの強制はあまり使われない。
    • 設定とファイル管理のテクニック
      • 権限管理(.claude ディレクトリ):JSON ファイル(パーミッションファイル)を直接編集することで、Claude Codeに許可する操作の権限を直接管理(追加・削除)
      • シンタックスによるファイル参照:プロンプトや CLAUDE.md 内で @ファイルパス と記述することで、そのファイルの内容をコンテキストに読み込ませることができる。
        #CLAUDE.md
        @AGENTS.md
        ## DETAILED PLAN
        @docs/PLAN.md
      • 効率的な活用例(ファイルの共通化)
        GitHub Copilot等の他ツールと設定を共通化したい場合、CLAUDE.md の中身を @AGENTS.md という1行だけにすることで、管理する設定ファイルを1つに集約できます。
        ・注意点: @ でディレクトリを指定した場合は、配下の全ファイルの中身ではなくファイル一覧が読み込まれる。コンテキストがすぐに埋まるため注意が必要。
  2. Sessions、Checkpoints、Git:Claude Code ワークフローの管理
    • ワークフロー管理における3つの手段
      Claude Codeでの作業状態を管理・復元するには、粒度の異なる3つのアプローチがある。
      • セッション(Sessions:高粒度)
        ・Claudeとの会話や文脈(コンテキスト)の完全な状態を記録するもの。
        ・任意のタイミングでセッションに名前を付けて保存(rename)でき、後からその状態を指定して再開(resume)できる。
        ※注意:復元されるのは「会話の文脈」のみであり、コードやリポジトリの状態は復元されない。
      • チェックポインティング(Checkpointing:低粒度)
        ・現在のセッション内における、プロンプト(指示)ごとのステップを記録。
        ・時間を一歩ずつ遡る「巻き戻し(rewinding)」が可能。
        ・会話だけでなく、Claudeが行ったコードの変更も元に戻せる。
        ・ただし、Claudeの知らないスクリプト等によって変更されたファイルは復元できない。
      • Git(コード管理の標準ツール)
        ・Claudeの文脈とは独立してコード全体の正確なスナップショットを記録。
        ・コードを過去の特定の時点へ確実に復元するための「本命」の手段。
    • おすすめのワークフロー
      • Gitの多用:コードの変更管理や過去への変更の巻き戻しには、チェックポイント機能よりも確実なGitコミットをメインに使う。
      • Markdownファイルでの進捗管理:過去のセッションを復元して文脈を追うのは混乱しやすいためMDファイルで進捗管理する方を好む。
    • セッション機能の実演(デモ)
      • Claudeに「皮肉っぽく(snarky)応答して」と指示
        今日の会話では、ぜひ機知に富んだ、皮肉の効いたやり取りをしてください。
        for our conversation today, I'd like you to be witty and snarky with me please.
      • そのセッションを「snarky Claude」と命名して一度終了
        > /rename snarky-claude
          L Session renamed to: snarky-claude
      • 普通にClaudeを起動してプロジェクトの要約を求めると、ビジネスライクで真面目な要約が返ってくる。
        > please summarize the project
        All 10 parts of the plan are complete the MVP is fully functional with login, persistent Kanban board, and AI-powered chat that can manipulate cards.
      • 一度終了し、今度は claude --resume で再開して「snarky-claude」を選択してから要約を求めると「皮肉混じりの」要約が返り、会話の文脈が復元されていることが実証される。
        > please summarize the project
        Current state: All parts of the plan are complete. You've got a working MVP with authentication, persistent data, and AI-powered card management.
        The vibe: "Keep it simple, don't over-engineer, prove problems before fixing them." Basically the opposite of most enterprise projects I've seen.
  3. Claude Code の Checkpoints、Rewind、YOLO Mode 解説
    Claude Codeを使用し、コードレビュー、シンキングプロセス確認、チェックポイント活用を行う。
    • コードレビューの実行とエラーの修正
      • 「プロジェクトの要約」と「コードレビュー」をClaudeに指示し、結果を review.md に出力
        > please do a code review and write results to review.md in the docs directory
        ...
        Do you want to make this edit to review.md?
          1. Yes
        > 2. Yes, allow all edits during this session (shift+tab)
          3. No
    • シンキングプロセスの可視化(ショートカットキー)
      • Ctrl + O:エージェントの思考トレース(詳細な思考プロセス)を展開・格納
      • Ctrl + E:すべてを表示し、もう一度押すと折りたたむ。
      • Ctrl + B:コマンドをバックグラウンドで実行させ、自身は別の操作を続ける。
    • Claudeは前回同様「.envファイルのAPIキーが露出している」と誤検知した。
      gitignoreにあるとは言わず、「本当に露出しているか?」と促すと、誤りを認めて自らファイルを修正。
    • チェックポイントとリワインドの仕組
      /rewind コマンドを使用することで、現在のセッション内の特定のチェックポイント(過去の会話時点)まで状態を巻き戻すことができる。
      • /rewindで、チェックポイント(過去の会話時点)を選択する。
        - please summarize the project
        No code changes
        - please do a code review and write results to review.md in the docs directory
        review.md +263-0
        - are you sure that the API key is exposed?
        review.md +9-23
      • 会話履歴のみ(Chat)、コードの状態のみ(Code)、あるいは「その両方(Both)」を過去に戻すかを選択可能。
        > 1. Restore code and conversation
          2. Restore conversation
          3. Restore code
          4. Never mind
      • 実演:巻き戻した結果、AIのチャット文脈だけでなく、review.md の内容も「誤検知が含まれる状態」へ復元。
        are you sure that the API key is exposed?
        ...
        1. Restore code and conversation
    • セッション再開(Resume)との違い
      • セッション再開(Resume):過去のセッションからClaudeの会話の「文脈(コンテキスト)」のみを引き継いで再開(コードの変更は伴わない)。
      • チェックポイント(Rewind):現在のセッション内で、会話の文脈と実際のコードの状態(ファイル変更)を過去に戻す機能。
    • 次回の予告:
      • 最後に現在の変更をGitコミット(git commit -m "before YOLO")し、画面をクリア。
      • 次回は、差分を自動承認して高速で開発を進める「YOLO(You Only Look Once)モード」とその応用について解説。
  4. Claude Code YOLO Mode:権限をバイパスして自律コーディング
    • 「YOLOモード(危険モード)」でのClaudeの起動
      GUIからの実行でも同じだと思われるが、ココで初めて大きめの注意喚起あり。
      • 概要:ユーザーの許可(パーミッション)を一切求めずに、モデルにすべての操作を自律的に実行させるモード(通称「YOLOモード」)の検証。
      • 起動方法:コマンドラインで claude --dangerously-skip-permissions とフラグを付けて起動する。
      • リスクと注意点:破壊的なコマンド(rm -rf など)が実行される確率は極めて低いが、統計的モデルであるためリスクはゼロではない(自己責任)。
      • 本来は、インターネットアクセスを制限し、簡単に復元できる「サンドボックス(仮想環境)」内で実行することが強く推奨されるが、今回はローカル環境でそのまま実行。
    • タスクの実行と結果
      • 依頼内容:プロジェクトのUI改善(削除ボタンのアイコン化、横方向のスペースの有効活用、レスポンシブ対応など)と、変更後の自動テストを指示。
        please improve the UI of this project, particularly making sure the horizontal layout looks better, with icons instead of delete buttons and using the horizontal space properly. Make your changes, test everything, let me know when done.
      • 実行プロセス:Claudeはユーザーの介入なしで完全に自律して動き、7分44秒でタスクを完了(その間、メールチェックなど別の作業)。
      • 検証結果:
        ・ローカルサーバー(localhost:8000)は問題なく起動。UIは指示通り美しく刷新され、横幅に応じたフルードレイアウトやモバイルレスポンシブにも対応。
        ・組み込まれているAIアシスタント機能(OpenRouter?経由)も正常に動作し、「すべてのカードをDone列に移動して」という指示を正しく実行。
        hi there
        Hello! How can I help you with your board today?
        please give all cards to the Done column
        All non-Done cards have been moved to the Done column,
    • 結論と事後処理
      • YOLOモードは、適切な指示を与えれば人間が目を離している間にUI全体を完全にリエンジニアリングできる強力な機能であることを実証。
      • 動作確認後、安全のためにすぐにGitコミット(git commit -m "after ui revamp")を行い、コードを保存して危険なセッションを終了。
  5. Claude Code の Ralph Loops:自律エージェントによるオートパイロットコーディング
    • Ralph loop(ラルフ・ループ)とは
      • 概要:オーストラリアのエンジニア、Geoffrey Huntley氏によって考案された、AIエージェントを自動で継続・周回させる仕組み(名称は『シンプソンズ』のラルフ・ウィガムに由来)。
      • 仕組み:AIが「タスクが完了した」と判断した際、文脈(コンテキスト)の肥大化を防ぎつつ、前の成果物をもとにさらにタスクを反復・改善するよう自動で裏からプロンプトを投げ直す「ループの外側のループ」。
      • メリット:通常数分で終わるタスクを、何時間もかけて自律的に何度も自己改善させ、より大規模で高精度な開発へとスケールアップできる。
    • 実演と検証結果
      • /plugin install でAnthropicの公式プラグインRalph loopをインストール(プラグインの詳細については後述)
        > /plugin install ralph-loop@claude-plugins-official
          L Plugin 'ralph-loop @claude-plugins-official' is already installed. Use '/plugin' to manage existing plugins.
      • 設定:max-iterations 10(最大10回反復)に設定し、既存のプロジェクトに「ユーザー管理機能、認証、複数のかんばんボード機能」を追加し、テストも徹底するよう指示。
        > /ralph-loop "Please significantly improve this project. Add user management, multiple kanban boards in a user, and other features to build out a comprehensive Project Management application, testing thoroughly as you go and maintaining strong test code coverage and good integration tests" --max-iterations 10
      • 安全性:リスクを伴う「YOLOモード(権限確認スキップ)」やサンドボックス外での自動実行は避け、安全のために手動で承認(Accept)を行いながら実行。
      • 結果:約1時間で1,300行以上のコードが追加・変更され、以下のような本格的なWebアプリケーションがほぼ全自動で完成した。
        ・サインアップ、サインイン/アウト
        ・マイページ(ユーザー名表示)
        ・複数のかんばんボードの作成・切り替え・カード移動・データ永続化
      • 動作確認の結果、いくつかの軽微な不具合を修正しただけで、実用に耐えうるプロトタイプが完成、自律性と成果を高く評価。
    • Ralph loopの使い所と今後の展望
      • 使い所:短時間でプロトタイプやMVP(実用最小限の製品)を構築したい時や、実験的な開発には最適。夜間に最大反復数を大きく設定して放置し、数万行規模のアプリを作らせることも可能。
      • 注意点:予測可能で信頼性の高い成果が必要な場合や、人が主導権を握って厳密に構築したい場合は、このループに頼らず、段階を踏んだ従来の手法(より統制されたプロセス)をとるべきである。
      • 今後のステップ:今回のRalph loopはあくまで前触れ(ティーザー)であり、今後は複数のサブ・エージェントの活用や、MCP(Model Context Protocol)、スキル、プラグインなどを学び、より堅牢な開発プロセスを構築していく。

Day 3

45-51

  1. MCP、Skills、Plugins:Claude Code の3大構成要素
    • Claude Codeの背後にある4つの大きなイノベーション
      • トリック1:記憶の錯覚
        私はエドです
        >> こんにちは、エド
        私は誰でしょう?
        >> わかりません
        私はエドです
        >> こんにちは、エド
        私はエドです。こんにちは、エド。私は誰でしょう?
        >> あなたはエドです
      • トリック3:ツール
        ツール:次の質問にPythonコードで答えるには、次のように返信してください:PYTHON: (ここにPython式を入力)
        質問:円周率の平方根は何ですか?
        回答:>> PYTHON: math.sqrt(math.pi) → ツールが呼び出される。
      • トリック2:推論/思考
        質問:コインを2枚投げます。1枚は表です。もう1枚が裏になる確率はどれくらいですか?
        推論:Step 1:サンプル空間を列挙(全件)、Step 2:「1枚が表」でフィルタ、Step 3:「もう1枚が裏」でフィルタ、Step 4:確率を計算=P(もう1枚が裏∣少なくとも1枚は表)
      • トリック4:ループ
        ステップ1:LLMに進行するように指示する
        ステップ2:目標が達成されたかどうかをテストする
        ステップ3:達成されていない場合は、ステップ1に戻る
    • AIを進化させる核心:ツール(Tools)の力
      • 単に次の単語を予測するだけのLLMを、自律的に動く「エージェント型AI(Claude Codeなど)」へと進化させた最大のイノベーションは「ツール(Tools)」の活用
      • AIはテキストを生成するだけでなく、ツールを実行するための命令(トークン)を出力することで、「コンテンツの生成」から「実際の行動(タスクの実行)」へと移行
      • Claude Codeには、最初から「ToDo?リスト管理」「ファイル編集」「ネット検索」などのツールが組み込まれている。
    • 3つの拡張機能の概要
      • MCP(Model Context Protocol)
        ・概要: Anthropicが2024年末に発表した、AIアプリケーションと外部システムを接続するためのオープンソースの標準規格(プロトコル)
        ・メリット:誰かが作ったツール(ネット閲覧、市場データ取得など)を、自分のClaude CodeやChatGPTなどに簡単に接続(プラグアンドプレイ)して共有・利用
        ・デメリット/注意点:MCPはあくまで接続のための「規格(プロトコル)」であり、ツールそのものではない。
        ・MCPサーバーを多く接続し過ぎると、Contextウィンドウを圧迫しやすく、AIのパフォーマンス低下を招く恐れがある。
        ・(ツール定義による消費、ツール実行結果の蓄積、誤ったツール選択、これらが会話履歴に積み上がる)
      • Skills (スキル)
        ・概要: MCPの後に登場した、AIに専門知識や機能を追加するためのもう一つのアプローチ
        ・特徴: MCPと競合・代替するような性質を持つが、MCPが抱えるいくつかのデメリット(コンテキスト効率の悪さなど)を解消する、より優れた方向性を持った技術
      • Plugins (プラグイン)
        ・概要: 最も高レベル(上位レイヤー)の概念です。
        ・特徴: 複数のMCPやSkills、その他の要素を一つにまとめた「パッケージ(便利セット)」
    • まとめ
      • これら3つは、すべて個別にインストールや有効化ができるため混同し易い。
      • ベースにあるのは**「AIにツール(行動力)を与える」**というアイデア。
      • これらを理解し適切に使い分けることで、Claude Codeの専門性を飛躍的に高める。
  2. MCP Server 解説:Host、Client、Discovery(Claude Code)
    ヤヤコシイので、必要に応じてコチラを確認のこと。
    • MCPの基本概念と3つの要素
      • MCPホスト (MCP Host):ツールを呼び出すAIアプリケーション全体
      • MCPクライアント (MCP Client):ホスト内で動作し、各ツールセットとの仲介を行うコード。
      • MCPサーバー (MCP Server):実際に外部で開発されたツールを管理する仕組み。AIアプリに追加する対象。
    • 2つの実行モード「トランスポート」と「ローカル」の誤解
      ローカル実行のMCPサーバーは、(COMで言う所の)ローカル・サーバーみたいなモン
      • 2つの方式:現在は「STDIO」が推奨方式で「SSE」は非推奨(レガシー)
      • ローカル実行:ローカルで動作。リモート実行:リモートで動作。
    • MCP最大のメリット
      • ターミナルで「わずか1行のコマンドを実行するだけ」で、AIアプリに新しい特定の機能やツールを即座に組み込める利便性の高さ。
      • この標準化された手軽さこそが、MCPが多くの開発者に支持されている理由(個人的見解:実際はSaaS機能のマーケット的な側面が強い)。
    • MCPサーバーの探索と「マーケットプレイス」の現状
      現在、誰もが1箇所に集まるような標準的な検索場所はなく「無法地帯(Wild West)」のような状態。
      • 公式レジストリ(registry.modelcontextprotocol.io):Linux Foundation傘下のオープンソース(公式だが、少し活気に欠け、ナビゲートが難しい)
      • AnthropicのGitHubリポジトリ:初期の参考サーバーやサードパーティの認定サーバーが並ぶ信頼できる場所。
      • 外部マーケットプレイス(mcp.so や Glamour.ai):1万数千以上の膨大なサーバーが登録され、ダウンロード数、レビュー・評価で活発さを確認できるサイト。
    • 信頼できるMCPサーバーの見極め方
      • マーケットプレイスには「Context 7」(最新のAPI情報をLLMに補完する人気ツール)のような優良ツールの偽物やクローン、ノイズも多く存在。
      • 安全性を確認する最善の方法は、開発元のGitHubリポジトリからスター数、Issueなどのアクティビティ、信頼できる開発元であるかを直接確認。
  3. Claude Code への MCP Server 追加:Context7 & Polygon IO
    • 「Context 7」MCPサーバーの追加と検証
      • 追加手順:Claude Codeを一度終了し、コマンドラインからGitHub/Glamourに記載の追加コマンド(claude mcp add context-7 -- <実行コマンド>)を実行
        > claude mcp add context7 npx -y @upstash/context7-mcp
      • ツール機能:統合すると、ライブラリIDを特定するツールと、そのドキュメントを検索するツールの2つがClaudeに追加される(以下を /context で確認)。
        MCP tools /mcp
        L mcp_ide_getDiagnostics: 111 tokens
        L mcp_ide_executeCode: 182 tokens
        L mcp_context7_resolve-library-id: 492 tokens
        L mcp_context7_query-docs: 401 tokens
      • プロンプトのコツ:確実にMCPサーバーを使わせたい場合は、プロンプト内で use context 7 と明示するのが有効、自動判断することもある。
        (明示:)> use context7 to summarize for me the right way to use OpenAI Agents SDK with a model other than OpenAI's models
        (自動:)> how do I turn off telemetry with CrewAI
    • 「Massive (旧 Polygon IO)」MCPサーバーの追加
      • 概要:コーディングとは直接関係のない拡張例として、市場データ(株価など)を取得するMCPサーバーを追加。利用にはAPIキーが必要(遅延データは無料)
      • 実演:追加後、Claudeに「Appleの現在の株価は?」と質問すると、自動で適切なツール(get snapshot ticker)が選択・実行され、最新の株価を回答。
        > claude mcp add massive e MASSIVE_API_KEY=your_api_key_here uvx-from git+https://github.com/massive-com/mcp_massive@v0.6.0 mcp_massive
        > what's the current share price of AAPL?
        AAPL (Apple Inc.) is currently trading at $270.01, up $9132 (+3.59%) from yesterday's close of $259.48. Today's range: $259.21- $270.49
    • Claude Codeの最適化(コンテキストの節約)
      • 大量のツールを提供する巨大なMCPサーバー(Massiveなど)にはContextウィンドウ消費問題があった。
      • Claude Codeは近年のアップデートにより「今必要なツールだけ」をコンテキストに読み込むように最適化された。
      • そのため、利用可能なツールが大量にあってもトークンを無駄に消費しないようにはなってきている。
    • MCPサーバーの削除:追加時と同様に、コマンドラインから claude mcp remove <サーバー名>(例: context-7 や massive)を実行
  4. Skills vs MCP:Claude Code で能力を追加するよりシンプルな方法
    • Agent Skills(スキル)」とは?
      • Skillsは、MCP(Model Context Protocol)の後に登場した新しいイノベーション。
      • LLMエージェントに対しMarkdownファイルを使って指示を与える仕組みであり「AGENTS.md」「CLAUDE.md」と同様の「SKILL.md」を複数持てるようにしたようなもの。
      • システム・プロンプトにSkillsの存在と利用方法が記述されており、エージェントが実行時に SKILL.md を読み込む(view ツールで参照する)ことで動作。
    • メリット(MCPとの比較)
      • 段階的開示:まずは最上部の「メタデータ(概要)」だけが読み込まれ、LLMが「必要だ」と判断した場合にのみ段階的に追加で読み込むためコンテキストの消費を抑え、効率的に動作。
      • シンプルで軽量:Skillsは「フォルダとファイルの集まり」だけで構成されているため、誰でも簡単に作成・共有が可能。
      • シェルスクリプトの実行:Markdownだけでなく、シェルスクリプトを持たせて実行させることができる。ツール呼び出しと同等の機能を実現できる。
    • デメリットと課題
      • 柔軟性とパワーの低下:Function Callingのパラメタ定義に比べると、構造がシンプル(スクリプトを実行するだけ)なため、高度で緻密な制御には向かない場合がある。
      • 発見の難しさ:MCPに比べてまだ普及の歴史が浅く、どこで優れたSkillsを探せばよいのかというエコシステムが未成熟(プラグイン経由でのインストールが主流)。
      • 呼び出しの曖昧さ:AIにSkillを使わせるトリガーがやや曖昧(アドホック)。ユーザーの指示がSkillのメタデータ(概要部分)にうまくヒットするように、指示の出し方に少しコツが必要。
    • Skillsの3段階構造(段階的開示の仕組み)
      階層名称内容読み込みのタイミング
      第1階層メタデータSkillの名前と概要説明常に最初に読み込まれる。 AIはこれを見て実行するか判断する。
      第2階層指示具体的なワークフローやガイドライン、コードスニペットなど。AIがそのSkillを**「必要」と判断した時**に読み込まれる。
      第3階層リソースとコードスクリプト(Python等)や、参照する追加ファイル。指示の中で必要性がトリガーされた時、オプションとして実行・読込される。
    • 実装方法(ファイルシステム・アーキテクチャ)
      Skillsは非常にシンプルで、特定のフォルダ構造を作るだけで機能する「Janky(型破り・泥臭い仕組みだが、それが良さでもある)」な仕組み。
      • 配置場所:
        ・プロジェクト個別:各リポジトリの .claude/skills/ フォルダ配下(そのプロジェクトでのみ有効。Gitで共有すればチーム全員が使える)。
        ・グローバル(PC全体):ホームディレクトリの .claude/skills/ フォルダ配下(PC内のすべてのプロジェクトで有効)。
      • 構成:skillsフォルダの中に「Skillごとのサブフォルダ」を作り、その中に SKILL.md (メタデータと指示を記述)と、必要に応じて実行スクリプトや追加ファイルを配置。
    • 総括:技術的な複雑さ(オーバーヘッド)が大きかったMCPに対し、Skillsはシンプルでエレガントな代替手段として期待されている。発展途上の拡張アプローチとして、多くの開発者に支持されている。
  5. Skills Marketplace:Claude Code に Agent Browser をインストール
    • 「Skills(スキル)」の概要とマーケットプレイス
      • 構造のシンプルさ:スキルはファイルとフォルダの集まりで構成されており、MCPサーバーよりも単純。
      • 主な入手先:
        Anthropic社のGitHubリポジトリ:仕様やテンプレートのほか、PDF作成やPPT操作、スキル自体を作成するスキルが公開されている。
        skills.sh (Vercel製):様々なスキルが公開されているマーケットプレイス。
    • スキルのインストール手順(Agent Browserの例)
      • 前提:npm を使用して、ヘッドレスブラウザ(Agent Browser)と、それを制御するChromium(Playwright経由)をPCにインストール
        > npm install -g agent-browser
        > agent-browser install
      • 追加:Vercelのユーティリティコマンド npx skills add [GitHubのURL] を実行
        > npx skills add https://github.com/vercel-labs/agent-browser-skill agent-browser
      • 設定:適用先として「Claude Code」を選択し、プロジェクトローカルにファイルをコピー(「Claude Code」なら .claude など)
      • 結果:スキルの組み込みは、プロジェクトの .claude/skills/agent browser/ ディレクトリ内に SKILL.md が配置され完了する。
    • 実際の動作とメリット
      • 実演デモ:Claude Codeに「ニューヨークのレストランを検索して」と指示すると「Agent Browser」スキルが自動でブラウザを起動、操作、スクリーンショットを解析して結果を要約。
        > Please interact with the browser to look for restaurant experiences in NYC next week, perhaps on rezy or opentable
        (来週ニューヨーク市でレストランを探すには、ブラウザを操作してください。RezyやOpenTableなどで検索できます。)
        ...I've searched both Resy and OpenTable for restaurant availability in NYC for next week (Saturday, February 7, 2026). Here's a summary of what I found:...
        ...ResyとOpenTableの両方で、来週(2026年2月7日土曜日)のニューヨーク市内のレストランの空席状況を検索しました。以下はその結果の概要です。...
      • チーム共有の容易さ:スキルはただのファイルで、Gitコミット&プッシュするだけで、チームメンバーに同じスキルを簡単に共有・装備させることができる。
  6. Claude Code Plugins:マーケットプレイス、インストール方法、最適な使い方
    • Agent Plugins(プラグイン)」とは?
      • 概要:2025年10月に導入された最も新しい概念。MCP、Skills、コマンド(/から始まる命令)、フック、などを1つにパッケージ化した「機能の束(バンドル)」
      • 目的:MCPやスキルの複雑な組み合わせをユーザーに意識させず、簡単に導入・管理できる。各種機能を発見する「マーケットプレイス」も提供されている。
      • 特徴:他のAI(ChatGPTなど)にはなく、Claude Code専用に設計されている。
    • メリットとデメリット
      • メリット(Pros):
        ・インストールするだけで使えてシンプル。
        ・コマンドを明示的に入力して実行するため、曖昧さがなく、動作が確実。
        ・迷ったら、MCPやスキルではなくプラグインから始めるのがおすすめ。
      • デメリット・制限(Cons):
        ・Claude Codeでしか使えない。
        ・パッケージとして一括導入されるため、細かいカスタマイズや要素ごとの組み合わせ(ミックス&マッチ)がし難い。
    • エコシステムとマーケットプレイス
      • 公式リポジトリ:GitHub上の anthropic/claude-plugins-official で管理されており、Anthropic製(plugins)と外部製(external_plugins)がある。
      • マーケットプレイスの追加:Claude Code内から直接アクセス可能なデフォルトの公式リポジトリ以外にも、カスタム・マーケットプレイス(Gitアドレス指定)を追加・共有できる。
    • 実際の操作と主なプラグイン
      • 操作方法:/plugin コマンドで管理画面(Discover / Installed / Marketplaces)を起動する(※ちなみにスキルの削除はディレクトリごとゴミ箱に捨てるだけで可能)。
        ・Discoverタブ:「マーケットプレイスのブラウザ」。登録済みのすべてのマーケットプレイスから利用可能なプラグインを一覧表示。
        ・Installedタブ:「インストール済みプラグインの管理画面」プラグインの一覧はスコープ別にグループ化され、問題のあるものが最上部に、お気に入りがその後に続き、無効なものは折りたたまれた状態で末尾に表示。
        ・Marketplacesタブ:「マーケットプレイス自体の管理」追加済みのすべてのマーケットプレイスをソースとステータスとともに一覧表示。マーケットプレイスの追加・削除、プラグイン一覧更新などをおこなう。
      • 人気のプラグイン例:
        ・Front-end Design:高品質なUIを作る、最も人気のプラグイン。
        ・Context 7 / GitHub:面倒なMCPサーバーの設定を簡単に導入できる。
        ・Code Review:プルリクエストのコードレビューを行う公式プラグイン。
        ・Code Simplifier:LLMが生成した複雑なコードをシンプルに修正するAnthropic製のOSS自律型エージェント。
        ・Ralph Loop: 前日にデモで使用した「/ralph-loop」コマンドは、プラグイン。
  7. MCP vs Skills vs Plugins:Claude Code で最適な構成を選ぶ
    • プラグイン(Code Simplifier)の検証
      • 導入:Anthropic製の「Code Simplifier」をインストール(SkillsやPluginsのインストールも /context で確認可能)。
        前述の「Discoverタブ」から「code-simplifier」プラグインを検索・選択してインストールする。
      • 実行:自然言語で「コードベース全体を簡素化して」と指示するだけで、適切なツールが自動で起動。
        > please use the code simplifier agent to simplify the entire codebase
      • 結果:約6分間の処理で多くの変更とテストが実行された後、ローカル環境(localhost:8000)でを起動したところ、正常に動作することを確認。
    • 3つの拡張技術の比較
      技術メリットデメリット
      MCP (Model Context Protocol)エコシステムが巨大、選択肢が豊富で柔軟。セットアップが複雑で、コンテキストを多く消費する。
      Skillsコンテキスト効率が良い、設定が簡単、チーム間での共有(リポジトリへのチェックイン)が容易。柔軟性に欠け、マーケットプレイスなどがまだ発展途上。
      PluginsMCPやSkills、エージェントなどを一括同梱可能。最も導入がシンプル。現時点ではClaude Code内に閉じている。多く入れすぎると環境が複雑化する。
    • どの技術を選ぶべきか(結論)
      選択肢(MCP/Skills/Plugins)の中からでは「先ずはPluginsから探すこと」が推奨されている。
      • 基本戦略:目的の機能を持つプラグインがあれば、それが最もシンプルで手軽なため最優先で選ぶ。
      • MCPを選ぶケース:市場データの取得など、非常に専門的なツール(例: PolygonのMCPサーバーなど)を直接、柔軟に組み込みたい場合。
      • Skillsを選ぶケース: Vercelのブラウザエージェントのような特定の優れたスキルを使いたい場合や、チームや組織内で簡単に独自のスクリプト一式を共有・管理したい場合。
    • 総括と次へのステップ
      • カリキュラム全体の折り返し地点(50%)を通過。
      • 翌日からは、これらを踏まえた実際のプロジェクトにおける最適なワークフローや、さらに発展した「エージェント」の開発・活用について学んでいく。

Day 4

52-57

  1. Claude Code、Jira、MCP、Plugins を活用した開発ワークフロー
    前回学んだMCP、スキル、プラグインなどの知識を実際の行動にし、Claude CodeやCLIツールを使ったビジネス機能構築の具体的なワークフロー、チームでの連携、そしてデバッグのアプローチについて学ぶ。
    • 3つの拡張機能の振り返りと比較
      • MCP (Model Context Protocol): Anthropicが開発した規格。
        ・プラス面: エコシステムが非常に膨大。
        ・マイナス面: コンテキストを消費しやすく、時に扱いが難しい。
      • スキル (Skills): Markdownやスクリプトを組み合わせた軽量な方法。
        ・プラス面: 効率的かつシンプルで、良い結果が得られやすい。.claudeフォルダに入れてGitHubで共有するのも容易。
        ・マイナス面: MCPほど強力・柔軟ではなく(認証機能など)、まだ発展途上。
      • プラグイン (Plugins): MCPやスキル、エージェントなどを一括インストールできるパッケージ。
        ・プラス面: 両者の良いとこ取りができる(現時点ではClaude Code特有の機能)。
        ・マイナス面: 大量に入れすぎると、LLM(Opus)がどのツールを使うべきか迷い、パフォーマンスが低下する。
      • 推奨されるアプローチ:
        ・先ずはプラグインマーケットプレイスからプラグインを試す。
        ・その上で、特定のエコシステムを活用したい場合は「MCP」を、チーム間で簡単に機能を共有したい場合は「スキル」を選択する。
    • 開発実践:「自分で選ぶ冒険(Choose Your Own Adventure)」
      以降はスライドを一切使わない実践形式で、全く同じ手順を踏む必要はなく、手法やアイデア、スキルを活用しながら、自身のアイデアで開発を進める。
      • 開発プロセスの出発点(Jiraのセットアップ)
        開発ライフサイクルの起点として、多くの企業で標準的に使われているJira(代替案としてGitHub Issues)を採用。
        ・Jiraは、バグトラッキングや課題管理、プロジェクト管理などで使用される。
        ・Jiraのサインアップ:https://www.atlassian.com/software/jira から、10ユーザーまで無料で利用可能なプランを使用。
        ・スペースの作成:「Kanban(カンバン)」テンプレートを使用し、新しいスペース(旧Jiraプロジェクト)を作成。
        ・詳しい手順:サインアップ、サインイン、サイト作成、カンバン・テンプレを用いてスペース作成(TEAM、OPEN、PL)
      • プロジェクトの題材:今回構築する製品の名前は「Pre-Legal(プリ・リーガル)」
        ・コンセプト:企業向けにNDAやクライアント契約書などの法的文書のドラフトを自動生成するツール。
        ・目的:弁護士の置き換えではなく、弁護士や法律事務員が仕事をスムーズに始めるための「前準備(Pre-work)」を生成AIで支援し、マネタイズを目指す。
      • 最初のタスク作成:Jira上に「Pre-Legalの会社概要を説明するシンプルなウェブサイトが必要」という最初の課題(タスク:PL-1)を作成し、ここから具体的な開発プロセスへと進む。
  2. Claude Code と MCP Serverを用いたJira、GitHub連携
    ClaudeCode?とJIRA、GitHub連携で、プラグインやスキルを使用しないのは、SaaS機能の利用はプロバイダが提供する生のMCPサーバーを使用するのが良いため。
    • Atlassian (Jira) MCPサーバーの連携とテスト
      • MCPサーバーの追加:VS Codeのターミナルから claude mcp add コマンドを使用し、AtlassianのリモートMCPサーバー(Jiraの機能を提供)をClaude Codeに登録。
        > claude mcp add --transport http atlassian https://mcp.atlassian.com/v1/mcp
        > claude
      • OAuth2.0による認証:/mcpコマンドで状況を確認後、認証を実行。ブラウザが立ち上がり、OAuth2 Flowによるアクセス承認(Approve)を行う。
      • トラブルシューティング:連携がハングした場合は認証が切れている可能性が高いため、再度 /mcpコマンドを実行して再認証(Re-authenticate)を行う。
      • ツールの検証: ・「/context」で多数のJira用ツールが追加されたことを確認。
        > /context
        MCP tools /mcp
        L mcp_atlassian_...
        ...
        ・事前にJira側で作成していたタスク「PL-1」についてClaudeに質問し、ツール経由で正しくタスク内容が取得できることを実証。
        > please tell me about jira issue PL-1
        Jira Issue PL-1
        |Field      |Value                                                        |
        |Summary    |We need a simple website that describes the Prelegal company |
        |Type       |Task                                                         |
        |Project    |Prelegal (PL)                                                |
        |Status     |To Do                                                        |
        |Assignee   |Unassigned                                                   |
        |Description|None provided                                                |
        Link: https://edwarddonner.atlassian.net/browse/PL-1
    • GitHubの準備とFine-grained Access Tokenの発行
      • Fine-grained Access Tokenとは、スコープ制御できるAPIアクセストークンでCI/CDで使用する、GitHubのPersonal Access Token(PAT)が代表例。
      • リポジトリの新規作成:GitHub上で「pre-legal」というプライベートリポジトリを作成(MITライセンス、Readmeを同梱)。
      • トークンの生成:ユーザーの「Settings」>「Developer settings」>「Personal access tokens」>「Fine-grained tokens」(https://github.com/settings/personal-access-tokens/new)からトークンを新規生成。
      • セキュリティの最小権限原則:有効期限を30日、アクセス権は対象リポジトリ(pre-legal)のみ、リポジトリの「Contents(読み取り)」「Issues(読み取り)」「Pull requests(読み書き)」を付与して生成。
      • 注意点:生成されたトークンは一度しか表示されないため、安全な場所にコピーして保管する(MS Wordなどのテキストを自動整形するアプリには貼り付けないこと)。
    • ローカル環境へのリポジトリのGitクローン
      • ポジトリのHTTPS URLをコピーし、VS Codeでターミナルを開き、ローカルのプロジェクト用ディレクトリへ移動後、git clone を実行。
      • Gitクローンした「pre-legal」ディレクトリ内に、GitHub上で作成したライセンスファイルとReadmeが存在することを確認。
  3. GitHub MCP Server と Featured Dev Plugin のセットアップ
    • GitHub MCPサーバーの導入と連携
      • VS Codeで新しいプロジェクトを開き、ターミナルからGitHubのリモートMCP(Model Context Protocol)サーバーをインストール。
        > claude mcp add --transport http github https://api.githubcopilot.com/mcp --header "Authorization: Bearer YOUR_GITHUB_PAT"
        > claude
      • 接続完了後、Claude CodeがGitHub関連の多数のツールにアクセス可能になったことを確認。
        > /context
        MCP tools /mcp
        L mcp_github_...
        ...
    • Claude CodeによるGitHub操作の実証
      • Issueの作成:Claudeに指示を出し、READMEの更新に関するIssueをGitHub上に自動で起票。
        > please write an issue to Github that the README needs to be updated
        (GitHubのIssue上に)The README needs to be updated to reflect the current state of the project.
      • Pull Request(PR)の作成とmerge:READMEにプロジェクトのステータスを追記し、ローカルでのcommit・pushを経て、GitHub上でPRを自動作成。ブラウザ側でこのPRをmergeし、変更が反映されたことを確認。
        > please update the README to reflect that the project is in progress and will be completed in 1 week. Then raise a PR for this to be merged.
        (GitHubのPR上に)title:Update README with project status #n;content:Summary please update the README to reflect ...
      • 事後処理:Git操作の仕上げとして、作業用ブランチからメイン(main)ブランチへ切り替えを実施(Claude Codeが切り替えたブランチが戻っていないので)。
        > git status
        On branch update-readme
        Your branch is up to date with 'origin/update-readme'.
        nothing to commit, working tree clean
        > git checkout main
        Switched to branch 'main'
        Your branch is up to date with 'origin/main'.
        > git status
        On branch main
        Your branch is up to date with 'origin/main'.
        nothing to commit, working tree clean
    • FeatureDev?」プラグインのインストール
      • /plugin コマンドで、Discover画面のプラグイン一覧から、Anthropic社が社内開発でも使用している公式プラグイン「FeatureDev?」を選択。
      • コレは「コードベースの探索」「設計」「品質レビュー」等、規律ある7段階のプロセスで新機能を開発するためのワークフローを提供。
      • チーム全体で共有できるよう、プロジェクト・スコープ(.claudeフォルダの作成)でインストールを実行。
    • プロジェクトの環境整備と最終確認
      • Claudeに対し、Python (FastAPI) と JavaScript (Next.js) のWebアプリ開発に適した標準的な .gitignore ファイルの作成、およびcommitとpushを指示。
        > please create a boilerplate .gitignore for this new project, for typical python fastapi nextjs webapp development, and then commit and push to github
      • Claudeが自動でGit操作(PRのmerge分のpull、commit、push)を完結、GitHub上で、更新されたREADME、.env(環境変数の設定された)、.gitignore が正しく反映されていることを確認。
    • 結論:Jira(タスク管理)とGitHub(コード・Pull Request(PR)管理)、FeatureDev?(規律ある開発プロセス)が導入されたことで、Claude Codeを用いた本格的なチーム開発の準備が整った。
  4. Claude Code の自律性:Jira Issue から MCP Server 経由でのPull Request(PR)作成まで
    • Jiraでの2つ目の課題を作成(タスク:PL-2)
      • タスク内容:「Common Paper」が公開しているCreative Commonsライセンスのリーガル文書(Markdown形式)を取得し、データセットを作成。
        Title:Create a dataset of legal document templates that the system will later be able to modify for the user
        Description:This task is a one-time data curation task to prepare data for the Prelegal project.
        For context, the CommonPaper github account at Common Paper contains a number of repos with legal agreement templates that can be copied and modified under a CC license. We will use this as our source of data.
        For this task, we need to browse these repos online to review all of Common Paper's repos, and retrieve all their markdown template legal agreements.
        Then put all the markdown files in our Protegal project in a directory called "templates".
        Additionally, make a new json file called catalog.json in the project root that contains the name, description and filename of each of the markdown documents that has been downloaded to "templates".
        Finally, add a text file in the "templates" directory to indicate that everything in this directory is under the appropriate CC By 4.0 license.
        表題:システムが後でユーザー向けに修正できる法的文書テンプレートのデータセットを作成する。
        説明:このタスクは、Prelegalプロジェクトのデータ準備のための、一度限りのデータキュレーション作業です。
        背景として、Common PaperのGitHubアカウントには、CCライセンスの下でコピーおよび修正可能な法的契約テンプレートを含むリポジトリが多数存在します。これをデータソースとして使用します。
        このタスクでは、これらのリポジトリをオンラインで閲覧し、Common Paperのすべてのリポジトリを確認して、すべてのMarkdownテンプレートの法的契約書を取得する必要があります。
        次に、すべてのMarkdownファイルをPrelegalプロジェクトの「templates」というディレクトリに配置します。
        さらに、プロジェクトルートに「catalog.json」という新しいJSONファイルを作成し、「templates」にダウンロードした各Markdownドキュメントの名前、説明、ファイル名を記述します。
        最後に、「templates」ディレクトリにテキストファイルを追加し、このディレクトリ内のすべてのファイルが適切なCC BY 4.0ライセンスの下にあることを示します。
      • 要件:templatesディレクトリへのMarkdownファイルの格納、各テンプレートを説明するcatalog.jsonの作成、ライセンスファイルの格納。
    • Claude Codeの準備とMCP連携
      • Atlassian(Jira)用のMCP(Model Context Protocol)サーバーを(プロジェクトが変わっているので)再インストールし、認証済みを信じず再認証を実行。
        > claude mcp add transport http atlassian https://mcp.atlassian.com/v1/mcp
        > claude
      • Claude Codeに対し、「Jiraの課題PL-2を実行し、PRを上げて」と高レベルな指示(プロンプト)を出す。
        > please carry out jira issue PL-2 and raise a PR with your changes
        PR created. Let me also update the Jira issue status to mark it as complete.
    • Claude Codeによる自律的な問題解決(自律性の発揮)
      • アプローチの最適化:
        ・当初、Claude CodeはGitHubツールでファイルを1つずつ読み込もうとしたが、「コンテキストが肥大化し効率が悪い(遅い)」と判断。
        ・途中で方針を切り替え、コマンドを実行してファイルを直接一括ダウンロードする効率的な方法を提案・実行した。
      • 成果物の生成:指示通りMarkdownファイル群、license.txt、catalog.jsonをローカルに自動生成。
    • Pull Request(PR)作成とJiraのステータス更新
      • PRの作成:ローカルのGitHub CLIツールが未インストールだったため、MCPサーバー経由のツールに切り替えてGitHub上にPR(add legal document templates data set)を自動作成。
      • トラブルシューティング(Jiraの認証切れ):
        ・Jiraのステータスを「完了」にする際、Atlassianの認証切れが原因で処理が一時停止(FAQ的な問題らしい)。
        ・/mcpコマンドから手動で再認証を行うことで、Claude Codeは処理を再開し、ステータスを無事「Done」に更新。
        > please try marking the jira issue complete again
    • ローカルでのmergeと完了
      • PRをmergeして、ブランチをmainに切り替えてください。
        > please go ahead and merge the PR, and also then switch the branch to main
      • PRのmerge権限がないと判明すると、Claude Codeは「ローカルでmergeしてからmainブランチにpushする」という代替案を自ら導き出し、タスクを完遂。
        ...
        The GitHub token doesn't have merge permissions. Let me merge locally and push instead.
        ...
        Done. Merged to main and switched branches. You're now on main with all the legal templates.
    • 結論 / 考察
      • AIのブレイクスルー:障害に直面した際、AIが自ら原因を理解し、合理的な回避策を見つけて自律的に解決していく知性に非常に驚かされた。
      • MCPの現状:認証が切れやすいなどの「わずかな不安定さ(flakiness)」はあるものの、総じてAIが効果的に問題を解決した素晴らしい例である。
  5. Claude Code が Jira チケットから Next.js アプリをフル構築
    • タスクの起票と初期設定
      • Jira上で「PL2」チケットの完了を確認後、3つ目の課題を作成(タスク:PL-3)
        Title:Prototype of Mutual NDA creator
        表題:相互秘密保持契約(NDA)作成プロトタイプ
      • 要件はあえて曖昧さを持たせたビジネス寄りの内容に設定。
        Description:A web application to create a Mutual NDA Document for a user.
        The user enters in some key information in a form. The website then displays the Mutual NDA with the key information filled in.
        The user can download the completed document locally.
        説明:ユーザー向けに相互秘密保持契約(NDA)を作成するWebアプリケーションです。
        ユーザーはフォームにいくつかの重要な情報を入力します。すると、Webサイトは入力された情報に基づいて相互秘密保持契約を表示します。
        ユーザーは完成した文書をローカルにダウンロードできます。
    • Claude Codeによる開発の実行
      • Claude Codeを再起動し、/contextコマンドでContextウィンドウを確認し、/mcpコマンドでAtlassianとの再認証を実施。
      • プラグイン(feature_dev)を使い「JiraのPL3をNext.js(frontendディレクトリ)で実装し、完了したらPRを作成せよ」と指示。
        >/feature-dev: feature-dev please implement jira issue PL-3 with a NextJS application in a directory called frontend, then raise a PR when done
        I'll start by fetching the Jira issue PL-3 to understand what needs to be built.
      • Claude(feature_dev)は7段階のプロセスに沿って動作を開始し、途中で仕様の曖昧な点を人間に質問し、回答を反映。
        Phase 3: Clarifying Questions
        Before proceeding with architecture, I have some questions:
        6 tasks ( done, 1 in progress, 5 open) ctrl+t to hide tasks
        ✓Implement Jira issue PL-3 with NextJS frontend
        ・Create NextJS project structure
        ・Build NDA form component
        ・Create NDA preview/display component
        ・Implement document download
        --------------------------------------------------
        ・Download・Form UX・Preview・Design・Submit
        Download:What download format should the completed NDA be available in?
        > 1. PDF (Recommended):Professional format, widely compatible for legal documents
          2. Markdown:Simple text format, matches source template
          3. Both PDF and Markdown:Give users a choice
          4. Type something.
          5. Chat about this
        Form UX:Should the app have a multi-step wizard or single-page form?
        > 1. Single page (Recommended):All fields visible at once, simpler for a prototype
          2. Multi-step wizard:Guided step-by-step experience, more polished
          3. Type something.
          4. Chat about this
        Preview:How should the NDA preview be displayed?
          1. Below the form (Recommended):Live preview that updates as user types
          2. Separate preview page:Navigate to see completed document
        > 3. Side-by-side:Form on left, preview on right
          4. Type something.
          5. Chat about this
        Design:Should this be a simple prototype or include styling polish?
          1. Functional prototype:Basic styling with Tailwind, focus on functionality
        > 2. Polished design:Professional look with careful attention to UI/UX
          3. Type something.
          4. Chat about this
        Submit:Review your answers
          - What download format should the completed NDA be available in?:PDF (Recommended)
          - Should the app have a multi-step wizard or single-page form?:Single page (Recommended)
          - How should the NDA preview be displayed?:Side-by-side
          - Should this be a simple prototype or include styling polish?:Polished design
    • アプリケーションの動作確認
      • わずか数分でNext.jsのフロントエンドファイル群とGitHubのPRが自動生成される。
      • ローカル環境でアプリ(npm run dev)を起動したところ、以下の機能が最初から(Zero-shotで)動作することを確認。
        Purpose:Evaluating whether to enter into a business relationship with the other party.
      • フォームに入力したデータ(会社名や準拠法など)が、右側のプレビューにリアルタイムに同期・反映される。
        Mutual Non-Disclosure Agreement
        Common Paper Mutual NDA Standard Terms Version 1.0
        Cover Page
        PURPOSE:Evaluating whether to enter into a business relationship with the other party.
        ...
      • 「PDFダウンロード」ボタンを押すと、カバーシート付きの綺麗な構造のPDFが正しく生成される。
    • プロセスの検証とテストの追加要求
      • /contextコマンドでContextウィンドウを確認、1/3 - 1/2ぐらい埋まっている事を確認。
      • 非常に完成度が高い一方、プロセス中に自動テストが実行された形跡がない。Claudeに「どのような品質レビューやテストを行ったか」を質問
        > It's working great. Based on the process you followed, what kind of quality review or testing have you already taken care of?
      • Claudeは「ビルド確認は行ったが、自動テストやコードレビュー(フェーズ6)はスキップした」と自己分析(内省)して回答。
        Good question. Here's what was actually done:
        Completed:
        - Build verification: Ran npm run build successfully confirms TypeScript compiles and Next.js can generate static pages
        Not done:
        - No automated tests were written
        - No manual testing I didn't run npm run dev and verify the UI works No
        - code-reviewer agents launched (Phase 6 from the feature-dev workflow was skipped)
        - No PDF download testing didn't verify the generated PDF renders correctly
        The build passing gives some confidence that the code is syntactically correct and types align, but it doesn't validate:
        - The form actually works and updates state correctly
        - The preview renders properly
        - PDF generation produces a valid desument
        - The layout looks good on different screen sizes
        Would you like me to:
        1. Run the dev server and do manual testing?
        2. Launch code-reviewer agents to check for bugs and code quality issues?
        3. Add some basic tests?
      • これを受け、「自動テスト・手動テストの追加、およびコードレビューエージェントによる検証」をClaudeに追加で指示。
        > yes to all 3 please add extensive automated tests and manual tests, and have the code-review agents do the review
  6. Claude Code のデバッグ戦略:体系的なアプローチ
    • 開発タスクの進捗と成果
      • 成果物の完成:Claude Code を用いて、NDA(秘密保持契約)作成アプリのプロトタイプと広範なテストスイート(5スイート、76テスト)をわずか数分で構築。
      • トラブルへの自動対応:サーバーの強制終了や、Contextウィンドウが満杯になったことによる「自動コンパクト化(Auto-compact)」が発生したものの、AIは自律的に問題を解決してタスクを完了。
      • 動作確認とデプロイ:localhost:3000 でアプリが正常に動作することを確認(PDFのダウンロードや、入力によるライブアップデート機能など)。
      • 最終処理:/mcpコマンドでAtlassianの再認証を行い、ローカルでPL3のPRをmergeしてmainブランチへpushし、mainブランチへ切替、Jira課題(PL3)の完了ステータス更新までを「1つのコマンド」で自動実行。
        > please merge the PR (legally) and push to main and switch the branch to main, and mark this issue PL-3 done in Jira
    • 推奨のデバッグ戦略(5つのステップ)
      今回はバグが発生しなかったため、次回以降に向けた実践的なデバッグ手法が共有されました。
      • スナップショットの取得(Gitコミット):AIが誤った方向に暴走した際、確実に元の状態に戻せるよう、必ず最初にGitコミットを行う。AIの「巻き戻し(Rewind)」機能だけでは、スクリプト実行による2次的な変更に対応できないため。
      • 手軽なアプローチ(コピー&ペースト):単純なエラーであれば、スタックトレースやエラーメッセージをそのままAIに貼り付けるだけで、文脈を理解して迅速に修正してくれる。
      • 規律あるアプローチとドキュメント化(規律モード)
        ・簡単な修正で解決しない場合は、Gitで元の状態に戻し、debug.md(または whatever.md)などのMDファイルを作成してAIに(エラーの確実な再現手順の記録、ログの調査と仮説の立案)を指示・記録させる。
        ・注意点: AIがネット上の古い、または無関係な1件のトラブル事例(Stack Overflowなど)を「既知の一般的な問題」と誤認して暴走することがあるため、人間によるサニティチェック(健全性確認)が必須。
      • 根本原因の証明と修正:AIに根本原因を証明させ、それを debug.md にドキュメント化させた上で修正を適用。修正後も一貫して動作することを確認させる。
      • 教訓の記録:会話のクリアやコンパクト化によってAIが過去の修正を忘れるのを防ぐため、学んだ教訓を claude.md に記録してプロジェクト内に残す。
    • デバッグのプロの技(Hot Tips)
      • 別のLLM(エージェント)の活用:Claudeが行き詰まった場合、異なるトレーニングやプロンプトを持つ別のモデル(Codexなど)に同じタスクを割り当てることで、別の視点から解決策が見つかることが多い。
      • デバッグスキルの活用:プラットフォーム内の「Systematic Debugging(体系的デバッグ)」などの既存スキルを読むことで、根本原因の追究(アイアンルール)やWeb検索を強化できる。
    • まとめと次回への展望
      • 本日の振り返り:Jiraからの課題読み込み、Claude Code(Feature Devプラグイン)による規律ある開発プロセス、GitHub MCP経由のPR作成・mergeまでの一連のワークフローが機能することを確認。
      • 現在の進捗:全行程の 60% を消化。AIを使いこなす技術が身についたため、明日からはこれらを実際の大型プロジェクトに投入していく。

Day 5

58-63

  1. SaaS プラットフォーム構築:Claude Code Skills & CLAUDE.md 設定
    前日から着手しているリーガル文書自動作成のSaaSプラットフォーム「PreLegal?」を構築するプロセスの主要なポイントを解説
    • Claudeの3つの拡張機能のまとめ
      Claudeに能力を付与する方法として、以下の3つの特徴とメリット・デメリットを再確認しています。
      機能特徴メリットデメリット
      MCPモデルとツールを結合するプロトコルエコシステムが豊富、柔軟性が高いコンテキストの消費量が多く、複雑(認証切れのリスク等)
      スキル (Skills)Markdown形式のテキストファイルシンプルでコンテキストの消費効率が良いMCPに比べるとパワー(機能性)が劣る。
      プラグイン (Plug-ins)上記の要素やエージェントをパッケージ化したものセットアップが極めて容易Claude Code専用
    • スキル (Skills)の構造と仕組み
      • コンテキスト節約のための3段階の読み込み:常にファイル(skill.md)の上部に「メタデータ(概要)」、必要に応じて「指示(Instructions)」、さらにスクリプトや外部ファイルと読み込む。
      • ファイル・システムによる実装:ホーム・ディレクトリ、またはプロジェクト・ディレクトリの .claude / フォルダ内に特定の階層で配置するだけで利用可能。
    • プロジェクトの整理とGit管理
      • 前日のPull Request(PR)作成時、Claude Codeは自動的に .claude ディレクトリをコミットしなかった
      • チーム共有のために手動で git add および git commit / push を行い、一貫性を保った。
    • ホーム・ディレクトリの CLAUDE.md の活用
      プロジェクト単位だけでなく、ユーザー自身のホーム・ディレクトリ(.claude/CLAUDE.md)にも設定ファイルを置くことが推奨されている。
      • 目的:すべてのプロジェクトで共通して適用したい、ユーザー個人の「開発スタイル」や「こだわり」をClaudeのコンテキストに毎回自動で追加。
      • コツ:すべての会話で読み込まれるため、トークン節約のために「極めて短く、簡潔に書く」ことが重要。
      • 注意:そして、ホーム・ディレクトリ(.claude/CLAUDE.md)には、claude独自のフォルダ構造が含まれているため触ってはいけない。
    • 具体的な設定例
      • アプローチ:常にタスクは小さく、段階的(インクリメンタル)に進め、過剰なエンジニアリングはしない。
      • ツール指定:Pythonのパッケージ管理には pip ではなく、常に uv(uv run や uv add)を使用する。
      • コードスタイル:明確で簡潔なドキュメント文字列を好む。
      • 新規追加ルール:絵文字(emojis)はPCでの不具合の原因になるため、コードやログに絶対に使用しない。 READMEは簡潔に保つ。
      • デバッグ:当てずっぽうで修正せず、必ず原因を特定し、1つずつテストして再現性を確認する。
        # VERY IMPORTANT
        - Be simple. Approach tasks in a simple, incremental way.
        - Work incrementally ALWAYS. Small, simple steps. Validate and check each increment before moving on.
        - Use LATEST apis as of NOW
        # MANDATORY Code Style
        - Do not overengineer. Do not program defensively. Use exception managers only when needed.
        - Identify root fause before fixing issues. Prove with evidence, then fix.
        - Work increnfentally with small steps. Validate each increment.
        - Use latest library APIs.
        - Use uv as Python package manager. Always uv run xxx never python3 xxx, always uv add xxx never pip install xxx
        - Favor clear, concise docstring comments. Be sparing with comments outside docstrings.
        - Favor short modules, short methods and functions. Name things clearly.
        # Important - debugging and fixing
        - When troubleshooting problems, ALWAYS identify root cause BEFORE fixing
        - PROVE THE PROBLEM FIRST - don't guess.
        - Try one test at a time. Be methodical.
        - Don't jump to conclusions. Don't apply workarounds.
  2. CLAUDE.md の作成と Cerebras 用カスタム Skill の構築
    • Claude.md(開発指示書)の作成と設定
      プロジェクトの全体像や開発プロセスをAIに理解させるためのファイル Claude.md を作成し、以下のコンテキストを定義。
      https://github.com/ed-donner/prelegal/blob/main/CLAUDE.md
      • プロジェクト概要(Pre-legal):
        ・テンプレートに基づいて法律契約書のドラフトを作成するSaaS製品。
        ・ユーザーはチャットを通じて必要なドキュメントの特定やフィールドの入力を行う。
        ・利用可能なドキュメントはルートの catalog.json に定義(@catalog.json の記述でファイルをインクルード)。
        ・初期実装は「フロントエンドのみのプロトタイプ」とする。
      • 開発プロセス:
        Jiraから機能要件を読み取り、テスト(単元・結合)を徹底した上で、GitHubでPRを作成。
        ・Atlassianツールを使用して、Jiraから機能の説明を読み取る。
        ・機能開発:機能開発の7ステッププロセスからどのステップも飛ばさない
        ・単体テストと統合テストで機能を徹底的にテストし、問題があれば修正。
        GitHubツールを使用してプルリクエストを送信。
      • AIデザイン
        ・LLMは、Cerebrasスキルを活用し、OpenRouter?経由でLiteLLMを使用して、Cerebrasのopenrouter/openai/gpt-oss-120bを呼出す。
        ・結果を解釈し、法的文書のフィールドに入力できるように、構造化出力を使用する必要があります。
        ・プロジェクトルートにある.envファイルにOPENROUTER_API_KEYが含まれています。
      • 技術設計(Technical Design):
        ・プロジェクト全体をDockerコンテナ化する。
        ・バックエンド:backend/ ディレクトリ配下、Pythonの uv を使用したFastAPI。
        ・フロントエンド:frontend/ ディレクトリ配下。
        ・データベース:SQLiteのコンテナ起動時に毎回作成(サインアップ/サインイン用テーブルを含む)。
        ・scripts/には以下のスクリプトが必要
        # Mac
        scripts/start-mac.sh    # Start
        scripts/stop-mac.sh     # Stop
        # Linux
        scripts/start-linux.sh
        scripts/stop-linux.sh
        # Windows
        scripts/start-windows.ps1
        scripts/stop-windows.ps1
    • Cerebrasを使用したカスタムSkillの追加
      LLMからのレスポンスを超高速にするため、特定のインファレンスプロバイダーを呼び出すカスタムSkillを構築
      • https://github.com/ed-donner/prelegal/blob/main/.claude/skills/cerebras/SKILL.md
      • 構成:.claude/skills/cerebras/ ディレクトリを作成し、その中にメタデータと実装を記述。
      • skill.md の作成:厳密なフォーマットに則り、メタデータ(名前、説明)を記述。
        ・仕様:LightLLM と OpenRouter? を経由し、インファレンス・プロバイダーとして Cerebras を指定してオープンソースモデル gpt oss 120b を呼び出す。
        ・結果の解釈や契約書フィールドへの流し込みを容易にするため、Structured Output(構造化出力)を使用するようコードスニペットやインポート文、実装例を記載。
        ---
        name: Cerebras Inference
        description: Use this to write code to call an LLM using LiteLLM and OpenRouter with the Cerebras inference provider
        ---
        # Calling an LLM via Cerebras
        These instructions allow you write code to call an LLM with Cerebras specified as the inference provider.  
        This method uses LiteLLM and OpenRouter. 
        
        ## Setup
        The OPENROUTER_API_KEY must be set in the .env file and loaded in as an environment variable.  
        The uv project must include litellm and pydantic.
        `uv add litellm pydantic`
        
        ## Code snippets
        Use code like these examples in order to use Cerebras.
        
        ### Imports and constants
        ```python
        from litellm import completion
        MODEL = "openrouter/openai/gpt-oss-120b"
        EXTRA_BODY = {"provider": {"order": ["cerebras"]}}
        ```
        ### Code to call via Cerebras for a text response
        ```python
        response = completion(model=MODEL, messages=messages, reasoning_effort="low", extra_body=EXTRA_BODY)
        result = response.choices[0].message.content
        ```
        ### Code to call via Cerebras for a Structured Outputs response
        ```python
        response = completion(model=MODEL, messages=messages, response_format=MyBaseModelSubclass, reasoning_effort="low", extra_body=EXTRA_BODY)
        result = response.choices[0].message.content
        result_as_object = MyBaseModelSubclass.model_validate_json(result)
    • 開発開始前の最終準備
      開発(ビルド)をスタートする前の最終調整として、以下の環境設定を行った。
      • Claude.mdのアップデート:AIデザインのセクションに、前述の gpt oss 120b モデルとCerebrasプロバイダーを使用する旨を明記。
      • 環境変数の設定:以前のプロジェクト(pm)から cp コマンドで .env ファイルをルートディレクトリにコピーし、OpenRouter? API Key を利用可能にし、Claude.md に追記してAIに明示。
  3. Claude Code で V1 製品を構築するための Jira チケット設定
    • Jiraでのチケット作成・更新
      プロトタイプから製品のバージョン1(v1)への移行に向けて、以下の4つのチケット(PL4〜PL7)を作成・編集。
      • PL4: 基盤の構築(Build foundation of V1 product)
        Description:Upgrade the prototype so that it is the proper technical foundation for the full V1 project, including frontend, backend and temporary database, with scripts to start and stop, but without updating the product features yet.
        プロトタイプをアップグレードして、フロントエンド、バックエンド、一時データベース、起動および停止スクリプトを含む、完全なV1プロジェクトの適切な技術基盤となるようにします。ただし、製品機能の更新はまだ行いません。
        ・内容: プロトタイプをフロントエンド、バックエンド、起動・停止スクリプト付きの移行用データベースを含む適切な技術基盤へとアップグレード。
        ・補足: 機能自体はまだ更新しない。認証機能は含めず、モックのログイン画面から直接プラットフォームに入れるようにする。
      • PL5: AIチャット機能の追加(Add AI Chat but still just Mutual NDA)
        Description:Now change the way the product interacts with a user. Instead of a series of questions, this should be a freeform chat with an AI. The AI asks about the document, asks questions related to the fields, and populates the document based on the responses.
        次に、製品とユーザーのやり取りの方法を変えてみましょう。一連の質問ではなく、AIとの自由形式のチャット形式にします。AIはドキュメントについて質問し、フィールドに関連する質問をし、回答に基づいてドキュメントに情報を入力します。
        ・ユーザーとの対話方法を一連の質問形式から、AIとのフリーフォームなチャット形式へと変更する。
        ・AIが文書に関する質問をして、回答に基づき必要項目を埋めるようにする(※対象はまだ相互秘密保持契約(Mutual NDA)のみ)。
      • PL6: 全法規文書タイプへの拡大(Expand to all supported legal document types)
        Description:Now expand the functionality so that it supports all the legal document types for which we have templates. Engage with the user if they want an unsupported document; explain that we can't generate that, but offer a closest document that we can generate, Guide the user through the document creation process.
        次に、テンプレートが用意されているすべての法的文書タイプをサポートするように機能を拡張します。ユーザーがサポートされていない文書を希望する場合は、その文書は生成できないことを説明し、生成可能な最も近い文書を提案します。そして、文書作成プロセスをユーザーに案内します。
      • PL7: 複数ユーザー対応と最終仕上げ(Support multiple users & final polish)
        Description:Add a proper sign in & sign up screen that lets the user register, and come back in to the platform.
        Store previously generated documents and allow the user to look back at prior documents that they have created. (The database can be temporary and be reset every time the server restarts).
        Also add polish to all the screens so that they look like a professional SaaS application. Also add a disclaimer that the documents should be considered draft and are subject to legal review.
        ・サインイン・サインアップ機能を実装し、過去に生成した文書を閲覧できるようにする(※DBは再起動時にリセットされる仕様で可)。
        ・また、プロ仕様のSaaSアプリに見えるよう画面を洗練させ、文書はドラフトであり法的レビューが必要である旨の免責事項を追加する
    • 開発環境の準備と認証
      • ContextとSkillsの確認:Claude Code側で /context コマンドを実行し、プロジェクト用スキルや既存のAtlassian(Jira)、GitHubのMCPサーバーなどのプラグインが認識されていることを確認。
      • Atlassianの再認証:Jiraとの連携を正常に動作させるため、Jira側の認証仕様に則って再認証(Reauthentication)とアクセス承認の手続きを行い、開発を実行する準備を整えた。
      • Jiraボードの構築が完了し、通常であればエンジニアリングチームに割り当てられるこれら4つのタスクを、今回はAIツール「Claude Code」に割り当てて実行。
  4. Claude Code、Jira、FastAPI を用いた機能開発
    • Jiraチケット「PL4」の拡張と実装
      >/feature-dev: feature-dev implement jira ticket PL-4 and make a PR
      • 要件定義と開発:JiraからPL4チケットの情報を取得し、開発を開始。認証機能は「プレースホルダーのみ」、NDAフォームは「クライアントサイドに維持」という仕様を対話で確定。
        Auth scope・NDA data・Submit
        Auth scope:The CLAUDE.md mentions sign up and sign in. For this V1 foundation ticket, should authentication be functional (even wirth temporary in-memory/SQLite users), or just have placeholder routes ready for the next ticket?
          1. Functional auth (Recommended)
             Implement working signup/signin with SQLite user storage, sessions, and protected routes
        > 2. Placeholder only
             Create auth routes and UI but no working implementation just the structure
          3. Type something.
          4. Chat about this
        NDA data:For the frontend-backend integration, should the current NDA form functionality remain client-side, or should form dat? be saved/persisted to the backend?
        > 1. Keep client-side (Recommended)
             NDA form works as-is, no backend integration focus on auth/infrastructure only
          2. Add backend persistence
             Save NDA drafts to database, user can retrieve later
          3. Type something.
          4. Chat about this
        Submit:Review your answers
          - The CLAUDE.md mentions sign up and sign in. For this V1 foundation ticket, should authentication be functional (eve with temporary in-memory/SQLite users), or just have placeholder routes ready for the next ticket?
            → Placeholder only
          - For the frontend-backend integration, should the current NDA form functionality remain client-side, or should form data be saved/persisted to the backend?
            → Keep client-side (Recommended)
        Ready to submit your answers?
        > 1. Submit answers
          2. Cancel
      • 設計レビュー:提示されたアーキテクチャを開発者がレビューし、承認。
        Does this architecture approach look good to proceed with implementation?
        > 1. Yes, proceed
             Implement the V1 foundation as described
          2. Need changes
             I have concerns or modifications to discuss
          3. Type something.
          4. Chat about this
      • 実装レビュー:モノリシックなコードにならず、適切な構造で生成されていることを評価。
      • テストと動作確認:自動生成された76個のテストがすべて合格。ローカル環境(localhost:8000)でスクリプトを実行し、正常な挙動を確認
      • ローカルでPL4のPRをmergeしてmainブランチへpushし、mainブランチへ切替
        > please merge the PR locally and push to main and switch branch to main
    • Contextのクリーンアップ(ベストプラクティス)
      • 次のチケット(PL5)に移る前に、/contextコマンドでContextウィンドウを確認後、実装済みセクションを claude.md に追記。
        > please add concise details to the end of CLAUDE.md with an update on what has been implemented, and change anything that's no longer accurate in CLAUDE.md
      • Contextが肥大化するとAIが自動圧縮を行い、重要な記憶を忘れるリスクがあるため、手動で /clearコマンドを実行してContextを初期化。
    • Jiraチケット「PL5」の開始とトラブルシューティング
      >/feature-dev: feature-dev implement jira ticket PL-4 and make a PR
      • 認証エラーの解決:PL5の読み込み時に処理が停止したため、認証切れと判断。ESCキーでセッションを中断し、/mcpコマンドで、Atlassian(Jira)のMCPの再認証を実行。
      • 要件の確定(チャットUIの導入):既存のフォームを完全に「チャットUI」へ置き換える仕様に決定。ドキュメントのライブアップデート、AIからの先制の挨拶、全フィールド入力後のダウンロード提示などを選択。
        UI Approach・Preview updates・Conversation start・Completion behavior・Submit
        UI Approach:Should the chat UI completely replace the form, or coexist with it (e.g., user can switch between chat and form views)?
        > 1. Replace form entirely
             Chat is the only way to fill in the NDA. Simpler UX, AI-first.
          2. Both available
             User can switch between chat and manual form. More flexible.
          3. Chat primary, form read-only
             Chat fills fields, form shows current values but is read-only.
          4. Type something.
          5. Chat about this
        Preview updates:Should the document preview update live as the AI extracts fields, or only after the user confirms?
        > 1. Live updates (Recommended)
             Preview updates immediately as AI extracts each field from chat.
          2. Update after confirm
             Preview only updates after user explicitly confirms AI suggestions.
          3. Type something.
          4. Chat about this
        Conversation start:How should the AI conversation begin?
        > 1. AI greets + asks first question
             AI initiate by asking about the parties involved.
          2. User types first
             Blank chat where user starts by explaining what they need.
          3. Type something.
          4. Chat about this
        Completion behavior:When all required fields are filled, what should happen?
        > 1. AI confirms show download (Recommended)
             AI summarize the NDA and prompts user to review and down load.
          2. Auto-generate PDF
             Automatically download PDF when all fields are complete.
          3. Type something.
          4. Chat about this
        Submit:Review your answers
        - Should the chat UI completely replace the form, or coexist with it (e.g., user can switch between chat and form views)?
          → Replace form entirely
        - Should the dosament preview update live as the AI extracts fields, or only after the user confirms?
          → Live updates (Recommended)
        - How should the AI conversation begin?
          → AI greets + asks first question
        - When all required fields are filled, what should happen?
          → AI confirms + show download (Recommended)
        Ready to submit your answers?
        > 1. Submit answers
          2. Cancel
    • PL5のアーキテクチャ議論
      • AIから3つのアプローチ(Minimal, Clean, Pragmatic)が提示される。
        Architecture:Which architecture approach would you like me to implement?
          1. Pragmatic Balance (Recommended)
             Streaming responses + parallel extraction. Good UX, simple backend.
          2. Minimal Changes
             Fewest new files, combined chit+extraction.
             Fastest to implement.
          3. Clean Architecture
             Full session persistence, service layers. Most robust, most work.
          4. Type something.
        > 5. Chat about this
      • AIは「ストリーミング応答」を提案、選択式のように見え、実質的にオープン・クエスチョンだったため、Chatで、Cerebras(推論エンジン)は非常に高速なためストリーミングは不要とした。
        What would you like to clarify about the architecture options? I'm happy to explain any aspects in more detail or answer questions about trade-offs.
        > I'd like the pragmatic choice except I only want 1 LLM call and no streaming, because Cerebras is so fast that streaming isn't necessary. 1 LLM call with structured outputs including the response is cleaner
  5. Cerebras と Claude Code で AI Legal Doc Generator をテスト
    • チケットPL5の実装と検証
      • 実装内容:Cerebras(LLM)と統合されたAIチャットインタフェースおよびバックエンドAPIの構築。
      • 検証:GitHubに自動生成されたPR(13ファイル、456行の変更)のコードを確認し、指示通りのスキルやモデルが使われていることを確認。
      • ローカルテスト:ローカル環境で起動し、相互秘密保持契約(NDA)の生成をテスト。Cerebrasによるレスポンスの速さ(ストリーミング不要なレベル)を高く評価。最終的にPDFのダウンロードまで正常に動作することを確認。
          Hello! I'll help you create a Mutual Non-Disclosure Agreement. Let's start with the basics what's the purpose of this NDA? For example, are you evaluating a potential business partnership, discussing a merger, or something else?
        > Yes I'm evaluating a business relationship
          Great, evaluating a business relationship it is. When would you like the agreement to become effective? If you're unsure, we can use today's date (2026-02-05).
        > yes today
          Sounds good-let's set the effective date to today, 2026-02-05.
          Next, how long should the overall MNDA last? You can choose a fixed period (e.g., expires after 2 years) or have it continue until either party terminates it.
        > 3 years please
          Got it-the MNDA will expire after 3 years.
        > OK what else do you need to know
          Great. Next, how long should the confidential information be protected? You can pick a number of years (e.g., 2 years) or choose "perpetuity" for indefinite protection.
        > 2 years
          Got it-the MNDA will expire after 3 years and the confidentiality obligation will last for 2 years.
        > what else do you need to know
          We're almost there! I just need a few more details:
          1. Which state's laws should govern this agreement (e.g., Delaware)?
          2. Where should any disputes be resolved (city and state, e.g., New Castle County, Delaware)?
          3. Party 1-the name of your company, the signatory's full name, their title, a notice-email address, and the date they'll sign (we can use today's date if that works).
          4. Party 2- the same information for the other side. Whenever you're ready, just share whatever you have and we can fill in the rest.
        > 1. new York 2. New York 3. Just put default company names in there for now
          Perfect-I'll use New York law and New York as the dispute location. For the parties, I'll insert placeholder details:
          
          **Party 1**
          - Company: Company A
          - Signatory: John Doe
          - Title: CEO
          - Notice address: john.doe@companya.com
          - Signature date: 2026-02-05
          
          **Party 2**
          - Company: Company B
          - Signatory: Jane Smith
          - Title: President
          - Notice address: jane.smith@companyb.com
          - Signature date: 2026-02-05
          
          If you'd like to change any of these later, just let me know. With these placeholders, we now have all the required information to complete the NDA. Shall I finalize it?
        > yes finalize it
          Excellent! Here's a summary of the Mutual Non-Disclosure Agreement you've configured:
          **Purpose:** Evaluating a business relationship
          **Effective Date:** 2026-02-05
          **MNDA Term:** Expires after 3 years (2029-02-05)
          **Confidentiality Term:** 2 years (until 2028-02-05)
          **Governing Law:** New York
          **Jurisdiction:** New York
          
          **Party 1**
          - Company: Company A
          - Signatory: John Doe
          - Title: CEO
          - Notice address (email): john.doe@companya.com
          - Signature date: 2026-02-05
          
          **Party 2**
          - Company: Company B
          - Signatory: Jane Smith
          - Title: President
          - Notice address (email): jane.smith@companyb.com
          - Signature date: 2026-02-05
          
          If everything looks good, this draft is complete and ready for you to review or copy into a document.
          Let me know if you need any final tweaks or a formatted version of the agreement!
      • 課題の発見:
        (1)AIが次の質問を継続して投げかけないため、会話が途切れてしまう。
        (2)入力後にテキストフィールドへのフォーカスが自動で戻らない。
    • 次のステップへの移行(Contextのクリーンアップ)
      • ローカルでPL5のPRをmergeしてmainブランチへpushし、mainブランチへ切替
        > yes please merge the PR locally and push and switch to main branch
      • プロジェクトのステータス管理ファイル(CLAUDE.md)の更新を確認。
        > please check CLAUDE.md is up to date with project status
      • Contextウィンドウの容量が限界に達したため(/context)、チャット履歴をクリア(/clear)、JiraのMCPを再認証(/mcp → Re-authenticate)。
    • チケットPL6の実装と機能向上
      • 追加の指示:Jiraチケット「PL6」に「PL5」の残件(「AIが常に次の質問をすること」「UIフォーカスを入力欄に戻すこと」)の修正に加え、すべての法的文書タイプへの対応を指示。
        >/feature-dev: feature-dev implement jira ticket PL-6.
        「Also please make a couple of fixes. Ensure that after answering a question, the UI focus goes back to the text input field.
        And ensure that the AI always asks a follow-on question if it needs more information. When PL-6 is done and these enhancements are done, please test」
        then make a PR
      • 結果:AIがタスクを完了し、PL6のPR(16ファイル、2500行以上の追加)を自動作成。
      • 最終テスト:
        ・クラウドSaaS契約の生成をテスト。AIが質問を繰り返し、右側のプレビュー画面がリアルタイムに埋まっていく仕様を確認。
          Hello! I'll help you create a legal agreement. What type of document do you need? For example, are you looking for:
          - An NDA to protect confidential information?
          - A Cloud Service Agreement for SaaS products?
          - A Pilot Agreement to trial a product?
          - Something else?
          Just tell me what you're trying to accomplish and I'll help you find the right document.
        > A cloud SaaS agreement
          Great, a Cloud Service Agreement it is! Let's start gathering the details.
          First, could you tell me the name of the SaaS provider company and the name of the customer company?
          And what's a brief description of the cloud service you'll be providing (e.g., "project-management platform with analytics").
        > Please use invented placeholder names for both companies; the cloud service is an Al Assistant
          Sure, I'll use placeholder names. Let's call the provider **Acme Cloud Solutions, Inc.** and the customer **Beta Enterprises, LLC**. The service will be an "Al Assistant**
          Next, what start date would you like for the agreement? You can say "today", a specific date (e.g., 2026-03-01 or any other date you prefer.
        > today please
          Got it the effective date will be today (2026-02-05). Which state's laws should govern the agreement, and in which jurisdiction (city/county) should any disputes be resolved?
        > New York, New York please
          Great! I've noted the effective date as 2026-02-05, governing law as New York, and jurisdiction as New York, NY.
          Now we'll need a few more details:
          1. How long is the subscription period (e.g., "1 year", "monthly", "2 years")?
          2. What level of technical support will be provided (e.g., "24/7 email support", "business hours phone support")?
        > 1 year, business hours phone support
          Got ita 1-year subscription with business-hours phone support.
          Next, could you let me know the pricing structure (e.g., "$5,000 per year" or "$500 per month") and the payment schedule (e.g., "annual upfront payment", "monthly invoicing within 30 days")?
        > $10,000 per annum, net 30
          Thanks for the details! Here's a summary of what we have so far for your
          Cloud Service Agreement:
          - Provider: Acme Cloud Solutions, Inc.
          - Customer: Beta Enterprises, LLC
          - Service: Al Assistant
          - Effective Date: 2026-02-05
          - Governing Law: New York
          - Jurisdiction: New York, NY
          - Subscription Period: 1 year
          - Technical Support: business-hours phone support
          - Fees: $10,000 per annum
          - Payment Terms: Net 30
          We have captured all required information, so the agreement draft is ready to be generated.
        ・ブランドカラーの適用や、最終的なPDFダウンロード機能を含め、100%に近い完成度のプロダクトが完成したと絶賛(最後にPRを確認)。
  6. 最終 PR merge、SaaS 完全デモ & Claude Code Week 2 勝利
    • 最終チケット(PL7)の実装と検証
      • ローカルでPL6のPRをmergeしてmainブランチへpushし、mainブランチへ切替
        > please go ahead and merge the PR locally, and push, and then switch the branch to main
      • プロジェクトのステータス管理ファイル(CLAUDE.md)の更新を確認。
        > please update CLAUDE.md to reflect the latest project status
      • プロセスの実行:Contextをクリアにした後(/clear)、JiraのMCPを再認証(/mcp → Re-authenticate)、最終チケット「PL7」をClaude Codeの「Feature Dev」機能で実装。
        >/feature-dev: feature-dev implement jira ticket PL-7. Then test and submit a PR.
      • 動作確認(デモ):サーバを再起動し、未ログイン状態での試用から、サインアップ、ログイン、ドキュメントの編集・保存(PDFダウンロード、データ永続化)までの一連の挙動がスムーズに動作することを確認。
      • 評価と課題:
        ・見栄えが非常に洗練されており、期待を大きく超える成果(プロダクト主導型成長:PLGのフリーミウムパターン)に大満足している。
        ・ただし、JIRAで指定した「法的免責事項」が記載されていないなどの漏れもあり、AIが完璧ではないため人間の二重チェックが必要であることも指摘。
    • GitHubへの反映と勝利宣言
      • コードベースの規模:生成されたプルリクエスト(PR)を確認したところ、22ファイルにわたり約1,500行のコードが追加されていた。
      • 完了手続き: ・ClaudeにローカルでのPRのmerge、push、mainブランチへの切り替え、
        > please merge the PR locally and then push and then switch to the main branch
        ・およびプロジェクトの最新ステータスを反映した CLAUDE.md の更新を指示し、プロジェクトの「勝利」を宣言。
        > please update CLAUDE.md with latest project status
      • 技術的要素:JIRA/Gitのシームレスな統合に加え、裏側では高速推論の「Cerebras」や構造化出力(Structured Outputs)が活用されている。
    • 課題とコミュニティへのお願い
      • 課題:JIRAやGitHub Issuesにチケットを切り、Claude CodeのFeature Devを活用して、テンプレートとチャットを組み合わせた独自のSaaSプロダクトを構築。
      • 成果の共有: 成果はLinkedIn?などでハッシュタグや講師へのメンションを付けて積極的に発信し、コミュニティ全体で称え合うことを推奨。
    • 次週(第3週)への展望
      • プログラム全体の3分の2(67%)を終えたマイルストーンを祝福。
      • 次週(最終週)は「さらにクレイジーでワイルドな内容」として、より大規模なコードベース、エージェント、フック、スウォーム(Swarms)、オーケストレーターなどを扱う。

Week 3

Vibe Engineering as an expert(エキスパート向け)

Day 1

65-71

  1. Claude Code Pro: サブ・エージェント、フック、スウォーム、そして制御されたカオス
    • 日替わりスケジュール
      • 1日目(今日):プロ向け機能の概観(カスタムコマンド、マルチ/サブ・エージェント、フックなど)
      • 2日目:サンドボックシング(環境の隔離と再現性の確保)
      • 3日目:大規模なコードベースにおけるデバッグと開発の成功法則
      • 4日目:スウォーム(群画)やオーケストレーターを用いた応用、および集大成となるキャップストーンプロジェクト
    • 核心概念:カオスとコントロールのバランス
      • 開発者は、AIがもたらす「爆発的な推進力(カオス)」と「確実な管理(コントロール)」のバランスを、プロジェクトの成熟度やリスク許容度に応じて調整する必要がある。
      • ゴールは「コントロールされたカオス」:まずは「コントロール」から始めて徐々に手を緩め、成果に応じて「カオス」を取り入れていく。最終的な成果物の責任は常に人間の開発者にある。
        分類特徴・具体的なアプローチ主な技術・概念
        カオス (Chaos)推進力の最大化正のフィードバック。信頼してAIに任せる、または自律的にループを回して一気に開発を加速させるアプローチ。YOLO、Ralphループ、GSD、スウォーム(多量のエージェントによる協調)
        コントロール (Control)安全性と品質の担保負のフィードバック。狂気的なカオスを枠内に収め、脱線を防ぐためのアプローチ。ファイルシステムによるプロセス間連携、自己修正プロセス、サンドボックス(環境隔離)、オーケストレーション(階層と役割の管理)
    • 本日(1日目)学習するプロ向け機能
      本日、リポジトリを使って実際に手を動かしながら学ぶ機能は以下
      • カスタムSlashコマンド:独自のSlashコマンド(/command)の作成
      • マルチ・エージェント vs サブ・エージェント:複数のClaude Codeを立ち上げるシンプルな手法 vs 本日深く掘り下げる、より高度な連携手法
      • エージェントチーム:チームとしての協調(4日目に本格実践)
      • フック (Hooks):Ralphループなどを実現するための仕組み
      • 独自プラグインの作成:チーム内での共有やマーケットプレイスへの公開方法
  2. FiNALLYプロジェクトのセットアップ:私たちのマルチ・エージェント取引アプリ(?アプリ内部もマルチ・エージェント?)
    • プロジェクトの概要
      • 今週の課題は、コースの集大成(キャップストーン・プロジェクト)となる「Finally(Finance Ally:金融の味方)」の構築。
      • 複数のAIエージェント(マルチ・エージェント)を協調・制御させて、本番クオリティのフルスタック・アプリケーションをほぼ一発(ワンショットに近い形)構築を目指す。
    • アプリケーションの機能とビジョン
      • AI搭載のトレーディング・ワークステーション:見た目や操作感は「AIコパイロットが統合された現代的なブルームバーグ端末」のようになります(株の知識が少しあれば理解できる内容です)。
      • 余談:「ブルームバーグ端末に手を出すな」(WSJ)では「安価なAIが代替できる」(テック業界)と「絶対に手放せない」(金融業界)の間で起きた論争が取り上げられている。
      • ライブ市場データのストリーミング:SSE(Server-Sent Events)技術を使用し、UI上にリアルタイムで価格をストリーミング。モックデータで有料WebAPI(Massive/旧Polygonなど)を使わなくても動作。
      • シミュレーション取引:ユーザーは仮想ポートフォリオで取引が可能です。
      • LLMアシスタントの統合:ポートフォリオの分析や取引の代行を実行できるAIアシスタントを搭載。Cerebras(またはOpen Router)のスキルや構造化出力を再利用し、高速なインタラクションを実現。
    • 技術スタックとアーキテクチャ
      • データベース:シンプルさを維持するため、前回同様にSQLiteを採用(アプリ起動時に自動生成され、セッション間でデータが永続化されます)。
      • デプロイ:複雑化を避けるため指示により単一のDockerコンテナでシンプルに全システムを実行する構成。これによりクラウド移行も容易。
    • 開発の進め方と初期リポジトリの構成
      指定のリポジトリ(https://github.com/ed-donner/finally)を git clone してVS Codeで開き以下の通り初期状態の主な構成を確認。
      > git clone https://github.com/ed-donner/finally.git
      • Claude.md:すべてのコーディング・エージェントがこの planning/PLAN.md を必ずコンテキスト(共通認識)として読み込むように制御するためのファイル。
      • 配置場所を明示する目的で、空のディレクトリ群(backend、frontend、db、test)や、環境変数ファイル(.env)が用意されている。
      • planning/PLAN.md:https://github.com/ed-donner/finally/blob/main/planning/PLAN.md
        ・ビジネス要件やアーキテクチャが定義された最重要書類(冒頭のビジョンを除きベースはClaudeとの対話で作成)。
        ・全エージェントが planning/PLAN.md に準拠してプロジェクトを組み上げる。
  3. Claude CodeでのカスタムSlashコマンドの作成
    ※ ココで新規作成したリポジトリに存在しないカスタムSlashコマンドは検証後に削除する。
    • Slashコマンドの概要と作成方法
      開発ツール(Claude Code)において、独自の「Slashコマンド(/で始まるショートカット)」を自作する方法には2つのアプローチがある。
      • 方法①:commands フォルダを使用する(従来の標準的な方法)
        ・手順:プロジェクト内(またはホームディレクトリ内)の .claude フォルダの中に、新しく commands というフォルダを作成します。
        ・定義方法:その中に、作成したいコマンド名(小文字+ハイフン推奨。例: doc-review.md)のMarkdownファイルを作成し、実行したいプロンプト内容を記述。
         例:Review the documentation file in the planning folder called $ARGUMENTS and add questions, clarifications or feedback to a new section at the end, along with any opportunities to simplify
        ・引数の利用:プロンプト内で $ARGUMENTS(すべて大文字)と記述すると、ユーザーがSlashコマンドの後に打ち込んだテキストをその部分に代入できる。
        ・メリット:YAML形式のメタデータ(フロントマター)を書く必要がなく、シンプルな指示文(1行のテキストなど)を記述するだけで簡単に作成できる。
      • 方法②:skills フォルダを使用する(現代の主流)
        ・もう1つの方法は「スキル(Skills)」として定義する方法
        ・.claude 内の skills フォルダに定義を追加するだけで、そのスキル名が自動的にSlashコマンドとして利用可能になる。
        ・現在の開発においては、この「Skills」としてSlashコマンドを実装する方法が主流となっている。
        ・以前実装したSkillsのnameをSlashコマンドで使用できるように「Cerebras Inference」→「cerebras-inference」に変更(ソレ以外の修正はない)
         ・https://raw.githubusercontent.com/ed-donner/prelegal/refs/heads/main/.claude/skills/cerebras/SKILL.md
         ・https://raw.githubusercontent.com/ed-donner/finally/refs/heads/main/.claude/skills/cerebras/SKILL.md
    • 実践:ドキュメントレビュー(doc-review)コマンドの実行
      計画書ファイル(PLAN.md)のレビューを行うコマンドを実際に実行し、そのプロセスと注意点について解説
      > /doc-review PLAN.md
      • 人間の監視と裁量の重要性:
        ・AI(Claude Opus 4.6)は指示通り「質問・明確化・修正点」および「簡素化の提案」をドキュメントの末尾に追加した。
        ・しかし、AIが提案した「簡素化」の多くは、システムの将来性(複数ユーザー対応など)を損なうオーバーな提案だった。
        ・同意できる(以下の)1点のみを残して却下。AIの提案を鵜呑みにせず、人間が必要な価値判断を行うことが重要
        システム設計(データベースやAPIなど)における数量(quantity)のデータ型に関する指摘
        ・指摘の内容現状:positions/trades(ポジションや取引)の数量が REAL 型(浮動小数点数)で定義されている。
        ・懸念点:もし「単元株(整数)」のみを扱うのであれば、INTEGER(整数型)の方が適切である。REAL 型を使うと、損益計算(P&L)などで浮動小数点特有の丸め誤差が発生するリスクがある。
        ・提案:REAL が意図的なのであれば、バリデーション(入力チェック)の仕様に「端数株(小数株)を許可する」旨を明記すべきである。
        ・回答:はい、端数株(fractional shares)をサポートすべきです。
        ・レビューの指摘に対するフィードバックに基づきPLAN.mdを更新する。
        > I've updated the comments at the end of PLAN.md with my feedback and removed the simplifications that I disagree with. Please now review the remaining issues, and incorprate the solutions throughout PLAN.md, letting me know any questions
      • 通常のコマンドとサブ・エージェントの違い:
        ・今回のような通常のコマンドやスキルは、すべてメイン・チャットの会話履歴(コンテキスト)に含まれる。
        ・一方で、今後学ぶ「サブ・エージェント」は別のLLMコールを独立して立ち上げるため、メインチャットのコンテキストを汚さずにファイルを更新できる。
    • まとめ
      • どちらの方法で作成した場合も、.claude ディレクトリに保存してGitにコミットすれば、プロジェクトチーム全員でそのカスタムコマンドを共有できる。
      • 今週の講義では、このようなレビューや開発のプロセスをさらに自動化していく方法(自動化レビューなど)について深く掘り下げていく。
  4. Claude CodeとCodex CLIを使ったエージェント&サブ・エージェントの構築
    ※ ココで新規作成したリポジトリに存在しないサブ・エージェントは検証後に削除する。
    • マルチ・エージェントの基本と課題
      • マルチ・エージェントの単純なアプローチ:ターミナルのタブ化でプロンプト(例: Claude)を複数立ち上げ、それぞれに「フロントエンド開発」「バックエンド開発」「テスト作成」といった異なる役割を並行して与える方法。
      • 現状の課題:開発計画の連携や境界線が十分に定義されていない段階でこれを実行すると、エージェント同士が互いの作業を認識できないため、整合性が取れず大混乱(カオス)を招く危険性がある。
    • 異なるCLIエージェント(Codex)との連携
      • 講義内の実験として、Claude Codeとは異なるAIエージェントであるOpenAIの「Codex CLI」を導入。
        > npm i-g @openai/codex
        > codex
      • codex exec コマンドを使用し、シェル(ターミナル)経由でCodexに計画書(PLAN.md)のレビューを指示し、結果を review.md に出力させる。
        > codex exec "ase review the file planning/PLAN.md and write your feedback to planning/REVIEW.md"
      • これにより、複数の異なるAIモデルを別々のエージェントとして外部コマンドから並行稼働させる可能性を示している。
    • サブ・エージェントの作成とメリット
      • サブ・エージェントとは:メインのClaude Codeから特定のタスク(ファイル探索、計画作成など)を切り離し、独立したコンテキスト(背景情報)で実行させる仕組み。
      • 主なメリット:
        ・コンテキストの分離: メインエージェントのトークン(記憶容量)を汚染・浪費しない。
        ・コストと速度の最適化: 処理に応じて「Haiku」のような軽量・安価なモデルを裏で使い分けられる。
        ・並行処理: 複数のタスクを同時に実行できる。
    • カスタム・サブ・エージェントの構築:
      • プロジェクト内の .claude/agents/ フォルダに reviewer.md という設定ファイルを作成し、役割(レビュー担当)と指示文を定義。
        ---
        name: reviewer
        description: carry out a comprehensive review when requested
        ---
        You review the file planning/PLAN.md and write your feedback to planning/REVIEW.md
      • 他にも以下のような属性を設定できるらしい(必須は name と description のみ)。
        tools: Read, Glob, Grep
        model: opus
        ...disallowedTools, permissionMode, maxTurns, skills, mcpServers, hooks, memory, background
      • Slashコマンドではなくプロンプトで指示を出すことで、メインの文脈を維持したまま、バックグラウンドで独立したレビュー処理を実行・完了させることに成功。
        > Use the reviewer agent to carry out a reivew
    • なお、/agentsコマンドで以下の項目を確認・実行できる。
      • Create new agent:平易な英語の説明文から、Project or PersonalのAgents定義を自動生成する。
        ・.claude/agents/ → プロジェクト固有(チームで共有可能)
        ・~/.claude/agents/ → 全プロジェクト共通(個人用)エージェント
      • Project agents:定義したプロジェクト・チーム用エージェント
      • Personal agents:定義した個人用エージェント
      • Plugin agents:Slashコマンド、サブ・エージェント、MCP、フックを組み合わせてパッケージ化したもの。
      • Built-in agents:Explore(ファイルの読み取りはできるが編集はできない)、Bash(コマンドを実行できるがウェブ検索はできない)、といったツールの制限が設定されている。
  5. Claude Codeにおけるサブ・エージェント vs エージェント・チーム(Codex Review付き)
    ※ ココで新規作成したリポジトリに存在しないサブ・エージェントは検証後に削除する。
    • Claude Codeにおけるサブ・エージェントの活用(異種LLMの連携)
      • .claude/agents/codex-reviewer.md に、以下のようにシェルコマンド経由で別LLMの Codex を呼び出してファイル(PLAN.md)のレビューを実行するサブ・エージェントを定義。
        ---
        name: codex-reviewer
        description: carry out a comprehensive review of PLAN.md when requested using codex
        ---
        You are using a different AI Agent to carry out a review of the document: planning/PLAN.md.
        You MUST execute the following shell command to carry out the review do not review yourself:
        *codex exec "Please review the file planning/PLAN.md and write your feedback to planning/REVIEW.md""
        This will run the review process and save the results. Do not review yourself.
      • サブ・エージェントを起動し、メインの文脈(コンテキスト)を汚さずに効率的な処理を実現。
        > Use your codex-reviewer subagent to carry out a review of planning/PLAN.md
      • .claude/agents/change-reviewer.mdに、以下のように特定ファイルのレビューから、前回のコミット以降の全変更点をレビューする、より汎用的なサブ・エージェントを定義
        ---
        name: change-reviewer
        description: carry out a compehensive review of all changes since the last commit
        ---
        This subagent reviews all changes since the last commit using shell commands.
        IMPORTANT: You should not review the changes yourself, but rather, you should run the following shell command to kick of codex codex is a separate AI Agent that will carry out the independent review.
        Run this shell command:
        codex exec "Please review all changes since the last commit and write feedback to planning/REVIEW.md""
        This will run the review process and save the results. Do not review yourself.
      • サブ・エージェントを起動し、メインの文脈(コンテキスト)を汚さずに効率的な処理を実現。
        > use the change-reviewer subagent to review changes since last commit
      • サブ・エージェント、外部LLM(Codex)とのやり取りは独立した環境で行われるため、メインのContextウィンドウはクリーンな状態(会話履歴が蓄積されない状態)に保たれる。
    • 「サブエージェント」と「エージェントチーム」の違い
      機能特徴・役割
      サブ・エージェント(Sub-agents)メインのClaude Codeから**単一の特定タスクを委託(デリゲート)**され、隔離されたコンテキストで実行して結果を戻す、シンプルかつ具体的な仕組み。
      エージェント・チーム(Agent teams)※実験的機能複数のClaude Codeを組み立てて協調しながら問題を解決する仕組み(スウォーム/オーケストレーション)。
      メインを介さずエージェント同士(例:テスターとフロントエンド/バックエンド担当)が直接対話・連携できる。
  6. Claude Code Hooks:イベント&コマンドによる自動レビュー起動
    • Claude Code の「フック(Hooks)」機能の概要
      日常的でない特定の状況(イベント)において自動で特定の処理を実行させることができる高度な(プロ向け)機能。
      • 仕組み: 特定の「イベント」が発生した際、あらかじめ設定しておいた処理を自動でトリガー(実行)。
      • イベントの例:
        ・ツール実行の前(Pre tool use) / 後(Post tool use)
        ・ユーザーへの権限確認時(例:確認時にスマホへ通知を飛ばすなど)
        ・Claude が作業を終了・停止する時(Stop / Session end)など多数。
      • トリガーできる3つの処理
        ・Command(シェル・コマンドの実行): 最も確実でバグが起きにくいオススメの処理。
        ・Prompt(Claudeへのプロンプト指示): 新たな指示を Claude に与える。
        ・Agent(サブ・エージェントの起動): コンテキストを汚さずに別エージェントに作業させる。
    • 実装例:作業終了時に自動コードレビューを行う
      Claude が作業を終えたタイミング(stop イベント)で、自動的に外部の codex エージェントを起動してコードレビューを行うフックの設定を行う。
      • 設定場所:プロジェクト内の .claude/settings.json(または /hooks コマンドからインタラクティブなメニュー画面で設定可能)。
        {
          "hooks": {
            "Stop": [{
              "hooks":[
                "type":"command",
                "command": "codex exec \"codex exer "Review changes since last commit and write results to a file named planning/REVIEW.md"
              ]
            }]
          }
        }
      • 設定方法:
        ・/hookコマンドでStopを選択し、
        /hooks
        Hooks
        6 hooks
          1. PreToolUse Before tool execution -
          2. PostToolUse After tool execution
          3. PostToolUseFailure After tool execution fails
          4. Notification -When notifications are sent
          5. UserPromptSubmit When the user submits a prompt
          6. SessionStart When a new session is started
        >  7. Stop Right before Claude concludes its response
          8. SubagentStart When a subagent (Task tool call) is started
          9. SubagentStop - Right before a subagent (Task tool call) concludes its response
          10. PreCompact Before conversation compaction
          11. SessionEnd When a session is ending
          12. PermissionRequest - When a permission dialog is displayed
          13. Setup Repo setup hooks for init and maintenance
          14. TeammateIdle When a teammate is about to go idle
          15. TaskCompleted When a task is being marked as completed
          16. Disable all hooks
        ・定義したフックを選択する。
        Stop
        Exit code 0 stdout/stderr not shown
        Exit code 2 show stderr to model and continue conversation
        Other exit codes show stderr to user only
         
          1. + Add new hook...
        > 2. codex exec "Review changes since last commit and write results to a file named planning/REVIEW.md" Project Settings
      • 動作の流れ:
        ・事前に、ココまでで作成した、カスタムSlashコマンドやサブエージェントは削除しておく。
        ・ユーザーが Claude に「README.md を作成して」と指示。Claude が README の作成を完了し、作業を終了(stop)する。
        > please make a concise README.md for the project
        - Let me check the current project state first.
        - Searched for 1 pattern, read 2 files (ctrl+o to expand)
        - Both backend/ and frontend/ are empty the project is in its planning phase. I'll write a concise README that reflects the vision without overpromising on what exists yet.
        - Write (README.md)
        Done. The README covers the essentials what the project is, how to run it, what it does, the architecture, env vars, and project structure all in a concise format.
        ・フックが発動し、バックグラウンドで codex exec コマンド(前回のコミットからの変更点をレビューし review.md に書き出すコマンド)が自動実行される。
        ・Claude 自身は裏でレビューが動いたことを認識していないが、ワークフローとして自動化が完了する。
    • まとめ、注意点とアドバイス
      • フックは開発プロセスを高度に自動化できる強力なツールだが、複雑性を伴う。
      • 最初から無理に覚えようとせず、「こういうことができる」という全体像だけを頭に入れておき、実際に必要になったタイミングで公式ドキュメントを参照するのが最適。
  7. カスタムClaude Codeプラグインとマーケット・プレイスの構築
    • 独自プラグインとマーケット・プレイスの作成・導入
      Claude Codeにおける独自プラグイン(例: 変更点を自動レビューする「independent-reviewer」)の作成と、それをチームや個人で共有するためのマーケット・プレイス構築の手順。
      • プラグインの作成手順
        ・フォルダの作成:任意の場所にプラグイン用の新規フォルダ(independent-reviewer)を作成する。
        ・設定フォルダとマニフェスト:その中に .claude-plugin という固定名のサブディレクトリを作り、メタデータ(名前、説明、バージョンなど)を記述した plugin.json ファイルを配置する。
        {
          "name": "independent-reviewer",
          "description": "Carry out an independent review of all changes since last commit",
          "version": "1.0.0"
        }
        ・機能の追加:役割に応じて、プラグイン・フォルダ内に以下の4つのサブ・フォルダを必要に応じて作成し、設定する。
         commands、skills、agents、hooks ... ココでは先ほど定義した .claude/settings.json を hooks/hooks.json として配置
        {
          "hooks": {
            "Stop": [{
              "hooks":[
                "type":"command",
                "command": "codex exec \"codex exer "Review changes since last commit and write results to a file named planning/REVIEW.md"
              ]
            }]
          }
        }
      • マーケット・プレイスによる共有とインストール
        ・マーケット・プレイスの定義:リポジトリのルートに .claude-plugin フォルダを作成し、その中に marketplace.json を配置する。ここに独自のマーケット・プレイス名や作成者情報、公開するプラグインのリストとパスを記述する。
        {
          "name": "ed-tools",
          "owner": {
            "name": "Ed",
            "email": "ed@edwarddonner.com"
          },
          "plugins": [{
            "name": "independent-reviewer",
            "source": "./independent-reviewer",
            "description": "Carry out an independent review of all changes since last commit",
            "version": "1.0.0",
            "author": {
              "name": "Ed"
            }
          }]
        }
        ・Claude Codeへの導入:/plugin コマンドを実行し、Marketplacesメニューから「Add marketplace」を選択。
        ・ローカルパス(./)やGitHubのURLを指定してマーケット・プレイスに追加(ココではローカルパス(./)を指定)。
        ・Discoverメニューからマーケット・プレイスに追加したプラグインをインストールし、Claude Codeを再起動すると機能が有効化される。 ・意図した指示を出してプラグインを動作確認する。
        > please write a concise project README.md
        - Let me read the current README and check project state first.
        - Read 4 files (ctrl+o to expand)
        - The project is still early no Dockerfile or scripts yet. I'll write a concise README based on the plan.
        - Write (README.md)
        Done. The README covers the project vision, features, architecture, quick start, environment variables, and project structure - all concise and scannable.
    • 特定のタスクをメインのClaude Codeから切り離して並行処理させるサブ・エージェントのメリットとデメリット、評価まとめ
      メリットデメリット
      並行処理と自己修正:複数のサブ・エージェントが協調し、相互にフィードバックをかけながら作業できる。複雑性の向上:動くパーツが増えるため、問題が発生した際の追跡やデバッグが難しくなる。
      コンテキストの節約:メインのClaude Codeのコンテキスト(対話履歴やメモリ)を圧迫せずに済む。境界問題とエラーの増幅:メイン・エージェントとのインターフェースで誤解が生じ、エラーが連鎖・増幅するリスクがある。
      タスクの特化:1つのタスクに特化させることで、プロンプトの最適化や精度向上がし易い。コストの不確実性:安価なモデルの利用で節約できる反面、自己修正などのループが増えると最終的な費用がかさむ。
    • 次回の予告
      • 翌日は、さらに重要なテーマである「サンドボックス化(Sandboxing)」および「Claude Codeの遠隔実行(リモート実行)」について解説。
      • 今回触れられなかった「MCPサーバー」や「LSPとの組み合わせについても補足予定。
      • 現在全体の「73%」完了、ここからさらに実践的で難易度の高い内容へと入っていく。

Day 2

72-77

  1. Claude Codeのサンドボックス化とクラウド実行の徹底解説
    • 前日の復習:Claude Codeのプロ機能(Slashコマンド、サブ・エージェント、フック、プラグインなど)と活用法
      • フォーカスの絞り込み:Slashコマンド: 現在はほぼ「スキル(Skills)」に置き換わっているため、重要度は低い。
      • フック/プラグイン:特定の課題解決やチーム共有には便利だが、使用頻度は低い。
      • 今後の中心:自身やチームのレポジトリで活用できる「スキル」や「サブ・エージェント」の開発に集中
      • 汎用的なスキル:これらの機能(特にスキル)はAnthropicが提唱したデファクトスタンダード(事実上の標準)で他にも普及しつつある。
      • プラグインの高度な構成ファイル:
        ・.mcp.json: プラグインに含まれるMCP(Model Context Protocol)サーバーを記述する。
        ・.lsp.json: LSP(Language Server Protocol)を利用し、Claude Codeがデフォルトでサポートしていない新しいプログラミング言語の構文規則や検証ルールをプラグインに追加。
    • サブ・エージェントのメリット・デメリット
      • メリット: 処理をサブエージェントに委譲することで、メイン・エージェントのコンテキスト(記憶容量)を解放・節約できる点。
      • デメリット:コンテキストの分離特性に起因。詳細な使い分けや「エージェント・チーム」との違いは今週後半に解説。
    • 本日の主要テーマ:サンドボックス化(Sandboxing)
      セキュリティ面の強化だけでなく、開発の生産性を劇的に向上させるための非常に重要な概念として紹介
      • リソースの隔離(リングフェンス):ファイルの読み書きを特定のサブディレクトリ内に制限する、ネットワーク接続を特定のWebサイトのみに制限する、といった安全柵を設ける。
      • 「YOLO(一か八か)」な生産性の実現:安全な環境が担保されるため、リスクを恐れずにAIに大胆なコード変更や実行を任せることができ、結果として生産性が向上する。
      • 「承認疲れ(Approval Fatigue)」の解消:
        ・サンドボックス化されていない環境では、AIの行動に対して人間が毎回承認(ステップ実行の「1」や「2」を押すなど)を行う必要がある。
        ・しかし、人間は慣れてくると内容を確認せずにボタンを連打しがちになり、結果として安全性が形骸化する(偽りの安心感)。サンドボックス化は、この承認疲れの根本解決につながる。
  2. Claude Code on the Webでのリモート実行&クラウド・サンドボックス
    主流だったコンテナ環境構築から一歩進んだ「コーディング・エージェントのためのクラウドのサンドボックス環境」の最新トレンドを解説
    (開発のスタイルがコーディング・エージェントを「自分のPCで実行する」から「クラウドのサンドボックス内で実行する」へとシフトしている)
    • ローカル・ネイティブ・サンドボックス(Local Native Sandbox)
      • 特徴:自分のパソコン(ローカル)上で動かす軽量なサンドボックス環境。OSレベルで実装されているため、Dockerよりも非常に高速かつ効率的。
      • 使い方:/sandboxコマンドで起動。環境内でのAIの操作が自動承認(auto-approve)されるためスムーズに開発できる。
      • 注意点:MacやLinuxユーザーは簡単に使えるが、Windowsユーザーは現時点では「WSL」の構築が必要となるため、少しハードルが高め。
    • マネージド・クラウド・サンドボックス(Claude Code on the Web)
      • 特徴:Anthropic社側のクラウド上でClaude Codeを立ち上げて実行させる最も画期的な方法。スマホから指示を出して作業を進め、帰宅後にPCで引き継ぐといった使い方が可能。
      • 主な機能・使い方:
        ・手軽な呼び出し: 命令の先頭に &(アンパサンド)を付けるか、PowerShell?等のターミナルで claude remote [コマンド] と打つだけでクラウド上で実行。
        GitHub連携:GitHubの「Claude GitHub App」を導入すると、リポジトリのIssue(課題)で @claude とメンションするだけで、AIがクラウド上でタスクをこなす。
        ・テレポートとタスク管理:/tasks コマンドで実行中の複数タスクを一覧、Teleport機能でそれらのアクティブなセッションに自分が飛び込んで会話を引き継ぐ。
    • 3rd party による外部サンドボックス(3rd party Claude Sandbox)
      • 特徴:Anthropic社公式ではなく、別の企業が提供する「AIコーディングエージェントに最適化されたクラウド上のサンドボックス環境」
      • 具体例:Fly.ioのチームが手がける Sprites.dev というサービスが、高速・シンプル・柔軟で注目されている。
      • メリット:Claude Codeだけでなく、ユーザーが選んだあらゆるコーディングエージェント(他のAIツール)にも適用できる。
  3. Claude CodeサンドボックスとGitHub連携のセットアップ
    Claude Codeにおける2つの主要なサンドボックス設定手順(①ローカルのサンドボックスモードの有効化、②Web・GitHub連携機能のセットアップ)について解説
    • ローカルでのサンドボックスモードの設定
      • 概要:.claude 設定内の不要なファイルを整理した状態から、ローカル環境でサンドボックス(仮想実行環境)を有効化する手順。
      • 設定方法:Claude Code 内で /sandbox コマンドを実行し、提示される選択肢から選択。
        Sandbox: Mode Overrides Config
        
        (Mode)Configure Mode:
        > 1. Sandbox BashTool, with auto-allow
          2. Sandbox BashTool, with regular permissions
          3. No Sandbox (current)
        
        (Overrides)Configure Overrides:
        > 1. Allow unsandboxed fallback (current)
          2. Strict sandbox mode
        - Allow unsandboxed fallback: When a command fails due to sandbox restrictions, Claude can retry with dangerouslyDisableSandbox to run outside the sandbox (falling back to default permissions).
        - Strict sandbox mode: All bash commands invoked by the model must run in the sandbox unless they are explicitly listed in excludedCommands.
        Learn more: code.claude.com/docs/en/sandboxing#configure-sandboxing
        
        (Config)
        Excluded Commands:
        None
        Filesystem Write Restrictions:
        - Allowed: /dev/stdout, /dev/stderr, /dev/null, /dev/tty, /dev/dtracehelper, /dev/autofs_nowait, /tmp/claude, /private/tmp/claude, /Users/ed/.npm/_logs, /Users/ed/.claude/debug, /private/tmp/claude-501/
        - Denied within allowed: /Users/ed/.claude/settings.json, /Users/ed/projects/finally/.claude/settings.json,/Users/ed/projects/finally/.claude/settings.local.json, /Library/Application Support/ClaudeCode/managed-settings.json
      • メリット:Claude が承認なしで自由に Bash スクリプトの実行やファイルの読み書きを行えるようになり、プロンプトごとの権限承認の手間が大幅に減る。Web検索など一部のアクションのみ確認が求められる。
      • 実演:市場データAPIの調査やシミュレータのドキュメント作成など、複数のリサーチおよびファイル書き出しタスクを、ユーザーの承認を挟むことなく一括で自動実行できることを確認。
        > Please carry out comprehensive research and write 3 documents to the planning directory. Research the API from Massive (formerly Polygon.io) for retrieving realtime and end of day prices for multiple tickers;
        write documentation with code examples in MASSIVE_API.md. Use that to design the unified Python API that we should use in this project for retrieving stock prices that uses the Massive API if MASSIVE_API_KEY is set otherwise uses a simulator;
        document this in MARKET_INTERFACE.md. Finally, document the approach for the simulator in MARKET_SIMULATOR.md; this is the approach and code structure for simulating stock prices.
      • 注意点:詳細な設定やセキュリティに関する注意点は公式ドキュメントを参照。また、Windows(WSLを経由しないネイティブ対応)への対応も間もなく予定されている。
    • Web版 Claude(GitHub連携)のセットアップ
      • 概要:ブラウザ(claude.ai/code)および GitHub リポジトリとローカル環境を連携させ、クラウド上で複数のコーディングタスクをシームレスに実行可能にするための設定。
      • 手順:
        https://claude.ai/code (Web)にアクセスし、LLMにやりたいことを言う(「Give Claude cloud environments」or「Let users move sessions from cloud to CLI」)
        GitHub側の連携画面が表示されるので認可を行い、Claude側で「Connect repositories」ボタンを押下して、GitHub側の管理画面でリポジトリでClaude Code GitHubアプリのインストール・認可を行う。
        ・Claude CLIを起動し「/install-github-app」と入力して表示される「GitHub CLIのインストールと初期設定の説明」に従ってコレを行う(話の内容からしてOAuth2のDeviceフローっぽい)。
        ・Claude CLIを再起動し「/install-github-app」と入力してリポジトリを選択すると https://github.com/apps/claude にアクセス、必要に応じて「Configuration」(変更などあれば)を行う。
        ・問題なければ、CLI側をEnterで進め「インストールするGitHubワークフローを選択してください」の表示に「Claude Code」「Claude Code Review」両方を選択(Spaceで[✓]する)してのインストールを行う。
        ・「Create a long-lived token with your Claude subss@iption subsription」「Enter a new API key」が表示されるので前者を選択して続ける。
        ・「Claude Codeは、あなたのClaudeチャット・アカウントに接続」と画面に出るので、コレを認可すると処理が進んで、リポジトリにインストールのPRが飛ぶ。
        ・PRをマージしてpullすると、.github/workflowsフォルダに「claude.yml」「claude-code-review.yml」ファイルが追加されていることが解る(コレが ≒ インストール)。
        ・Claude CLIを再起動し「/install-github-app」と入力すると、「GitHub Actions workflow created!」「API key saved as CLAUDE CODE_OAUTH_TOKEN secret」(オールグリーン)になっているので続ける。
        ・「> hey what's 2 + 2」を「& hey what's 2 + 2」や「claude -remote "what is 2+2"」の様に使うとタスクがリモートで実行され、「> /tasks」でタスク一覧が確認できるようになる。
        ・また、https://claude.ai/code (Web)のChatウィンドウから直接以下のような指示を出すと、タスクがリモートで実行され、実行結果はPRで反映されることが確認できる。
        Please read all the documents in the planning directory. Then design the market data backend in detail. Write a new document called MARKET_DATA_DESIGN.md that has code snippets and examples to implement all the market data functionality (unified API, simulator, Massive API).
      • 結果:リポジトリ内に .github/workflows フォルダと設定ファイルが追加され、GitHub の Issue やタグを介して Claude にタスクを処理させるための連携準備が完了する。
  4. Claude Codeをリモートで実行する5つの方法:「&」「--remote」、Web、Mobile、GitHub Issue
    • ① ローカルセッション内でのコマンド実行
      • 方法:ローカルで起動しているClaude Codeのセッション内で、コマンドの先頭にアンパサンド(&)を付けて実行する。
        >& hey what's 2 + 2
      • 特徴:
        ・コマンドはローカルではなくクラウド上のサンドボックス環境で実行される。
        ・これまでの会話の文脈(フルコンテキスト)がすべてクラウドに引き継がれ、/tasks コマンドで並行して走っているタスクの一覧を確認できる。
    • ② ターミナルからの直接実行
      • 方法:ターミナル(コマンドライン)で claude --remote [コマンド] と入力する。
        > claude -remote "what is 2+2"
      • 特徴:1と同様にクラウド側で処理が実行される。
    • ③ Webブラウザ(https://claude.ai/code)の利用
      • 方法:ブラウザで専用UIを開き、クラウド環境をセットアップした上で、リポジトリと実行したい指示を指定。
        Please read all the documents in the planning directory. Then design the market data backend in detail. Write a new document called MARKET_DATA_DESIGN.md that has code snippets and examples to implement all the market data functionality (unified API, simulator, Massive API).
      • 特徴:ローカルマシンのリソースを一切消費しない。
        ・「設計ドキュメントの作成」を指示し、10分ほどで1490行のドキュメントが自動生成。
        GitHubへpushされるのでPRしてmergeする。※プレビュー版のため、動作が少し遅く不安定な場合がある。
    • ④ モバイルアプリの利用
      • 方法:スマホのClaude公式アプリから「Code」ナビゲーションを開き、新しいセッションを作成して指示を出す。
      • 特徴:Webブラウザ版と全く同じI/F。出先などPCがない環境からでもスマホひとつで複数のタスクを並行して回し、GitHubへコードをプッシュできる。
    • GitHub Issueとの連携(Claude Bot)
      • 方法:自身のGitHubリポジトリで新しいIssue(課題)を作成し、本文に具体的な指示を書き込んだ上で @claude とタグ付けして投稿。
        Title:Build complete Market Data backend #3
        Content:@claude
        Read all the documents in the planning directory, then build the complete Market Data backend in the backend/ directory. This should include:
        1. The Massive API interface
        2. The unified market data interface
        3. The market data simulator
        Include full unit tests
      • 特徴:
        ・投稿すると自動的にバックエンドでClaude Codeのインスタンスが立ち上がり、UI上にタスクの進捗状況がリアルタイムで表示。
        ・Jiraのチケットを割り振るように、複数のIssueを作ってClaudeに並行して開発タスクを処理させることが可能。
    • 全体のまとめ
      • Claude Codeをクラウドで実行することにより、ローカルマシンの負荷をゼロにしながら、重い開発タスクやドキュメント生成を非同期かつ並行して処理できる。
      • 特にGitHub Issueとの連携(5つ目の方法)は、タスク管理とAIへの自動割り振りがシームレスに融合した強力な開発スタイルとして紹介されている。
  5. 3rd party クラウド・サンドボックス:Sprites.devでのClaude Code実行
    • GitHub連携による自動プルリクエスト
      • AIエージェントにタスクを指示したところ、わずか数分で90以上の包括的なテストを含む21ファイル(約1,600行)のコードを自動生成。
      • AIが作成したブランチからGitHub上でプルリクエスト(PR)を作成し、中身をマージ(反映)する一連の流れを実演。
      • この手法を使えば、開発者はGitHubのIssue(課題)を次々と投入するだけで、クラウド上でプロジェクトを自動進行させることができる。
    • リモート実行における3つのアプローチ 講義の中でカバーしている「AIコードの実行環境」に関する3つのアプローチ(色別)をおさらいしている。
      • ネイティブのサンドボックス環境(/sandbox)を使用し、承認を自動化して制御する手法。
      • Web上のサンドボックスでClaudeを実行する5つの手法(モバイル環境や、非常に強力なGitHub連携など)。
      • 3rd partyのクラウド・サンドボックスを利用する手法(オプション扱いだがClaude以外のAIを使う際などに有用)(今回のメイン)
    • Sprites.devの導入と実践(≒ この辺 https://docs.sprites.dev/quickstart/ の言ってる事)
      • 概要:fly.ioが開発して話題の「Sprites.dev」を紹介。これは、チェックポイントや復元機能を備えた、ハードウェア的に隔離された永続的なLinuxサンドボックス
      • 登録:https://sprites.dev/ からクレカ登録(無料枠あり)を経て、VS Codeのターミナルから専用のCLIをインストールし、ログイン。
      • 起動:sprite create <名前> コマンドを叩くと、わずか0.6秒でクラウド上に独自の実行環境が立ち上がる。
        > sprite create finally-worker
      • 実演: ・立ち上がった環境でGitHubリポジトリをクローン
        > sprite@sprite:~# git clone https/github.com/ed-donner/finally.git
        > sprite@sprite:~# cd finally
        > sprite@sprite:~/finally# ls
        backend CLAUDE.md LICENSE planning README.md
        ・プリインストールされている「Claude Code」を起動。
        > sprite@sprite:~/finally# claude
        ・認証して、立ち上がった環境で「Claude Code」を実行。
        Claude Code can be used with your Claude subscription or billed based on API usage through your Console account.
        Select login method:
        > 1. Claude account with subscription Pro, Max, Team, or Enterprise
          2. Anthropic Console account API usa af billing
          3. 3rd-party platform Amazon Bedrock, Microsoft Foundry, or Vertex AI
      • 利点:ローカルPCを一切汚さず、YOLOの重いタスクをサンドボックスで、完全に委任できる。
        > Please read all the documentation in the planning folder. The Market Data backend has been implemented with tests. Please carry out a comprehensive code review, run all tests, and write your conclusions to a file MARKET DATA REVIEW.md in the planning folder.
  6. クラウド・サンドボックス総まとめ:Sprites.devとGitHub PRを使ったYOLOモード
    • Claude Codeを用いたGitHub連携のワークフロー
      • トラブルと解決:Claude CodeにGitHubへの変更プッシュを指示した際、未ログインのため失敗。ctrl+cで一時停止し、gh auth loginで認証後、/resumeコマンドで会話をシームレスに再開。
        ARGUMENTS: I need to push a git branch to GitHub but gh auth is not configured. Can you help set up GitHub authentication so I can push?
        ...
        Once you provide a GitHub token or authenticate via gh auth login, the push will work immediately.
        > OK. I've logged you in to github please try now
      • 成果:Claudeは自動的にbranchを作成してGitHubへpush、PRを作成し、mergeを完了させた。
        > OK I've merged please switch to main and do a pull. Then please carry out all the fixes and improvements that you've documented in the review file. Keep working until all tests pass and the market data backend is ready. Then push your new branch to github.
    • リモート・サンドボックス(sprites.dev)での自律的な開発
      • 効率的なデバッグ:開発環境を sprites.dev(Fly.io提供の3rd party製クラウド・サンドボックス)へ移行。mainブランチのpull、ドキュメントに基づいた修正、テストがすべて合格するまでのバグ修正をClaudeに一任。
      • 安全性と生産性の両立:完全なサンドボックス化でローカル環境(自身のPC)への被害を心配せず、権限承認の手間を省いた「YOLOモード」の利点を確認。追加のフィードバック修正を含んだPRをマージ。
    • 本日紹介された3つのサンドボックス手法のまとめ
      • 内蔵サンドボックス:ローカルPC上で動作する、Dockerコンテナのような軽量なOSレベルの簡易的な環境。
      • Anthropicの遠隔実行環境:Anthropicが提供するリモート環境。Web I/Fやモバイル・アプリのほか、GitHubのIssueにClaudeをタグ付けして自動でbranch作成、pushまで行う強力な連携を実演。
      • 3rd partyのクラウド・サンドボックス(sprites.dev):VS Code内からシームレスにリモート接続でき、ローカル環境のような感覚でセキュアかつ高速に自律運用が可能(Claude以外のLLMも利用可)。
    • 次回(明日以降)の予告
      • コースの80%が終了。
      • 次回(明日):多くの開発者が懸念する「大規模なコードベース」にコーディング・エージェントがどう対応するかを解説(スパイス要素もあり)。
      • 次々回(明後日):現在トレンドとなっている「スウォーム(Swarms)」や「オーケストレーター(Orchestrators)」について扱い、最終プロジェクトへと向かう。

Day 3

78-82

  1. 大規模コードベースでのClaude Code、Codex、Sprites.dev活用
    大規模なコードベース、大開発チーム、そして「Claude Code」や「Codex」といったプロフェッショナルなコーディングエージェントを活用した協調ワークフローについてのまとめ
    • これまでの機能の振り返り(Pro機能・サンドボックス)
      • SlashコマンドとSkills:Claude Codeでのコマンド実行や機能拡張。現在はMCPよりも「Skills」が主流になりつつある。
      • マルチ/サブ・エージェント:
        ・マルチ・エージェント:複数のClaudeを同時に走らせたり、GitHub IssueにClaudeをタグ付けして自動でタスクを処理させる手法。
        ・サブ・エージェント:特定のタスク(大量のファイルを探索して要約を返す「explorationサブエージェント」など)を委託する機能。
      • プラグイン:Skillsやサブエージェントなどをパッケージ化し、マーケットプレイスで公開・共有できる。
      • サンドボックス(セキュリティ対策):安全にコードやシェルスクリプトを実行するために、ローカルのネイティブ・サンドボックスや、Web/Mobile、GitHubと連携したリモート環境を活用。
        ・コマンドの前に「&」を付けることで、会話コンテキストをリモートのClaudeに投げてバックグラウンド実行(slash tasksで確認可能)ができる。
        ・Sprites.dev:状態が保存され、起動が非常に速いサードパーティ製のリモート・サンドボックス。ターミナルから手軽にアクセスでき、開発に非常に便利であると絶賛。
    • リモート環境を用いたゼロショット開発の実証デモ
      • 前日の講義後、リモートのSprite環境(サンドボックス)でClaudeに対し、ドキュメントの要約と、市場データシミュレーターが動作することを示すためのターミナル用デモの作成を依頼した。
      • ローカル環境にその成果物を git pull して実行したところ、「ゼロショット(修正指示なしの一発)」で完璧に動作するデモが完成。
        >git pull
         Already up to date.
      • 株価ティッカー、価格変更(赤と緑の色分け表示)、テキストベースの株価グラフ(スパークライン)が動く、エージェントの強力な実用性を示す好例。
        >cd backend
        >uv run market_data_demo.py
        |FinAlly Market Data Simulator | 17.7s elapsed | 42.3s remaining | 10 tickers | Ctrl+C to exit |
        |---------------------------------------- Live Prices ----------------------------------------
        |Ticker | Price   | Change | Chg %  | | Sparkline|
        | AAPL  | $189.97 | +0.01  | +0.01% | |          |
        | GOOGL | $174.93 | -0.01  | -0.01% |
        | MSFT  | $420.17 | -0.02  | -0.00% |
        | AMZN  | $184.99 | -0.01  | -0.01% |
        | TSLA  | $249.85 | -0.05  | -0.02% |
        | NVDA  | $799.76 | -0.06  | -0.01% |
        | META  | 5500.03 | +0.01  | +0.00% |...
  2. 大規模チームのコードベースでClaude Codeを使うためのベストプラクティス
    大規模なチームや大規模なコードベースにおいて、高度なコーディングAIエージェント(Claude Codeなど)を最大限に活用するための実践的なアプローチと注意点について解説
    • 適切なドキュメント管理(agents.md の活用)
      • 階層的な記述:各サブディレクトリに agents.md や cloud.md を配置し、エージェントがファイル群をすべて読み込まなくても、そのパッケージのインターフェースや役割を即座に理解できる情報量に調整。
      • 適切なコンテキスト制御:大きな文書を直接 @ タグで読み込ませるとコンテキストを消費しすぎるため、概要とリンク(参照)を記載し、必要に応じてエージェント自らに読み込ませる構造にする。
    • チーム内での一貫したワークフローとプラグインの導入
      • プロセスの統一:GitHubでのClaudeのタグ付けや、JIRAによるチケット管理など、チーム全体で統一されたプロセス・ルールに沿ってエージェントを使用する。
      • プラグインとスキルの活用:FeatureDev? などの「プラグイン」を導入し、プロジェクト独自の開発「スキル」をエージェントに使用させる事で、コードの品質と実装アプローチを標準化する。
    • テスト駆動開発(TDD)の戦略
      • 網羅率(カバレッジ)に固執しない:AIは網羅率を上げるために、過度なモックを用いた脆いテストを書きがち。
      • 意味のあるテストの要求:リファクタリングで壊れず、ロジックのバグを正確に検知できる本質的なテストを書かせるよう、プロンプトやルールで制御。
    • 人間の責任(レビュー文化)と「小分け」にした開発
      • 人間が最終責任を持つ:AIが生成する冗長で防衛的なコード(スロップ/Slop)を拒否できる、強い人間レビューの文化を維持。
      • タスクの細分化:大規模プロジェクトにおいて「コードベース全体のリファクタリング」といった大雑把な指示は避け、人間やAIを使ってタスクを独立してテスト・レビュー可能な「小さなステップ」に分割してエージェントに割り当てる。
    • 推奨される練習(課題)
      大規模なOSSプロジェクトをクローンし、何が有効で何が機能しないかを体感することを推奨
      • ディレクトリ全体に agents.md を整備し、AIに「TODO」を探させて解決させてみる。
      • アンチパターン:全体の一括リファクタリングをラルフループに入れて10回繰り返してみる。
  3. Claude Agent SDKによるClaude Codeのプログラム的制御
    「Claude Agent SDK」を用いて、コード(Python)経由で「Claude Code」の機能を動かし、ブラウザゲームを作成するデモ動画
    • Claude Agent SDKの概要
      • 誤解の解消:名前は「Claude Agent SDK」だが、所謂、一般的な「エージェントフレームワーク(LangChainやCrewAIなど)」ではない。
      • 本質:ターミナルから対話的に使う「Claude Code」の強力な自律型エージェント機能を、独自のPythonコードなどからプログラムによって直接操作するツール。
      • 旧称:以前は Claude Code SDK と呼ばれており、現在は「Agent」が単数形の Claude Agent SDK に名称変更されている。
      • ユースケース:日常的ではないが、Claudeのプラグインやエコシステムを活用した独自アプリや自動化ツールを開発したい場合に有効。
    • デモの準備と環境構築
      • VS Code上の完全に空のディレクトリから開発をスタート
      • プロジェクト管理:
        ・高速なPythonパッケージ管理ツール uv を使用。
        ・uv init --bare で空のプロジェクトを作成。
        > uv init -bare
        Initialized project 'space
        ・使用Pythonバージョン:3.13
        > uv python pin 3.13
        Pinned python-version to 3.13
      • インストールした主要ライブラリ:
        ・python-dotenv:APIキーなどの環境変数管理用。
        ・requests:HTTPリクエスト用。
        ・claude-agent-sdk:本デモの核となるSDK。
        > uv add python-dotenv requests claude-agent-sdk
    • 実装コードのポイント (main.py)
      プログラムからClaude Codeを動かすための主要な処理は以下の通り
      • ファイルの作成:main.py、.env、.gitignore
      • main.pyに以下を実装
        import asyncio
        from dotenv import load_dotenv
        from claude_agent_sdk import query, ClaudeAgentOptions
        load_dotenv(override=True)
        PROMPT = ""
        TOOLS = []
        async def main():
      • プロンプトの設定:
        PROMPT = """
        Make a vanilla HTML+JS+CSS website for a game of Space Invaders. Write the code to files in the current directory, including index.html.
        """
        (現在のディレクトリに index.html を含む、素HTML/JS/CSS で "Space Invaders"を作成せよ)
      • ツールの付与:Claudeに対し、read、write、editファイル操作を可能にするツール群(allowed_tools)を権限として渡す。
        TOOLS = ["Read", "Write", "Edit", "Bash", "Glob", "Grep", "AskUserQuestion"]
      • モデルの指定:デモ用に贅沢に Claude Opus 4.6 を指定(※ 高コストなため、普段の検証では安価なモデルを推奨)。
      • 実行ルーチン:async for message in query(...) を使い、Claudeが思考しファイルを生成していくプロセス(非同期ストリーム)をループで回して進捗を表示。
        async def main():
          options = ClaudeAgentOptions(allowed_tools TOOLS, model="claude-opus-4-6")
          async for message in query(prompt=PROMPT, options=options):
            print(message)
        
          asyncio.run(main())
    • 実行結果と成果物
      コードを実行すると、プログラムから呼び出されたClaudeが自律的にファイルの書き込みを始め数分で処理が完了し、以下の成果物が生成された。
      > uv run main.py
      • 成果物:完全に動作する index.html。
      • ゲームのクオリティ:
        ・効果音(サウンド)が実装されている。
        ・キーボードの矢印キーで自機を操作できる。
        ・スコア機能や、最上部を移動するUFO(インベーダー)も再現されている。 ・チープなものではなく、カラーや挙動も含めて非常に完成度が高い。
      • 考察:
        ・トレーニングデータ(学習データ)に類似のコードが含まれていた可能性は高いものの、
        ・Pythonスクリプトを1度実行しただけでここまでのゲームが自動生成される点は非常に強力。
  4. Claude Cowork:日常業務向けエージェントAIデモ
    Anthropic社の強力なエージェント機能を、日常的な事務・ビジネス業務向けに提供する新しいプロダクト「Claude CoWork?(リサーチプレビュー版)」の紹介と、実際のデモ。
    • 主な特徴と機能
      • 対象ユーザー:エンジニアだけでなく、一般のビジネスパーソンや日常のタスクを効率化したいすべての人。
      • 利用方法:https://claude.com/product/cowork から「Claudeデスクトップアプリ」をダウンロードしてインストール、Googleアカウントで認証してCoworkタブを選択し、ワークスペースをセットアップ。
      • 出来ること:画面のスクリーンショットの整理、週のスケジュールの最適化、ファイルの並べ替え、データの深掘り、財務管理、契約書のレビュー(NDAの仕分け)など。プラグインやによる機能追加も可能。
    • デモの内容(経費精算書の自動作成)
      • 共有:「Work in folder」から「receipts(領収書)」フォルダをClaude CoWork?に共有(アクセスを許可)。
      • 指示:「これらの領収書をレビューして、Excelファイル(expenses.xlsx)で経費精算書を作って」と指示。
        In the folder that I've shared with you, there are a bunch of receipts. Please review these and make me an Expenses report as an excel file expenses.xlsx
      • 処理:Claude CoWork?が自動で処理を開始。PDFを画像として読み込むなどの調整を自律的に行いながら、5-10分ほどかけてファイルを解析。
      • 結果:指定したフォルダ内に、綺麗にフォーマットされたExcelの経費精算書(購入した機材やサブスクリプションの項目、合計金額などがすべて網羅されたもの)が自動生成される。
    • 結論:エンジニアにとって非常に役立つ「Claude Code」の魔法のような自動化体験を、Excelの経費精算書作成といった「面倒な日常業務」に落とし込み、誰でも簡単に恩恵を受けられる。
  5. OpenClaw?:Telegram&WhatsApp?で使えるパーソナルAIサイドキック
    • OpenClaw?(オープンクロー)の概要
      • 位置付け:現在非常に注目(ハイプ)されている個人向けのAIアシスタント。
      • 名称の変遷:ClaudeBot?(Anthropicから手紙を受け取った) ➔ Maltbot(聞こえなかったし、言いにくかった) ➔ OpenClaw? と改名された。
      • 特徴:
        ・コーディング・エージェント(Claude Codeなど)の思想を、開発以外の日常生活全般に応用したもの。
        ・PCに直接インストールし、ローカル環境のファイル、ブラウザ、各種アプリ、プラグインへのフルアクセス権限を与えて動作させる。
        ・ユーザーは主に TelegramやWhatsApp?などのチャットアプリ を通じて「外出先」(やスマホ)からでも「自宅PC」に指示を出せる。
    • セキュリティとリスク
      • 高いリスク:PCの全権限を握るため、悪意あるプロンプト(プロンプトインジェクションなど)によって予期せぬ危険な操作を行うリスクがある。
      • 利用の前提:セキュリティ専門家からも懸念されており、導入にはターミナルの操作知識やリスクへの理解が必要(サンドボックス環境での実行も推奨される)。
    • インストールとセットアップ手順(デモ内容)
      • 手順:
        ・ターミナルからワンライナー(1行のコマンド)でインストール。セキュリティ警告に同意。
        ・モデル認証プロバイダーの選択:デモでは OpenAI の ChatGPT OAuth を使用。
        ・デフォルト・モデル:Keep current (openai-codex/gpt-5.3-codex)
        ・チャネル:連携チャットツール(Telegram)の設定(BotFather?を使用してTelegramのAPIトークンを取得)。
        ・スキル(プラグイン)の導入(デモではnpmを選択し、音声認識の「OpenAI Whisper」を導入)。
        ・AIの名前やキャラクター(バイブス、絵文字)を設定。
    • 実際の動作デモ
      • 指示内容:
        ・Telegramを使用して指示
        ・「テスラの株価を調べて、今日上がっていれば陽気な曲を、下がっていれば暗い曲を再生して」
      • AIの自律的な挙動:
        ・ウェブ検索でテスラの株価が上昇したことを確認。
        ・「陽気な曲」という条件から、ダイアナ・ロスの「Upside Down」をAIが自律的に選曲。
        ・PC上の Spotifyアプリを勝手に起動・操作 して音楽を再生した。
    • 本セッションのまとめと次回予告
      • 本日のまとめ:大規模リポジトリへのアプローチ方法を学んだ後、Claude Agent SDK、Cowork(ビジネス向け)、OpenClaw?(個人向け)など可能性を広げる最新トレンドを紹介。
      • 次回予告: 明日は「スワーム(Swarms)」やチーム開発、複数のAIエージェントを連携・調和させて大規模なタスクを達成するオーケストレーション手法について解説。

Day 4

83-88

  1. Claude Codeエージェントチーム:スウォームとオーケストレーション
    AIエージェントの大量運用における「スウォーム(群れ・混沌)」と「オーケストレーション(構造化・管理)」の概念を学び、実験的機能である「Claude Agent Teams(エージェントチーム)」の実践方法
    • スウォーム(Swarms)とオーケストレーション(Orchestration)
      • 段階的進化:Steve Yegge氏のチャートにおけるステージ7(多数のエージェントが混沌と動くスウォーム)~8(LLMが全体を統制・構造化するオーケストレーション)への移行。
      • 連続性:これらは二者択一ではなく、自由な混沌から厳密な組織化までのグラデーション(連続体)であり、設定次第で調整可能。
    • 「Claude Agent Teams」とは
      複数のClaude Codeインスタンスを連携させて1つの目標を達成する機能
      • 役割分担:「チームリード(全体管理・タスク割り当て)」と、独立して動く「チームメイト(相互にメッセージ交換が可能)」で構成
      • サブエージェント(Sub-agents)との違い: ・サブエージェント: インのClaudeの補助として一時的に存在し、人間が直接指示を出すことはできません(トークン効率が良い)。 ・エージェントチーム:各自が独立したフル文脈(Context Window)を持ち、人間も各チームメイトに直接メッセージを送る(複雑な共同作業向けだが高コスト)。
      • 主なユースケース: ・複数ソース(WikipediaやStack Overflowなど)の並行リサーチ。 ・システムの独立したモジュールごとの並行開発。 ・開発レイヤー(フロントエンド、バックエンドなど)に応じた垂直・水平的な役割分担。
    • 実装の5ステップと操作方法
      • 設定の変更:settings.json で experimental agent teams を有効化する。
      • モード選択:全プラットフォーム対応の画面切り替えモード(in process)か、Mac/Linux向けの画面分割モード(tmux)を選択。
      • チームの起動:Claudeに対して「〇〇のためのエージェントチームを作って」とプロンプトを出す。
      • 操作と制御:Shift + Tab で委譲モードにし、リードが勝手に作業しないよう制御。Shift + ↑ / ↓ で表示するエージェントを切り替え。
      • 終了処理:個別にシャットダウンを命じるか、全体をクリーンアップするコマンドを送る。
    • 実践における3つの留意点
      • CLAUD.md の活用:全エージェントの文脈に読み込まれるため、共通前提の指示をここに集約。
      • 高コストへの覚悟:トークン消費が激しいため、無料モデルでの運用は非推奨。コスト監視を徹底。
      • 試行錯誤の前提:非常に実験的で予測不能な動きをすることもあるため、Gitで巻き戻して指示を微調整しながら、何度もやり直す前提で挑む。
  2. フルスタック開発のためのClaude Codeエージェントチームのセットアップ
  3. マルチ・エージェント・チーム構築:Claude Opusによるライブ取引ダッシュボード
  4. GSD:仕様駆動設計とマルチ・エージェント・オーケストレーションの融合
  5. Claude GSDによる取引プラットフォーム構築:5時間徹底解説
  6. GSD vs Claude Agent Teams:UI比較と総括

Day 5

89-95

  1. Gastown:Claude Codeエージェントのスウォームをオーケストレーション
  2. GastownのParallel Polecats:Claude Codeエージェントがカオスの中で構築
  3. Gastown vs Claude Agent Teams vs GSD:マルチ・エージェント・オーケストレーター比較
  4. Codexの勝利:ライブ市場データ付き最終トレーダー用ワークステーション
  5. 最終デプロイ、コース総括&コーディング・エージェントのベストプラクティス
  6. コース総復習:Vibe Codingからエージェントエンジニアへ
  7. ボーナス講義 - あなた専用の限定リンク集

詳細

手順をメモ

様々なツールのYOLOを試す

VS Code(GitHub Copilot、OpenAI Codex)、Cursor、Antigravity IDE、Claude Code

Cursor

1

※ ブラウザ翻訳で日本語になっているが、元々は英語表記。

VS Code + GitHub Copilot

2

VS Code + OpenAI Codex

3

Antigravity IDE

4

Claude Code

10段階計画

VS Code + GitHub Copilot

1週、5日目の内容

...

...

参考

コード

github.com/ed-donner

スライド

https://drive.google.com/drive/folders/1vvp15mK3ZXDfY8HE4g-tlF2CTfBfSDQ8

その他

プロダクト関連

論文関係


トップ   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS