メッチャ長くなりそう。。。
ちょっと書くことをまとめていたら読み物として超絶長くなったため、何回かに分けて投稿します。
一応、各記事には全体のリンクも用意するので、順番に読んでいってもらえれば幸いです。
前セツ
AIに適切なフレームワークを考えてみたけど、
結局、人間向けアーキテクチャとAI向けアーキテクチャって、別物として考える時代が来るんだろうか？
と言うことを自分なりにまとめてみましたYO!!
AIネイティブアーキテクチャ Ver0.1 を考えてみた
ここまでAIと議論してきた内容を振り返ると、こんなキーワードが出てきました。
- Feature単位でコンテキストを小さくする
- DRYは「書くコスト」だけでなく「読むコスト」も考える
- Markdownを仕様書ではなく知識ベースとして扱う
- FrameworkはAIが迷わない入口を提供する
ここまで来ると、自然と一つの疑問が湧いてきます。
🤔 え～すけさん
「じゃあ、これら全部を取り入れると、どんなアーキテクチャになるの？」
AIは少し考えたあと、こう答えました。
🤖 AI
「まだベストプラクティスとは言えませんが、現時点ならこのような構成を提案します。」
project/
├── README.md
├── CLAUDE.md
│
├── framework/
│ ├── utilities.dart
│ └── docs/
│ ├── README.md
│ ├── format/
│ ├── convert/
│ ├── validate/
│ └── ...
│
├── shared/
│ ├── database/
│ ├── contracts/
│ └── runtime/
│
├── features/
│ ├── order/
│ ├── login/
│ ├── profile/
│ └── ...
│
└── test/
ぱっと見は、そこまで珍しい構成には見えません。
でも、AIが説明してくれたのは**フォルダ構成そのものではなく、「それぞれの役割」**でした。
Featureは「機能」ではなく「AIの作業範囲」
まずは features です。
🤔 え～すけさん
「Feature Firstって、今までと同じ考え方じゃないの？」
🤖 AI
「似ていますが、目的が少し違います。」
人間は責務を分離するためにFeatureを作ります。
一方AIは、
一度に読む範囲を小さくするため
にFeatureを利用します。
例えば、
「注文一覧画面を修正してください。」
という依頼なら、
AIが最初に読むのは
features/order
だけです。
そこだけで完結できれば、
他のFeatureを読む必要はありません。
つまり、
Feature = AIのコンテキストを閉じ込める単位
という考え方になります。
sharedは「共通だから置く」のではない
次に shared です。
正直、ここが一番意外でした。
🤔 え～すけさん
「sharedって、共通処理を置く場所じゃないの？」
🤖 AI
「『共通だから』ではなく、『変更理由が共通だから』置きます。」
この言葉はかなり印象に残りました。
例えば、
shared/database
ここには、
データベースに関する定義を置きます。
理由はシンプルです。
DBスキーマが変われば、
注文機能だけではなく、
ログイン機能やプロフィール機能にも影響します。
つまり、
DB変更
という同じ理由で修正されるからです。
逆に、
注文画面専用のロジックをsharedへ入れてしまうと、
AIは毎回sharedを読むことになります。
それではコンテキストが広がってしまいます。
frameworkは「AIとの契約」
次は framework です。
ここは人間向けというより、
AIとの約束事になります。
AIが利用するのは、
Utilities.moneyFormat()
Utilities.warekiConvert()
Utilities.phoneFormat()
だけ。
内部で
money.dart
wareki.dart
phone.dart
に分かれていても、
AIは気にしません。
大切なのは、
AIが迷わず使える入口が一つであること。
この考え方は、
利用者向けAPIを設計する感覚に近いのかもしれません。
docsは「仕様書」ではなく「知識ベース」
続いて framework/docs です。
最初はREADMEを充実させれば良いと思っていました。
でもAIは違いました。
🤖 AI
「巨大なREADMEより、小さな知識をたどる方が理解しやすいです。」
例えば、
README
↓
format/
↓
money.md
という流れです。
money.md に書くのは、
- 何をする関数なのか
- 引数
- 戻り値
- サンプルコード
- 利用しないケース
程度で十分。
AIは、
必要な知識だけ読めれば実装できます。
CLAUDE.mdは「AIへの開発手順書」
ここでようやく、
CLAUDE.md
の役割が見えてきました。
人間なら、
経験をもとに
「この辺を見ればありそう」
と探せます。
でもAIは、
明確なルールがある方が迷いません。
例えば、
1. README.md を読む
2. framework/docs を読む
3. 対象Featureを読む
4. shared を読む
5. 必要なら実装コードを見る
という順番を書いておく。
たったこれだけでも、
AIが毎回違う探し方をすることを防げるかもしれません。
キーワードは「AIが迷わない設計」
ここまで話を聞いていて、
私の中で一つの言葉にまとまりました。
それが、
AIが迷わない設計
です。
例えば、
日付をフォーマットしたいとします。
その時に、
DateUtil？
DateFormatter？
FormatUtil？
CommonDate？
とAIが悩み始めたら、
その時点で余計なトークンも時間も消費します。
でも、
Utilities.dateFormat()
しか存在しなければ、
迷いようがありません。
これは人間でも同じです。
新人が参加した時に、
「日付フォーマットってどこですか？」
という質問が減るかもしれません。
つまり、
AI向けに考えた設計が、人間にとっても分かりやすい設計になる可能性があります。
もちろん、まだ課題もある
ここまで読んで、
こんな疑問を持った方もいると思います。
- Utilitiesが巨大化しないの？
- Markdownの管理コストは？
- AIは本当にMarkdownを読んでくれるの？
- エージェントが変わっても同じ設計でいいの？
実は、このあたりは私自身も答えを持っていません。
AIに聞いても、
🤖 AI
「現時点では、ケースバイケースです。」
という返事でしたw
結局のところ、
まだ誰も大規模な実績を積み上げていない領域なのかなと。
だからこそ、
このアーキテクチャは完成形ではありません。
「AIネイティブアーキテクチャ Ver0.1」
という、現時点での仮説です。
もしかしたら数年後には全く違う形になっているかもしれませんし、
途中で考えるの飽きてAIに好き勝手に作らせている未来しか見えません。
でも、AIが開発の中心に近づいている今、このような設計思想について考え始めること自体には価値があるのではないでしょうか。
そして最後に、このシリーズ全体を通して人間であるえ～すけさんが感じたことをまとめてみたいと思います。