「.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：IDEのサイドバーにコーディング・エージェントを配置し、承認を得ながらコードを修正。
      • ステージ3（YOLOモード）：エージェントを全面的に信頼し、すべての変更を未確認で即座に承認（一括受け入れ）。
      • ステージ4：意識の対象がコードからエージェントへと移る。エージェントに集中し、コードの変更履歴はたまに眺める程度。
      • ステージ5：IDEからCLIに移行。Claude Codeなどを使用し、人間は画面のスクロールをただ眺めるか、席を外して完了を待つ。
      • ステージ6：CLI上で複数のエージェント（3〜5体）を同時に起動し、チームとして並行してプロジェクトを進めさせる。
      • ステージ7：10体以上のエージェントをCLI上で稼働させ、人間がそれらの進捗や連携を自ら管理・調整。
      • ステージ8：役割を持ったマルチエージェントネットワークが自動で機能する最上級ステージ。
    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：
    • コンテキストエンジニアリングとは以前は「プロンプトエンジニアリング」と呼ばれていたが、最適な出力を得るための全技術を指す「コンテキストエンジニアリング」へと概念が拡張された。
    • 入力コンテキストを構成する主要要素：システム・プロンプト、ツールの説明、メモリ、会話履歴、など
    • コンテキストウィンドウには最大サイズがあるのでコンパクション（圧縮、要約）技術もあるが信頼性に課題もある。
  4. AGENTS.mdを極める：コーディング・エージェントのためのContext Window戦略
    • 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、Copilot、Codex、そしてAgentic Vibe Codingの実践：
    • 講義の目的と心構え（バイブ・コーディングの原則）
      • ツールの選択は自由： 紹介するツールをすべて使う必要はありません。見るだけでも1つ選んで使い続けるでも。
      • 結果は人それぞれ： 使用するモデル（無料版や安価な版など）によって講師と異なる結果が出ることがある。
      • イライラしない（最も重要）： 的外れな出力には「焦らず、フィードバックを与え、問題を極限までシンプルにする」
    • ハンズオン：環境構築とプロジェクトの準備
      • Cursorの起動とNode.jsのインストール
      • GitHubからのプロジェクト複製（クローン）と切り替え
  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 の導入：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 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、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出力の直接使用は禁止、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 を使用して適切なコミットを行うべきであり、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/tree/main/frontend）をコピー、
      • VS Codeのターミナルで git clone を実行。クローンした「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. AI Copilotでステップバイステップ構築：計画と足場作り：
    • 全体方針と開発哲学
      • 計画と制約（ガードレール）の重要性：ハイレベルな計画をAIにすべて丸投げすることも可能だが、自分の意見や意図を反映させるために、あらかじめ人間が10個のプロセス（骨子）を用意し、AIの行動に「ガードレール」を設けることを推奨。
      • 段階的なコミットと検証：一気に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による進捗の保存と次への準備
      • ローカルコミット：今後データベースを扱うパート5という「リスクの高いフェーズ」に入る前に、これまでの成果（パート1〜4）をGitでローカルリポジトリにコミットし、いつでも復元できる状態にした。
      • 開発者が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）。
    • コンテキスト・ウィンドウ対策と次への準備（Part 8へ）
      • コンテキストの肥大化問題：開発がPart 7まで進んだことで、AIのコンテキストウィンドウ（記憶容量）が一杯になりつつある。
      • チャットのリセット：効率的な開発を維持するため、現在のチャットを一度終了して新しいチャットで再開する手法をとる。
      • 事前にこれまでの設計方針や進捗を 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に最終コミットを終えた後、新規チャット（New Chat）を開き、AI連携機能を実装する「Part 8」へと移行した。
  7. AIアシスタントKanbanアプリ完成：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で未コミットの変更をステージング・コミットして最新状態にした。
      • 新しいターミナルを開き、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万トークンという限られたコンテキスト・ウィンドウの使用状況を視覚的なメーターで確認できる。
      • メーターには「メモリ（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 のコマンド、ショートカット、設定の徹底解説
    • 主要なスラッシュコマンド
      ツール内のみで実行され、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サーバーを多く接続し過ぎると、コンテキストウィンドウを圧迫しやすく、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など）にはコンテキストウィンドウ消費問題があった。
      • 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 commit して push するだけで、チームメンバーに同じスキルを簡単に共有・装備させることができる。
  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、スキル、プラグインなどの知識を実際の行動にし、Cloud 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などのテキストを自動整形するアプリには貼り付けないこと）。
    • ローカル環境へのリポジトリのクローン
      • ポジトリのHTTPS URLをコピーし、VS Codeでターミナルを開き、ローカルのプロジェクト用ディレクトリへ移動後、git clone を実行。
      • クローンした「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.github.copilot.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.
      • プルリクエストの作成とマージ：READMEにプロジェクトのステータスを追記し、ローカルでのコミット・プッシュを経て、GitHub上でPRを自動作成。ブラウザ側でこのPRをマージし、変更が反映されたことを確認。 
        > 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（コード・PR管理）の連携に加え、FeatureDev?（規律ある開発プロセス）が導入されたことで、Claude Codeを用いた本格的なチーム開発の準備が整った。
  4. Claude Code の自律性：Jira Issue から MCP Server 経由で PR 作成まで
    • Jiraでのタスク作成 (PL-2)
      • タスク内容：「Common Paper」が公開しているCreative Commonsライセンスのリーガル文書（Markdown形式）を取得し、データセットを作成。
      • 要件：templatesディレクトリへのMarkdownファイルの格納、各テンプレートを説明するcatalog.jsonの作成、ライセンスファイルの格納。
    • Cloud Codeの準備とMCP連携
      • Atlassian（Jira）用のMCP（Model Context Protocol）サーバーをインストールし、認証を実行。
      • Cloud Codeに対し、「Jiraの課題PL-2を実行し、PRを上げて」と高レベルな指示（プロンプト）を出す。
    • Cloud Codeによる自律的な問題解決（自律性の発揮）
      • アプローチの最適化： ・当初、Cloud CodeはGitHubツールでファイルを1つずつ読み込もうとしたが、「コンテキストが肥大化し効率が悪い（遅い）」と判断。 ・途中で方針を切り替え、コマンドを実行してファイルを直接一括ダウンロードする効率的な方法を提案・実行した。
      • 成果物の生成：指示通りMarkdownファイル群、license.txt、catalog.jsonをローカルに自動生成。
    • PR作成とJiraのステータス更新
      • PRの作成：ローカルのGitHub CLIツールが未インストールだったため、MCPサーバー経由のツールに切り替えてGitHub上にPR（add legal document templates data set）を自動作成した。
      • トラブルシューティング（Jiraの認証切れ）：Jiraのステータスを「完了」にする際、Atlassianの認証切れが原因で処理が一時停止。手動で再認証を行うことで、Cloud Codeは処理を再開し、ステータスを無事「Done」に更新。
    • ローカルでのマージと完了
      PRの直接マージ権限がないと判明すると、Cloud Codeは「ローカルでマージしてからmainブランチにプッシュする」という代替案を自ら導き出し、タスクを完遂した。
    • 結論 / スピーカーの考察
      • AIのブレイクスルー：障害に直面した際、AIが自ら原因を理解し、合理的な回避策を見つけて自律的に解決していく知性に非常に驚かされた。
      • MCPの現状：認証が切れやすいなどの「わずかな不安定さ（flakiness）」はあるものの、総じてAIが効果的に問題を解決した素晴らしい例である。
  5. Claude Code が Jira チケットから Next.js アプリをフル構築
    • タスクの起票と初期設定
      • Jira上で「PL2」チケットの完了を確認後、新しいタスク「PL3: 相互秘密保持契約（Mutual NDA）作成ツールのプロトタイプ」を作成。
      • 要件は「ユーザーがフォームに情報を入力すると、その内容が反映されたNDA文書が表示され、ローカルにダウンロードできるWebアプリ」という、あえて曖昧さを持たせたビジネス寄りの内容に設定。
    • Claude Codeによる開発の実行
      • Claude Codeを起動し、Atlassianとの再認証を実施。
      • プラグイン（feature_dev）を使い、「JiraのPL3をNext.js（frontendディレクトリ）で実装し、完了したらPull Request（PR）を作成せよ」と指示。
      • Claudeは7段階のプロセスに沿って動作を開始し、途中で「DL形式」「Form形式」「プレビュー配置」「デザインの仕上げ」といった仕様の曖昧な点を人間に質問し、回答を反映。
    • アプリケーションの動作確認
      • わずか数分でNext.jsのフロントエンドファイル群とGitHubのPRが自動生成される。
      • スピーカーがローカル環境でアプリ（npm run dev）を起動したところ、以下の機能が最初から完璧（Zero-shot）に動作することを確認。
      • フォームに入力したデータ（会社名や準拠法など）が、右側のプレビューにリアルタイムに同期・反映される。
      • 「PDFダウンロード」ボタンを押すと、カバーシート付きの綺麗な構造のPDFが正しく生成される。
    • プロセスの検証とテストの追加要求
      • 非常に完成度が高い一方、プロセス中に自動テストが実行された形跡がない。
      • Claudeに「どのような品質レビューやテストを行ったか」を質問
      • Claudeは「ビルド確認は行ったが、自動テストやコードレビュー（フェーズ6）はスキップした」と自己分析（内省）して回答。
      • これを受け、「自動テスト・手動テストの追加、およびコードレビューエージェントによる検証」をClaudeに追加で指示。
  6. Claude Code のデバッグ戦略：体系的なアプローチ
    • 開発タスクの進捗と成果
      • 成果物の完成：Claude Code を用いて、NDA（秘密保持契約）作成アプリのプロトタイプと広範なテストスイート（5スイート、76テスト）をわずか数分で構築。
      • トラブルへの自動対応：サーバーの強制終了や、コンテキストウィンドウが満杯になったことによる「自動コンパクト化（Auto-compact）」が発生したものの、AIは自律的に問題を解決してタスクを完了。
      • 動作確認とデプロイ：localhost:3000 でアプリが正常に動作することを確認（PDFのダウンロードや、入力によるライブアップデート機能など）。
      • 最終処理：MCP（Model Context Protocol）サーバーを介してAtlassianと再認証を行い、ローカルでのPRマージ、mainブランチへのプッシュ、Jira課題（PL3）の完了ステータス更新までを「1つのコマンド」で自動実行。
    • 開発者が推奨するデバッグ戦略（5つのステップ）
      今回はバグが発生しなかったため、次回以降に向けた実践的なデバッグ手法が共有されました。
      • スナップショットの取得（Gitコミット）：AIが誤った方向に暴走した際、確実に元の状態に戻せるよう、必ず最初に git commit を行う。AIの「巻き戻し（Rewind）」機能だけでは、スクリプト実行による二次的な変更（サイドエフェクト）に対応できないため。
      • 手軽なアプローチ（コピー＆ペースト）：単純なエラーであれば、スタックトレースやエラーメッセージをそのままAIに貼り付けるだけで、文脈を理解して迅速に修正してくれる。
      • 規律あるアプローチとドキュメント化（規律モード）
        ・簡単な修正で解決しない場合は、Gitで元の状態に戻し、debug.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作成・マージまでの一連のワークフローが機能することを確認。
      • 現在の進捗: 全行程の 60% を消化。AIを使いこなす技術が身についたため、明日からはこれらを実際の大型プロジェクトに投入していく。
↑

Day 5 †

58-63

  1. SaaS プラットフォーム構築：Claude Code Skills & CLAUDE.md 設定
  2. CLAUDE.md の作成と Cerebras 用カスタム Skill の構築
  3. Claude Code で V1 製品を構築するための Jira チケット設定
  4. Claude Code、Jira、FastAPI を用いた機能開発
  5. Cerebras と Claude Code で AI Legal Doc Generator をテスト
  6. 最終 PR マージ、SaaS 完全デモ & Claude Code Week 2 勝利
↑

Week 3 †

Vibe Engineering as an expert（エキスパート向け）

↑

Day 1 †

↑

Day 2 †

↑

Day 3 †

↑

Day 4 †

↑

Day 5 †

↑

詳細 †

手順をメモ

↑

様々なツールの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
↑

10段階計画 †

↑

VS Code + GitHub Copilot †

1週、5日目の内容

↑

... †

↑

... †

↑

参考 †

↑

コード †

github.com/ed-donner

↑

スライド †

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

↑

その他 †

↑

プロダクト関連 †

↑

論文関係 †

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