Be Framework + BEAR.Sunday — AI コーディング時代の潜在能力

EC-CUBE 4.3 を Be Framework + BEAR.Sunday へ移植する BeMart プロジェクトの途中記録として書く論評。フレームワークそのものの実務レビュー（摩擦点・upstream 課題）は FRAMEWORK_REVIEW.md が扱う。本稿はその先 — 「なぜこの 2 つのフレームワークが AI コーディング時代に効くのか」 を、この移植が実証しつつあることから論じる。

2026-06-01 注記: 本稿の数値は執筆時点の途中スナップショットです。現在の到達点は ../migration-status.md が正で、ALPS route-gate と Ray.MediaQuery cutover 後のプロジェクト規模は拡大しています。本文の価値は数値ではなく、AI エージェントに効いた構造的制約の観察にあります。

論拠は思弁ではない。BeMart の 144 transition・34 storage・34 admin ページは、その大半が並列 AI エージェントの波（wave）で生成された。以下はその実地観察に基づく。

結論

Be + BEAR は AI のために設計されていない。テスタビリティと明晰さという、人間のための理由で設計された。ところがその設計が持つ性質 — 不変性・決定的構造・外部契約 — は、そのまま AI が大規模に正しいコードを書くために必要な性質でもあった。正しい設計が、新しい理由で正しかった、という事例である。

そして同じ「構造による制約」は、まだ解かれていない設計課題をも照らし出す。後半はそれを扱う。

AI コーディングが構造に要求するもの

AI によるコーディングの失敗モードは、モデルの賢さの問題というより構造の問題である:

可変状態の追跡 — エージェントは有限のコンテキストしか持たない。可変状態はプログラム全体に非局所的な影響を撒く。「ここを直すと向こうが壊れる」を AI は追えない。
並列・分散作業の大域的不整合 — 複数エージェント（複数セッション）は、局所的には綺麗で大域的にはパッチワークなコードを生む。本プロジェクトの 8 wave でも section 間の細かな不揃いとして実際に観察された。
接地点（ground truth）の欠如 — AI は「もっともらしい」コードを生む。契約が無ければ「正しそう」が「正しい」を置き換える。
検証ギャップ — コードを書くことより、それが正しいと知ることが難しい。「テストが通る」は「振る舞いが正しい」ではない。
コンテキスト経済 — 1 機能を触るのに 20 ファイルの絡まりを読む必要があれば、AI はコンテキストを焼き尽くして間違える。1 機能が読める局所単位なら成功する。

要するに AI コーディングは本質的に 局所推論 である。良い AI 向けアーキテクチャとは、正しさを局所化するアーキテクチャ だ。

Be Framework の構造的応答

不変性 — 失敗モード 1 を構造的に消す。追うべき可変状態グラフが存在しない。オブジェクトは変化せず、新しいオブジェクトになる。エージェントは Input → Being → Final の局所の鎖だけ読めばよく、プログラム全体を保持しなくてよい。これが最大の効き目。
Becoming chain = 線形に読める物語 — 1 機能が 1 本の鎖。上から下へ読めば機能の全体が手に入る。コンテキスト経済（失敗モード 5）で勝つ。
Final-as-proof — Final オブジェクトが構築できたこと自体が遷移成立の証明。AI に 検査可能な的 を与える。「Final が立ったか」は局所的かつ二値の正しさ信号（失敗モード 4）。
Semantic の名前ベース自動発見 — 概念ごとにバリデーションの置き場所が一意に決まる。エージェントは置き場所を 探さない — 構造が指定する。決定を取り除くこと = AI が間違えようのない決定を増やすこと。
パターン語彙（Direct / Linear / Multi-Reason / Diamond / Branching） — 「これは doRegisterCustomer 型の Multi-Reason Being」と言えれば、エージェントは初回で正しい構造を出す（FRAMEWORK_REVIEW.md で観察）。閉じた少数の「かたち」の語彙は、開放的な生成を 制約付きのパターン具現化 に変える。

BEAR.Sunday の構造的応答

決定的な URI ↔ クラス解決 — 推論すべきルーティング設定が無い。構造がルーティング。エージェントは予測可能なパスにファイルを置けば当たる。決定を 1 つ取り除く。
メソッド単位の薄い Resource — 各 Resource は小さく完結し、丸ごとロードできる単位。再びコンテキスト経済。
#[Link] による遷移宣言 — 次状態がファイル内に宣言される。エージェントは Resource を読めば局所の遷移グラフを見られる。
DI による context 切替 — app / prod / html、テストの Fake。これが検証を成立させた。hypermedia-test-as-contract（G-23、hypermedia-test-principle.md）— Fake 版と SQL 版が同一アサーションで両方緑なら、差し替えは client から区別不能、と構成的に言える。契約が外部にあるので AI は「見えないテスト」を誤魔化せない（失敗モード 3・4）。

メタ命題 — 「Be」であって「Do」でない

2 つのフレームワークは哲学を共有する: 正しさを構造に担わせ、書き手（人間でも AI でも）が間違えうる余地を減らす。

従来のフレームワークは力を与える — やり方が何通りもある。力は AI には危険だ。自由度の一つ一つが drift の経路になる。Be + BEAR は逆に 制約する — 選択肢を削るほどに意見が強い。人間にとっては窮屈に感じうる。だが AI にとっては窮屈さこそが価値 である — 生成されたコードを spec の上に留めるレールだ。

