Vibe CodingからAgentic Engineeringへ — CLAUDE.mdに反映した5つの原則

Mar 17, 2026 6分で読めるテック

Claude Code AI Agentic Engineering ワークフロー

「Vibe codingはスラングだ」——OpenClawの作者Peter Steinbergerが、Lex Fridmanとの3時間インタビューでそう言い切りました。

プロンプトを投げて祈る。出てきたコードを眺めて、なんとなくOKなら次に進む。これがVibe codingです。対して、Steinbergerが提唱する「Agentic Engineering」は、AIエージェントを意図的に導き、構造化された協業をする手法を指します。

自分はClaude Codeを毎日使っています。CLAUDE.md、SKILL.md、hooks、Plan mode、subagentsを組み合わせたワークフローは、振り返ればAgentic Engineeringそのものでした。ただ、明文化されていない暗黙のルールも多かったのが実情です。

Steinbergerのインタビューから抽出された原則を読んで、自分のグローバルCLAUDE.mdに反映する実験をしたので、その記録を残します。

反映した5つの原則

1. Fix forward — リバートせず前進する

Steinbergerはgit revertを使いません。理由は明確で、ロールバックするとエージェントがビルド中に蓄積した「問題の理解」を捨てることになるからです。

これは自分の経験とも一致します。Claude Codeが間違った方向に進んだとき、git checkout .で全部戻してやり直すより、「ここが問題。この方針で直して」と伝えた方が、エージェントの理解が維持されて次の出力の精度が上がります。

CLAUDE.mdに追加したルール:

Fix forward: 問題が起きたらリバートせず前進する。
ロールバックはコンテキストを捨てることになる

2. まず議論、次にビルド

いきなり「この機能を実装して」と頼むのではなく、まず「どうアプローチするか議論しよう」と伝えます。Steinbergerのワークフローはこうです:

ビルド前: 「議論して。選択肢を出して。まだコードは書くな」
ビルド中: 「OK、ビルド」で20分放置
ビルド後: 「違う方法でやるなら？」「リファクタリングは？」

特に3番目が重要です。エージェントはビルド中に痛みを経験しています。その文脈が消える前に、改善点を聞き出します。

これはClaude CodeのPlan modeと組み合わせると強力になります。Plan modeで方針を固めてからビルド、完了後に「今のセッションで感じた改善点は？」と聞くワークフローを標準化しました。

3. アーキテクチャヒントを1-2文で与える

エージェントは毎セッション、ゼロからプロジェクトを理解しなければなりません。10万行のコードベースを「fix this bug」だけで投げるのは、新人エンジニアにオンボーディングなしでバグ修正を頼むのと同じです。

解決策はシンプルです。タスクの冒頭で、関連ファイルやモジュール構成を1-2文で伝えます。

「認証周りのバグ。src/lib/auth/にSupabase Auth統合がある。
middleware.tsでセッション検証している。」

これだけで、エージェントがファイルを探索する時間が激減します。CLAUDE.mdにプロジェクト構造の要約があればなお良いです。

4. 命名はエージェントに任せる

これは最も反直感的な原則でした。自分の命名規則と合わなくても、エージェントが選んだ名前を受け入れます。

理由はこうです。モデルのweightに入っている名前は、次にそのコードを検索・修正するときにもモデルが見つけやすい名前です。自分の好みで上書きすると、エージェントのナビゲーション性が下がります。

もちろん、プロジェクトの命名規約（camelCase等）は守らせます。ただ、fetchUserDataかgetUserDataかのレベルの違いは、エージェントの選択を尊重するようにしました。

5. 自分で答えられる質問は自分で調べさせる

Steinbergerの「magic question」: エージェントに「質問ある？」と聞きます。返ってきた質問のうち、コードを読めば答えられるものは「読んで答えて」と返します。残った質問だけが、本当に人間の判断が必要な質問です。

これはコンテキストの節約にもなります。エージェントに答えを直接教えると、その情報がコンテキストを消費します。エージェント自身にコードを読ませれば、必要な部分だけを効率的に取得できます。

反映しなかった原則

Steinbergerは「CLI > MCP」を強く主張しています。MCPはコンテキストを汚す、CLIの方がcomposable、という論理です。

これには部分的にしか同意できません。自分の環境ではGA4やGmail等のMCPサーバーが不可欠で、CLI化するコストが見合いません。ただ、MCPの出力が肥大化してコンテキストを圧迫する問題は実感しています。MCPサーバー側でレスポンスを絞る設計が重要だと再認識しました。

変更後の体感

まだ反映して数時間ですが、最も即効性があったのは「Fix forward」です。以前ならgit checkout .してやり直していた場面で、エージェントに修正方針を伝えて前進させると、2回目の出力の精度が明らかに高くなります。コンテキストが維持されているからです。

「命名委任」は意外と心理的ハードルが高いです。自分の好みを押し付けたくなります。ただ、エージェントとの協業においては「自分のコード」ではなく「チームのコード」だと考えた方が生産的です。

まとめ

Vibe CodingとAgentic Engineeringの違いは、「祈り」と「設計」の違いです。

CLAUDE.md、Plan mode、hooks、subagentsは、すべてエージェントとの協業を構造化するための道具です。Steinbergerの原則は、これらの道具をどう使うかの指針を与えてくれます。

リバートせず前進する
まず議論、次にビルド
アーキテクチャヒントを与える
命名はエージェントに任せる
自分で調べられることは調べさせる

どれもすぐに実践できます。CLAUDE.mdに5行追加するだけです。

リファレンス

質問・リクエストを送る

記事についての質問や、取り上げてほしいテーマがあればお気軽にどうぞ。いただいた質問はブログ記事として回答し、Q&Aページで公開することがあります。