🎉

Everything As Codeで描く、次世代の開発手法

2025/12/31に公開

テーマ「2025年の最も大きなチャレンジ」

 はじめに2025年は、AI駆動開発の手法が飛躍的に広がり、多くの企業で導入や検証が進められた一年だったと感じています。

ただ正直に言うと、実務レベルの大規模開発で本当に使えるかというと、かなり難しい というのが率直な感想です。
おそらく、日常的にAIを使っているエンジニアの多くが、

同じような違和感を感じているのではないでしょうか。
デモではすごい
個人開発では便利
新規プロダクトだと導入できるが既存の大規模プロジェクトには難しい
今回の記事では、

「なぜ実務で大規模開発でAI駆動開発が成立しにくいのか」

そして

「どうすれば実務でも通用する形に持っていけるのか」

について、現時点での僕の仮説を整理してお話しします。

 なぜ今「AI駆動開発」へシフトできないのか

 現在のAIコーディングのレベル整理まず前提として、

「AIコーディング」と一口に言ってもレベル感は大きく異なります。
僕の中では、現状は大きく 4段階 に分かれています。

 レベル0：IDEによる補完（AI以前）これはAIとは直接関係ありませんが、
Emmet
IDEの自動補完
スニペット
といった、人間が書く前提の補助機能 です。

便利ではありますが、思考主体は完全に人間側です。

 レベル1：インラインコード補完GitHub Copilot が出た初期に多かった使い方です。
1行だけ補完する
メソッドを1つ生成する
if文やfor文を書かせる
あくまで 「人が主導で、AIが横で補助する」 状態です。

 レベル2：AIエージェントによる複数ファイル編集（現状の限界点）ここが 現時点で実務的に到達可能な最大レベル だと考えています。
目的だけを与える
AIが対象ファイルを自分で探す
複数ファイルを編集しながら機能を実装する
Cursor や Github Copilot のエージェントモードが、この領域に該当します。

 レベル3：AIエージェントによる長期自動運転長期間にわたって自律的に開発を進める
設計・実装・修正を自走する
これは 来年以降に流行る領域 だと考えています。

なお、今流行っている「AIエージェント」とは 別物 です。

 開発現場は今どこにいるのか実際の開発現場を見ていると、
基本はレベル1（インライン補完）
一部でレベル2（エージェントモード）を試している
このあたりが実態だと思います。
今回の記事では、

ここからどうやってレベル2を実務で成立させるか

にフォーカスしています。

 なぜAI駆動開発にシフトできないのか

僕が思う理由は大きく3つあります。

 ① AIに与えている情報が圧倒的に足りないたとえば、僕に対していきなり、
「明日までに他社のシステムに機能を追加して」
と言われたらどうでしょうか。
他社がどんなアーキテクトでどんなデザインパターンで作られているか分からない
使用言語も分からない
コーディングルールも分からない
インフラ構成も分からない
これでは人間でも無理です。
今、AIにもまったく同じことをやっています。

情報が少なくAI自身もどうしたらいいかわからなくなります。

 ② AI中心の構造になっていないコード量が多すぎる
情報が分散している
AIが読みにくい形式で管理されている
この状態で

「AIに全部任せたい」は成立しません。

 ③ エンジニア側のAI理解が足りていないAIが何を理解できるのか
どんな情報を与えると精度が上がるのか
この理解が不足していると、

雑な指示 → 雑なコード になります。

 AI中心で考えると、問いが変わる!
AI駆動開発では、次の問いを考える必要があります。
AIはどうすれば正しいコードを書けるのか
どうすればドメイン知識を理解できるのか
チーム特有のルールをどう伝えるのか
インフラ構成をどう理解させるのか
これらを解決する考え方が、

Every Singers Code です。

 Every Singers Code とは何か
AWSが提唱している考え方で、

「すべてをコード化する」 という思想です。
現状、多くのプロジェクトでは、
プログラムコードだけがコード
設計書はスプレッドシート
インフラはコンソール操作
になっています。
Every Singers Codeでは、
ソースコード
テストコード
設計書
ドキュメント
インフラ構成
すべてをコードとして管理し、AIが読める状態にする

ことを目的としています。
最大の狙いは、
人間しか知らない情報をなくすこと
です。

 現状の致命的な問題
たとえば自社では、
設計書：Googleスプレッドシート
ソースコード：Github
インフラ：AWSコンソール
すべてが 別々の場所 にあります。
この状態では、
AIが設計書を読めない
AIがインフラ構成を理解できない
つまり、

AI駆動開発はほぼ不可能 です。

 Every Singers Codeを実現するとどうなるか同一リポジトリ内に
ソースコード
Markdown化した設計書
IaC（CDK / Terraform）
を配置することで、
👉 AIが 設計・コード・インフラを横断的に理解 できる状態になります。

 設計書は何を含めるべきか設計書とは、以下すべてを指します。
基本設計書
詳細設計書
画面設計書
帳票設計書
テーブル定義
要件定義の議事録
会議ログ
Slackなどのチャットログ
とにかく「人が判断に使っている情報」はすべて対象 です。

 設計書をコード化する3つの方法
 方法①：GitBook（Markdown化）

Markdown → 設計書UIを自動生成
読みやすい
既存設計書が多いと移行コストが高い
ただし、
VS Codeで設計書を直接開ける
エージェントモードで設計書自体を編集できる
という大きなメリットがあります。

 方法②：MCPツールを作る
スプレッドシート設計書を検索・要約
VS Code / Cursor からAPI的に呼び出す
設計書の場所を変えずにAIから参照できる点は強力ですが、

Google製品のため セキュリティ設計は要注意 です。

 方法③：VectorDB + RAG
設計書をMarkdown / PDF化
ベクトル化してDBに保存
必要な情報を検索取得
技術的には可能ですが、

構築コストは高めです。

 現実的な第一歩いきなり全部は無理です。
まずは、
今開発している 対象機能の設計書だけ
Markdown or PDF化
ソースコードと同じディレクトリに配置
VS Codeのエージェントモードで参照
これだけでも、

AIの出力精度は明確に変わります。

 AI駆動開発で最も重要なこと最後に一番大事な話です。
AIの出力精度は、使う人で決まります。
雑な指示 → 雑なコード
条件・制約・技術スタックを明示 → 高精度
AIは、
自分が理解できるレベルのコードしか出せない
出力されたコードを、
説明できるか
評価できるか
これができない限り、

実務では使えません。

 まとめAI駆動開発は魔法ではない
情報設計と人間側のスキルが鍵
言語理解 × AI理解 = 開発速度2倍以上
AIは本当に楽しいです。

ぜひ一緒に、実務で使えるAI駆動開発 を作っていきましょう。