A Framework for Frontier AI and the Dawning of a New Age (フロンティアAIのフレームワークと新時代の幕開け) - Demis Hassabis

Demis Hassabis (@demishassabis) の投稿が示唆に富んでいたため日本語に翻訳しました。

Demis Hassabis (デミス・ハサビス)とは

The Infinity Machine: Demis Hassabis, DeepMind, and the Quest for Superintelligence (English Edition)

Demis HassabisはDeepMindとAlphaFoldで現代AI/生命科学の最前線を牽引する英国の科学者・起業家です。

基本

  • 氏名: Sir Demis Hassabis(サー・デミス・ハサビス)CBE FRS ほか
  • 生年月日: 1976年7月27日(現在49歳)
  • 出身: ロンドン(ギリシャ系キプロス人の父と、中国系シンガポール人の母)
  • 現職:
    • Google DeepMind 共同創業者・CEO
    • Isomorphic Labs 創業者・CEO
    • 英国政府のAIアドバイザー

経歴

  1. チェス神童 — 4歳でチェスを始め、13歳でマスター級(Elo 2300前後)。イングランド代表ジュニアにも。
  2. ゲーム業界 — 17歳頃からBullfrogで『Theme Park』のリードプログラマ/共デザイン。ケンブリッジ大(コンピュータサイエンス、double first)卒業後、Lionheadで『Black & White』のAI、自社Elixir Studios創業。
  3. 神経科学 — UCLで認知神経科学PhD(2009、指導教員 Eleanor Maguire)。記憶・想像・海馬の研究で著名論文多数。
  4. DeepMind — 2010年にShane Legg・Mustafa Suleymanらと共同創業(ロンドン)。ミッションは「知能を解き、その知能で他のすべてを解く」。2014年にGoogleが約4億ポンドで買収後もCEOを継続。

主な功績

  • AlphaGo — 囲碁の世界チャンピオン級(李世乭ら)を破ったAI。
  • AlphaFold / AlphaFold 2 — タンパク質立体構造予測の約50年の課題を事実上解決。全既知タンパク質約2億種の構造を公開。
  • 2024年ノーベル化学賞 — John M. Jumperと共同受賞(AlphaFold関連)。
  • その他: AtariゲームのDQN、深層強化学習の先駆け、データセンター冷却効率化など。

称号・栄誉(抜粋)

  • 2017年 CBE、2018年 王立協会フェロー(FRS)
  • 2024年 ナイト(Knight Bachelor、AIへの貢献)
  • Lasker賞、Breakthrough Prize、Gairdner賞 など多数
  • Time 100(2017・2025)、2025年 Time Person of the Year の「Architects of AI」の一員など

AGIへのスタンス

AGI(人工汎用知能)の実現を目指しつつ、AI安全性・倫理を重視。誤用リスクを警告しつつ、医療・気候変動などへの便益も強調しています。

[以下訳文] フロンティアAIのフレームワークと新時代の幕開け

オリジナル↓ ※なお翻訳はGrokをもちい、わたしのほうでいくつか修正・注釈をつけています

これは人類史における重要な転換点です。人工汎用知能(AGI)——脳が持つ認知能力を幅広く発揮するシステム——は、おそらくあとわずか数年以内に実現するでしょう。数十年後にこの時代を振り返ると、私たちは「シンギュラリティの麓」に立っていたと実感するはずです。それは、人類にとって新しい時代の夜明けに他なりません。

私はこれまで人生のすべてをAGIの開発に捧げてきました。責任を持って構築・展開すれば、これまでに発明された最も有益で変革的な技術の一つになると、常に確信してきたからです。AGIは、インターネットやモバイルのような通常の技術的進歩とは比べられません。電気や火の発見にずっと近いものです。よく考えてみれば、私たちは本質的に「砂*1に思考能力を与える」方法を見出したのです。これは奇跡的と言えます。

この技術がもたらす影響の規模は前例のないものになるでしょう。産業革命の10倍規模を、10倍の速度で実現する可能性があります。薬の発見加速、新しいクリーンエネルギー源の開発、先進材料の創出など、社会が直面する最大の課題解決に寄与します。将来的には、資源が人間の進歩を制限する要因ではなくなり、驚くべき豊かさの新時代を迎えることさえあり得ます。

フロンティアにおける課題

AIはすでに現実世界で具体的な利益を生み出し始めています。しかし、その大きな可能性を実現するには、この重要な開発段階を慎重かつ思慮深く進める必要があります。AGIに近づくにつれて生じるリスクに、早急に対処しなければなりません。すでにフロンティアモデルがサイバーセキュリティ分野で課題を生じさせていることが確認されており、能力のさらなる進化に伴い、核や生物学的リスクなどの脅威も間もなく顕在化する可能性があります。将来的には、自律性が高く(エージェント的)、再帰的に自己改善するシステムの制御を維持するための強固なセーフガードが必要となり、時間とともに明らかになる未知の課題にも対応しなければなりません。

