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

目次 †

↑

概要 †

↑

Week 1 †

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

↑

Day 1 †

1-7日

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

Day 2 †

8-13

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

Day 3 †

14-20

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

Day 4 †

21-26

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

Day 5 †

27-33

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

Week 2 †

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

↑

Day 1 †

34-39

  1. Pro Week へようこそ：Vibe Coding から Vibe Engineering へ
    • プロ向けの2週の幕開けとコアツールの導入
      • 応用・発展フェーズへの移行：基礎的なスキルを習得した第1週を終え、第2週からは、より深く、プロフェッショナルでハードコアな実践を行うプロ週へと移行します。
      • Claude Codeの導入：今週のプラットフォーム・プロダクト（Yellow Day）の目玉として、今後2週間の中心的なツールとなるCLIツール「Claude Code」を導入。あわせてOpenCode?などの他のCLIツールも扱う。
    • AIコーディングの進化と今週のアプローチ
      • 進化のステージ：AIコーディングは、単なるChatGPTの利用（第1週の内容）から、第2週の「ステージ5（CLIツールやエージェントの本格活用）」、そして第3週の「オーケストレーション・プラットフォーム（マルチエージェントのスウォームなど）」へと進化。
      • 開発スタイルとマインドセット：ミッションクリティカルな大規模コードや革新的なコードでは「計画・実行・レビュー・テスト」のステップを踏む「信頼せよ、されど確認せよ（Trust but verify）」のマインドセットが不可欠。
      • 一方で、リスク許容度が高いMVP（最小限の試作品）やボイラープレート（定型）的なフロントエンド開発では、より大胆な自動化（YOLOやRalph loops）を取り入れる。
      • どのような手法であれ、コードの品質と動作に対する最終的な責任と説明責任（Accountability）は開発者自身にあるという原則が強調される。
    • 「バイブ・エンジニアリング（Vibe Engineering）」への昇華
      • エンジニア・ライターのSimon Willison氏のブログ記事を引き合いに、今週のテーマである「バイブ・エンジニアリング」の概念が説明されている。
      • バイブ・コーディングとの違い：
        ・「バイブ・コーディング（Vibe Coding）」：プロンプト主導でコードの仕組みを深く考えずに素早く大雑把に作る。
        ・「バイブ・エンジニアリング（Vibe Engineering）」は、熟練のプロがLLMの恩恵を受けて生産性を高めつつ、品質への説明責任を100%保持するスタイル。
      • プロのAIエンジニアリングに求められるスキル：
      • 厳格なプロセス：事前の計画、綿密なドキュメント作成、自動テストの組込、GitやClaude Codeの機能を活用したバージョン管理。
      • 高度なマネジメント・レビュー力：LLMに自身の成果物をレビューさせる文化、手動QA（品質保証）、AIがサボったり誤魔化したりしないように管理する能力。
      • 切り分けの直感：AIに「任せられるタスク（フロントエンドなど）」と「任せられない／注意が必要なタスク（バックエンドやリファクタリング）」を正しく判断する直感。
      • 見積もりの罠への対処：AIはコードを瞬時に生成できる反面、一度壁にぶつかると解決に数時間を要する特有の性質があるため、それを考慮したプロジェクトの見積もりを行う。
  2. Claude Code の台頭：歴史、セットアップ、VS Code へのインストール
  3. Claude Code CLI 入門：Init、Context、Testing
  4. Claude Code レビュー：ハルシネーションの修正とコードのリファクタリング
  5. OpenCode?：GLM 4.7 などの無料モデルを Claude Code の代替として使う
  6. OpenRouter? と Ollama を使った AMP Code、OpenCode?、Claude Code
↑

Day 2 †

40-44

  1. Claude Code のコマンド、ショートカット、設定の徹底解説
  2. Sessions、Checkpoints、Git：Claude Code ワークフローの管理
  3. Claude Code の Checkpoints、Rewind、YOLO Mode 解説
  4. Claude Code YOLO Mode：権限をバイパスして自律コーディング
  5. Claude Code の Ralph Loops：自律エージェントによるオートパイロットコーディング
↑

Day 3 †

45-51

  1. MCP、Skills、Plugins：Claude Code の3大構成要素
  2. MCP Server 解説：Host、Client、Discovery（Claude Code）
  3. Claude Code への MCP Server 追加：Context7 & Polygon IO
  4. Skills vs MCP：Claude Code で能力を追加するよりシンプルな方法
  5. Skills Marketplace：Claude Code に Agent Browser をインストール
  6. Claude Code Plugins：マーケットプレイス、インストール方法、最適な使い方
  7. MCP vs Skills vs Plugins：Claude Code で最適な構成を選ぶ
↑

Day 4 †

52-57

  1. Claude Code、Jira、MCP、Plugins を活用した開発ワークフロー
  2. Claude Code と Jira MCP Server、GitHub リポジトリの連携
  3. GitHub MCP Server と Featured Dev Plugin のセットアップ
  4. Claude Code の自律性：Jira Issue から MCP Server 経由で PR 作成まで
  5. Claude Code が Jira チケットから Next.js アプリをフル構築
  6. Claude Code のデバッグ戦略：体系的なアプローチ
↑

Day 5 †

58-63

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

Week 3 †

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

↑

Day 1 †

↑

Day 2 †

↑

Day 3 †

↑

Day 4 †

↑

Day 5 †

↑

詳細 †

手順をメモ

↑

様々なツールのYOLOを試す †

VS Code（GitHub Copilot、OpenAI Codex）、Cursor、Antigravity IDE、Claude Code

↑

Cursor †

1

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

↑

VS Code + GitHub Copilot †

2
↑

VS Code + OpenAI Codex †

3
↑

Antigravity IDE †

4
↑

参考 †

↑

コード †

github.com/ed-donner

↑

スライド †

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

↑

その他 †

↑

プロダクト関連 †

↑

論文関係 †

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