名前のレベルでも符合する。フレームワークは「Do」ではなく「Be」だ。何をするか（命令的な手順）ではなく 何であるか（状態・証明）をモデル化する。命令的コードは変異の列 — AI が最も追えないもの。宣言的な「being」のコードは事実と変換の集合 — AI が最もよく推論できるもの。AI 時代は命令的・手続き的フレームワークより宣言的・存在論的フレームワークに報いる。Be は名前においても本質においても存在論的だ。

ALPS もこの線上にある。ALPS は機械可読な契約 = 接地点。プロジェクト全体の構造は ALPS（spec / 真実）→ Be（構造的に制約されたドメイン）→ BEAR（決定的な境界）→ テスト（外部契約による検証）。各層で AI の drift する自由が囲われている。本プロジェクトは事実上、「spec 接地・構造制約・外部検証」が大規模 AI 移植を実際に成立させるアーキテクチャの形である、という proof-of-concept だ。

発展の余地 — 構造がまだ解いていない問題

この移植は、Be + BEAR を AI 時代のフレームワークとして さらに強くする ための具体的な設計課題を照らし出した。欠点の列挙ではなく、次に解くべき問題のリストである。

G-17 — #[Be] 行き先がクラス固定。 同じ前処理 Being を別の Final に向けられず、Being を複製するしかない。AI にとって複製は 生成は安い が 一貫した保守は高い（パッチワーク問題そのもの）。生成を助ける制約が、大域的一貫性の軸では足を引っ張りうる。
G-23 — 共有配線ファイルの競合。 Be + BEAR はファイル単位の分離（resource ごと・クラスごと）は得意だが、AppModule のような共有配線ファイルは並列エージェントの競合点になった。AI 時代のフレームワークは「共有可変ファイルを最小化する」ことを要求する。本セッションでも per-section ja-message split で同じ発見を再演した — 解決パターンは「共有ファイルを分片化する」。
#[Be] 鎖の静的解析不透明。 BecomingInterface が object を返すため Psalm の taint 追跡が各変容で切れる。AI は速くコードを生むが、検証器が抽象を見通せなければ検証の脚が 1 本折れる。
最も深い含意 — 制約するフレームワークは与えられたものを増幅する。 spec（ALPS）が正しければ構造は正しさを伝播する。spec が微妙に間違っていれば、構造は間違いを効率よく自信ありげに伝播する。AI × 制約フレームワークは 力の乗数 であり、乗数には符号がある。人間の判断はすべて spec / 存在論の層に移る。決定的要素（命名・登録・対応規則）はフレームワークが機械化し、非決定的要素（存在論の設計）が人間の仕事と risk の全部になる。

このプロジェクトが示した（示しつつある）こと

EC-CUBE という実在の商用レガシーアプリが、AI エージェントの波で、クリーンなアーキテクチャへ移植されつつある — おもちゃではなく。Phase A で 144 transition、Phase 2 で 34 storage、Phase 3 で storefront 全画面 + admin の 3 分の 1 強。「アーキテクチャが EC-CUBE の全パターンに耐えるか」という最大の不確実性はすでに retired した。

まだ証明は未完だ（admin Tier-2、stub 7 件、本番カットオーバー）。だが残りは「未知」ではなく「既知の反復と既知の難問」。BeMart は 「制約されたフレームワーク + 外部契約 + 並列 AI オーケストレーション」が成立する という主張の、進行中の実証である。

潜在能力を解き放つために必要なこと

フレームワーク側（AI 時代という観点で FRAMEWORK_REVIEW.md の upstream リストを読み直すと）:

並列編集に安全な配線 — AppModule のドメイン別分割。共有可変ファイルの最小化は AI 時代の第一級要件。
鎖を見通す静的解析 — #[Be] を辿って型と taint を伝播する Psalm プラグイン。検証の脚を繋ぎ直す。
Being の行き先を可変にする道 — G-17 の複製圧を下げ、AI 生成のパッチワーク化を防ぐ。

そして移植ワークフロー自体（.claude/ の orchestrator + worktree 並列サブエージェント + ALPS 契約 + docs/skills/）が、「レガシーアプリを Be + BEAR に載せ替える」再利用可能な方法論として切り出せる。

結語

Be + BEAR の AI 時代における潜在能力は、新機能にあるのではない。既存の設計思想 — 不変性・決定性・契約 — が、人間の明晰さのために選ばれたまま、機械の明晰さにも当てはまった ことにある。

AI は局所推論器であり、drift する。正しさを局所化し、決定を構造に肩代わりさせ、ドリフトを外部契約で捕えるアーキテクチャは、AI を大規模に生産的にする。Be + BEAR はそれをほぼ体現している — 「ほぼ」の差分が上の upstream リストだ。

最後に、最も大事な点を繰り返す。乗数には符号がある。フレームワークが存在論を増幅するなら、存在論を正すこと — ALPS を正すこと — が AI 時代の唯一にして全部の人間の仕事になる。フレームワークはコードを書く仕事を肩代わりした。残るのは「何が あるべき か」を決める仕事だ。それは肩代わりできない。