私は常に、人間の創意工夫と創造性がどのような問題も解決できると信じてきました。AIに関連する技術的リスクの軽減は、私たちが集団で対処可能な課題だと確信しています。ただし、そのためには「この次の重要なステップを正しく行う」ための時間と余裕が必要です。現在、AI分野としても社会全体としても、それができていません。

現在、私たちは極めて激しく、多層的な商業的・地政学的な競争の中にあります。この競争は急速な進歩を促し、大きなメリットを加速させていますが、一方でフロンティアでの進歩は、私たちの技術理解を上回るペースで進んでいます。世界の誰も、ここから何が起こるかを確実に予測できておらず、専門家の間でも意見が分かれています。不確実性が大きく、賭け金が極めて高い状況では、「慎重な楽観主義」で進むのが合理的です。そのためには、イノベーションを促進しつつ責任と安全を奨励する公共政策、主要な安全問題に関する国際協力、そして社会全体の利益を考慮したAIの展開を促す枠組みが必要です。

フロンティアAI基準機関のための枠組み

AIの急速な進歩には、フロンティアモデルの能力を動的・適応的・厳格に評価する新しい手法が必要です。米国は経済力と技術力から、この枠組みを最初に構築するのに適した立場にあります。連邦政府が監督する公私連携組織、またはFINRA(金融業規制機構)のような自己規制組織をモデルとした新たな基準機関を設立することが考えられます。この機関の運営委員会には、独立した一流の技術専門家とオープンソースの代表者を加え、資金は主に業界から十分に調達して、世界トップクラスの人材と大規模評価に必要な計算資源を確保します。

この基準機関は、評価プロトコルの策定を担い、関係連邦機関や米国国立研究所と協力して、国家安全保障に関わる領域でのテストを実施します。モデルが、基準機関が定め、AI能力の進化に合わせて定期的に更新されるベンチマーク群で一定の閾値を満たした場合、「フロンティアクラス」と認定されます。これらの基準を満たす「フロンティアモデル」を開発する組織は「フロンティアラボ」と位置づけられ、以下のベストプラクティスの採用を促されます:

  • 技術詳細を記載したモデルカードの公開
  • 強固な内部サイバーセキュリティの維持
  • 重要人員の審査
  • 安全・セキュリティ研究への十分な資源配分
    など

当初は、フロンティアラボがリリースの最大30日前までに自発的にモデルを基準機関に提供してレビューを受けます。評価プロトコルが有効かつ信頼できることが実証されれば、速やかに制度化され、米国市場で展開されるフロンティアモデルはすべてこの評価を通過することが義務付けられます。また、リリース後の重大な脆弱性に対しても、基準機関と協力して対応します。

モデル評価では、サイバーセキュリティ、生物学的脅威、その他の高リスク領域における能力について、科学的で厳格な検証を行います。特にエージェント型AIのテストでは、安全ガードレールの回避試行や欺瞞の兆候を検知し、AI生成画像へのデジタル透かし付けや、モデルの推論過程を人間が理解しやすい形で出力するなどのベストプラクティスを徹底します。

これらの評価は、最初は四半期ごとなどに定期的に更新し、陳腐化したり飽和したりしたベンチマークは廃止・置き換えます。初期段階ではフロンティアラボと相談しながら作成しますが、最終的には基準機関自身がラボから独立した「非公開(ホールドアウト)テスト」を構築できる技術力を身につけ、過学習(オーバーフィッティング)を防ぐべきです。米国政府と連携し、第三者監査人のエコシステムを育成することで、評価や新ベンチマークの開発を支援することも可能です。

この手法の利点は、技術的に焦点を絞りつつ、イノベーションを阻害せず、責任ある行動を強く促す点にあります。分野の加速に追いつき、特定された最大のリスクに柔軟に適応できる設計で、状況が深刻化すれば、必要に応じてフロンティアラボ間の開発ペースを調整(スローダウン)することも可能にします。「フロンティアラボ」の指定は大きな名誉となり、ベンチマーク基準を満たせば国籍やオープン/クローズドを問わず、どの組織も参加可能です。この枠組みはフロンティアクラスのモデルすべてに適用されますが、スタートアップや学術機関などの非フロンティアモデルは対象外とします。

この米国主導の取り組みは、フロンティアAIに関する国際共通基準を築く強力な起点となります。この技術は地球全体に影響を及ぼすため、理想的にはこの枠組みが国際社会の合意形成を後押しし、最も深刻なリスクを管理しつつ、誰もがAIの機会にアクセスして恩恵を受けられる仕組みを構築するでしょう。

未来はまだ書かれていない

