ROBOCO

意外にも9倍安いラルフループ - コンテキストキャッシングの経済学

Sun, 26 Jul 2026 10:00:00 +0900

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

チョン・ドヒョン - ROBOCO首席コンサルタント

ラルフループ（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倍安かった

指標	Ralph loop	Plan-then-execute
完了判定	通過	通過
実時間	14分	49分
セッション数	1	16
outputトークン	90,877	797,845
cache_creationトークン	233,687	2,040,513
billable合計	324,775	2,839,815

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

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

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

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

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

認知負債 - バイブコーディング時代の新しい負債管理法

Sat, 18 Jul 2026 10:00:00 +0900

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

チョン・ドヒョン - ROBOCO首席コンサルタント

バイブコーディングで仕事をしていると、奇妙な瞬間が訪れます。間違いなく自分のプロジェクトなのに、コードを開いてみると他人の家のようです。エージェントが設計し、エージェントが実装し、私は承認ボタンを押しました。仕事は早く終わりました。ところが障害が起きると、こう言うことになります。「この問題はなぜ起きたのでしょう？ 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はなぜ脱落したのか、「運用経験あり」が決定を正当化するほど重要な条件だったのか、この文書は何も語りません。同じ決定を叙述型で書くとこうなります。

プロダクト

Sat, 16 May 2026 10:00:00 +0900

ROBOCOが作る、バイブコーディング時代のツール群

ROBOCOは、コンサルティングと教育の現場で得た知見を自社プロダクトへと発展させています。すべて誰でも利用できるよう公開しており、ご意見・コントリビューションを歓迎します。

Intent Engineering

Ship intent, not code. — 意図を明確に記録し、残りはAIに委ねるバイブコーディングのパラダイム。

コードを直接書いていた時代から、AIに意図を伝える時代へと移行する今、「何を、なぜ作るのか」を正確に表現することが最も重要な作業になりました。Intent Engineeringは、この意図を文書として整理し、進化させ、チームと共有するための実践的な方法論です。

こんな方に役立ちます

AIに仕事を委ねる中で、意図がぼやけてしまう経験をした方
プロジェクトの「なぜ」を見失わずに、素早く作りたい方
チーム内でAI協業の共通言語を定着させたいリーダー

リンク

サイト: intent.roboco.io
GitHub: roboco-io/intent-engineering

VAF — Vibe Adoption Framework

バイブコーディング、どこから、どのように導入するか。 — 既存企業がエージェント中心の開発体制へ移行する旅路を構造化したフレームワーク。

ツールをいくつか導入したからといって、開発方法が変わるわけではありません。VAFは、ROBOCOがバイブコーディング・AXコンサルティングの現場で蓄積したベストプラクティスを整理し、すでに確立された組織が何を最初に点検し、どの順序で移行すべきかを示します。

3つの貫く原則: エージェントは人的レバレッジである・オーナーシップは人に残る・認知負債は管理されるべきである
6つの観点: 戦略・人材とオーナーシップ・ガバナンスとガードレール・エージェント環境・ナレッジ・ハーネスエンジニアリング(26の能力項目)
4つの転換領域: コード生産・品質保証・ナレッジ・組織と役割
4段階の導入プロセス: 準備 → 診断 → パイロット → 転換

こんな方に役立ちます

組織レベルでのバイブコーディング導入を設計する必要があるCTO・エンジニアリングリーダー
パイロットは成功したものの、全社展開で行き詰まっているチーム
AI導入の進捗状況を能力単位で診断したい組織

リンク

サイト: vaf.roboco.io(韓国語: /ko/、日本語: /ja/)
GitHub: roboco-io/vibe-adoption-framework

VDLC — Vibe-Driven Development Lifecycle

意図とコンテキストが一次成果物であり、コードはそこから再生成可能な二次成果物である。 — バイブコーディングを前提に再構築されたソフトウェア開発ライフサイクル。

既存のSDLCの実装フェーズにAIを組み込むだけのやり方には、明らかな限界があります。VDLCは、AIエージェントが実装の主体となる状況を最初から前提とし、開発の全プロセスを再設計したライフサイクルです。

6つの原則: 意図がソースである・人間は判断しAIは実行する・速度は検証が決定する・コンテキストは資産である・小さく回して頻繁にフィードバックする・理解が所有である
6段階のライフサイクル: 意図定義 → コンテキスト設計 → 共同実装 → 検証 → デプロイと観察 → フィードバック
週次サイクル: Shape Upをバイブコーディング前提で再解釈したチーム運営リズム(4日ビルド+1日クールダウン)
実務資産: 段階別プレイブック、文書テンプレート、成熟度モデル、導入ロードマップ、測定指標

こんな方に役立ちます

AIがコードを書くチームで、プロセスとゲートを再定義する必要があるリーダー
スプリント・レビュー・QAなど、既存の開発リズムがもはや合わないと感じているチーム
コンテキストと文書をチームの資産として管理する方法を探している組織

リンク

サイト: vdlc.roboco.io(韓国語: /ko/、日本語: /ja/)
GitHub: roboco-io/vibe-driven-development-lifecycle

VibeMap

アイデアからデプロイまで、バイブコーディングの全体地図。 — Intent Engineering・Claude Code・Git・TDD・AWSサーバーレスなど60以上の概念をインタラクティブなグラフで探索。

Karpathy LLM Wikiは本当に効果があるのか - 72-runベンチマーク

Thu, 07 May 2026 11:00:00 +0900

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

チョン・ドヒョン - ROBOCO首席コンサルタント

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に変わりました。

手法	トークン（平均）	時間（平均）	品質（25点）
Vanilla（直接read/grep）	755K	167s	15.1
LLM Wiki	350K	101s	16.0
Graphify (GraphRAG)	617K	180s	13.6

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

1. 比較した三つの手法

手法	動作方式	追加で露出した資料
Vanilla	補助ツールなしでファイルを直接read/grep	（なし）
LLM Wiki	LLMがあらかじめコンパイルしておいたマークダウンのwikiを先に読む	`wiki/` 全体 + 引用ルール
Graphify	エンティティ・関係グラフ（GraphRAG）を先に問い合わせる	`graphify-out/` + CLI

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

Ruflo徹底解剖：Claude Codeにマルチエージェント・オーケストレーションを載せるということ

Mon, 04 May 2026 11:30:00 +0900

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

チョン・ドヒョン - ROBOCO首席コンサルタント

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はその背後でエージェントのルーティング、メモリ、スウォーム調整、バックグラウンドワーカー、プラグイン実行を担います。

能力	Claude Code単体	＋Ruflo
エージェント協働	セッション単位、共有コンテキストは限定的	共有メモリ＋合意ベースのスウォーム
調整	ユーザーが作業を分割し統合する	Queen-led階層、topology、consensus
メモリ	セッション中心	AgentDB、HNSWベースのベクトルメモリ
学習	個人セッションの中に閉じこもりやすい	SONA、パターンマッチング、trajectory learning
洞察の再利用	人が文書化しなければならない	プロジェクト／エージェント間のメモリ転移が可能
作業ルーティング	ユーザーが判断	知的ルーティング、ただし定量的な数値は自社主張
バックグラウンドワーカー	なし	12個の自動トリガーワーカー
LLMプロバイダー	主にAnthropic	Claude、GPT、Gemini、Cohere、Ollamaなど

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

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

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

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

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

