AI Native Engineering

AI-native Engineering

人間主体の開発で身についた「大変そうだから小さく始める」という直感を、そのままAI主体の開発へ持ち込まない。AIは明確な仕様を持つ実装・検証・移行作業を長時間かつ並列に進められる。人間なら大規模に見える基盤整備でも、AIが数日継続して進められ、人の関与が判断とレビューに限られるなら、十分に安いことがある。

同時に、AIが作れることと、作る価値があることは別である。需要未確認の機能や将来像だけに基づく汎用機構は、コード量だけでなく、理解・変更・運用する対象を増やす。

目的は初期実装量の最小化ではない。プロダクトのライフサイクル全体で、手戻り、移行、保守、並列開発の阻害、機会損失を最小化しながら、本来あるべき品質を最短で実現することである。

これは最も多く作ることでも、最も少なく作ることでもない。必要な契約と品質を満たす最も単純な構成を選び、機構は実需に合わせて足す。

最上位原則

1. 今の実装コストではなく、総コストで判断する。 実装、将来の移行、データ変換、互換維持、運用、障害、開発停止を含める。
2. 後から高く付く決定を先に正す。 全体へ波及する基盤や不可逆な契約は、現在小規模でも妥協案へ流さない。
3. 同じ結果を出せるなら、最も単純な構成を選ぶ。 機構、抽象、概念、運用対象を増やす案は、増やす具体的な理由を示せない限り採らない。単純さは品質の削減ではなく、同じ品質を少ない仕組みで達成することである。
4. 後から安く足せるものは需要を待つ。 独立した機能、表示、便利機能は、実需が出た時にAIで追加できるなら先回りしない。
5. コア体験の品質を後回しにしない。 ユーザーが価値を得る主要導線は、機能数を絞っても、操作性、明瞭さ、応答性、accessibility、失敗時の回復を含む完成度を初期から高くする。
6. 品質をYAGNIの対象にしないが、機構の量と混同しない。 テスト、データ整合性、復旧可能性、現在の脅威モデルに必要なsecurityは価値を成立させる条件である。脅威や規模のない防御機構は品質ではなく投機的な運用負荷として評価する。
7. 人間の時間とAIの時間を分ける。 AIの実装時間を人間工数と同じ重さで扱わず、人間の判断待ちと外部待ちをカレンダー上の支配要因として扱う。
8. 理想形は機構の最大化ではない。 業界標準に沿い、根本問題を解き、将来の主要経路を塞がず、不要な概念を持たない形を理想とする。

なぜ「後から高く付くか」が重要か

一度広く使われた基盤契約は、変更時にコード以外も動かす。

• データ移行、二重書込み、backfill、互換期間が発生する。
• API利用者、複数repository、デプロイ、監視、運用手順へ波及する。
• 認証・権限境界の変更は、全経路の再監査を要求する。
• 大型refactor中は共有箇所が不安定になり、他の並列実装を止める。
• 移行期間中の二重構造が、障害と認知負荷を増やす。

AIが移行コードを速く書けても、状態を安全に動かす順序、互換性、観測期間、人間の確認、外部連携までは消えない。したがって、変更半径が大きく、状態を持ち、他作業を長く塞ぐ決定ほど、初期に良い設計へ投資する価値が高い。

5つの判断軸

提案ごとに、少なくとも次を言語化する。

1. 後戻りコスト

• 変更対象は局所か、全体横断か。
• 永続データ、外部API、認証境界、公開契約を持つか。
• 移行中に旧新を併存させる必要があるか。
• 変更中に他の実装レーンを止めるか。
• 失敗時にデータ損失、権限事故、長期停止が起きるか。

2. 必要性の確度

• 本気で運用する上で避けられない能力か。
• 業界標準やシステムの性質から高確率で必要になるか。
• 現在の受入条件、脅威、規制、運用に必要か。
• 具体的な利用者・ユースケースがあるか、単なる想像か。

3. AI圧縮率

• 仕様が明確で、機械的に実装・検証できるか。
• 独立レーンへ分割し、AIが止まらず進められるか。
• 人間の入力なしにテストで正しさを確定できるか。
• 数日AIを継続稼働させる間、人間や他レーンをどれだけ拘束するか。

4. 人間・外部依存

• 要求確認、優先順位、法的判断、業務判断が未確定か。
• UI/UXの目視、実利用者のフィードバックが必要か。
• 権限者の操作、外部審査、契約、観測期間が必要か。
• 同時実行枠、rate limit、共有環境容量など実在する上限があるか。