AGIは、科学と医学を劇的に進歩させる究極のツールとなり、莫大な生産性向上と経済成長を推進する可能性があります。しかし、それを実現するには、共有されたグローバル枠組みを中心に調整し、最も厳格な科学的アプローチを用い、最高の人材を集めて課題に取り組むことで、技術的基盤を正しく整える必要があります。

これらの困難な技術的課題を解決したとしても、さらに複雑な経済的・哲学的な問いが残ります。例えば、豊かさが当たり前になった世界(ポスト・スキャーシティ社会)で、誰もが繁栄できる新しい経済モデルはどのようなものか? 私たちが生きる価値観は何か? 意味や目的とは何か? 人間の条件自体がどのように変わるのか? これらの問いを解決することは、技術者だけに任せるべきではなく、社会のあらゆる分野が集まってこの新しい章を定義していく必要があります。

AIの周りには大きな興奮と不確実性の両方があり、どちらも正当です。しかし、未来はまだ書かれていません。AGIが到来するまでのこの貴重な時間を活用し、全人類の利益のためにこの技術を形作らなければなりません。私たちが今、集団で何をするかが、文明の次の段階がどのように展開するかを決めます。AGIを安全に世界に導くことで、私たちは科学発見と進歩の新しい黄金時代を迎え、驚くべき人間の繁栄の明るい未来を切り開くことができるのです。

*1:訳者注:砂状であるシリコンを指しています

Claude Codeで実践する仕様(スペック)駆動開発入門

吉田真吾 (@yoshidashingo) です。

これだけは覚えて帰ってね💡

  • バイブコーディングの対極にある仕様駆動開発は、ソフトウェアエンジニアリングの基本原則をAI時代に再現するアプローチ
  • 仕様駆動開発は仕様で「開発ライフサイクルを」駆動するのではない。仕様を唯一の情報源 (Single Source of Truth) としつつ、プロセスはルールブックによって駆動される
  • Claude Codeでのステアリングには複数の方法があり、CLAUDE.md・スキル・AI-DLCのルールブックなど、目的に応じた使い分けと創意工夫の余地がある

本日、デブサミで登壇してきました。

event.shoeisha.jp

Claude Codeで実践するスペック駆動開発入門 speakerdeck.com

『実践Claude Code入門』の第4章で触れているスペック駆動開発について、最近個人的にハマっている『AI-DLCワークフロー』まで含めて解説しました。


バイブコーディングの何が問題か

Andrej Karpathyが2025年2月に「Vibe Coding」を提唱したとき、彼は個人プロジェクトの文脈で語っていました。「Vibeに身を委ね、コードが存在することすら忘れる」── プロトタイプの探索やアイデアの検証には有効なアプローチです。しかし、プロダクションコードに同じアプローチを持ち込むと何が起こるでしょうか。

Werner Vogelsは、AWS re:Invent 2025のキーノートでこう断じました。

"We can't just pull a lever on your IDE and hope that something good comes out. That's not software engineering. That's gambling."

「IDEのレバーを引いて、いいものが出てくることを願う。それはソフトウェアエンジニアリングではない。ギャンブルだ」。

実務の現場で起きる問題は具体的です。

Verification Debt (検証負債) の蓄積。 AIがコードを生成する速度は、人間が理解・検証する速度をはるかに超えます。従来の技術的負債が「理解した上での妥協」であるのに対し、検証負債は「そもそも何が問題なのかわからないまま積み上がった構造」です。負債の存在すら認識できないという点で、従来の技術的負債よりも深刻です。

「動くけど何をしているか分からないコード」の増殖。 バイブコーディングでは、AIが生成したコードの内部構造を精査せずに「だいたいうまくいく」ことを確認して先に進みます。短期的にはプロジェクトは前に進みますが、コードベースの中に「誰も理解していない領域」が広がっていきます。

デバッグ不能な状態への到達。 問題が発生したとき、コードの意図を誰も理解していなければ、デバッグは困難です。AIに「直して」と頼んでも、文脈を理解していないAIが場当たり的な修正を重ねるだけで、根本原因にたどり着けません。

バイブコーディングを全否定するのは公平ではありません。問題は、プロトタイプで通用するアプローチをプロダクションコードにそのまま持ち込むことにあります。


仕様駆動開発とは何か

Thoughtworks Technology Radarでの位置づけ

仕様駆動開発 (Spec-driven Development) は、Thoughtworks Technology Radar Vol.32 (2025年4月) でTrial (試験運用) として採用された手法です。その核心は、仕様 (Spec) を先に定義し、その仕様に基づいてAIにコードを生成させることにあります。