Rufloがすること

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

Serverless Autoresearch：バイブコーディングでML実験パイプラインをサーバーレス化した記録

Sun, 29 Mar 2026 16:00:00 +0900

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

チョン・ドヒョン - 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ワークロードにも適用可能な運用哲学であることを示しているわけです。

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

区間	内容	費用
初期の成功実験	L40S Spotで最初のend-to-end成功	$0.06
バッチサイズの罠の検証	4回の並列実験で誤った仮説を除去	$0.07
5世代の自律進化	20回の実験で最適パラメータを探索	$0.31
合計	25回の実験	$0.44

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

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

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

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

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

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

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

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

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

OpenClawの5層ゲートキーピング：AIエージェント時代の品質管理

Fri, 27 Mar 2026 00:00:00 +0900

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

チョン・ドヒョン - ROBOCO首席コンサルタント

以前の記事では、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スクリプトを通じて自動的に有効化され、コミットのたびに実行されます。

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

ステージされたファイルを種類別にフィルタリング
oxlint --type-aware --fix — リントエラーを自動修正
oxfmt --write — フォーマットを自動修正
修正されたファイルを再びステージング
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の内部パスを参照したり、パッケージルートの外へ相対パスを伸ばしたりするのを検出します。

バイブコーディング時代、リポジトリ規則と個人の好みの境界

Thu, 26 Mar 2026 17:26:21 +0900

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

チョン・ドヒョン - ROBOCO首席コンサルタント

バイブコーディングを導入したチームは、まもなく似たような問いに直面します。リポジトリごとに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、テンプレート、サンプルコード、個人プロンプト、チームプレイブックのような軽い装置で扱うほうが適しています。そうしてこそ、好みは維持しつつリポジトリの指針が過度に重くならずに済みます。

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

バイブコーディング導入のための組織設計

Fri, 20 Mar 2026 21:23:40 +0900

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

チョン・ドヒョン - ROBOCO首席コンサルタント

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

バイブコーディングはオートコンプリートではなく、働き方の再設計に近いものです。組織のメンバー一人ひとりがより広い領域をカバーし、チーム間のハンドオフとコミュニケーションのコストを減らせるとき、生産性は大きくなります。とはいえ、目標が人員削減だというわけではありません。核心は、同じ組織がより多くのことを、より速く、より安全に届けられるようにすることにあります。そのためには、要求をどう分解するか、どの変更を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

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

バイブコーディングのトークン管理戦略

Thu, 19 Mar 2026 09:00:00 +0900

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

チョン・ドヒョン - ROBOCO首席コンサルタント

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方式の検討
完了条件: 重複ログインの再現テストが通ること

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

OpenClaw：世界最大のバイブコーディングプロジェクトから学ぶ9つのベストプラクティス

Sat, 14 Mar 2026 10:00:00 +0900

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

チョン・ドヒョン - ROBOCO首席コンサルタント

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自身が段階的に内容を追加してきたからです。¹³ 中核となるセクションは次のとおりです。

Everything Claude Code vs Oh My ClaudeCode — チーム/企業導入の観点からの比較

Tue, 27 Jan 2026 09:30:31 +0900

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

チョン・ドヒョン - ROBOCO首席コンサルタント

先行する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)	Oh My ClaudeCode (OMC)
中核の哲学	ツールと指針の提供、ユーザー主導	自動オーケストレーション、システム主導
機能	エージェント/スキル/フックの総合セット、TDD・検証ループ、メモリの永続化	5つの実行モード、32個のエージェント、スマートモデルルーティング
並列処理	なし（逐次実行）	Ultrapilotで最大5倍の加速、Swarmによる協働
使いやすさ	学習曲線あり、スラッシュコマンドを活用	ゼロコンフィギュレーション、自然言語インターフェース
技術スタック	JavaScript 70%、設定ファイル中心	TypeScript 82%、アプリケーションロジック中心
コミュニティ	Star 30k以上、ハッカソン優勝作、初期段階	Star 2.8k、リリース30回、着実な更新
適した状況	品質重視、長期プロジェクト、細やかな制御	素早いプロトタイピング、大規模な並列作業

機能の比較と分析

Everything Claude Code (ECC)

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

企業／ヘビーユーザーの視点で見た、最高のプロダクションレベル・コスパのバイブコーディングツール（2026年1月時点）

Sun, 25 Jan 2026 11:45:52 +0900

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

チョン・ドヒョン - ROBOCO首席コンサルタント

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

先に結論から言うと、この記事を書いている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ドル前後のプランでの制限のかかり方はこれだけ違う

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

ツール	月額コスト	制限のかかり方（要約）	コンテキスト（要約）
Claude Code (Max)	約200ドル	5時間のローリングウィンドウに基づく使用量	200K（1Mベータ）
OpenAI Codex/ChatGPT (Pro)	約200ドル	5時間単位のメッセージ／作業制限	最大400Kクラス
Cursor (Ultra)	約200ドル	月間クレジットプール（使用量を金額に換算）	モデルにより200K〜1M
Amazon Kiro (Power)	約200ドル	月間クレジット（0.01単位の精密な計測）	200K
Google Gemini (Ultra)	約250ドル	1日あたりの作業数（エージェント基準）	1M

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

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

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

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

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

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

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

Oh My Claude Code - Claude Codeを「チーム」として使うプラグイン

Wed, 21 Jan 2026 22:03:59 +0900

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

チョン・ドヒョン - ROBOCO首席コンサルタント

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.」です。¹ 要点は二つあります。

自動委任（delegation-first）：「複雑な作業だ」と言えば、設計／リサーチ／実行／QAといった専門的な役割に分割して並列に走らせます。
自動モード切り替え：「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といった補強レイヤーを重ねる、という具合です。² つまり、モードを「乗り換える」のではなく 振る舞いを「重ね着する」方式 なので、文脈が途切れません。

Everything Claude Code — ハッカソン優勝者のAI開発チームレシピ

Tue, 20 Jan 2026 09:30:07 +0900

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

チョン・ドヒョン - ROBOCO首席コンサルタント

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つです。

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

この哲学を土台に、リポジトリ全体が「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の実行 → コードレビュー → ドキュメント同期」といった一連の開発フローをボタンのように実行できます。

バイブコーディングとセキュリティ：真実か嘘か

Tue, 30 Dec 2025 10:01:21 +0900

チョン・ドヒョン - ROBOCO首席コンサルタント

最近では「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導入ガイド

Fri, 26 Dec 2025 09:16:27 +0900

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

チョン・ドヒョン - ROBOCO首席コンサルタント

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段階へ移りつつあるという流れが見えなければなりません。

LLMプロンプティング：ペルソナ指定とメタ認知方式の違い

