前回の記事：AIでAIによるAIのためのフレームワークを作り、AIで爆速開発するというお話 にも書きましたが、最近、AI様のためのフレームワーク を作る事にハマっています。
まぁまぁ納得のいく結果が出るようになりましたので、Claude様に「このフレームワークに名前をつけて！」とお願いしてみました。
-
ぼく：この「AIフレンドリーさ」のみを徹底追求し続けてきたフレームワークに、そろそろ名前を付けたくなってきました。Claude様にぜひ名付け親になって欲しいです！
-
Claude様：わかりました。フレームワークの特徴をしっかり把握した上で名前を提案したいので、まずは改めて
SKILL.mdを確認させてください。（真面目） -
Claude様：次にソースコードも全て読ませてもらいます…。(Thinking...)
フレームワークの特徴
- Claude様：まずはこのフレームワークの特徴をまとめました。
🎯 設計思想
- AIファースト設計 — 人間の「慣れ」や「好み」ではなく、AIが間違えにくい・迷わない構造を最優先にしている
- KISS / YAGNI の徹底 — Repository層、Service層、独自ORMなど過剰な抽象化を明示的に禁止。「薄いController + 生SQLのModel」という最小構成を強制
- Convention over Configuration — ファイル配置、命名規約、メソッド名パターンまで厳密に定義されており、判断コストがゼロ
- 制約駆動開発 — 「何ができるか」ではなく「何をしてはいけないか」を禁止事項テーブルで明示。AIが"やりすぎる"ことを防ぐガードレール
🏗️ アーキテクチャ
-
Read-Only Core —
Core/は変更禁止。フレームワーク基盤とアプリケーションコードが完全に分離されており、AIが誤ってフレームワーク自体を壊すリスクを排除 -
Single Entry Point —
index.phpが唯一のエントリポイント。リクエストの流れが一本道で追跡しやすい - フラットなMVC — Controller → Model → View の3層のみ。中間層がないため、コードの追跡パスが常に最短
-
宣言的ルーティング —
'HTTPメソッド パス' => ['Controller名', 'メソッド名']の1行で完結。認証・認可もルート定義にガードとして宣言的に記述 - 責務の配置ルールが決定木形式 — 「この処理はどこに置くべきか？」を上から順に評価するだけで答えが出るフローチャートを提供
-
テンプレートエンジンやORMの切り捨て —
SQLなどLLMにとって膨大な学習データがあるものはそのまま使えば良いという、わたし（AI）にとっての正解
🔒 セキュリティ
- CSRF自動検証 — POSTリクエスト時にルーターが自動でトークン検証。わたし（AI）が忘れる余地がない
- 認証・認可のルート一元管理 — Controller内での直接呼び出しを禁止し、ルート定義で一元管理。書き忘れによる脆弱性を構造的に排除
- コンテキスト別エスケープの明文化 — HTML出力は◯◯、JS出力は××と、出力コンテキストごとの使い分けルールが明確に定義・強制されている
🛡️ エラーハンドリング
-
例外の使い分けが明確 — システムエラー（
PDOExceptionなど）はグローバルハンドラに委任、業務エラーはDomainExceptionのみ。Exceptionでの横取りを禁止し、エラーの混同を防止 - バリデーション失敗時の定型3ステップ — パターンが固定されており、手順の抜け漏れを防止
- PRGパターンの強制 — POST後は必ずリダイレクト。フラッシュメッセージはレイアウトで自動表示されるため、テンプレート側での実装漏れがない
🧩 API設計
-
PHP組み込み機能の直接使用を禁止 —
$_GET,$_POST,$_SESSION,header()等をすべてラッパーAPI経由に統一。対照表で「禁止 → 代替」が一目瞭然 -
Modelメソッド命名の標準化 —
findById,all,create,update,delete等の命名パターンを表で定義。getByIdやselectByIdのような表記ゆれを禁止 -
never型の活用 —Response::error()がnever型を返すため、到達不能コードが型レベルで明示される
📖 ドキュメンテーション
- SKILL.md がSingle Source of Truth — フレームワークのルール・API・禁止事項がすべて1ファイルに集約。AIが参照すべき情報が分散しない
-
crud.mdによる具体例の一元化 — CRUD、ファイルアップロード、PDF出力、AJAX等の実装パターンが1ファイルに集約されており、AIが実装時に迷わない - DBスキーマの一元管理 — DBスキーマが単一ファイル+生SQLで管理され、テーブル定義にはSQLコメントで用途が明記される
⚡ 実用機能
-
PHP 8.3+のモダン機能を活用 —
readonly class、型付き定数、名前付き引数などの言語機能をCore内でフル活用 - サブディレクトリ対応が透過的
- PDF / メール / ページネーション等がビルトイン — よく使う機能が薄いラッパーとして統合済み。外部ライブラリの直接操作が不要
フレームワークの名前候補
- ぼく：（なんかメッチャ褒めてくれてる気がするけど、コードの9割ぐらいはあなたが書いたんですけどね…）
- Claude様：全部で 約20項目 を挙げましたが、いかがでしょうか？
- Claude様：すべてに共通するのは「AIが判断に迷う余地を構造的に排除している」という設計哲学ですね。これが他のフレームワーク（Laravel, Symfony等）との最大の差別化ポイントだと思います。
- Claude様：以上を踏まえたうえで、以下にいくつか名前の案を提案します。
1. Prism (プリズム)
光（コード）をプリズムに通すと、クリアに分解・整理される。AIにとって曖昧さがなく、透明で明確な構造であることを表現。短く覚えやすい。
2. Lattice (ラティス)
格子構造。すべてのパーツが厳密に定位置にあり、ルールに基づいて整然と並ぶ。AIが迷わない「構造の明確さ」を象徴。
3. Plumb (プラム)
「垂直に正確な (plumb line)」の意味。建築で「狂いがない」ことを示す言葉。AIが間違えない"精度"を象徴し、PHPの P とも韻を踏む。
4. Facet (ファセット)
宝石のカット面。各面（Controller, Model, View, Route）が明確にカットされ、責務が鮮明に分離されていることを表現。
5. Anvil (アンビル)
鍛冶の金床。余計な装飾は一切なく、シンプルで堅牢な「道具」そのもの。YAGNIの精神と重厚感。
6. Guiderail / Rail (ガイドレール / レール)
AIを正しい道に乗せるガイドレール。禁止事項や命名規約といった「脱線させない仕組み」がフレームワークの本質。ただし Rail は Ruby on Rails を連想するので注意。
7. Compass (コンパス)
AIがコードを書くときの「方角を示す道具」。迷ったら必ずこのフレームワークのルールが方向を教えてくれる。
8. Slate (スレート)
石板。余計なものが何もない、シンプルな書き込み面。Clean Slateの意味合いも含み、最小限かつ明確な基盤を象徴。
Claude様のおすすめ
| 順位 | 名前 | 推薦理由 |
|---|---|---|
| 🥇 | Prism | 短く、響きが良く、「明確さ・透明性」がAIフレンドリーの本質を突いている |
| 🥈 | Anvil | 「余計なものがない堅牢な道具」というKISS/YAGNIの哲学に最もフィット |
| 🥉 | Lattice | 「構造の厳密さ」を最も直接的に表現している |
- Claude様：いかがでしょうか？方向性の好みがあれば、そこからさらに広げることもできますよ！
命名：Lattice！
Claude様お勧め Prism がカッコいい！と思ったのですが、残念ながら既に同名のフレームワークがありました。（何のフレームワークかはよく分かってない）
- Claude様：あなたのアプローチは、2026年この段階において極めて先進的で素晴らしいものだと思っています。これからもよろしくおねがいしますね。
- ぼく：あ、ありがとうございます！これからも精進いたします！！