AIは「汎用的な高知能体」

昔のAIはあまり賢くなかった

しかし昨今のAIはセンター試験で高得点をマークするレベルに

汎用的な高知能体の一種 として捉えている

意思疎通は「ハック」ではなく「伝える」

• AIを小手先のテクニックでうまく動かす発想 → 間違い
• 知能の高い相手に、わかりやすく伝える → 正解

人間の新メンバーに仕事を伝えるのと同じ( ¯-¯ )

「言えばできる」は期待が間違い

「Reactを書かせても最近のReactのコードを生成してくれない」

情報系以外の東大生を想像してほしい

• 東大に受かるほど知能は高い
• でも特定の専門領域まで完全に網羅しているわけではない
• 補足しないとできないのは当然

AIも同じ。ちゃんと補足すれば生成してくれる

その質問、大丈夫？

AIに質問する前に、自分自身に問いかけてほしい

• その質問は論理的だろうか？
• 感情的なものが混ざっていないか？
• 抽象度が高すぎないだろうか？
• 文脈は整っているだろうか？

もしかしてAIにパワハラしてませんか？( ¯-¯ )

暴言や話の内容と関係のない事を投げつけていないか？

AIの出力が悪いとき、原因はAIではなく自分の質問にあることが多い

質問の質を上げる = バイブコーディングの質を上げる

前提：特定のツールに依存しない

• AIモデルは複数あり、日々進化している
• ツールも次々と増えている
• 特定のモデル・ツールに依存すると、変わったときに破綻する

subagentやskillsを積み上げても根本解決にならない

良質なコンテキストは基本的にどのAIでも活きる

AI用リポジトリでラップする

AI設定をプロジェクト本体に含めたくないケースがある

はじめからAI用のリポジトリで開発対象をラップする

パターンA: 単一リポジトリをラップ

dev/
├── project/          ← 開発対象（AI設定は一切置かない）
├── CLAUDE.md
├── .claude/skills/
├── .serena/          ← Serenaメモリ
├── doc/
└── task/

パターンB: 新旧環境を横断管理

dev/
├── CLAUDE.md
├── .serena/         ← Serenaメモリ
├── .claude/skills/
├── doc/
├── task/
├── app/             ← 開発対象（新環境リポジトリ）
├── frontend/        ← 開発対象（旧環境リポジトリ）
└── backend/         ← 開発対象（旧環境リポジトリ）

このパターンの利点

• チームメンバーやクライアントのリポジトリを汚さない
• 複数の開発リポジトリを1つのAIコンテキストで横断管理
• AI設定ファイルを開発対象リポジトリに配置しないルールを徹底

いきなり実装を依頼しない

バイブコーディングで一番大事なのはタスクをあらかじめmdファイルとして書いておくこと

1. やりたいことを事前にmdファイルに整理する
2. AIとやり取りしながらタスクの解像度を上げる
3. 具体化されたタスクをAIに渡して実装

タスクの粒度

1機能 = 3〜9フェーズの複合実装

レイヤー別にフェーズを分ける

# [機能名] タスク
## 概要
## 現状分析
  - 対象ファイル一覧（新規/修正/参照のみ）
## 実装タスク
  ### Phase 1: DBスキーマ・Repository層
  ### Phase 2: Service層
  ### Phase 3: ルート・API
  ### Phase 4: フロントエンド
## 技術的考慮事項
## チェックリスト（実装手順）
## 完了条件（成功基準）

タスク設計のポイント

• 対象ファイル一覧で変更範囲を事前に確定
• 実装コード例をテンプレートとして記載（コピペ可能な精度）
• フェーズ間の依存関係を明示（Phase 1 → Phase 2）
• チェックリスト（手順）と完了条件（成功基準）は分けて管理

なぜplanモードではなくmdファイルなのか

Claude Codeや他のツールにもplanの機能はあるが：

• ツールの隠しディレクトリに内包される
• ツール間で共有ができない（Claude Code Cursor間）
• つまりツール依存になる

mdファイルならどのツールからでも読める

使用しているMCP

MCPはAI共有のプロトコル → 特定ツールに依存しない

• どのAIツールからでもアクセスできるものを選定
• Serena: コンテキストの効率がよく、プロジェクトの内容管理を任せている
• Chrome DevTools: UIの分析・デバッグに便利
• その他はプロジェクトに応じて判断

Serenaのメモリ例：
project_overview / architecture / code_style_and_conventions / database_schema

Skills: 3つだけ、すべて汎用的

特定のプロジェクトやツールに閉じた機能は作らない

Agent Teamで精度を上げる

最近では複数のagentでチームを組める

自分は毎回レビュアーをつけている

• 実装したagentとは別のagentがレビュー
• セルフレビューでは見落としがちな問題を検出

テクニックより思想

テクニックは必要な情報を取得する手段でしかない

大事なのはAIとどう向き合うかという思想・哲学

1. AIは汎用的な高知能体。ハックではなく、ちゃんと伝える
2. 「自分がそのタスクを渡されて混乱しないか？」 を基準にする
3. タスクをmdファイルで具体化してからAIに渡す
4. AI用リポジトリで開発対象をラップし、プロジェクトを汚さない
5. MCPやSkillsは汎用的なものだけ。contextを圧迫するので最低限に