Thu, 27 Nov 2025 07:57:49 +0900

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

チョン・ドヒョン - ROBOCO首席コンサルタント

はじめに

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

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. 実務での活用ガイド

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

Claude Code Deep Dive：Claude Codeはどのように実装されているのか？

Tue, 25 Nov 2025 10:05:54 +0900

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

チョン・ドヒョン - ROBOCO首席コンサルタント

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

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

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

TL;DR

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

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段階の緻密なパイプラインを稼働させます。

Tidy First方法論：Kent BeckのAugmented Codingの解釈と適用

Sun, 27 Jul 2025 06:29:39 +0900

チョン・ドヒョン - ROBOCO首席コンサルタント

最近、私は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とともに作業する際に開発者がコードに対する主導権と明確さを維持できるようにしてくれ、コードの品質と複雑さを管理するうえで大きな助けになります。

この方法論は、みなさんのプロジェクトにもきっと効果的でしょう。ぜひ一度試してみることを強くおすすめします。

バイブコーディングとエンジニアリング成熟度の向上、どちらが先か？

Fri, 11 Jul 2025 14:46:42 +0900

チョン・ドヒョン - ROBOCO首席コンサルタント

多くの開発者はバイブコーディングを単に「コードを自動的に生成する方法」だと考えています。ツールに指示を出して待っていれば、素晴らしいコードがさっと出来上がるだろうと期待するわけです。しかし現実はそれほど単純ではありません。自動化されたテストがない環境で、堅牢な設計もなく、機能するレビュープロセスさえないのであれば、バイブコーディングは「ゴミコード」を素早く量産するだけです。

これはツールの問題ではなく、エンジニアリング成熟度の問題です。ソフトウェアエンジニアリングの成熟度とバイブコーディングは互いを補完します。エンジニアリング成熟度が高い環境でこそ、バイブコーディングは本来の力を発揮できるのです。

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）アプローチによって、バイブコーディングがもたらすコードの品質とスピードを最大化できるでしょう。

バイブコーディング時代の採用戦略

Sun, 06 Jul 2025 19:04:33 +0900

チョン・ドヒョン - ROBOCO首席コンサルタント

いよいよバイブコーディングの時代が幕を開けようとしています。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の決断があってこそ、企業全体が変化に追いつき、先んじることができます。

エージェンティックコーディング推奨事項の解説

Tue, 17 Jun 2025 13:38:18 +0900

チョン・ドヒョン - ROBOCO首席コンサルタント

この記事は、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は自身の記事の中で、エージェンティックコーディングを効果的に活用するための助言を数多く示しています。プログラミングの基礎程度を知る読者にも理解できるよう、彼の主な推奨事項を一つずつ解きほぐして説明します。

単純で安定した言語の選択：エージェントが扱う言語を選べるのであれば、可能な限り単純な言語を選ぶようArminは勧めています。彼は新しいバックエンドプロジェクトの場合にGo言語を強く推奨しましたが、その理由は明確です。Goは文法が単純で予測可能なため、エージェント（LLM）がミスをする余地が少なく、テストの実行も自動で一度にうまく動作するからです。たとえばGoではgo testコマンドで必要なテストを一度にまとめて回せます。エージェントがテスト対象の選定で混乱することがありません。またGoのエコシステムは変化が遅く後方互換性が良いため、AIが古い例示コードを生成する危険が小さいのです。一方、Pythonのようにマジック（magic）の多い動的言語では、エージェントが隠れた挙動を誤解したり、実行環境の問題で試行錯誤しやすいといいます。したがって、言語自体が単純で環境の変化が少ないほど、エージェントはより安定してコードを扱えます。
エージェントに優しい開発ツールの設定：言語と同じくらい、開発ツール（tool）をどう整えるかも重要です。Arminの助言は「ツールは何でも構わないが、必ず速く明確に動作しなければならない」というものです。エージェントは皆さんの環境でbashコマンド、ビルドツール、テストランナーなどを実行することになりますが、反応が遅かったり出力が不必要に冗長なツールは避けるべきです。たとえばArminは自身のプロジェクトでMakefileを活用し、よく使うコマンドを整理しています。make devで開発サーバーを立ち上げ、make tail-logでログを見るという具合です。重要なのは、エージェントがこうしたツールを使う際にエラーが出たら即座に知らせ（logging）、重複実行を防ぐといった保護の仕組みも必要だという点です。実例として、Arminはプロセス管理ツールを修正し、すでにサーバーが実行中であれば二度目を立ち上げられないようにし、その代わり「すでに実行中」というエラーを明確に出力するようにしました。おかげでエージェントはmake devを実行したときにサーバーがすでに動いているかを判断し、すぐにログを確認する次のステップへ進むことができました。

そしてログ（logging）そのものをエージェンティックコーディングの核心的なツールとして活用するよう、Arminは繰り返し強調しています。たとえば会員登録時に認証メールを実際に送る代わりに、開発モードではメールの内容をコンソールログに出力しておけば、エージェントがそのログを読んで認証リンクを自動的に見つけてクリックできます。Arminは自身のCLAUDE.md設定ファイルに「デバッグモードではメールがログに出力される」という情報を入れておき、Claudeエージェントはそれを参照して、実際に会員登録から認証までを自ら完了させました。このように、明確なログと親切なツールの出力はエージェントの目と耳になってくれます。私たちが開発するときにコンソールやログを見ながら問題を把握するのと同じく、エージェントもログを通じて状況を理解し、次の行動を決めるからです。