これは新しい発明ではありません。ソフトウェアエンジニアリングが数十年にわたって実践してきた基本原則 ── 要件を定義し、設計し、実装し、テストする ── をAI時代に再適用したものです。AWS re:Invent 2025でVogelsが紹介したKiro IDEも、Requirements → Design → Tasks → Code Generationというフローでこの思想を体現しています (Kiro IDEのデモは、KiroチームのシニアプリンシパルデベロッパーClare Liguoriが担当しました) 。

仕様書とは何か

仕様駆動開発における「仕様 (Spec)」は、一種類の文書ではありません。開発のフェーズに応じて、さまざまな形をとります。

仕様の種類 役割 例
要求仕様 (Requirements Spec) 何を作るか、なぜ作るかを定義 ユーザーストーリー、EARS記法の要件文
設計書 (Design Doc) アーキテクチャと技術的設計を記述 コンポーネント図、API仕様、データモデル
ユビキタス言語 (Ubiquitous Language) ドメインの用語をチーム内で統一 用語集、ドメインモデル図
テスト仕様 (Test Spec) 期待する振る舞いを事前に定義 テストケース、受入基準
実行計画書 (Task Plan) 実装の順序と単位を規定 タスクリスト、スプリントバックログ

これらの仕様書群が「何を作るか」の情報源となり、AIはこれらを参照してコードを生成します。

仕様駆動 ≠ 仕様でプロセスを駆動する

ここで重要な区別があります。「仕様駆動」という名前から、仕様書が開発プロセス全体を駆動するかのように聞こえますが、実態は異なります。

仕様は「唯一の情報源 (Single Source of Truth)」であって、「プロセスの駆動源」ではありません。

何を作るかを定義するのは仕様の役割です。一方、どのような手順で・どのような品質基準で・どのような承認プロセスを経て作るかを決めるのは、仕様ではなくプロセスルール (ルールブック) の役割です。

なぜこの区別が重要なのか。仕様がプロセスを駆動すると考えると、「仕様書を書けばあとはAIが勝手にやってくれる」という誤解に陥ります。実際には、仕様の粒度をどう調整するか、どの段階で人間が承認するか、タスクの複雑さに応じてプロセスの深度をどう変えるか ── これらはすべてプロセスルール側の責務です。Kiro IDEのRequirements → Design → Tasks → Codeという順序制約も、仕様の「内容」ではなく「プロセス」のルールです。


『実践 Claude Code 入門』で体験する仕様駆動開発

仕様駆動開発の原則は理解できた。では、実際にClaude Codeでどう実践するのか。『実践 Claude Code 入門』(以下、本書) の第4章では、Claude Codeを使った仕様駆動開発を読者が一通り体験できるように構成されています。

第4章の概要

本書第4章では、CLAUDE.md をステアリングファイルとして活用し、以下のフローで仕様駆動開発を進めます。

  1. CLAUDE.md にプロジェクトの制約・規約・文脈を定義する
  2. .steering/ 配下に作業バッチフォルダを作成する
  3. 作業バッチごとに要件定義書・設計書・タスクリストを生成・保存する
  4. タスクリストに沿ってコードを生成し、テストする

Claude Codeの標準機能だけで完結するため、特別なフレームワークやプラグインは不要です。仕様駆動開発の「仕様を先に定義し、その仕様に基づいてコードを生成する」という原則を、最小構成で体験できます。

4章で作成する CLAUDE.md の例は以下で公開されています。

github.com

CLAUDE.md をステアリングにする功罪

4章でClaude Codeと壁打ちして開発ルールを CLAUDE.md に記載するアプローチは、仕様駆動開発の入門ハードルを下げていますが、プロジェクトの規模が大きくなるにつれて限界が見えてきます。

メモリファイルの肥大化。 開発ルールが増えるにつれて、CLAUDE.mdが膨れ上がります。Claude Codeのコンテキストウィンドウには上限があり、起動時に必ず読み込まれるメモリに今すぐ必要ではないかもしれないすべてのルールを読み込む意味はありません。開発ルール自体を工程や手法ごと、ドキュメント種別ごとに適切に構造化しておくことで、必要なタイミングで段階的開示されるように仕組み化しましょう。

ワークフローの適応性の低下。 本書で示した CLAUDE.md に制約を書き、.steering/に仕様を保存する方式では、「どのような順序で作業を進めるべきか」のプロセスルールまでは明示的に定義されていません。仕様書類に抜け漏れがないこと、観点漏れがないことなどは担保されておらず、生成された仕様書をチェックする人間のスキルに委ねられます。

本書は仕様駆動開発の入門部分を理解するために、プロセスの複雑さや構造的な構成を避けた結果です。チーム開発や監査要件が厳しい環境では、より構造化されたアプローチが必要になります。


AI-DLCのステアリング ― フレームワークレベルの規律

AI-DLCは、前セクションで挙げた限界に対して構造的な解決策を提供しています。

本書のアプローチとの対比

