はじめに
こんにちは。主にXにてAI駆動開発について発信している熊井悠 と申します。
この度、念願のQiitaを投稿してみようと思い筆を持った次第なのですが、以前からAI駆動開発において『Project as Code』が重要と口酸っぱく言っていますら。ただProject as Codeって検索しても出てこないという話がありました。なぜなら僕が造語したからです。
そのため本記事ではProject as Codeについて解説しようと思います！
Project as Code（PaC）とは
PaCはインフラのコード管理の概念である「Infrastructure as Code」という用語に倣い僕が作成した言葉です。いわゆるシステム開発プロジェクトの全てをコード管理・バージョン管理していこうという取り組み、スローガンです。
なぜPaCが必要か？
なぜ必要なのでしょうか？シンプルに言うとAI駆動開発においてコード生成の質を担保するのは「コンテキスト」だからです。
「いやいや、claude-3.7-sonnetのコード生成品質が高いから安心」という声も聞こえてきそうですが、システム開発プロジェクトにおいて「正しい仕様」と「顧客もしくは指示者が正しいと言う仕様」のいずれが正義でしょうか。
答えは聞かなくてもわかりますね。
※コード品質は正しい記法だけではなく、要件・仕様通りに書けているかも指します。
つまりプロジェクトの大前提となる要件、仕様（=コンテキスト）を正しくAIに伝えることが非常に重要な世界になってきます。
以前から当たり前の概念ではあった
あれ？エンジニアでも同じでは？そうなんです。ただ一つ大きな違いと言えば、AIとのコミュニケーションは現時点でほぼテキストであるということです。そのためAIが理解しやすい形式でプロジェクトの全ての情報をコード管理していく必要があるのです。
PaCの大前提の話
コンテキストの重要性
PaCがなぜ必要か？で説明してきましたが、もう少し細かく見ていきましょう。今回はAIコードエディターであるCursorを前提で話を進めたいと思います。Cursorをお使いの皆さんであればAI生成を利用する際にコンテキストを追加しますよね（下図参考）
Cursorは非常にコンテキスト機能が優れているので、どの情報をインプットに生成するかを @シンボルでファイルやフォルダ、コード、ドキュメントなど複数から選択することが可能となります。
さて具体的な使い方や方法論はCursorに関する記事をぜひ参照してください。
何が重要かというと、このコンテキストに「何を与えるか？」によってアウトプットに違いが生じるという点です。実はChatGPTのプロンプトでも何を元に判断させるか、という点で何ら違いはありません。
優れたコンテキストとは？
では生成精度を上げる優れたコンテキストとは何かを考えてみます。コードに近い箇所から考えてみましょう。開発ルール、コード規約、フォルダ構成、ファイル構成、フレームワーク・アーキテクチャの原則など開発にまつわる様々な情報もコンテキストです。Cursorで言うと、Cursor Rulesに書かれるような内容ですね。非常に重要です。
ではこちらを正しく整備すればプロジェクトで構築するシステムは完成するのでしょうか。残念ながらコードの品質は高まるでしょうが、要件を満たすという意味での品質は担保されないままです。
繰り返しになってしまいますが、要件・仕様と言ったコンテキストがないと正しいゴールに導くことが出来ません。つまりプロジェクトの情報を網羅的かつ正しい粒度で管理していく必要があるのです。
PaCの思考方法
では早速PaCをどう実践に移すかを見ていきましょう。
前提として下記の3層に分けて考えることを推奨しています。
- layer3（第3層）：思考・アイデア（Concept）
- layer2（第2層）：ドキュメント・成果物（Facade）
- layer1（第1層）：実体ファイル（Definition）
第2層であるドキュメントに関しては人間が見て理解するためのものですので、本質的にはlayer3とlayer1のコミュニケーションが上手くいけば問題ありません。
※コミュニケーションは口頭だけではなく情報連携という意味も指す
図として整理したものが下記です。
基本的には上記の層を意識してプロジェクトに必要な情報は漏れなくコード管理していくとこを推奨します。それこそがPaCなのです。
PaCのコミュニケーションの流れ
上記の3層を意識してプロジェクトの情報を格納していきます。実際の各レイヤーの流れを整理してみましょう。
layer3→layer1
最初の難関にはなるのですが、思考を文書にしていくのが一番大変だったりするので僕は思考フレームワークやヒアリングシートを多用して管理しています。（また別記事で紹介するのでまずは思考を落とし込むイメージで大丈夫です）
layer1
markdownやYAMLなどCursorで扱いやすい形で管理していきます。ここからGitHubを使うと楽です。
layer1→layer2
本質的には不要なのですが人間の目で見て理解することが必要なケースがまだ多いので成果物を逆引きします。究極のAI駆動開発では見たいときにリアルタイム生成が理想ですね。
layer2→layer3
さて実際の思考と合っているか合意形成をしていきましょう。あとは繰り返しです。
実際のコンテキストになるまで
恐らく多くの場合はlayer1の情報量が多すぎる、もしくは雑多すぎるので一度整理が必要になると思います。下記の図のように人間が理解する形式でなくても大丈夫ですが、画面設計、DB設計、API定義といった形式で「layer1+α」のような中間コンテキストを生成する（これもAIで生成）のがポイントです。
コンテキストの使い分け
そのあとの利用方法は簡単に例を示すと下記のようなイメージです。基本的には生成したいコードによってコンテキストを使い分けることです。実際にプロジェクトで必要なコンテキストは何かをぜひ考えてみてください。
重要な「人」の介在と未来
再度下記のレイヤーを見てみますがポイントは「人」をあえて書いていないことです。
もちろん途中の矢印では人は暗黙的に登場するのですが、ポイントは各層を分離したうえですべての情報を人の記憶領域ではなく、GitHubなどでコード管理することです。
- layer3（第3層）：思考・アイデア（Concept）
- layer2（第2層）：ドキュメント・成果物（Facade）
- layer1（第1層）：実体ファイル（Definition）
またもうひとつ重要な点として残念ながらlayer3は記録が難しいという点があります。
僕はエンジニアの今後の生き残りのためには「業務ドメイン知識」が重要であることを様々な場で伝えているのですが、PaCの流れを見て貰えば、それがどの層に該当するかわかると思います。だからこそ頭の中にある経験則や知識もまだまだ重要だと思っているのです。（少し脱線でした）
実際の現場での浸透はどうするか
さて最後に非常に重要な点を投げかけましょう。
現場浸透にあたり、PaCを本気でやるにはプロジェクト事ではなく会社事になる可能性が高いです。なぜなら既に走っているプロジェクトの情報をコード化するのは骨が折れるからです。サイロ化とはよく言ったものです。まさにPaCの前にはBefore AIのサイロとAfter AIのコードが横たわっています。
個人的にはまずは新しいプロジェクトからPaCを進めていき効果のほどを実感していくことが重要です。（というのもこの流れをある程度は自動化する必要もあるからです。そのため最初が肝心です）
最後に
以上、駄文にお付き合いくださりありがとうございました。
普段はXでAI駆動開発の組織論などについて語っているのでぜひ未フォローの方はフォローしてもらえると嬉しいです！また『クマイ総研』というAI駆動開発のコミュニティ運営もしています。月に2～3日しか募集していないのですが気になる方がいればぜひチェックを！
ではでは、皆さんの貴重なお時間でお付き合い頂きありがとうございました！クマイでした～