速度と効率の最適化：エージェンティックコーディングのボトルネックは、主にAIモデルの推論コストと非効率なツールの使用から生じます。したがって応答速度を上げ、不要なトークンの浪費を減らすことが重要です。上で述べたとおりツールの迅速な実行が基本であり、さらにエージェントが新たに書いて実行するコード（「emergent tool」）もできる限り軽く作るべきです。たとえば、エージェントがある作業のために一時的なPythonスクリプトを書いて回すとしましょう。このときそのスクリプトの実行に5秒かかり、実行のたびに初期化で1分ずつ消費するとすれば、全体の流れは大きく遅くなります。Arminは実際の業務プロジェクト（Sentry）で、エージェントがコードをリロードするのに時間がかかりすぎたため、一時的に「ファイルの変更を検知して自動的にモジュールをimportし、結果をログに書く」デーモンを作り、エージェントに活用させたといいます。複雑な再起動なしに素早くコードを注入して実行結果だけを確認させたわけです。このような創造的な方法で、できる限りリアルタイムに近いフィードバックを返すよう環境をチューニングすれば、エージェントの作業効率は上がります。またログもあまり冗長だとトークンを食い速度を落とすので、重要な情報だけを含むよう適切な水準に調節するのがよいと助言しています。
安定性と最小驚きの原則：Arminは「安定したエコシステム」の価値を繰り返し言及します。AIがコードベースを扱うとき、外部の変化が少ない環境でははるかにミスが減ります。たとえばLLMエージェントはGoやFlaskのような長く検証された技術スタックを好みます。逆に、依存関係が激しく変わるJavaScriptエコシステムのように、毎日新しいバージョンとライブラリが押し寄せる環境では、AIが数日前のコードを参照して誤ったコードを生成する危険が高くなります。またエージェントは、コードを書きながら決定した理由をコメントとして残すなど、自分なりの痕跡（breadcrumb）を残す傾向がありますが、私たちが何気なく依存ライブラリを最新バージョンに上げてしまうと、そうしたコメントやコードパターンはたちまち古いものになり、AIの思考の流れに混乱を与えかねません。人間も同じですが、AIは「どうせテストが通ればいいのでは」という気持ちで手軽にアップグレードを試みることがあるので、特に注意が必要です。Arminの助言を一言で言えば「以前よりもさらに保守的にアップグレードせよ」ということです。そして新しいライブラリをあまり使わず、可能なら直接コードで実装するほうがよいとも述べています。どうせエージェントが素早くコードを作ってくれるのだから、複雑な依存関係を持ち込む代わりに必要な機能は自分で書き、一貫性と予測可能性を保てという意味です。実際にArminは「なぜ自分でコードを書くべきか」という題の記事を以前書いており、エージェンティックコーディングをやってみてその考えがより確固たるものになったといいます。
コードは可能な限り単純に：「複雑なコードはエージェント環境で性能が出ない。最も愚かに見えるが動く解決策を選べ」——Arminが強調した一文です。エージェントがコードを扱うときは明瞭さが最優先です。したがって開発者は普段よりもさらに直截的で単純なコードスタイルを追求すべきです。たとえば複雑なクラス継承よりも、長く具体的な名前の関数を複数作るほうが理解しやすくなります。あまりに抽象的なパターンやマジック（マジックナンバー、リフレクションなど）を乱発すると、AIは文脈を見失いやすくなります。Arminは「普通のSQLクエリを直接書け」とまで助言します。ORMなどを通じて間接的にデータベースを扱うより、いっそエージェントにSQLを書かせたほうが、AIがログのSQL出力と自分のコードをすぐに対応づけてデバッグしやすくなります。また権限チェックのような重要なロジックは、可能な限り当該コードの近くに置くべきです。もし権限検査が設定ファイルやデコレータに隠れていると、エージェントが新しい機能を追加する際にその部分を見落とし、セキュリティホールを作るおそれがあります。結局、「単純明瞭で一貫したコード」がエージェントにも人間にも良いコードだ、ということです。
並列化（Parallelization）を念頭に置く：エージェント一つでは非常に速いわけではありませんが、複数を同時に走らせれば作業を並列処理して効率を高められます。たとえば数百個のファイルのlintエラーを一度に直さなければならない場合、一つのエージェントが順番に処理する代わりに、複数のエージェントにそれぞれ一部のファイルを任せるという具合です。そのためには、共有資源（ファイルシステム、DBなど）の衝突を最小化できるようプロジェクトを構成する必要があります。簡単なことではありませんが、ArminはDockerを用いた隔離実行ツールや、CI（継続的インテグレーション）環境でバックグラウンドエージェントを走らせるなど、初期の試みが出てきていると紹介しています。現在は自身のワークフローに完全には適用できていないものの、まもなく急速に発展する分野だと見通しており、遠からず実用化される可能性があります。
適時にリファクタリングする：エージェンティックコーディング環境では、リファクタリング（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アシスタントとして使うこともできます。

AIでアーキテクチャ図を描く

Sat, 14 Jun 2025 12:35:06 +0900

チョン・ドヒョン - ROBOCO首席コンサルタント

バイブコーディングをするとき、人はしばしばコードさえあれば十分だと考えがちです。しかし現実は違います。文書化のないコードは、地図を持たずに出かける旅のようなものです。目的地がどこなのか、道のりがどうなっているのかが分からなければ、誰も一緒に来てはくれません。バイブコーディングにおいて文書化が特に重要なのは、コードが単に動作するためのものではなく、アイデアと設計の意図を他の人に正確に共有するためのものだからです。文書化は協働を滑らかにし、プロジェクトの方向性を明確にし、ひいては持続可能な開発環境を築く土台になります。

私は文書化の作業をコードと一緒に管理する方式を強くおすすめします。特に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ではまだこの最新機能がサポートされていないため、先ほど説明した方法が当面は最も有用なアプローチになるでしょう。

良い文書は単なる説明書にとどまらず、協働の質を高め、長期的にプロジェクトの価値を持続させます。バイブコーディングにおいて文書化は選択ではなく必須です。

バイブコーディングのレビュー戦略

Sat, 07 Jun 2025 12:21:04 +0900

チョン・ドヒョン - ROBOCO首席コンサルタント

バイブコーディングを導入すると開発のさまざまな領域が自動化され、生産性が向上するのは事実です。しかし、結果に責任を負うレビューは人間がやらなければならないため、結局レビュー（ドキュメントレビュー、計画レビュー、コードレビューなど）でボトルネックが発生します。今日はレビューについて話してみたいと思います。

TL;DR

バイブコーディングは生成の速度を上げますが、コード・ドキュメント・計画のレビューがそのままなら、ボトルネックはレビュー段階へ移動します。
レビュー品質を高めるには、承認の責任を明確にし、チェックリストとリスク表示によってレビュアーが能動的に判断するようにしなければなりません。
自動化が増えるほど人間のレビューはより責任ある形で設計される必要があり、小さな行動にも意味と責任を与える構造が求められます。

まずはコードレビューの話から始めましょう。

コードレビューでボトルネックが生じるのは、たいていレビュアーが責任をあまり感じていなかったり、受動的にボタンを押すだけになっていたりするからです。これを改善するには、「承認ボタンを押せばコード品質に共同で責任を負うことになる」という明確なルールを作るとよいでしょう。承認の前にレビュアー自身が「このコードの品質と安全性をすべて確認しました」という誓約文を確認するようにすれば、心理的な責任感は確実に高まります。

また、レビューする項目をチェックリストとして整理し、レビュアーに細かく検討させる方法も効果的です。コードレビューで性能、セキュリティ、コードスタイルなどを項目ごとに点検すれば、見落としなく体系的にレビューできます。実際、一度のコードレビューを400行以下に制限してチェックリストを活用すると、欠陥の発見率が大きく高まると言われています。この方法は実際に多くの企業で成果を上げています。

開発者に対して、レビュー時のリスクや重要性を強調して提示するのもよいでしょう。「この変更は決済システムに関わるので、非常に慎重に見なければならない」といった文言を入れておけば、レビュアーは適当に流さず、より責任を持って向き合うようになります。さらに、レビューで発見されずに問題へつながった実際の事例を共有すれば、レビュアーは自分の役割がどれほど重要かを実感し、いっそう注意を払うようになります。

社会的比較や称賛の文化もよい方法です。「レビュー活動が最も活発な開発者」を選んだり、レビューを通じて欠陥を捕まえた事例を称賛して表彰する小さなイベントを開いたりするのも効果があります。レビュー活動をゲームのように仕立てて協力的で楽しいものにすれば、開発者はレビュー作業そのものを達成のプロセスとして受け止めるようになります。

