「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
Week 1 †
Vibe Coding for fun and profit（バイブ・コーディング）
- Agentic Coding（エージェント型コーディング）
- Cursor、GitHub Copilotなどの主要ツールの紹介
- MVP（実用最小限の製品）開発などのプロジェクト
- Agentic Coding Landscape
全体像、基礎、コンテキストの理解。
- Foundations AGENTS.md Context
エージェント型コーディング向けの専用コンテキストファイルとして作られたオープン標準。
- プロダクト
- Cursor
- GitHub Copilot
- Codex
- Antigravity
- プロジェクト
- Project 1：YOLO
- Project 2：Commercial MVP
Day 1 †
1-7日
- コースへようこそ：Cursor AIを使った3Dゲーム制作：
- Cursorで「矢印キーで移動し、スペースキーで発砲して、1台のコンピュータ対戦相手とアリーナで戦う、3D一人称視点シューティングゲームのウェブサイトを構築してください。」と入力
- すると自動でコード（index.html）を生成（Cursorは以前サインアップしたアカウントで試したらモデル選択が「Auto」からできなかった）
- ポイントは単純なコード作成に留まらず、ファイル生成や、Node.jsのインストールから、起動（npx serve .）などの作業も行われる点。
- Cursor AI Agentで一人称視点シューティングゲームを構築する：
- 生成物を分析・動作確認し、プロンプトを修正し得て動作を改善することを行う。
- その中で「Zero-shot（ゼロ・ショット）」「Ralph Loop（ラルフ・ループ）」と呼ばれる手法（単語レベル）を紹介する。
- Agentic Coding（エージェント型コーディング）のための欠かせないマニュアル：
- コース誕生のきっかけ（カルパシー氏のポスト）、
- 対象となる受講者
- すべての人向け、意欲あるエンジニア・初心者～シニア・ベテランエンジニア
- コース修了後に得られる成果
- コースのスタンス（誇大広告（ハイプ）への警戒）について解説。
- 講師紹介＆3週間AI Coderコースのロードマップ：
- 講師（Ed Donner）の経歴と実績
- 本コースの位置づけ「AI（エージェント）を使ってコードを書く」「幅（Breadth）」「深さ（Depth）」の両立。
- 3週間のカリキュラム構造。
- Vibe Coding、Agentic Coder、そしてClaude Codeのようなコーディング・エージェント：
- 「バイブ・コーディング（Vibe Coding）」の誕生とこれまでの歩み。
- 曖昧な用語の整理（Vibe Coder、Vibe Engineer、Agentic Coder、Coding Agent。
- 3つの対話I/F（IDE型、エディタ拡張型、CLI型。
- 結論と心構え（この分野の進化スピードは凄まじく、毎日膨大な情報（津波）が押し寄せている）
- AIコーディングの8段階：ChatGPTからAgent Orchestrationまで：（Steve Yegge氏の説）
- AIをコーディングに活用するレベルは、初級から上級まで以下の8つのステージに分類される。
- ステージ1：インテリセンス的スニペット生成：ChatGPTとの対話や、AIによるコードの自動補完を参考程度に使う。
- ステージ2：ChatUIを用いたコード生成：IDEのサイドバーにコーディング・エージェントを配置し、承認を得ながらコードを修正。
- ステージ3：YOLOモード（エージェントの結果を一括受け入れ）：エージェントを全面的に信頼し、すべての変更を未確認で即座に承認。
- ステージ4：エージェントへの委託＆検収１：意識の対象がコードからエージェントへと移る。エージェントに集中し、コードの変更履歴はたまに眺める程度。
- ステージ5：エージェントへの委託＆検収２：IDEからCLIに移行。Claude Codeなどを使用し、人間は画面のスクロールをただ眺めるか、席を外して完了を待つ。
- ステージ6：マルチ・エージェント１：CLI上で複数のエージェント（3〜5体）を同時に起動し、チームとして並行してプロジェクトを進めさせる。
- ステージ7：マルチ・エージェント２：10体以上のエージェントをCLI上で稼働させ、人間がそれらの進捗や連携を自ら管理・調整する。
- ステージ8：マルチ・エージェント３：役割を持ったマルチ・エージェント・ネットワークが自動で機能する最上級ステージ
- ステージとアウトラインのマッピング
- 第1週：ステージ2〜4
- 第2週：ステージ5
- 第3週：ステージ6〜8
- 企業の開発における最適解はステージ5〜6
- 利用コスト
- コース自体は無料で完結可能
- 推奨されるプラン：初期はCursorの無料期間を利用し、第2週・第3週に向けてClaude Code（月額20ドルプラン）に加入。
- 自己責任の原則：費用の管理や解約の判断は必ず受講生自身が行う必要があります。
- まとめ：これから始まる、あなただけのAgentic Coding Journey
- 変化の激しい環境への心構え
- 本コースha、全員が同じコードを実行して同じ結果を得るわけではない。
- 講師によるサポートとコミュニティへの参加（Q&Aやメール、LinkedIn?）
Day 2 †
8-13
- LLMの仕組み：トークン、メモリ、推論を解説：
- 大規模言語モデル（LLM）の基本
- LLM単体 と LLMを組込んだAIアプリケーションの違い
- AIアプリケーションでインテリジェンスを疑似体験させるトリック
- トリック1：記憶の錯覚（Ilusi Memori）：チャット履歴
- トリック2：推論・思考（Penalaran / Pemikiran）：Few-shot
- ツール、ループ、そしてAI Agentの定義：
- AIアプリケーションでインテリジェンスを疑似体験させるトリック
- トリック3：ツール（Tools / Tool Calling）
- トリック4：ループ（Loop）
- AIエージェントの最新の定義
「目標を達成するために、ループ（繰り返し）の中でツールを実行するLLMシステム」
- Context Engineering：System Prompt、Context Window、AGENTS.md：
- コンテキストエンジニアリングとは以前は「プロンプトエンジニアリング」と呼ばれていたが、最適な出力を得るための全技術を指す「コンテキストエンジニアリング」へと概念が拡張された。
- 入力コンテキストを構成する主要要素：システム・プロンプト、ツールの説明、メモリ、会話履歴、など
- Contextウィンドウには最大サイズがあるのでコンパクション（圧縮、要約）技術もあるが信頼性に課題もある。
- AGENTS.mdを極める：コーディング・エージェントのためのContextウィンドウ戦略
- AGENTS.md とはコーディング・エージェント用のシステム、プロジェクトに沿ったプロンプトを記載したMarkdown形式のファイル。
- 配置ルールは、ルートとサブ・ディレクトリに配置できる。ルートはプロジェクト全体に適用され、サブはサブ・プロジェクトに適用される。
- 効果的な記述のコツ：
- 簡潔、明確、断定的に、プロジェクト全体目標と成功基準、肯定文に集中、強調は大文字の 「IMPORTANT（重要）」 を使う。
- 長文で冗長、過剰、防御的（数多くの例外ケース）
- 2025年型アプローチ vs 2026年型アプローチ
- 2026年型の思想（自律・手放し）：研究分野ではプログレッシブなコチラが重視されている。
- 2025年型の思想（管理・最適化 ※推奨）：実用的な大規模プロジェクトにおいてはコチラの方が成果が出る。
- AIコーディング・ワークフローの進化：YOLOからRalph Loopsへ：
- 2025年のマインドセット（低い〜中程度の信頼度）：マイクロマネジメント、計画・実行・レビュー・テスト、仕様ベース開発 / 信頼するが検証する
- 2026年のマインドセット（高い信頼度・自律駆動）：YOLO、ラルフ・ループ（Ralph Loops）、マルチ・エージェント（Multi-agent / Swarm）
- YOLOは元々は英語の古い格言的な表現（「人生は一度きり」）でAIの文脈では「一度きりだから大胆に試せ」「失敗を恐れず全力で行動せよ」の意味（マーケっぽいな）
- 賢く見えないシンプソンズのキャラクター（Ralph Wiggum）に因んで「しつこく繰り返せば最終的に成功する」と言うAIの運用哲学。
- ハイプ（過度な期待）を超えて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
- Cursor、GitHub Copilot、Codex、そしてAgentic Vibe Codingの実践：
- 講義の目的と心構え（バイブ・コーディングの原則）
- ツールの選択は自由： 紹介するツールをすべて使う必要はありません。見るだけでも1つ選んで使い続けるでも。
- 結果は人それぞれ： 使用するモデル（無料版や安価な版など）によって講師と異なる結果が出ることがある。
- イライラしない（最も重要）： 的外れな出力には「焦らず、フィードバックを与え、問題を極限までシンプルにする」
- ハンズオン：環境構築とプロジェクトの準備
- Cursorの起動とNode.jsのインストール
- GitHubからのプロジェクト複製（Gitクローン）と切り替え
- 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）：ファイル作成などのステップごとにユーザーの承認を求める。何が起きているかを確認しながら進めたい初心者向け。
- 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に対し、「エラーの修正」「ドラッグ＆ドロップの挙動のスムーズ化」「列内での並び替え機能の追加」「画面への紫と黄色の配色追加」をフィードバックとして指示。
- 改善結果の確認：デザインに指定通りの紫と黄色が取り入れられ、列内でのカードの並び替えも可能になった。一方で、エラー表示の赤アイコンは完全には解消されなかった。
- 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エージェントにデバッグを依頼する際は、「直した」という言葉を鵜呑みにせず、人間がボスとしてプロセスを管理し、「再現・原因特定・修正・実証」のステップを厳密に指示することが成功への近道。
- OpenAI Codex VS Code拡張：ゼロショットでKanbanアプリを構築：
- OpenAI CodexはCLIツールとしての側面を持つが、今回はIDE（VS Code）の拡張機能として使用する。利用にはOpenAIのアカウント（ChatGPTのサブスクリプションプラン）が必要となる。
- 「agent full access」（YOLOモード）、「GPT 5.5」、「reasoning effort」を「High」に設定（※思考させすぎると逆効果になることもある）。
- 同様に、アプリケーションの動作確認（自動起動と初期機能、初期状態の評価）を実施し、必要に応じてフィードバックによる反復改善（追加指示の提示、改善結果の確認）を行う。
- 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アプリは、デザインが新鮮かつクリーンで動作もスムーズだったが、一部の機能がシンプルすぎる（不十分な）ため、今後の改善の余地あり。
- 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
- 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）を目で確認しながら進める。
- Vibe Codingを成功させる5つの原則：
- 「5大原則（Be the Boss）」：AIを自律的な意思決定者として扱うのではなく、優秀だが助手として扱うマインドセット
- AGENTS.md（指示書）の充実：「要件（仕様）」「スタイル」「成功基準」の3要素を、簡潔かつ明確に記述。
- 小さく始める：最初から複雑なアプリを狙わず、まずは最も基本的なMVP（最小限の製品）の構築からスタート。
- 段階的に進める（インクリメンタル）：各ステップで常にテストと検証を繰り返し、規律を持ってマイルストーンを達成。
- 油断しない（怠けない）：初期にうまくいくとAIを過信しがちだが、AIが過去のステップで致命的な勘違いをしているケースがある。常に警戒。
- 泥臭く検証する（異議申し立てと証拠の要求）：AIが「修正した」と自信満々に言っても鵜呑みにせず、根本原因、テストの結果、証拠を厳しく求める。
- 混乱や失敗：「フラストレーションや壁にぶつかることもプロセスの一部」だと受け入れ、それを管理・回避する方法を学ぶことが成功への鍵。
- AIに仕事を丸投げするとスキルが身につかず、将来のフラストレーションに繋がる。
- AIに質問を投げかけ、何が起きているかを理解してシニアへのステップアップに活かす。
- AIは時に的外れで、自信満々に間違え、根本解決ではなくパッチを当てようとする。常にチェックする。
- コードを書く喜びは減るが、苦手分野を克服し、システム全体を高速に構築する新しいパワーを手に入れたと捉える。
- 責任ある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ドルから入金できるため、初心者にも優しい仕様となっている。
- 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サイトが短時間で完成。
- 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）から、現状のシステムプロンプトは非常にシンプルであるため、プロフィール情報などをプロンプトに組み込むといった改善を検討。
- チュートリアル、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
- 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）、一歩一歩着実にビルドしていく姿勢で、この新しい開発体験を心から楽しむ。
- 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コマンドを実行しても良さそう。
- 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: 次のステップで確認する、計画と実行のためのドキュメント。
- 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がどのように工程を進めているか観察・質問すること自体が、最高の学習機会（教材）になる。
- 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で進捗を保存。
- 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へ）
- 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（バイブ・エンジニアリング：プロフェッショナル向け）
- Claude Code や Open Codeを使用したCLIコーディングの深掘り。
- MCP（Model Context Protocol）、プラグイン、チーム開発、デバッグ手法の学習。
- SaaSプラットフォームを構築する大規模なプロジェクト。
- Claude Code、Open Code、others（Codex、Cursor、GitHub Copilot）CLI
主に2025〜2026年に流行した端末ベースのAIコーディング・エージェント群。
- Commands Checkpoints Ralph Loops
Claude Codeを使った自律型AIエージェントのループ手法
Day 1 †
34-39
- 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はコードを瞬時に生成できる反面、一度壁にぶつかると解決に数時間を要する特有の性質があるため、それを考慮したプロジェクトの見積もりを行う。
- 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）」での操作をメインに扱う。
- 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 が起動していないことを検知しコレを起動（高度な処理能力を称賛）。
- バックエンドおよびフロントエンドの全テストが走り、すべてパスした結果がターミナル上に表形式で出力。
- 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 コマンドについて説明。
- 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はモデルの切替、併用などについて優れた選択肢であり、使い分けが可能。
- 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
- 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の強制はあまり使われない。
- 設定とファイル管理のテクニック
- 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.
- Claude Code の Checkpoints、Rewind、YOLO Mode 解説
Claude Codeを使用し、コードレビュー、シンキングプロセス確認、チェックポイント活用を行う。
- コードレビューの実行とエラーの修正
- シンキングプロセスの可視化（ショートカットキー）
- 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）モード」とその応用について解説。
- 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"）を行い、コードを保存して危険なセッションを終了。
- 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
- 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の専門性を飛躍的に高める。
- 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などのアクティビティ、信頼できる開発元であるかを直接確認。
- 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）を実行
- 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はシンプルでエレガントな代替手段として期待されている。発展途上の拡張アプローチとして、多くの開発者に支持されている。
- Skills Marketplace：Claude Code に Agent Browser をインストール
- 「Skills（スキル）」の概要とマーケットプレイス
- スキルのインストール手順（Agent Browserの例）
- 実際の動作とメリット
- 実演デモ：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コミット＆プッシュするだけで、チームメンバーに同じスキルを簡単に共有・装備させることができる。
- Claude Code Plugins：マーケットプレイス、インストール方法、最適な使い方
- 「Agent Plugins（プラグイン）」とは？
- 概要：2025年10月に導入された最も新しい概念。MCP、Skills、コマンド（/から始まる命令）、フック、などを1つにパッケージ化した「機能の束（バンドル）」
- 目的：MCPやスキルの複雑な組み合わせをユーザーに意識させず、簡単に導入・管理できる。各種機能を発見する「マーケットプレイス」も提供されている。
- 特徴：他のAI（ChatGPTなど）にはなく、Claude Code専用に設計されている。
- メリットとデメリット
- メリット（Pros）:
・インストールするだけで使えてシンプル。
・コマンドを明示的に入力して実行するため、曖昧さがなく、動作が確実。
・迷ったら、MCPやスキルではなくプラグインから始めるのがおすすめ。
- デメリット・制限（Cons）:
・Claude Codeでしか使えない。
・パッケージとして一括導入されるため、細かいカスタマイズや要素ごとの組み合わせ（ミックス＆マッチ）がし難い。
- エコシステムとマーケットプレイス
- 実際の操作と主なプラグイン
- 操作方法：/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」コマンドは、プラグイン。
- MCP vs Skills vs Plugins：Claude Code で最適な構成を選ぶ
- プラグイン（Code Simplifier）の検証
- 3つの拡張技術の比較
| 技術 | メリット | デメリット |
| MCP (Model Context Protocol) | エコシステムが巨大、選択肢が豊富で柔軟。 | セットアップが複雑で、コンテキストを多く消費する。 |
| Skills | コンテキスト効率が良い、設定が簡単、チーム間での共有（リポジトリへのチェックイン）が容易。 | 柔軟性に欠け、マーケットプレイスなどがまだ発展途上。 |
| Plugins | MCPやSkills、エージェントなどを一括同梱可能。最も導入がシンプル。 | 現時点ではClaude Code内に閉じている。多く入れすぎると環境が複雑化する。 |
- どの技術を選ぶべきか（結論）
選択肢（MCP/Skills/Plugins）の中からでは「先ずはPluginsから探すこと」が推奨されている。
- 基本戦略：目的の機能を持つプラグインがあれば、それが最もシンプルで手軽なため最優先で選ぶ。
- MCPを選ぶケース：市場データの取得など、非常に専門的なツール（例: PolygonのMCPサーバーなど）を直接、柔軟に組み込みたい場合。
- Skillsを選ぶケース: Vercelのブラウザエージェントのような特定の優れたスキルを使いたい場合や、チームや組織内で簡単に独自のスクリプト一式を共有・管理したい場合。
- 総括と次へのステップ
- カリキュラム全体の折り返し地点（50%）を通過。
- 翌日からは、これらを踏まえた実際のプロジェクトにおける最適なワークフローや、さらに発展した「エージェント」の開発・活用について学んでいく。
Day 4 †
52-57
- 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）を作成し、ここから具体的な開発プロセスへと進む。
- 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が存在することを確認。
- GitHub MCP Server と Featured Dev Plugin のセットアップ
- GitHub MCPサーバーの導入と連携
- 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フォルダの作成）でインストールを実行。
- プロジェクトの環境整備と最終確認
- 結論：Jira（タスク管理）とGitHub（コード・Pull Request（PR）管理）、FeatureDev?（規律ある開発プロセス）が導入されたことで、Claude Codeを用いた本格的なチーム開発の準備が整った。
- 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のステータス更新
- ローカルでの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が効果的に問題を解決した素晴らしい例である。
- 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
- Claude Code のデバッグ戦略：体系的なアプローチ
- 開発タスクの進捗と成果
- 推奨のデバッグ戦略（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
- 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.
- CLAUDE.md の作成と Cerebras 用カスタム Skill の構築
- Claude.md（開発指示書）の作成と設定
プロジェクトの全体像や開発プロセスをAIに理解させるためのファイル Claude.md を作成し、以下のコンテキストを定義。
https://github.com/ed-donner/prelegal/blob/main/CLAUDE.md
- 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に明示。
- 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」に割り当てて実行。
- Claude Code、Jira、FastAPI を用いた機能開発
- 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!
- 課題の発見：
（１）AIが次の質問を継続して投げかけないため、会話が途切れてしまう。
（２）入力後にテキストフィールドへのフォーカスが自動で戻らない。
- 次のステップへの移行（Contextのクリーンアップ）
- チケット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を確認）。
- 最終 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への反映と勝利宣言
- 課題とコミュニティへのお願い
- 課題：JIRAやGitHub Issuesにチケットを切り、Claude CodeのFeature Devを活用して、テンプレートとチャットを組み合わせた独自のSaaSプロダクトを構築。
- 成果の共有： 成果はLinkedIn?などでハッシュタグや講師へのメンションを付けて積極的に発信し、コミュニティ全体で称え合うことを推奨。
- 次週（第3週）への展望
- プログラム全体の3分の2（67%）を終えたマイルストーンを祝福。
- 次週（最終週）は「さらにクレイジーでワイルドな内容」として、より大規模なコードベース、エージェント、フック、スウォーム（Swarms）、オーケストレーターなどを扱う。
Week 3 †
Vibe Engineering as an expert（エキスパート向け）
- 「コントロールされたカオス（Controlled Chaos）」をテーマに、より高度でラジカルなプロ向けの開発テクニックを学ぶ。
- マルチ・エージェント、サンドボックス環境の活用。
- 大規模なコードベースへの対応、エージェント・スウォーム（群）とオーケストレーターの利用。
- 最終的な集大成となるキャップストーン・プロジェクト。
- プロダクト
- Multi-Agents Sub-Agents Hooks
- Sandboxing
- コアスキル
- Large Codebase Workflow
- Swarms Orchestrators
- プロジェクト
Project 4：Capstone
Day 1 †
65-71
- 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ループなどを実現するための仕組み
- 独自プラグインの作成：チーム内での共有やマーケットプレイスへの公開方法
- FiNALLYプロジェクトのセットアップ：私たちのマルチ・エージェント取引アプリ（？アプリ内部もマルチ・エージェント？）
- Claude CodeでのカスタムSlashコマンドの作成
※ ココで新規作成したリポジトリに存在しないカスタムSlashコマンドは検証後に削除する。
- Slashコマンドの概要と作成方法
開発ツール（Claude Code）において、独自の「Slashコマンド（/で始まるショートカット）」を自作する方法には2つのアプローチがある。
- 実践：ドキュメントレビュー（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にコミットすれば、プロジェクトチーム全員でそのカスタムコマンドを共有できる。
- 今週の講義では、このようなレビューや開発のプロセスをさらに自動化していく方法（自動化レビューなど）について深く掘り下げていく。
- Claude CodeとCodex CLIを使ったエージェント＆サブ・エージェントの構築
※ ココで新規作成したリポジトリに存在しないサブ・エージェントは検証後に削除する。
- マルチ・エージェントの基本と課題
- マルチ・エージェントの単純なアプローチ：ターミナルのタブ化でプロンプト（例: Claude）を複数立ち上げ、それぞれに「フロントエンド開発」「バックエンド開発」「テスト作成」といった異なる役割を並行して与える方法。
- 現状の課題：開発計画の連携や境界線が十分に定義されていない段階でこれを実行すると、エージェント同士が互いの作業を認識できないため、整合性が取れず大混乱（カオス）を招く危険性がある。
- 異なるCLIエージェント（Codex）との連携
- サブ・エージェントの作成とメリット
- サブ・エージェントとは：メインの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（コマンドを実行できるがウェブ検索はできない）、といったツールの制限が設定されている。
- 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を組み立てて協調しながら問題を解決する仕組み（スウォーム/オーケストレーション）。
メインを介さずエージェント同士（例：テスターとフロントエンド/バックエンド担当）が直接対話・連携できる。 |
- 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 自身は裏でレビューが動いたことを認識していないが、ワークフローとして自動化が完了する。
- まとめ、注意点とアドバイス
- フックは開発プロセスを高度に自動化できる強力なツールだが、複雑性を伴う。
- 最初から無理に覚えようとせず、「こういうことができる」という全体像だけを頭に入れておき、実際に必要になったタイミングで公式ドキュメントを参照するのが最適。
- カスタム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
- 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」を押すなど）を行う必要がある。
・しかし、人間は慣れてくると内容を確認せずにボタンを連打しがちになり、結果として安全性が形骸化する（偽りの安心感）。サンドボックス化は、この承認疲れの根本解決につながる。
- 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ツール）にも適用できる。
- 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 にタスクを処理させるための連携準備が完了する。
- Claude Codeをリモートで実行する5つの方法：「&」「--remote」、Web、Mobile、GitHub Issue
- ① ローカルセッション内でのコマンド実行
- 方法：ローカルで起動しているClaude Codeのセッション内で、コマンドの先頭にアンパサンド（&）を付けて実行する。
>& hey what's 2 + 2
- 特徴：
・コマンドはローカルではなくクラウド上のサンドボックス環境で実行される。
・これまでの会話の文脈（フルコンテキスト）がすべてクラウドに引き継がれ、/tasks コマンドで並行して走っているタスクの一覧を確認できる。
- ② ターミナルからの直接実行
- ③ 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への自動割り振りがシームレスに融合した強力な開発スタイルとして紹介されている。
- 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.
- クラウド・サンドボックス総まとめ：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は自動的にブランチを作成してGitHubへプッシュし、プルリクエスト（PR）を作成。スピーカーはこれを確認し、マージを完了させた。
> 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
- 大規模コードベースでのClaude Code、Codex、Sprites.dev活用
- 大規模チームのコードベースでClaude Codeを使うためのベストプラクティス
- Claude Agent SDKによるClaude Codeのプログラム的制御
- Claude Cowork：日常業務向けエージェントAIデモ
- OpenClaw?：Telegram＆WhatsApp?で使えるパーソナルAIサイドキック
Day 4 †
83-88
- Claude Codeエージェントチーム：スウォームとオーケストレーション
- フルスタック開発のためのClaude Codeエージェントチームのセットアップ
- マルチ・エージェント・チーム構築：Claude Opusによるライブ取引ダッシュボード
- GSD：仕様駆動設計とマルチ・エージェント・オーケストレーションの融合
- Claude GSDによる取引プラットフォーム構築：5時間徹底解説
- GSD vs Claude Agent Teams：UI比較と総括
Day 5 †
89-95
- Gastown：Claude Codeエージェントのスウォームをオーケストレーション
- GastownのParallel Polecats：Claude Codeエージェントがカオスの中で構築
- Gastown vs Claude Agent Teams vs GSD：マルチ・エージェント・オーケストレーター比較
- Codexの勝利：ライブ市場データ付き最終トレーダー用ワークステーション
- 最終デプロイ、コース総括＆コーディング・エージェントのベストプラクティス
- コース総復習：Vibe Codingからエージェントエンジニアへ
- ボーナス講義 - あなた専用の限定リンク集
詳細 †
手順をメモ
様々なツールのYOLOを試す †
VS Code（GitHub Copilot、OpenAI Codex）、Cursor、Antigravity IDE、Claude Code
- Cursor（、Antigravity IDE）はIDEと言われているが、実体は、VS Codeベースのエディタ
- 一方で、GitHub Copilot、OpenAI Codexは、VS Code拡張と言う意味では同じだが、
- GitHub Copilotは企業向け導入が多いこともあり、YOLO的な動きはCursorが一歩先を行く感じ。
- エディタ拡張系の使用感は
- どれも同じで、暗黙の業界標準がある模様（コレから外れると使用が困難になり劣勢になる）。
- AGENTS.mdが業界標準になりつつあるのは良い。ただ設定インターフェイスはまちまちで「plan（計画）」モードは無いモノもある。
- CLI系の使用感は...
- GUIと大差無しだが、コマンド指示ができるので、より細かな制御が可能。
- そう言えば、GitHub CopilotにもSlashコマンドってあったなと。
- ただ、アレは、CLIが実行されるのではなく、Copilot Chat の Slashコマンドは、プロンプトに影響を与えるか、LLMが学習いているかの何れか（若しくは併用）と思われる。
- ...よくよく考えると、Claude Code の Slashコマンドも、インタラクティブ・モードで使うので、Copilot Chatと同じ仕組みだよね（Skillsで定義できるとのこと）♨
- 「抽象的な指示を実行させる場合」
- 安全モードは手間なダケな（価値の作り込みや、高リスク問題の判定のケースが少ない）のでYOLOモードを使用しガチ。
- ずーっと、意味のないプロンプト・フローのログを読んで、意味のない承認依頼に対する承認処理を行い続けるのが苦痛になってくる。
- 「段階的に指示を実行させる場合」
- 完了までの時間も短縮されるので、安全モードの手間は感じ難くなってくる。
- 都度確認による手間も、やり直しが減るので全体として時間短縮に繋がる。
- また、承認の度、以降の再承認が不要になるモノが積み上がっていくのもある。
- その他、思った事。
- Nodeのサーバプロセスが残留して他をブロックすることがあったので、必要に応じ、タスクマネージャから、Nodeで検索して全削除した。
- 一応、プロンプト出力自体が進捗には成っているが、全体計画から何％の所まで進んだか？良く解らない点は改善して欲しい点（段階的に進めるしかない？）。
- コチラのアクション（承認とか起動とか）がボタン化されるモノは解り易いが、プロンプト出力されるものは読んで理解してプロンプト入力となるので一手間。
Cursor †
- 紹介ページ（https://github.com/daisukenishino2）のWebサイトを作成
- webフォルダを作成し、ソコに、紹介ページを印刷してPDF化したファイルを配置
- CursorのワークスペースをwebフォルダにしてAGENTS.md 無しで実行する（プロンプトは以下）。
Please build me a Professional Website running locally. My GitHub profile is in daisukenishino2_Profile.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.
- 計画中のチャットで、PDFが読み込めずURLを直接渡した。また、NextJSのモードから「App Router」を選択した。計画の立案が終わったところで「Build」を実行した。
- We're experiencing high demand for the selected model right now. Please upgrade to Pro, switch to Auto, another model, or try again in a few moments.
- Kanbanアプリ（https://github.com/ed-donner/kanban）
README.md、AGENTS.mdを確認しつつ、Gitクローンして、WindowsのCursorでワークスペースとして開く。
- WindowsのCursorで「Ctrl + Shift + J」→「agents」→「auto run」セクションから、YOLOモード（Run everything unsandboxed）を選択。
- 作業スペースを広く確保するためエージェント画面を左に広げ、使用モデルは「auto（自動選択）」に設定。エージェントを「plan（計画）」モードに切り替え「Go ahead and plan.」（さあ、計画を立てよう）と指示を出す。
- デフォルトで読み込まれる設定ファイル AGENTS.md を基に、AIが自動で「kanban_mvp_build_XXXXXXXX.plan.md」を生成（の内容をCursor上で「Ctrl + Shift + V」するか、ココらへん https://dillinger.io/ に貼り付け翻訳して読むと良い）。
- 生成された計画書のレビューをスキップし「build」ボタンを押して開発を開始。ユーザーはコンテキスト（メモリ）使用量が徐々に増えていく様子や、AIが自ら思考・修正するプロセスを確認。
- ビルド完了後、アプリ（Next.jsベース）が自動起動し、ローカルサーバー（http://localhost:3000/）でかんばんボードが立ち上がる。初期状態の評価を行う。
- 引き続きプロンプトに「フィードバック」（任意、以下に例を示す）を入力して反復改善。改善された点も在れば、改善されない点も出るものと思われる。
概ね問題なく動作していますが、Next.jsでエラーが1つ発生していると表示されています（画面下部に赤いアイコンが表示されます）。また、ドラッグ＆ドロップの動作が少し不安定で、列内での並べ替えができません。これをよりスムーズにすることは可能でしょうか？さらに、画面に黄色と紫の色をもっと多く取り入れていただけると嬉しいです。
it's mostly working nicely, but NextJS is showing that there's 1 error (red symbol at bottom of screen). Also the drag and drop is a bit janky and it's not possible to reorder within a column -can this be made more slick? Also it would be nice to have more yellow and purple on the screen.
※ ブラウザ翻訳で日本語になっているが、元々は英語表記。
- 前述の、「紹介ページのWebサイト」に「経歴について回答できるAIチャット機能」の追加を指示。
- webフォルダに「OPENROUTER_API_KEY」を記載した.envと、.envを除外する.gitignoreを配置、
- CursorのワークスペースをwebフォルダにしてAGENTS.md 無しで実行する（プロンプトは以下）（プロプラン以上が必要とのこと）。
素晴らしいですね。では、私のキャリアに関する質問に答えてくれる「デジタルツイン」とのAIチャット機能を追加してください。OpenRouterを使用してください。私のOPENROUTER_API_KEYはプロジェクトルートのenvファイルにあります。「openai/gpt-oss-120b」という名前のモデルを使用してください。変更を加え、動作確認をしてから、準備ができたら教えてください。
That's great. Please now add the ability to have an Al chat with a "Digital Twin" which can answer questions about my career. Please use OpenRouter. My OPENROUTER_API_KEY is in the env file in the project root. Please use the model named "openai/gpt-oss-120b". Make the changes, make sure it works, let me know when ready for me.
- 実際に使用するモデル名は、https://openrouter.ai/models で、「free」「OSS」などのキーワードを使用して検索すると良い。
- 計画の立案が終わったところで「Build」を実行し、出来上がったサイトの動作、生成されたファイルの確認をしながら改善を検討。
VS Code + GitHub Copilot †
- GitHub Copilot と VS Code の導入を参考にして、VS Code + GitHub Copilotをインストールしてセッティングする。
- プロジェクトを準備（既存の Kanban ディレクトリの名前を Cursor_Kanban に変更し、再度Gitクローン）しワークスペースを変更する。
- ショートカットキー（Mac：Command + Shift + I / PC：Ctrl + Shift + I）またはメニューから「Chat」を起動して、使い慣れたサイドバー形式の「Build With」エージェントを表示。
- 作業スペースを広く確保するためエージェント画面を左に広げ、使用モデルは「auto（自動選択）」に設定。エージェントを「plan（計画）」モードに切り替え「Please plan the task at hand.」（目前のタスクを計画して下さい。）と指示を出す。
- 実行プランが生成された趣旨の出力があり、「Planから続行」から「Start Implementation」を選択し実装を行う。「モデルがXXXXしようとしています。これを許可しますか？」で「このセッションで許可する」を押下して続ける（≒ YOLOモードに入る）。
- 「次に実行するコマンド（ローカル端末で）」（cd frontend / npm install / npm run dev）また「続けて欲しい事を教えて下さい。」が表示される。ターミナル部分ウィンドウから「cd frontend / npm install」コマンドを実行。
- 「npm install」でエラーが出たのでエラー出力をプロンプトとして入力して再実行し、ファイルが修正されたところで、再度「npm install」コマンドを実行、コレをパスしたら「npm run dev」を実行する。
- アプリ（Next.jsベース）が起動し、ローカルサーバー（http://localhost:3000/）でかんばんボードが立ち上がる。初期状態の評価を行う（モデルの関係か、コチラの実装のほうがショボい感ある）。
- 引き続きプロンプトに「フィードバック」（任意、以下に例を示す）を入力して反復改善。改善された点も在れば、改善されない点も出るものと思われる。
- カード削除機能以外はすべて正常に動作しているようです。
everything seems to be working well, except the delete card feature isn't working.
- それでは解決しません。まず問題を再現し、再現できたことを証明し、根本原因を特定し、それを修正し、修正できたことを証明してください。
That didn't fix it. Please first reproduce the problem, prove you've reproduced it, find the root cause, fix it and prove you've fixed it.
VS Code + OpenAI Codex †
- VS Code拡張（Ctrl + Shift + X）から「Codex – OpenAI’s coding agent」をインストールする。
- プロジェクトを準備（既存の Kanban ディレクトリの名前を Copilot_Kanban に変更し、再度Gitクローン）しワークスペースを変更する。
- ショートカットキー（Mac：Command + Shift + I / PC：Ctrl + Shift + I）から「Chat」を起動、CODEXタブを選択して、ChatGPTの利用アカウントにログインする。
- 「Agentフルアクセス」（YOLOモード）、「GPT-5.5」、「推論」を「高」に設定し「Please go head.」（どうぞ、続けてください。）と指示を出す。
- （実行前にサンドボックスの設定を要求されたので許可する。サンドボックスの設定が終わるまで暫く待たされ、終わったらプロンプトを再送する）
- （Codex Windows版入門 — ネイティブサンドボックスで安全にAIコーディング #OpenAI - Qiita）
- カナリ長時間考え、出来上がった結果は過去一良い。ChatGPTのすら若干劣勢と思われるOpenAIが挽回のために、GPT-5.5を大盤振る舞いしているのかも？
Antigravity IDE †
- プロジェクトを準備（既存の Kanban ディレクトリの名前を Copilot_Kanban に変更し、再度Gitクローン）する。
- AntigravityではなくAntigravity IDEを既定値でインストールして。Googleの利用アカウントにログインして、ワークスペースの変更を行う。
- Antigravity - Settingsから：「Lintエラーの自動修正機能（Agent Autofix lints）」、「確認なしで処理を続行させるYOLOモード（Always proceed）」に設定。
- Antigravity IDEは、標準になりつつあるAGENTS.mdを使用しないので、所定の.agent/rules/strategy.md に配置（AGENTS.mdは削除、序に一応、README.mdもcommunity_contributionsも削除しておく）。
- モデル推論を「Gemini 3.5 Flash (High)」に設定し「Please go head.」（どうぞ、続けてください。）と指示を出す。実装計画が出来上がると承認を依頼されるので「I approve.」（承認します。）と指示。
- 出来上がった結果、色使いが若干独特（笑）引き続きプロンプトに「フィードバック」（任意、以下に例を示す）を入力して反復改善。改善された点も在れば、改善されない点も出るものと思われる。
Claude Code †
- プロジェクトを準備（https://github.com/ed-donner/pmをGitクローン）する。
- claude コマンドを入力して Claude Code CLI を起動、初めて使用する場合は、/login コマンドで認証し、/initコマンドでCLAUDE.mdを自動生成
- その後、YOLOモードにするには、一旦 claude を抜けて「claude --dangerously-skip-permissions」とフラグを付けて起動。
- Tabキーで、「Plan（計画）モード」から「Build（構築）モード」に変更し、テキトウな指示を実行
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.
10段階計画 †
VS Code + GitHub Copilot †
1週、5日目の内容
... †
... †
参考 †
コード †
github.com/ed-donner
スライド †
https://drive.google.com/drive/folders/1vvp15mK3ZXDfY8HE4g-tlF2CTfBfSDQ8
- Al Coder Week 1
- Al Coder Week 2
- Al Coder Week 3
その他 †
プロダクト関連 †
論文関係 †
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