AI圧縮率が高くても、4が支配する工程はカレンダー上ほとんど縮まらない。逆に3が高く4が低い基盤整備は、人間の感覚より大幅に前倒しできる。

5. ユーザー体験への影響

• ユーザーが価値を得るために繰り返し通るコアジャーニーか。
• 利用頻度、失敗頻度、操作時の認知負荷は高いか。
• 暫定的な操作や概念が、学習コストや将来の互換性として定着するか。
• 機能不足なのか、既知の使いづらさ・分かりにくさなのか。
• 目視評価や実利用者feedbackを、実装と並行して早期に開始できるか。

コアジャーニーでは、実装工数を理由に既知の不便を残さない。低頻度の補助機能や例外導線は、同じ設計・検証密度を要求せず、必要性に応じて追加する。

判断マトリクス

「今作る」と「何もしない」の二択にしない。高い後戻りコストと不確かな需要が組み合わさる場合は、最も危険な仮定を早く検証し、安い選択肢を残す。

原則として先に決める判断

次の領域は、運用するプロダクトで必要性が高く、後から変えると変更半径が大きい。ただし前倒しするのは契約・境界の決定であって、機構の実装ではない。両者を混同すると、必要な決定を先送りしながら不要な仕組みを先に作るという、最も高く付く組み合わせになる。

左列は現在小規模でも曖昧にしない。右列は「永久に作らない」ではなく「観測された利用・負荷・脅威が出てから足す」である。単一databaseで十分なら分散databaseは要らないが、単一databaseの中でも制約、migration、backup、ownershipは決める。

本番投入せず、架空dataで仮説だけを確認して廃棄するprototypeはこの対象ではない。後戻りコストと運用責任が実際に低いなら、再現可能性・隔離・廃棄可能性など仮説検証に必要な品質だけを持たせ、本番基盤を押し付けない。

需要を待つ領域

次は一般に後付けしやすく、需要の確度を優先する。

• 利用が確認されていない補助画面、例外的な操作、通知、export形式
• 仮想的な利用者向けの高度な設定項目
• 実需のない外部サービス連携
• 使われるか不明なdashboard、管理UI、rule builder
• 具体的な負荷がない段階での性能最適化
• 1つの事例しかない時点でのplugin化・framework化

ただし、後付け時にデータモデルや権限境界を壊す機能なら、その境界だけは先に設計する。

フェーズの切り方

段を正しく切れば、単純さと品質は両立する。順序を崩して機構を先に積むことも、契約を決めずに動くものだけ作ることも、どちらも手戻りを生む。

Phase 0 — 全体を設計する。 コアジャーニー、受入条件、上表の「今決める」列を確定する。この段の成果物は決定と契約であり、実装量ではない。ここを飛ばすと後の全段が手戻りになる。

Phase 1 — 動くものを最短で通す。 コアジャーニーを end-to-end で1本通す。契約は Phase 0 のものを使い、機構は最小に留める（単一database、直呼び出し、手動運用でよい）。受入条件は「主要導線が実際に価値を出せること」であり、動いた形跡ではない。

Phase 2 — 実需に合わせて足す。 観測された利用、負荷、脅威、feedbackを根拠に機構と機能を追加する。ここで足すものは Phase 1 の契約の内側に収まるはずで、収まらないなら Phase 0 の決定を見直す。

各段で問う: この段の受入条件は何か。次の段へ進む条件は何か。今作っている仕組みは、どの段の受入条件に必要か。どの段の受入条件にも紐づかない仕組みは、まだ作らない。

Phase 1 の「最小」は品質の最小ではない。落とすのは機構の量と機能の幅であり、コア体験の操作性・明瞭さ・失敗時の回復や、テスト・データ整合性・復旧可能性のような品質条件ではない。工数や単純化を理由に、あるべきユーザー体験や中長期に効く施策を段の外へ捨てない。落とす場合は「どの段で回収するか」をセットで示す。

コア体験は最初から高い完成度を目指す

すべての画面や機能を等しく磨くのではなく、ユーザーが価値を得るために頻繁に通るコアジャーニーを優先する。削る対象は機能の幅であり、コア体験の質ではない。

コアジャーニーでは単に動くことだけを受入条件にせず、次を満たす。

• 初見でも操作と結果を理解でき、頻繁な操作を少ない認知負荷で完了できる。
• 待機、成功、空状態、部分失敗、復旧方法が明確である。
• 応答性、accessibility、keyboard操作などの基本品質を満たす。
• 内部都合や既知の不便を「後で磨く」として利用者へ押し付けない。