ドキュメントレビューも同じです。ドキュメントをレビューする際に、開発者が技術的なシナリオや性能上の問題、エラー処理のシナリオなどをチェックリストで細かく検討すれば、レビューの質は高まります。また、レビュー開始前に「今回のドキュメントでは最低でも一つは改善点を必ず見つけよう」といったルールを基本として設定しておけば、開発者はレビューの過程で能動的に意見を出すようになります。開発者があらかじめドキュメントを読んで参加できるよう、簡単な質問票を渡すのもよい方法です。

計画レビューでは、開発者が現実的な観点を提供することが重要です。企画が過度に楽観的なとき、開発者が「最悪のシナリオは何か？」といった問いを通じて現実的なリスク要因を引き出すよう促すと効果的です。レビュー後、意見が実際のプロジェクトにどう反映されたのか、フィードバックを共有することも重要な要素です。レビューの結果が現実でどう作用したのかを知ることで、次のレビューにはより真剣に臨むようになります。

結局レビューというものは、責任感と参加度がすべてです。バイブコーディングの時代に自動化が増えるほど、人間の責任あるレビューはいっそう重要になります。ですからレビューを設計するときに人間の行動心理をうまく活用すれば、自然とレビュー品質と生産性を高めることができます。大切なのは、小さな行動一つにも意味を与え、責任を感じさせることです。そうすればレビューのボトルネック緩和に役立つだけでなく、品質も向上するでしょう。

バイブコーディングとXY問題

Fri, 06 Jun 2025 09:56:25 +0900

チョン・ドヒョン - ROBOCO首席コンサルタント

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が追求するバイブコーディングの核心戦略は、どうすれば最小限の労力で「意図」を明確に伝えられるかということなのです。

バイブコーディングの弱点と長所

Mon, 02 Jun 2025 10:40:26 +0900

チョン・ドヒョン - ROBOCO首席コンサルタント

先のバイブコーディングの生産性についての記事でも述べたとおり、バイブコーディングの生産性は二つの要素に大きく左右されます。一つは人の生産性、すなわち開発者の問題解決能力と分析能力です。もう一つは、それを補完し強化するツールやプロセスの生産性です。ここでいう生産性とは、単にコードを速く書く能力だけを指すものではありません。計画を立て、問題を分析し、解決策を見つけるという全般的な力量までを含みます。

TL;DR

バイブコーディングの生産性は、AIツールの性能だけでなく、開発者の問題分析力と作業設計能力に大きく左右されます。
仕様が明確な作業、移植（ポーティング）、入力と出力がはっきりしたスクリプト的な作業では、とりわけ強みを発揮します。
何を作るのかが不明確な作業や、コンテキストが複雑な作業では、人の判断と範囲の限定が依然として重要です。

私は実際にいくつものプロジェクトを進めながら、バイブコーディングが得意な作業とそうでない作業を経験的に分類してみました。どんな仕事であれ、ツールが得意なことと不得意なことを知っておくのが大切です。うまく活用するには、ツールの特性をよく知る必要があるということです。

まずは、バイブコーディングがとりわけ得意な作業から見ていきましょう。

第一に、仕様が明確に定義された作業です。バイブコーダーが細部のすべてを把握していなくても、作業の内容と進行順序がきちんと文書化されていれば、AIは驚くほど正確な成果物を出してきます。明確な文書化こそが、AIの能力を最大限に引き出す鍵というわけです。

第二に、移植作業です。すでに別の言語やプラットフォーム、フレームワークで完成しているプロジェクトがあれば、そのコード自体が完璧な仕様書の役割を果たします。AIは既存コードを参照して、高い完成度で移植作業を素早く進められます。とくに既存プロジェクトに自動化されたテストが不足している場合は、AIを使って単体テスト（UT）、結合テスト（IT）、エンドツーエンドテスト（E2E）を先に生成し、それを移植対象のプロジェクトに適用すれば、はるかに正確かつ効率的に作業を進められます。

第三に、簡単なスクリプトやユーティリティの作業です。入力と出力が明確に決まっている作業であれば、AIはまるで光の速さで仕事をこなします。使い捨ての作業であっても、テスト駆動開発（TDD）の方式を取り入れれば、速く進めながら信頼性も高められます。

しかし、すべての仕事がそれほど単純なわけではありません。バイブコーディングが不得意な作業もあります。

第一に、何を作るべきかが不明確な作業です。ソフトウェア開発ではしばしばあることで、実際の実装過程を通じて少しずつ仕様を改善しながら進めなければならない作業があります。DevOps関連のツールや、複雑なワークフローの設計がその例です。こうした作業は、ChatGPTのような対話型AIサービスを通じてさまざまな状況をAIとの対話でシミュレーションしながら方向性を定めたうえで実装するのが賢明です。

第二に、複雑なコンテキストを抱えた作業です。とくに複雑なリレーショナルデータベースを備えたモノリシックアーキテクチャのようなプロジェクトは、コンテキストが膨大で入り組んでおり、人ですら迷い込みやすいものです。理想的にはマイクロサービスの形に分割して作業するのがよいのですが、現実的には難しい場合も少なくありません。そんなときは、プロンプトエンジニアリングによってAIが処理するコンテキストの大きさを制限する方法があります。作業ごとに関連する文書やコードだけを選び、ルールファイルとして与える方式です。もちろん作業のたびにルールを動的に更新しなければならない手間はありますが、最近はTaskMaster AIやBMAD-METHODのようなツールが登場し、この部分まで自動化できるようになりつつあります。

このように、バイブコーディングを効果的に活用できるかどうかは、結局のところAIと人が互いの強みと弱みをよく理解して使いこなせるかにかかっています。明確に定義された作業ではAIの処理の速さと正確さが光りますが、複雑で曖昧な作業では人の判断力と分析力が依然として重要です。

今この瞬間にも、世界中のバイブコーダーが絶えず実験を重ねています。すでにバイブコーディングで作れる作業は実際に実装されており、まだ実現していない複雑な問題についても、解決しようとする試みが途切れることなく続いています。ツールには限界があるかもしれませんが、そのツールを活用する人間の創造力と挑戦する精神に限界はありません。

AI、私の仲間になれ！

Sun, 25 May 2025 07:30:47 +0900

チョン・ドヒョン - ROBOCO首席コンサルタント

去る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人の人材が複数の開発者、マネージャー、プロダクトプランナーの役割まで兼ねられるようになるからです。

AIの脅威はもはや現実です

一方、非テック企業は、これほど大きな変化が世に登場したという事実すら知らない場合が少なくありません。テック企業だからといって状況が大きく違うわけでもありません。Business Insiderは、2024年6月ごろ、Amazon Web Services（AWS）のトップであるマット・ガーマン（Matt Garman）氏が従業員との対話の中で「24か月後にはほとんどの開発者がコーディングをしなくなる可能性がある」と発言したと報じました。私は、この発言はあまりにも呑気な楽観だったと思います。すでにその時期には、Cursorが開発者の間で口コミによって急速に広まっていたからです。

