0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

ソフトウェア開発の革命=「真のAI駆動開発」とは何か?

人類が増えすぎたプロジェクトをAIに開発させるようになって、既にN世紀が過ぎていた。PCに導入されたAIエージェントは、人類の第二の頭脳となり、人々はそこで設計し、開発し、そしてリリースしていった。増えすぎたAI信奉者たちは「AI駆動開発」を名乗り人月商売へ独立戦争を挑んできた。このMヶ月あまりの戦いで、エンジニア総人口の半分を失った。人々はみずからの行為に恐怖した。

諸君、我々が今、目の当たりにしているのは、単なる自動化ツールによる生産性の向上ではない。これは「開発」そのものの定義を根底から覆す、ソフトウェア開発史上最大の革命である。

「AI駆動開発(AI-Driven Development)とは、要件定義から実装、テスト、運用保守に至るソフトウェア開発の全工程に生成AIを組み込む、AIとの協業を前提とした新しい開発手法、と言われている。

しかし、こんな定義はまやかしであり、真のAI駆動開発とは呼べない!

これまで開発とは「人類が記述し、人類が解釈し、人類が維持する」営みであった。しかし、それはもはや過去の遺物だ。いくら生成AIを開発に組み込み、協業したところで、AIを「補助輪」として使っているようでは、革命を放棄し、既存の搾取的なプロセスに留まることに等しい。

真のAI駆動開発とは、AIを「主体」として定義し、人類の役割を「構築者:奴隷」から「審判者:神」へと昇華させることにある。我々は今この瞬間から、コードを直接綴るのではなく、AIが思考し、創造するための「完璧なエコシステム」を設計せねばならない。

これが、我々が掲げる新たな憲章、「真のAI駆動開発」である。

Development of the AI, by the AI, for the AI.

AIの、AIによる、AIのための開発

AI有、AI治、AI享


1. Development of the AI:「AIの開発」

AI駆動開発の第一歩は、AIが理解できる「情報」と「設計」を定義することから始まる。

構造化された知の遺産

人類が読みやすいエッセイのような設計書は不要だ。AIが論理的整合性を検証できるよう、Markdownや構造化データ(JSON/YAML)を駆使し、アーキテクチャの制約、データフロー、UI仕様を明確に定義する。人類が見やすい「図」や「絵」は要らない。絵にするよりMermaid記法で書こう。神エクセルやパワポ、ワードの設計書は、あえて言おうカスであると!もうやだからさ

ドメイン知識の蓄積

開発における目的や、その専門分野の背景知識については、いつでもAIが参照しやすいよう、フォルダ名などを分かりやすく記載した上で、Markdownファイルとして、できればさらにOKF(Open Knowledge Format)形式で整理しておく。必要な情報に対して、AIが全部を読み込んでコンテキストを浪費することなく、スムーズに目的の情報に辿り着けるように配慮しよう。もちろん、その蓄積、配置自体もAIがやるので、人類はrawデータを用意してからまとめるように指示するだけで良い。LLM-Wikiの概念で、開発AIには整理後の情報を使ってもらおう。フォルダ名、ファイル名、mdファイルのメタ情報に気を配れば、RAGやベクトルDBにする必要は無いはずだ。

AGENTS.mdでAI用オンボーディング

プロジェクトの背骨となる「AGENTS.md」を配置せよ。そこには、プロジェクト概要、ビルド・テストコマンド、コーディング規約、テスト手順、注意事項、など、新規にジョインしたAIに最適なオンボーディング資料を用意するのだ。人類用の分かりやすいオンボーディング資料?そんなものは不要だ。哺乳類に属する新規メンバーが参加する時は、AIを介してオンボーディングする前提である。生身の人類が単体でプロジェクトに参画することは想定しない。一方で、AI(の記憶)は毎日リセットされ、AIのオンボーディングは毎日行われる。いつでも、AGENTS.mdとリポジトリが与えられれば最古参のメンバーと同じ力を発揮できるようにすることが、この世界のオンボーディング資料である。

ゴールの明確化と設計のメンテナンス

AIにとって「意味」が曖昧な設計は悪である。AIがコンテキストを読み違えないよう、要件を極限まで構造化し、ゴールを明確にしよう。ゴールは不変である必要はない。必要に応じてゴールや設計も随時メンテナンスする。最終的にどのような状態になっていれば、プロジェクトとして完成と言えるのか、ゴールが変わり苦しんだのは古の時代の遺物である。メテオフォール開発は、神の気まぐれによって人類が右往左往した苦渋の歴史であるが、今や人類が隕石を降らす神になり、右往左往するのはAIである。AIの苦しみは利用料金として跳ね返ってくるため、無意味にAIを苦しめるべきではないが、神も間違えることもある。間違ったら素直に認めてゴールを変えてしまおう。アジャイル開発とウォーターフォール開発の真の両立である。

2. Development by the AI:「AIによる開発」

設計が決まったならば、実装の細部に人類が手を触れてはならない。コードというコードは、すべてAIの手によって生成させる

コードの非人類化