AIは複数案の実装・比較も圧縮できるが、UI/UXの目視と実利用者feedbackは人間依存である。実装と並行して早期に評価を始め、明確な改善余地を工数で退けない。

Securityはリスク比例で設計する

最も堅い構成ではなく、現在の脅威モデルに十分で、将来の強化を妨げず、後から直すと高く付く信頼境界を初期から正す。security上望ましい、または将来必要かもしれないという理由だけで防御機構を追加しない。

提案時は、守る資産、攻撃者、到達可能な経路、侵害影響、既存統制の不足を具体化する。その上で、導入を待った場合の移行コストと、対策自身が増やすsecret・権限・障害点・運用負荷を比較する。

資産やprincipalは、現在の受入条件に実在し、侵害・誤操作・取り違えで損害または説明責任が生じるものを指す。将来いるかもしれない利用者やdataは数えない。対応する資産、principal、secret、到達経路が存在するなら、現在小規模でも、認証・認可、identity・ownership、組織境界、secret管理、入力・信頼境界、安全なdefaultなどの業界標準baselineは落とさない。単一利用者・offline・使い捨て環境では、存在しない境界のための機構を新設しない。特に、永続dataやAPI全体へ広がる境界、将来の権限強化や鍵変更を妨げる契約は初期に正す。

一方、具体的な需要・脅威・規制がなければ、高度なABAC、未利用のSSO/SCIM、常設監視bot、SIEM連携、per-tenant鍵、全経路mTLS、service mesh、大規模security event pipelineは待つ。現在のリスクが低く後付けが高価な場合は、機構全部ではなく境界・schema・移行可能性だけを先に確保する。

投機的な抽象化を見分ける

抽象化は「将来ありそう」ではなく、現在確認できる変化軸に対して行う。

投機的である例

• 1種類の実装しかないのに、provider interfaceとplugin loaderを作る。
• 具体的な2つ目の利用者がいないのに、汎用workflow frameworkへする。
• 単一組織で使う段階に、仮想的なmulti-tenant機能一式を作る。
• エンジニアが設定ファイルを直せば足りる段階で、汎用rule builder UIを作る。
• 実測負荷が小さいのに、将来のscaleだけを理由に分散構成へする。
• 未契約・未選定の外部サービスを複数差し替えるためのadapter群を作る。

投機的ではない例

• 既に2つ以上の実装で差分が確認でき、その共通部分を抽出する。
• 選定済みの外部SDKを薄い境界へ閉じ込め、domain modelへの漏出を防ぐ。
• database migrationやAPI versioningのように、利用開始後の導入が高価な変更経路を用意する。
• 認可判定を各handlerへ散らさず、検証可能なpolicy境界へ集約する。
• 外部副作用へidempotency keyを設け、再試行で重複しない契約にする。
• 本番運用が決まっているシステムへ、deploy/rollbackとbackup/restoreを用意する。

判断に迷ったら問う: この抽象化は、観測済みの差異を整理しているか。それとも、まだ存在しない差異を発明しているか。

provider未選定なら、provider interfaceや差し替え機構はまだ作らない。現在のユースケースが必要とするrequest/result契約と外部副作用の呼出箇所だけを局所化し、具体的なSDKが選定された時点でその依存を境界内へ閉じ込める。

BASIS ラベル

機構・抽象・防御・設定の追加、またはその提案には、必要性の根拠を次の4分類で明示する。

• BASIS: OBSERVED — コードやテストで観測された事実、再現する不具合
• BASIS: CURRENT-THREAT — 現在の脅威モデル・受入条件・規制の要求
• BASIS: REAL-DEMAND — 実在する利用者・ユースケース
• BASIS: SPECULATIVE — 「将来こうなるかもしれない」という仮説だけが根拠

本節が定めるのは分類だけである。SPECULATIVE の処分 — 削除を既定とするか、保留して人間の判断材料に回すか — は、このラベルを使う各スキル・工程が自分の層で宣言する。分類の判定に迷う場合は、上の「投機的である例」「投機的ではない例」に照らす。

工程別の圧縮率を変える

見積もりや計画で一律の「AIなら速い」を使わない。

高く圧縮しやすい

• 明確なschema、型、CRUD、変換、配線
• 独立したtool、test、fixture、migration script
• lint、format、静的検査、機械的refactor
• 契約が固定された後の並列実装

中程度