テック企業だけでなく、あらゆる既存企業が、これからバイブコーディングを武器に挑んでくるスタートアップから深刻な脅威を受けることになります。ここでAIを単なる脅威とみなすなら、企業と開発者の生存期間は短くならざるを得ません。AIの脅威を猛獣から逃げる状況にたとえるなら、食べられないためには隣の人より速く走りさえすればよい、と考えることもできます。ただしそれは時間稼ぎにすぎず、結局は食べられる運命だという点に変わりはありません。

しかし、AIと同じ側に立つとしたらどうでしょうか。AIは開発者だけでなく、あらゆる役割において、自分の持つ能力を増幅してくれる道具になり得ます。

もはやバイブコーディングは選択肢ではありません。生存のための必須戦略です。

AIに「開発者の頼もしい仲間になったAIロボット」を描いてほしいと頼んだところ、頼んでもいない猫を添えてくれました。やはり開発者には猫ですよね！

バイブコーディングの生産性方程式

Wed, 21 May 2025 08:56:24 +0900

チョン・ドヒョン - ROBOCO首席コンサルタント

私はよく開発者からこんな質問を受けます。「私はこうやって開発しているのですが、これはバイブコーディングで合っていますか？」正直かなり戸惑います。なぜ韓国の人はとりわけ、宗教的原理主義のように基準に合わせることを好むのでしょうか。重要なのは、バイブコーディングをうまく実践できているかどうかではなく、バイブコーディングがどれだけ生産性の向上に役立っているかです。

また、こんな質問もよくあります。「プログラミングをまったく知らなくても、本当にバイブコーディングはできるのですか？」今日はまさにその話をしてみようと思います。

バイブコーディングとは、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バイブコーディングは万能ではありません。それは魔法ではなく、開発者の力量とツールの力を最大化する一つの開発手法にすぎません。ですから生産性の向上のためには、開発者の力量とともに、ツールとプロセスを改善することに集中してください。

バイブコーディング成熟度の尺度

Fri, 16 May 2025 09:06:12 +0900

チョン・ドヒョン - ROBOCO首席コンサルタント

最近、開発者の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の助けを借りて、より効率的に行われます。今後数年以内に、開発者がコードを直接触るケースは大きく減るか、ほとんどなくなるでしょう。現在のシニア開発者が担っている業務が一般化するということです。

バイブコーディングはもはや単なるツールではなく、開発のやり方そのものを変える大きな流れになりました。しかし、誰もが同じやり方と水準でバイブコーディングを使っているわけではありません。この記事がそれぞれの成熟度を推し量り、次の段階へ進むうえでの小さな道しるべになれば幸いです。

Clineの勢いが尋常ではない

Thu, 15 May 2025 08:08:46 +0900

チョン・ドヒョン - ROBOCO首席コンサルタント

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に注目する理由は十分にあります。

バイブコーディングの技術

Sun, 04 May 2025 11:59:09 -0700

チョン・ドヒョン - ROBOCO首席コンサルタント

バイブコーディング（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時代の強力な思考法として浮上しました。しかし、直感だけでは足りません。このゲームは結局のところ、収束をうまく調整する仕事です。単純化し、自動化し、明確に方向を示してください。そうすれば、モデルは正しい道を見つけ、自ら「バイブ」に乗ることでしょう。

ソフトウェア開発に特化したGPT-4.1がリリース

Tue, 15 Apr 2025 07:22:08 +0900

チョン・ドヒョン - ROBOCO首席コンサルタント

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のイベントを活用して、コスト負担なくバイブコーディングに入門してみてください。

Googleプロンプトエンジニアリング白書のバイブコーディング関連内容まとめ

Sun, 13 Apr 2025 08:32:57 +0900

チョン・ドヒョン - ROBOCO首席コンサルタント

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へ説明し、混乱を防ぎます。

肯定的な指示を使う

「してはいけないこと」よりも「すべきこと」を中心に指示します。たとえばコードを書かせるときは、制限事項よりも目標を明確に伝えます。

変数を活用したプロンプティング

繰り返し使えるプロンプトを書き、変数を通じてコードの再利用性と保守性を高めます。

プロンプティングの形式とスタイルの多様性を実験する

さまざまな表現・文体・指示スタイルを試し、最も効果的なプロンプティングの方法を見つけます。

プロンプティングの結果を文書化して体系化する

さまざまなプロンプティングの試行を記録し、うまくいった事例を特定してプロンプティングの品質を継続的に改善します。

バイブコーディングとの関連の整理

この文書で示されているコードプロンプティングの手法は、バイブコーディングの中核概念と非常に密接に結びついています。

バイブコーディング時代に開発者が備えるべき特性

Fri, 11 Apr 2025 12:21:17 +0900

チョン・ドヒョン - ROBOCO首席コンサルタント

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（最高水準の基準を求める）

バイブコーディングでは韓国語より英語のほうがうまく動作するのか？

Fri, 04 Apr 2025 08:12:04 +0900

チョン・ドヒョン - ROBOCO首席コンサルタント

バイブコーディング（Vibe Coding）、つまりGPTのような大規模言語モデル（LLM）を使って開発する方式について、よく聞かれる質問が一つあります。「このモデルと韓国語で対話するときと英語で対話するときとで、作業の品質に違いはあるのか？」という点です。結論から言えば、私の経験からも、LLMの動作原理から見ても、言語そのものによって作業の質が変わることはありません。

TL;DR

韓国語と英語のどちらがより良い結果を出すかよりも重要なのは、トークン効率です。
韓国語は同じ内容を伝えるのにより多くのトークンを使うことがあり、コスト、速度、そして渡せるコンテキストの量に影響を与えかねません。
大規模プロジェクトやルールファイルのように繰り返し入力されるドキュメントは、英語で簡潔に管理する戦略を検討する価値があります。

まず原理を簡単に見ておきましょう。LLMは入力されたテキストをトークン（token）という単位に分割し、それらのトークンをもとに次の内容を予測しながら作業を実行します。英語は一般に単語または単語の一部が一つのトークンに分割されますが、韓国語は音節や形態素の単位でより細かく分割されます。

たとえば「Hello」は通常1つのトークンが使われますが、「안녕하세요」はLLMサービスの内部動作によって差はあるものの、「안」「녕」「하세요」のように複数のトークンに分割される可能性が高いのです。

とはいえ、これが作業の品質に影響を与えるとは考えにくいでしょう。結局のところLLMは、入力された内容を理解し文脈を把握する過程で、言語の違いをかなりうまく乗り越えるからです。

しかし、注目すべき点は別にあります。それがトークン使用量です。英語は比較的簡潔にトークンが消費される一方、韓国語は同じ内容を伝えるのにもより多くのトークンを必要とします。これは単なるコストの問題にとどまらず、プロンプトの処理速度や、渡せるコンテキスト全体の大きさにも影響します。