観点 本書のアプローチ AI-DLCワークフローのアプローチ
ステアリング CLAUDE.md (制約と文脈) CLAUDE.md + core-workflow.md + ルールブック
仕様の管理 .steering/ に作業バッチ単位で保存 aidlc-docs/ にステージ単位で保存
プロセスの駆動 CLAUDE.mdのプロンプトに依存 ルールブックがステージ順序を規定
状態管理 .steering/ 内のタスクリスト aidlc-state.md (専用ファイル)
監査証跡 タスクリストの完了状態 audit.md (全やり取りをタイムスタンプ付きで記録)

コアワークフローとルールブックによるプロセス駆動

AI-DLCワークフローでは、CLAUDE.md はプロジェクトの文脈 (技術スタック、ディレクトリ構造、コーディング規約) を伝える役割に留まります。プロセスの駆動は、core-workflow.md (ワークフロー定義) とルールブック (aws-aidlc-rule-details/) が担います。

これは、前セクションで述べた「仕様 ≠ プロセスの駆動源」という原則のアーキテクチャレベルの実装です。仕様書はaidlc-docs/に保存されますが、開発プロセスの順序・深度・承認タイミングは、ルールブックが規定します。

AI-DLCワークフローをClaude Codeで利用するガイダンスとして core-workflow.md を CLAUDE.md に上書きして使う記述も見られますが、適応型ワークフローの柔軟性を確保するという点からは推奨されません。

順序の強制。 Requirements Analysis → Workflow Planning → Functional Design → Code Generationという順序がフレームワークレベルで固定されています。「仕様を先に定義し、コード生成は後」という原則が、プロセスの構造に組み込まれています。

承認ゲートによるHuman-in-the-Loop。 14ステージ中13ステージに承認ゲートが設けられています。仕様書に「DO NOT PROCEED until user confirms」と明記されている通り、承認なしに次のステージへ進むことはできません。

Adaptive Depthによる深度調整。 同じステージでも、タスクの複雑さに応じて3段階 (Minimal / Standard / Comprehensive) で深度が自動調整されます。仕様駆動開発の「重さ」がタスクに合わせて伸縮します。

状態管理と監査証跡の分離

AI-DLCは、状態管理と監査証跡を専用ファイルに分離しています。aidlc-state.md が現在のフェーズ・完了したステージ・保留中のタスクなどの進捗状態を記録し、audit.md がすべてのユーザー入力とAI応答をタイムスタンプ付きで原文のまま記録します。

証跡の限界。 本書では作業バッチ単位のタスクリストを事実上の証跡として扱っています。しかし、タスクリストには「何をやったか」は記録されても、「なぜその判断をしたか」「ユーザーとAIの間でどのようなやり取りがあったか」は残りません。

本書のタスクリストが「何をやったか」の記録に留まるのに対し、audit.mdは「なぜその判断をしたか」までを含みます。規制対応やチーム間のナレッジ共有が求められるエンタープライズ環境では、この差は大きな意味を持ちます。

ルールブックの二層構造による組織カスタマイズ

AI-DLCのルールブックは、ベースレイヤーと拡張レイヤーの二層構造を採用しています。

aws-aidlc-rule-details/    ← ベースレイヤー (AI-DLC標準、変更不可)
ga-aidlc-rule-details/     ← 拡張レイヤー (組織固有のカスタマイズ)

ベースレイヤーがフレームワーク標準のルールを提供し、拡張レイヤーが組織固有の知見・品質基準・テンプレートで補完します。フレームワークの標準プロセスを壊さずに、業界固有の規制要件や社内の品質基準を追加できる設計です。


スキル化の功罪と適応型ワークフロー

スキルによる定型作業のコマンド化

Claude Codeのスキル (Skills) は、定型作業を手順化して再利用可能にする仕組みです。.claude/skills/にMarkdownファイルを配置すると、/スキル名で呼び出せるプロジェクト固有のスキルとして登録されます。

注: Claude Codeの初期バージョンでは.claude/commands/に配置する「カスタムスラッシュコマンド (Custom Slash Commands)」として提供されていた機能です。現在は.claude/skills/配下の「スキル (Skills)」に移行されています。

# .claude/skills/tdd-cycle.md の例
以下のTDDサイクルを実行してください:

1. $ARGUMENTS に基づいてテストファイルを作成する
2. テストを実行し、失敗することを確認する (Red)
3. テストを通す最小限の実装を書く (Green)
4. テストが通ることを確認する
5. コードをリファクタリングする (Refactor)
6. テストが引き続き通ることを確認する

このようなタスク単位のスキルは、スキルの中では手順に従い、スキルの外では自由に振る舞います。TDDサイクルを実行した後、次に何をするかはAIが状況に応じて判断できます。適応型ワークフローの中に事前定義型のサブワークフローを埋め込む手法であり、スキルの粒度が小さい限り、適応型ワークフローの柔軟性は保たれます。

