Vibecoding on ROBOCO

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

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を信じるな。人も信じるな。代わりに、信じられるシステムを作れ。そのシステムの核心は、組織が統制できる自動化されたプロセスとガードレールです。

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

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アシスタントとして使うこともできます。

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

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

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

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がプロジェクトの途中でツールを切り替えるのを防ぎます。