特にバイブコーディング環境で使う.cursorrules（Cursor）、.windsurfrules（Windsurf）、CLAUDE.md（Claude Code）のようなルールファイルは、モデルとやり取りするたびに繰り返し入力されるため、これらのルールを最適化することが非常に重要になります。言語を選ぶという問題は、ここで実質的な意味を持ちます。ルールやドキュメントをより簡潔な言語で整理すれば、不要なトークン消費を減らし、より多くのコンテキストを渡せるようになります。

ほとんどの開発作業では、実のところ韓国語で進めたからといって大きな問題が生じることはありません。しかし大規模プロジェクトや複雑なコンテキストを扱わなければならない場合であれば、英語の使用を一度検討してみるのも良いアプローチになりえます。トークン使用を最小化しながら、より速く効率的なバイブコーディング環境を構築できるからです。

結局、韓国語と英語のどちらがより「うまく」動作するのかという問いの本質は、作業の品質ではなく効率性の問題として捉えるべきです。コストと速度、効率的なコンテキスト管理が必要な状況であれば、英語でプロンプトとルールを書く戦略が賢明な選択となるでしょう。

MCPはバイブコーディングに必須なのか？（feat. CLI）

Tue, 01 Apr 2025 10:28:00 +0900

チョン・ドヒョン - ROBOCO首席コンサルタント

最近の開発者コミュニティを眺めていると、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に既存のインターフェースを活用させることがいくらでもできるのです。

バイブコーディングについての真実、あるいは嘘

Thu, 27 Mar 2025 10:18:33 +0900

チョン・ドヒョン - ROBOCO首席コンサルタント

私は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のためのプログラミング言語やフレームワークが登場する可能性すらあります。

最後に、バイブコーディングは大企業では使えないのでしょうか？ バイブコーディングの普及は、クラウドコンピューティングの導入と似た様相を見せると予想しています。大企業の立場からすると、バイブコーディングを素早く導入するのは容易ではないでしょう。しかし時間が経つにつれ、コンプライアンスのような問題はクラウド事業者が解決策を提供してくれるはずです。技術に対するインサイトを持つ企業は可能性を確かめ、導入を急ぐでしょう。大企業に比べて身軽なスタートアップは、すでに速いスピードでバイブコーディングを導入しています。とはいえ、ビジネスの問題を定義し解決することは、依然として人の役割です。

まとめると、バイブコーディングは一時的な流行ではありません。まだ足りない部分はあるものの、非常に強力な可能性を秘めており、絶えず進化しています。重要なのは、これを理解し正しく活用できる私たちの姿勢です。

Vibe Codingマニュアル：AI支援開発のためのテンプレート

Tue, 11 Mar 2025 06:52:53 +0900

（バージョン1.0 – 2025年3月）

この記事は、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つの核心的な柱に基づいています。

仕様（Specification）：目標を定義します（例：「ログイン機能付きのTwitterクローンを構築する」）。
ルール（Rules）：明示的な制約条件を設定します（例：「Pythonを使う、複雑さを避ける」）。
監督（Oversight）：プロセスを監視・調整し、一貫性を保証します。

このマニュアルは、Bermanの土台の上に、YouTubeのコメント（u/nufh、u/robistoccoなど）とRedditのスレッド（u/illusionst、u/DonkeyBonkedなど）から得たコミュニティの知見を統合し、あらゆるレベルの開発者に向けた包括的なフレームワークを提供します。

このフレームワークが有用な理由

AIモデルは強力ですが、過剰なエンジニアリング、スコープ拡大、コンテキスト喪失といった混乱に陥りやすいものです。このマニュアルは次の問題を解決します。

混沌の制御：ルールへの厳格な遵守を強制し、逸脱した振る舞いを最小化します。
時間の節約：構造化されたステップと要約により、手戻りを減らします。
明確さの提供：技術者でない利用者でも容易に追随でき、プログラマーは精密な制御を得られます。

主な利点

明確さ：ルールがモジュール式に構成されており、参照や調整が容易です。
制御：利用者がAIの作業の速度と範囲を直接指示します。
拡張性：小さなスクリプト（例：電卓）から大規模アプリ（例：Webプラットフォーム）まで適用できます。
保守性：文書化と追跡により、長期的なプロジェクトの存続性を保証します。

マニュアルの構成：どのように組み立てられているか

このフレームワークは、.cursor/rulesディレクトリ（または.windsurfrules）に置く、それぞれ固有の目的を持つ4つのファイル（またはセクション）で構成されます。

コーディング選好 – コードのスタイルおよび品質基準を定義します。
技術スタック – ツールおよび技術を明示します。
ワークフロー選好 – AIのプロセスと実行を管理します。
コミュニケーション選好 – 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がプロジェクトの途中でツールを切り替えるのを防ぎます。

ソリューション

Mon, 17 Feb 2025 20:08:42 +0900

経営全般にAIが統合されるよう、ROBOCOが伴走します

AIは人間の代わりになるものではなく、能力を数十倍に増幅させてくれるものです。ROBOCOは、この増幅効果を貴社が直接享受できるよう、コンサルティングと教育とソフトウェア開発を総合的に提供します。

AIブートキャンプ — はじめの一歩

AI活用を初めて始める企業のためのサービスです。貴社の中核人材がAIを活用して業務全般の生産性を高め、自らソフトウェアを作り運用できる能力を身につけられるよう教育します。

こんな企業に適しています

アイデアはあるが技術チームがないスタートアップ
AI活用を始めたいが、どこから手をつければよいか分からない企業
外注依存から脱却し、内部能力を育てたい企業

提供内容

経営・業務にAIを活用する実践教育(意思決定、分析、コミュニケーションなど)
バイブコーディング実践教育(開発者/非開発者の分離トラック) — 開発者はAIを同僚として活用して開発速度を高め、非開発職は反復業務を自ら自動化して運用時間を削減することが目標です
AIツールの選定および業務別ワークフロー構築支援
最初のプロトタイプ/MVPを顧客自身が作るハンズオンワークショップ
クラウドインフラの基礎セットアップガイド
その後、顧客組織が自ら運用・改善できるガイドラインとチェックリストを提供(監査・コンプライアンスのような規制環境がある領域では、内部人材が匿名化・検証・回答品質管理を反復運用できるよう定着させます)

実際の適用事例

ブートキャンプの目的は講義を聴くことではなく、顧客チームが自らAIを同僚として活用し、自分たちの業務を自動化・改善できるようにすることです。

バイブコーディングワークショップカリキュラム — シニア開発者と非開発職を分離したトラックで扱い、開発者はAIを同僚として活用して開発速度を高め、非開発職は反復業務を自ら自動化して運用時間を削減します。
Challenge Driven Learning — HR担当者・ピープルマネージャー・受講者・運用者の4つの役割を明示的に分離した教育プラットフォーム。現場の課題を持ち込み、学習成果が組織レベルで測定・定着するようにすることで、教育予算が費用ではなく資産として残るよう設計しました。
グローバルサービス企業の韓国法人によるK-FSI監査対応支援 — ポリシー・エビデンス整理・回答書作成ワークフローをAIと共に設計し、監査人からの質問への対応時間と一貫性を向上させ、内部人材が匿名化・検証・回答品質管理を自ら運用できるガイドラインを定着させることで、コンプライアンスリスクを構造的に低減しました。(認証準備の全過程にわたる専任支援は、下記の認証・コンプライアンスコンサルティングをご参照ください)