aidlc-cc-plugin ― フルプロセスのスキル化が招く制約

しかし、スキル化の粒度を大きくすると話が変わります。AI-DLCの実行をフルプロセスでスキル化したaidlc-cc-plugin がその例です。このプラグインはClaude CodeにAI-DLCのワークフローをスキルとして組み込みます。

aidlc-cc-pluginでstartコマンドを実行すると、AI-DLCのフェーズに沿った実行が開始されます。しかし、フェーズに沿った実行が完了するとセッションが終了します。AI-DLCのワークフローを途中で離れて別の作業をしたり、フェーズの合間に自由な対話を挟んだりすることができません。AI-DLCのフェーズ実行に特化しているため、それ以外の用途には使えないのです。

プロンプトの精度 ― すべてのアプローチに共通する土台

どのアプローチを選んでも、最も基本的なステアリング手段はプロンプトの精度です。Vogelsはキーノートで「曖昧なプロンプトは曖昧なソフトウェアになる」と述べています。

  • 具体的なインプット例: 入力値の形式・バリデーションルール・エッジケースまで明示する
  • 期待するアウトプット: レスポンスの形式・ステータスコード・セッション管理の方法まで記述する
  • 制約条件: 「セキュアに実装する」ではなく、「bcryptでパスワードをハッシュ化し、JWTの有効期限は1時間とする」のように具体化する

CLAUDE.mdの制約も、スキルのテンプレートも、ルールブックの詳細ルールも、すべてプロンプトの精度を構造的に担保する仕組みです。ステアリングの設計とは、プロンプトの精度をどの粒度で・どの層で・どこまで事前に定義するかの設計に他なりません。


まとめ

  • バイブコーディングはプロトタイプには有効だが、プロダクションコードにはVerification Debt (検証負債) を蓄積するリスクがある
  • 仕様駆動開発は仕様で「開発ライフサイクルを」駆動するのではない。仕様を唯一の情報源としつつ、プロセスはルールブック (プロセスルール) によって駆動される
  • 『実践 Claude Code 入門』のCLAUDE.md + .steering/方式は入門に適しているが、メモリファイルの肥大化・ワークフローの適応性低下・証跡の限界がある
  • AI-DLCは、コアワークフロー + ルールブックによるステアリングと、専用の状態管理 (aidlc-state.md) ・監査証跡 (audit.md) で、これらの限界を構造的に解決している
  • スキル化はプロセスの再現性を高めるが、適応型ワークフローの柔軟性とトレードオフがある。ステアリングの設計とは、プロンプトの精度をどの層で・どの粒度で事前に定義するかの設計である

AI-DLCを完全理解する 第2回: はじめかた ― まず「現状を知る」

吉田真吾 (@yoshidashingo) です。

これだけは覚えて帰ってね💡

  • AI-DLCは最初に「今、何がある?」を自動で調べる (Workspace Detection)
  • 既存コードがあれば、AIがリバースエンジニアリングで全体像を読み解く
  • 「現場を把握してから計画する」という考え方は、TOGAFやレガシーコード改善にも共通する

https://extravaganzarr.s3.ap-northeast-1.amazonaws.com/aidlc-image03.png

引用元:AI 駆動開発ライフサイクル:ソフトウェアエンジニアリングの再構築 | Amazon Web Services ブログ


なぜ「出発点」が大事なのか

ソフトウェアプロジェクトには、大きく分けて2つの出発点があります。

ゼロから作る (Greenfield) か、既存のコードがある状態から始める (Brownfield) か。

Greenfield (更地) は文字通り何もない状態です。自由度は高いですが、すべてを一から決める必要があります。一方、Brownfield (既開発地) は既存のシステムがすでに動いています。制約は多いですが、ゼロから作る必要はありません。

この区別が重要なのは、出発点によってやるべきことがまったく違うからです。更地に家を建てるのと、既存の家をリフォームするのでは、最初にやるべき調査が根本的に異なります。AI-DLCはこの違いを、フレームワークレベルで自動判定します。


Workspace Detection: AI-DLCの「健康診断」

AI-DLCのプロセスは、Inception (計画) フェーズの最初のステージ「Workspace Detection」から始まります。第1回で紹介した14ステージの1番目にあたります。

やること

Workspace Detectionでは、AIが以下の6ステップを実行します:

  1. 既存プロジェクトの確認: 以前のAI-DLCセッションの状態ファイル (aidlc-state.md) があるか確認します。あれば、前回の続きから再開できます。
  2. コードの有無を調べる: ソースコードファイル (.java, .py, .ts, .goなど) 、ビルドファイル (package.json, pom.xml, build.gradleなど) 、プロジェクト構成を自動スキャンします。
  3. Brownfield/Greenfieldの判定: コードがあればBrownfield、なければGreenfieldとフラグを立てます。
  4. 状態ファイルの作成: プロジェクトの基本情報をaidlc-state.mdに記録します。
  5. 結果の報告: 「こういう状態でした」とユーザーに知らせます。
  6. 次のステージへ自動で進む: ここが特徴的 ― 承認不要で次に進みます。