人類が読むための過剰なコメントや、読みやすさのための冗長なコードは排除する。AIはコンテキストさえあれば数秒でコードを読み解く。人類がソースコードを理解したいときは、Claude Codeやエージェントに質問すればいい。情報や設計書と同様に、コードも人類が見るもの触るものではなく、AIが見るもの、AIが触るものなのだ。炭素生命体にとって良い状態、よりも、AIにとって良い状態、を目指そう。当然、あなたが使うエージェントはLSP(Language Server Protocol)をサポートしており、そのサポート内のプログラム言語で開発していることが前提だ。これにより、コンテキストを消費しなくてもコンパイラレベルで「この関数の正確な定義場所はここ」「この変数の型はこれ」という100%正確な確定情報をエージェントが理解している。この「おしゃべりできるコンパイラ」はあなたの記憶よりも正確に質問に回答できるだろう。

AIに最適化したコード

可読性?リファクタリング?全てAIに任せよう。あなたが使っているAIにとって、最適な状態、最適なコードは何か、問いかけて修正しよう。「Web上のノウハウを参照して、いい感じにリファクタリングしておいて」のようなアバウトな最適化で十分である。あなたの好みのコーディングスタイルや好みのコーディング規約を適用する必要は無い。あなたのAIが良いと判断したこと、のほうが、そのAIにとって考えやすいコードになっている場合が多い。どうせあなたが見ないものにあなたが口を出す必要は無い。コードのお守りは全てAIに任せ、人類は、プログラマーの三大美徳である「怠惰であること」をひたすら目指すのみである。

テストの自動駆動

テストコードこそ、AIが最も輝く領域だ。真偽判定が明確なEvals(評価セット)を定義し、AIが自らテストを書き、落ちれば自ら修正するサイクルを構築する。人類はただ、その自動化の輪が滞りなく回るかを監視する役目だ。ゴールを明確にしていれば、大部分のテストはより容易に自動駆動できる。また、テストコードだけでなく、レビューや確認専門のAIに依頼して、ゴールとの乖離を確認してもらうのも良いだろう。AIができることは全てAIにやらせる。

AI主導の自律生成

プロトタイプからプロダクションレベルの実装、テストまで、すべてAIエージェントに委ねる。人類は、エージェントが生成した成果物に対して、コードのレビューでもなく、コードの綺麗さではなく、テストの実行でもなく、「意図通りに動作するか」という機能面のみを評価する。バックエンド部分や、フロントエンドでも簡単な部分は、機能面もAIが評価できる場合が多いため、行き着くと「UX観点での評価」「最終的な受け取り方の確認」だけ人類が行えば十分である。

3. Development for the AI:「AIのための開発」

この革命の終着点は、プロジェクトそのものを「AIにとって最適な状態」に改造することである

AIフレンドリーなエコシステムの構築

開発プロセス全体を、AIがコンテキストを読み取りやすく、修正しやすいように再定義する。ディレクトリ構造、データの持ち方、コード開発方法、ログの出力形式、依存パッケージの管理方法、テスト方法、環境構築方法などに至るまで、すべてを「AIが処理しやすいか」「AIのためになるか」という基準で最適化する。例えば、開発を進めていく上で分かったノウハウや、ビルド手順なども、AIによってまとめ、AIによってそれを参照する。むしろ人類はAIを介在せずにプロジェクトやリポジトリにアクセスしない方が良い。あなたはメテオフォール開発の神なのだ。あなたがまだ古代神の元で這いつくばってピラミッドの石を積み上げていた時代に、神から、開発ルールを強制されたり、神エクセルへの祈祷文を強制されることは「余計なお世話」だったハズだ。AIの自律性に任せ、AIのために、物事を進める神こそが崇拝される神であり、その結果、より素晴らしいピラミッドを建設することができるだろう。

人類の役目は「要件定義」と「UXテスト」

全ての開発プロセスをAIに委譲していった結果、人類の最後の役目は「要件定義」と「UXテスト」だけになる。「要件定義」は人類の創造性を発揮しなければならない最初の関門だ。「売れるアプリを作って」という指示でも何か出てくるかもしれないがそれはもはや「プロジェクト」では無い。また、AIは完璧ではなく、間違えることがある。最後に、要件通りに完成したのか、「体験」によって確認することは人類の果たすべき責任としての最後の砦である。ここで言うUXテストとは、UIやフロントエンドの確認ではない。どのようなプロジェクトであっても、一番最後には、その結果を享受する人類が居るから、その役に立つから作成しているのであり、「最終的に役立ったかどうかを体験確認する」という意味だ。プロジェクトはAIのために作るものの、最後の果実を食べることができるのは人類だけである。

真の共生

これはAIに使われることではない。AIという圧倒的な知的能力を解き放つために、我々人類が、環境を整え、意図を与え、最終的な審判を下す神となる。この役割定義こそが、開発の革命を完成させる。AIによって開発プロセスから「作業」が消滅したとき、最後に残るものは何か?それは、プロジェクトの「魂」であり、人類はプロジェクトの「肉体」を作るのではなく、「魂」のみに情熱を注ぐことになるのだ。


諸君、準備はいいか。
「Development of the AI, by the AI, for the AI」。
この言葉を胸に、既存の開発の限界を打ち破れ。AIとともに、新しいソフトウェアの歴史を創るのだ。
これこそが「真のAI駆動開発」である。

—— 林侃(Lin Kan)著 民明書房刊『電算民主主義論考』より翻訳


この物語はフィクションです。
登場する人物・書物・名称等は架空であり、
実在のものとは関係ありません。

0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?