ROBOCOの役割: コーチ。貴社が自ら行い、ROBOCOは隣で教え、修正します。

AIパートナーシップ — 共に成長する

AI活用を始めたものの、より深い挑戦が必要な企業のためのサービスです。貴社が主導するAIトランスフォーメーションの旅路において、技術的な難関を共に突破します。

こんな企業に適しています

AI活用を始めたが、拡大に苦戦している企業
レガシーシステムの刷新が必要だが、方向性が定まらない企業
内部チームのAI能力を体系的に高めたい企業

提供内容

顧客の内部人材とのペアプログラミング/ペア設計(顧客主導、ROBOCOが補助)
レガシーシステムのモダナイゼーション戦略策定および実行支援
AIベースの業務自動化設計教育および実装支援
技術的意思決定における助言およびリスク評価
社内AIチャンピオンの育成 — 全開発者を対象とした導入論、シニアリーダー向けのモダンSWエンジニアリング、終日開催の導入ワークショップへとつながる多段階プログラム(国内セキュリティソフトウェアグループ企業の事例)のように、リーダーと実務担当者が同じ言葉で変化を主導できるよう、組織規模に合わせてAIチャンピオンを養成
週次定例ミーティング: 進捗レビュー、方向性の調整、つまずいている部分の解決

実際の適用事例

パートナーシップの目的は、顧客がハンドルを握ったまま、より大きな変化を素早く生み出せるよう、隣に寄り添うことです。

国内セキュリティソフトウェアグループ企業へのバイブコーディング導入コンサルティング — 開発者70名を対象とした「バイブコーディングの現在地」導入論セッション、シニアリーダー20名を対象としたモダンSWエンジニアリングセッション、そして終日開催の導入ワークショップへとつながるWhy・What・Howの3段階プログラムを設計・運営。リーダーと実務担当者が同じ言葉で変化に合意できるようにし、組織全体のAI導入速度と一貫性を共に高めたチェンジマネジメントプロジェクトです。

ROBOCOの役割: シニアパートナー。貴社がハンドルを握り、ROBOCOは助手席でナビゲーションします。

AIトランスフォーメーションアドバイザリー — 組織全体を変える

組織全体のAI変革が必要な中堅~大企業のためのサービスです。経営陣と共に戦略を策定し、経営全般——戦略、マーケティング、運営、開発——にAIが統合されるよう、体系的に変化を導きます。

こんな企業に適しています

AI変革戦略は必要だが、どこから始めればよいか分からない企業
全社的にAI能力を高めたい企業
技術スタックのモダナイゼーションと組織文化の変革を同時に推進したい企業

提供内容

経営全般のAI統合戦略策定およびロードマップ作成(経営陣ワークショップ)
部署別のAI活用機会の発掘と優先順位付け(Persona Insightのようにマルチ LLM並列分析と4次元スコアリングを活用し、データに基づく優先順位決定を支援——専任のデータサイエンス組織がなくても可能)
全社的なAI活用教育プログラムの設計および運営(経営陣~実務担当者)
AI導入PoCを顧客チーム自身が実行できるよう支援 — 専任のクラウド研究チームがなくても、S3の多目的活用、SageMaker Spot、マルチLLM分析、サーバーレスLLMエージェントといった高度なパターンを小さな実験単位で検証できるようサポートします
内部AI CoE(Center of Excellence)構築支援
四半期ごとの経営陣ブリーフィングおよびロードマップレビュー

実際の適用事例

アドバイザリーの目的は、経営陣が方向性を決定する際に必要な情報と実行方法を共に提供することです。その根拠を、ROBOCOは顧客PoCだけでなく、AIを研究員として活用した自社実験からも直接生み出します。

ROBOCO（Robot Co-worker）のご紹介

Mon, 17 Feb 2025 11:47:08 +0900

ROBOCOと一緒に、革新を現実にしてみませんか？

「うちの会社も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・クラウドの革新と実質的な組織力量の強化を通じて、御社のビジネスを新たな次元へと飛躍させる経験を一緒につくっていきましょう。

ROBOCOがサポートします

Mon, 01 Jan 0001 00:00:00 +0000

AIは人間の代わりにはなりません。貴社チームの能力を数十倍に増幅させます。

お問い合わせ

Mon, 01 Jan 0001 00:00:00 +0000

ROBOCOへのお問い合わせがございましたら、いつでもお気軽にご連絡ください

ROBOCO

意外にも9倍安いラルフループ - コンテキストキャッシングの経済学

チョン・ドヒョン - ROBOCO首席コンサルタント

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

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

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

認知負債 - バイブコーディング時代の新しい負債管理法

チョン・ドヒョン - ROBOCO首席コンサルタント

人を挟めば解決するのか

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

第一に、小テスト

第二に、文芸的コードdiff

第三に、叙述型の文書

プロダクト

ROBOCOが作る、バイブコーディング時代のツール群

Intent Engineering

こんな方に役立ちます

リンク

VAF — Vibe Adoption Framework

こんな方に役立ちます

リンク

VDLC — Vibe-Driven Development Lifecycle

こんな方に役立ちます

リンク

VibeMap

Karpathy LLM Wikiは本当に効果があるのか - 72-runベンチマーク

チョン・ドヒョン - ROBOCO首席コンサルタント

TL;DR

1. 比較した三つの手法

Ruflo徹底解剖：Claude Codeにマルチエージェント・オーケストレーションを載せるということ

チョン・ドヒョン - ROBOCO首席コンサルタント

TL;DR

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

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

Rufloがすること

Serverless Autoresearch：バイブコーディングでML実験パイプラインをサーバーレス化した記録

チョン・ドヒョン - ROBOCO首席コンサルタント

TL;DR

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

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

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

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

OpenClawの5層ゲートキーピング：AIエージェント時代の品質管理

チョン・ドヒョン - ROBOCO首席コンサルタント

TL;DR

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

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

バイブコーディング時代、リポジトリ規則と個人の好みの境界

チョン・ドヒョン - ROBOCO首席コンサルタント

TL;DR

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

OpenClawが実際に示したもの

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

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

バイブコーディング導入のための組織設計

チョン・ドヒョン - ROBOCO首席コンサルタント

TL;DR

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

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

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

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

バイブコーディングのトークン管理戦略

チョン・ドヒョン - ROBOCO首席コンサルタント

TL;DR

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

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

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

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

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

OpenClaw：世界最大のバイブコーディングプロジェクトから学ぶ9つのベストプラクティス

チョン・ドヒョン - ROBOCO首席コンサルタント

TL;DR

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

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

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

Everything Claude Code vs Oh My ClaudeCode — チーム/企業導入の観点からの比較

チョン・ドヒョン - ROBOCO首席コンサルタント

TL;DR

比較サマリー

機能の比較と分析

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

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

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

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