唯一の「承認なし」ステージ

第1回で「ほぼすべてのステージに承認ゲートがある」と書きました。Workspace Detectionは、承認ゲートの例外です。

なぜ承認が不要なのか? このステージは情報を集めるだけで、何も変更しないからです。コードを書き換えたりファイルを消したりしません。ユーザーの意思決定を要する判断もしません。「現場の状況を報告する」だけなので、逐一承認を求める必要がありません。

これは合理的な設計です。承認ゲートは重要ですが、何でもかんでも承認を求めると作業が停滞します。「リスクのない情報収集は自動で、判断を伴うステップは承認を」という設計思想がここに表れています。


Brownfield判定のあと: Reverse Engineering

Workspace Detectionの結果によって、次に何が起こるかが分岐します。Greenfieldと判定された場合はそのまま要件分析 (Requirements Analysis) へ進みます。一方、Brownfieldと判定された場合は「Reverse Engineering」が実行されます。これはCONDITIONAL (条件付き実行) ステージの1つで、既存コードがあるときだけ実行されます。

既存コードを「読み解く」とは

Reverse Engineeringという言葉は、もともとハードウェアの世界で使われていました。完成品を分解して、設計図を逆算する行為です。ソフトウェアの世界では、既存のコードベースを解析して、設計上の意図や構造を文書化することを指します。

AI-DLCのReverse Engineeringステージでは、AIが既存のコードを隅から隅まで読み、以下の8つの成果物を生成します:

# 成果物 内容
1 ビジネス概要 システムの存在目的、ビジネスコンテキスト図、業務トランザクション一覧
2 アーキテクチャ コンポーネント構成、データフロー、外部システムとの統合ポイント
3 コード構造 ビルドシステム、主要クラス/モジュール、採用されている設計パターン
4 API仕様 REST/内部APIのエンドポイント一覧、リクエスト/レスポンスのデータモデル
5 コンポーネント一覧 アプリケーション/インフラ/共有ライブラリ/テストの分類と構成
6 技術スタック 言語、フレームワーク、インフラ基盤、ビルドツールのバージョン情報
7 依存関係 内部依存のMermaid図、外部ライブラリのバージョンとライセンス
8 コード品質評価 テストカバレッジ、コーディング規約の遵守状況、技術的負債の所在

なぜ8つも必要なのか

一見すると多く見えます。しかし、これには明確な根拠があります。

既存コードベースを前にしたとき、「何が分からないか分からない」状態に陥りがちです。「認証はどうなっているんだろう」「このAPIはどこから呼ばれているんだろう」「テストはどこまで書かれているんだろう」― 疑問は尽きません。

AI-DLCは、8つの成果物テンプレートであらかじめ「調べるべきこと」を網羅的に定義しています。AIが「何を調べればいいか」を判断するのではなく、フレームワークが「これを調べろ」と指示する構造です。抜け漏れを防ぐための設計です。

Reverse Engineeringの特殊な再実行ルール

もう1つ注目したい仕様があります。Reverse EngineeringはBrownfieldプロジェクトが検出されるたびに必ず再実行されます。以前の成果物が残っていても、スキップせずに最新のコード状態を反映し直します。

「前回の解析結果をそのまま使えばいいのでは?」と思うかもしれません。しかし既存コードは日々変化します。前回の解析時から新しいAPIが追加されていたり、依存ライブラリが更新されていたりする可能性があります。陳腐化した設計文書は誤った判断を招くリスクがあります ― AI-DLCはこのリスクを「毎回やり直す」というシンプルなルールで回避しています。


既存手法との比較: 同じ知恵、異なるスケール

AI-DLCの「事実確認ファースト」は、実はソフトウェア工学の世界で繰り返し発見されてきたアプローチです。3つの既存手法と対比してみましょう。

TOGAFのArchitecture Vision

TOGAF (The Open Group Architecture Framework) は、エンタープライズアーキテクチャのフレームワークとして広く知られています。その中核であるADM (Architecture Development Method) の最初のフェーズが「Phase A: Architecture Vision」です。

Phase Aでは以下のようなことをします:

  • ステークホルダーの特定と要件の把握
  • ビジネスゴールと推進要因の確認
  • 現在の能力 (Capability) の評価とギャップ分析
  • 目指すべき将来像 (Architecture Vision) の策定
  • リスクの洗い出し

AI-DLCのWorkspace Detection + Reverse Engineeringと並べてみると、面白い対比が見えてきます:

観点 TOGAF Phase A AI-DLC (WD + RE)
目的 将来のアーキテクチャビジョンを定義 現在のワークスペース状態を把握
対象 組織全体のエンタープライズアーキテクチャ 1つのプロジェクト/コードベース
実行者 人間のアーキテクト AI
所要時間 数週間〜数ヶ月 数分〜数十分
成果物 Architecture Vision文書、Statement of Architecture Work 8つの設計文書 (自動生成)
承認 ステークホルダー承認が必要 WDは承認不要、REは承認必要

※AI-DLC側の所要時間はコードベースの規模やAIモデルの処理能力に依存します。上記はあくまで目安です。

スケールと対象はまったく異なるため単純比較はできませんが、「まず現状を把握してから計画を立てる」という設計思想は共通しています。

レガシーコード改善の考え方

Michael Feathersの名著『Working Effectively with Legacy Code (レガシーコード改善ガイド) 』では、レガシーコードを「テストのないコード」と定義しています。そして、レガシーコードを改善する最初のステップは「まず理解する」ことだと説いています。

Feathersが提案するアプローチはこちらです:

  1. 変更すべき箇所を特定する: どこを直したいのかを明確にします
  2. テストを書ける場所を見つける: 既存コードの中で、テストが書ける「接ぎ木点 (seam) 」を探します
  3. 依存関係を把握する: 変更対象のコードが、他のどこに影響するかを調べます
  4. テストで保護してから変更する: テストという安全網を張ってから、初めてコードに手を入れます

AI-DLCのReverse Engineeringが生成する依存関係の文書、コード品質評価、技術スタック一覧は、この「テストで保護する前段階の理解」と同じ発想をAIによる解析で実現しようとするものです。

Strangler Figパターンとの接点

Brownfieldプロジェクトで既存システムを段階的に刷新する手法に、Martin Fowlerが命名した「Strangler Fig (絞め殺しの木) パターン」があります。熱帯の絞め殺しの木が宿主の木に巻きついて徐々に置き換えるように、レガシーシステムの機能を新しいシステムに少しずつ移行していきます。

このパターンの第一歩も「既存システムの理解」です。何が動いているのか分からないまま置き換えを始めるわけにはいきません。AI-DLCのReverse Engineeringで生成されるビジネス概要やAPI仕様は、Strangler Figパターンを適用する際の「置き換え計画」の基礎資料としても機能します。


AI-DLCが「出発点」で示す設計原則

ここまで見てきたWorkspace DetectionとReverse Engineeringには、AI-DLC全体を貫く3つの設計原則が凝縮されています。これらの原則は、今後の回で取り上げるすべてのステージにも共通するものです。

1. 事実 → 判断 → 実行の順序を強制する

AI-DLCはステージの実行順序をフレームワークレベルで固定しています。「何を作るか」を議論するRequirements Analysisの前に、必ずWorkspace Detectionが来ます。人間だけのプロジェクトでは「とりあえず作り始めよう」と順序が崩れがちですが、AI-DLCではそれが構造的に起こりません。

2. リスクに応じてプロセスを調整する

Greenfieldでは発生しない「既存機能の意図しない破壊」というリスクに対して、BrownfieldではReverse Engineeringが自動で追加されます。プロセスの重さを一律にするのではなく、リスクの大きさに応じて調整する ― この考え方は第7回で扱う「Adaptive Depth (適応型深度) 」にもつながっていきます。

3. 承認コストを最小化する

前述のとおり、Workspace Detectionは情報収集なので承認不要、Reverse Engineeringは設計判断を含むので承認必要。この使い分けは、後続のステージでも一貫して適用される原則です。


まとめ

第2回はAI-DLCの出発点となるWorkspace DetectionとReverse Engineeringについて説明しました。今回学んだことは以下です。

  • AI-DLCは最初のステージ「Workspace Detection」で、プロジェクトの状態を自動調査します
  • Brownfield/Greenfieldの判定結果に応じて、以降のプロセスが自動で分岐します
  • Brownfieldの場合は「Reverse Engineering」でAIが8つの設計文書を生成し、毎回最新状態を反映し直します
  • 「事実確認ファースト」の考え方は、TOGAF、レガシーコード改善、Strangler Figパターンにも共通します
  • 「事実 → 判断 → 実行」の順序強制、リスクに応じたプロセス調整、承認コストの最小化 ― この3原則はAI-DLC全体を貫く設計思想です

次回予告

第3回では、現場把握のあとに来る「Requirements Analysis」と「User Stories」を取り上げます。「何を作るか」をどうやって決めるのか? AI-DLCが採用する3段階の深度 (Minimal / Standard / Comprehensive) や、質問ファイル方式という独自の仕組みを、アジャイルのユーザーストーリーやEARS記法、DDDのユビキタス言語と比較しながら解説します。

Image