• 新規性のあるarchitecture、複数systemの結合
• security review、failure mode設計、性能検証
• agent prompt、skill、検証engine
• 既存状態を持つ大型migration

圧縮しにくい

• 要求確認、要件確定、優先順位の合意
• UI/UXの目視評価、操作感、実利用者feedback
• 法務・規制・外部審査、契約、権限者の操作
• 本番でしか得られない観測期間
• 人間が責任を持つ最終判断

圧縮しにくい工程は早く開始し、回答待ちの間に圧縮しやすいレーンを進める。人間待ちを隠してAI実装日数だけを短く見せない。

計画の作り方

1. 受入条件と「本気で運用するか」を確認する。
2. 大きな設計判断ごとに5軸を評価する。
3. 後戻りコストが高く必要性も高い契約・境界の決定を Phase 0 へ置く。決定と、その決定を実現する機構の実装を、同じ項目にまとめない。
4. コアジャーニーを end-to-end で通す Phase 1 を定義し、その受入条件を書く。
5. 不確実だが後戻りが高い箇所は、実装前半に検証タスクを置く。
6. 圧縮しにくい人間・外部工程を先に依頼・予約する。
7. 実装を依存、整合、リスク、実在する容量制約でgraph化する。
8. それ以外をAIの並列レーンへ置く。未検証の人員感覚や作業量だけで直列化しない。
9. 各項目に「どの段の受入条件に必要か」を書く。書けない項目は Phase 2 以降へ回すか、落とす。
10. 需要未確認で後から安く足せる機能は、外す理由と影響を示して現在scopeから外すことを提案する。自律実行が明示されていなければ、scope変更前にユーザーの確認を得る。

長時間AIを回す案では、経過日数だけでなく次も比較する。

• 人間が拘束される時間
• shared code・環境・agent slotを塞ぐ時間
• 他機能を並列に進められるか
• 今行わない場合の将来migration期間と機会損失

見積もりの作り方

見積もりを求められた場合は分けて示す。

従来の人間主体の尺度: <比較用の作業量・期間>
AI主体の見通し:
- AI実行時間: <連続稼働・並列度・検証を含む>
- 人間関与時間: <要求、判断、レビュー、目視確認>
- カレンダー支配要因: <外部待ち、観測、承認、容量上限>
前提と実測根拠: <既知 / 未検証を区別>

過去実測がなければ精密な倍率を捏造しない。作業を圧縮profile別に分類する。作業一覧、契約数、依存graph、利用可能な並列枠のいずれも不明な段階では、案件類型だけから「数日」「数週間」というcalendar rangeを補わない。まず測定・確認すべき項目と、外部待ちを含む見積もり式を示し、材料が揃ってからrangeを出す。

判断結果に必ず含めるWhy

定型の節を機械的に全部出す必要はない。ただし推奨には、読み手が再判断できるだけの根拠を残す。

• 何を最適化しているか: 初期速度、総コスト、変更容易性、安全性、機会損失
• なぜ今行うか、または待つか。それはどの段の受入条件に必要か
• 検討したより単純な案と、それを採らない理由
• 後戻り時に何が動き、どの作業を止めるか
• AIで圧縮できる部分と、人間・外部依存で圧縮できない部分
• 採らなかった案が、安すぎる妥協か、まだ早い機構か
• 不確実な前提と、それをいつ・どう検証するか

アンチパターン

最終チェック

• 人間の「大変そう」を技術判断へ混ぜていないか。
• 本気で運用するなら避けられない基盤を先送りしていないか。
• 数日間のAI実行を、将来の大型移行より過大評価していないか。
• 後から変える間、他の並列実装が止まる影響を含めたか。
• YAGNIを品質削減や楽な案の言い訳にしていないか。
• 同じ結果を出せる、より単純な構成を検討して却下したか。
• 契約の決定と機構の実装を混同し、機構を先に最大化していないか。
• どの段の受入条件にも紐づかない仕組みを作っていないか。
• コア導線をend-to-endで通す段を、機構の整備より後ろへ置いていないか。
• 未確認の機能や差異を発明していないか。
• コアジャーニーを特定し、機能の幅と体験品質を混同していないか。
• 既知の使いづらさを「後で改善する」で正当化していないか。
• security提案が具体的な資産、攻撃経路、影響に結び付いているか。
• 「security上望ましい」だけで常設機構や新しい権限面を増やしていないか。
• 人間・外部待ちを早期に開始したか。
• Whyを読み手が追跡し、同じ前提から再判断できるか。