Agentic-Dev on ROBOCO

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

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はなぜ脱落したのか、「運用経験あり」が決定を正当化するほど重要な条件だったのか、この文書は何も語りません。同じ決定を叙述型で書くとこうなります。

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の内部パスを参照したり、パッケージルートの外へ相対パスを伸ばしたりするのを検出します。

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のフロントエンドパターンやデータベースのパターンといった知識スキルのテンプレートも提供します。¹

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の実行 → コードレビュー → ドキュメント同期」といった一連の開発フローをボタンのように実行できます。

Agentic-Dev on ROBOCO

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

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

人を挟めば解決するのか

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

第一に、小テスト

第二に、文芸的コードdiff

第三に、叙述型の文書

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

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

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

TL;DR

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

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

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

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

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

TL;DR

比較サマリー

機能の比較と分析

Everything Claude Code (ECC)

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

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

TL;DR

1. プロジェクト概要

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

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

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

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

TL;DR

1. プロジェクト概要

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

2.1 Agents

2.2 Skills

2.3 Commands

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