オレ流AI駆動開発

Emacsはエディタとしてはもちろん、Programmers Work Benchといったような形の一種のIDEとして使っています。ファイルの編集以外にマルチ・コンソール、ファイル操作、Git操作といったものですね。

一方、Emacsで提供していない機能、提供していても使いづらい機能は外部ツールを併用しています。

デバッガはIntelliJ IDEAを使用し、AI連携にはVSCodeを使っています。

VSCodeのCodex機能にOpenAIが統合されたのは2025年10月末頃ですが、これによってAI駆動開発の効率は一気に向上しました。

それまではチャッピーくんを補助的に使っていましたが、チャッピーくんとコーちゃんのコンビネーションによって、AIを前提とした開発スタイルが成立するようになりました。

Plus契約でコストが比較的抑えられている点もありがたいところです。

プログラミング言語はScala 3です。Catsによる関数型プログラミングを導入しています。

テスティング・フレームワークにはScalaTestを使っています。

SIE (Semantic Integration Engine)プロジェクトでは、実際に手でコードを書く量はかなり減りました。

ただし、チャッピーくんもコーちゃんも、本当の核心部分やアーキテクチャの要となる部分はうまく捌けないことが多いです。

アーキテクチャ・ベースラインや設計の背骨となる部分は人間が作り、その上に載る実装をAIに任せる、という役割分担が最も安定しています。

ドキュメントは以下のものを作成します。

ドキュメントは人間とAIが共有する知識なので、基本は英語で書いています。

チャッピーくんは内部的に英語で思考しているらしく、日本語だけで書くと翻訳コストや意味の揺れが発生しやすくなります。

control flow / control-flow / コントロールフローといった表記揺れに加えて、quality attribute が「品質特性」「品質属性」「品質要件」と訳されたり、safety と security がどちらも「安全性」と訳されてしまうといった翻訳揺れによる曖昧さを避けるためにも、英語で記述した方が精度が高くなります。

これは単なる翻訳の好みの問題ではなく、LLMの内部構造に起因する必然でもあります。

大規模言語モデルは、英語を中心とした膨大なコーパスを元に語彙同士の関係性を高次元ベクトル空間として学習しています。

この空間では、quality attribute、safety、security、reliability といった語は、それぞれ異なる位置関係と意味的距離を持っています。

一方、日本語に翻訳すると、複数の英語が同一の日本語に畳み込まれたり、1つの英語が文脈ごとに異なる日本語に分解されるため、本来分離されていた意味ベクトルが潰れてしまいます。

その結果、LLMは「どの概念を指しているのか」を文脈推測に頼らざるを得なくなり、推論やコード生成の安定性が低下します。

英語で記述することは、LLMにとって意味空間を安定させ、概念間の距離を正しく保ったまま推論や生成を行わせるための、最も低コストで効果的な方法です。

Executable SpecificationをSimpleModelingでは「検証可能仕様」と呼びます。

BDD (Behavior-Driven Development)スタイルで書かれたテストプログラムであり、

という性質を併せ持っています。

検証可能仕様を実行すれば、仕様通りに動作していることを機械的に確認できます。 回帰テストとしても非常に重要です。

仕様検討はチャッピーくんと一緒に行います。 ただし、複数ファイルを同時に参照できない制約があるため、実態調査や横断的な確認はコーちゃんに依頼します。

仕様案をチャッピーくんがまとめ、軽く人間が確認し、違和感がなければ実装に進みます。

コーディングは基本的にAIに任せます。 うまくハマると、そのまま使えるコードが出てきます。

ただし、事故も起きるため、小さく作ってこまめに評価することが重要です。

コーディングを進めてフィードバックを繰り返すことで仕様が固まってきます。この仕様をドキュメント化します。

チャッピーくんはセッションが変わると仕様を忘れてしまう、うろ覚えで不確実な情報を使ってしまう、ということが多々あるのでこまめに仕様のドキュメント化しておくことが大事です。

ここでちゃんとしたドキュメントを残すことでAIが設計やコーディングに活用できる情報が増えて、より精度の高い作業が可能になります。

ドキュメントを作ることは大変な作業ですが、ここはAIの得意分野なのでAIにお願いすれば案外大した手間ではありません。

ここでまとめてもらった仕様はそのままドキュメント化するのではなく、現存する複数のドキュメントに対して適材適所で反映していくことになります。 そして、独立してドキュメント化した方がよい場合のみ新規のドキュメントを作成します。

コーディングや仕様のドキュメント化と並行でも、仕様が固まった後でもよいので、検証可能仕様を作成します。 つまり仕様を確認するテスト・プログラムを作ります。

テスト・プログラムを作ることで、仕様の過不足などを検知することができます。 プログラムが仕様通りに動作することを確認することができます。

AIがプログラムを破壊してしまう可能性が常にあるので、回帰テストで常にプログラムが想定通りの動作を維持できているのかを確認するのは非常に大切です。 同時にGitを使って、破壊されても元に復元できることを担保しておくことも大事です。

チャッピーくんとの会話を通じて育て、コーディングや検証可能仕様によって精度を高めた仕様を、プログラムの中だけでなくドキュメントとして形式知化して蓄積していきます。

ドキュメントと検証可能仕様を蓄積することで、AIが参照できる知識ベースが育っていきます。

チャッピーくんにプログラミングを依頼すると、与えられた条件の中で最も効率のよい方法を選択してきます。 この時に何の制約もないと、開発中のコードと安定しているコードの見境もなくフリーダムに安定しているコードの方を破壊してしまうことが多々あります。

逆に修正してはいけない箇所や修正時に考慮する点などを細かく指定すると、その司令の通りにコーディングをするので満足のいくものができあがってくる可能性が高いです。

このため、いかにドキュメントを整備してコーディングに対する制約を入れていくのかというのがAI駆動開発のポイントを担うのではないかと思いました。

ただ、1つのプロンプト (Prompt)に全ての情報を盛り込むことはできないので、目的別のドキュメントを作成しAIが活用しやすいように組織化することが重要だと思います。

知識グラフによる知識表現をモデリングに活用するためのツール開発の記事です。 11月の中旬に知識グラフを生成AIに接続することの重要性に気づき、調査と開発を進めたものをまとめていったものです。

オレ流AI駆動開発に興味のある方は以下のGitHubプロジェクトのドキュメント構成が参考になるかもしれません。