AI DEVELOPMENT PLATFORM
KUMIRAI ／ AI駆動開発プラットフォーム
設計から単体テストまで、AIが作り、機械が確かめ、人が決めます。
実装の計画を人が承認してから生成し、機械検証と整合性の確認を通したコードをお渡しします。
作業・成果物の版・レビューの指摘・採用の判断を結びつけて残し、担当が替わってもたどれます。
AIがコードを書くようになっても、交付の手前で詰まっている
AIで書く時間が減った分、確かめる時間が増えています ── 2.2万人の開発者の計測では、レビューにかかる時間の中央値が441.5%増えました（Faros AI『Acceleration Whiplash』、2026年）。交付の手前で詰まっているのは次の四つです。
AIの出力は用語・粒度・検査の要求がお客様の標準とずれ、そのままでは納品物になりません。日本語の設計書の「適宜」「検討の上」を、AIは確定した意味に読み替え、読み替えたことを告げません。
資料が欠けていたり食い違っていたりして、業務の規則と残すべき振る舞いが確かめられません。形は正しいのに業務の論理が違う、というコードがここから出てきます。
プルリクエストの数も1件の量も増え、業務の判断と修正の確認は少数の熟練者に頼っています。生成が速くなった分だけ、確認の待ちが長くなります。
作業の状態・採用した版・確認の記録を、そのたびに探し直しています。経緯を知る人がいなくなると、判断の根拠をたどれません。
共通の作業方式と工程
工程が変わっても、作業の型は同じです ── 入力を確かめ、成果物を作り、独立に検査し、人が確かめ、版と証跡を残す。実装と単体テストで、その型がどう具体になるかを切り替えて見られます。
上の帯が KUMIRAI 共通の作業方式、その下がそれを工程ごとに具体にした順序です。
人の確認は二か所です ── 生成の前に計画を、生成の後に指摘の採否を確かめます。事前検査を通らない計画は人の前に出ません。
コードは計画に書かれた依存の順（設定 → 実体と契約 → 永続層 → サービス → コントローラー）で生成します。機械検証は通るまで自動で往復し、同じ作業が3回を超えて往復したら止めて人の判断に回します。実装工程では単体テストを流しません。
上の帯が KUMIRAI 共通の作業方式、その下がそれを工程ごとに具体にした順序です。
テスト方針だけは常に人が主導します。残る五つの環節は、AI の作成 → AI の自己検査 → 人の関門を同じ形で繰り返し、放行されないものは次の環節へ流れません。
バックエンド（JUnit 5）、画面の単体テスト、画面の E2E（Playwright）の3系統がこの形で回り、最後に review-gate がケース数とテストコード数、未対応の指摘を突き合わせます。
生成が増えても、人の確認が膨らまない開発
機械で判定できることは機械が止め、共通の部分は土台に置き、判断の記録は作業に結びつけます。そのうえで人は、機械が決められないことだけを決めます。
人の確認は、生成の前と後の二か所だけです。そのあいだに機械の関門を三つ置いています ── 計画の事前検査、コンパイルと起動が通るまで回す機械検証、7つの観点で設計とコードを突き合わせる整合性の一次審査。どれかで落ちたものは、該当する部分だけを作り直し、人の前には出しません。
だから人が見るのは「計画が期待どおりか」と「指摘を採るか」の二点に絞られます。AIの生成量が増えても、人の確認はそれに比例して膨らみません。
認証と権限、キャッシュと冪等、流量制御、データアクセス、ファイル保存といった共通の機能は、COREという土台にまとめてあります。応答の形・エラーコード・追跡用のIDもここで統一し、既定の実装は差し替えられます。その上にSpring BootとAngular・React・Vueの雛形（BUILD）を載せています。
AIは雛形の層と依存の境界に沿ってコードを書き足すので、案件ごとに書くのは業務の規則だけになります。立ち上がりが早く、どの案件でも生成物の作法がそろいます。
1件の作業に入力の依拠・変更の範囲・担当・完了の条件を書き、そこへ成果物の版、レビューの指摘と修正、最後に採用した判断を結びつけます。これを受け持つのがFLOWです。
引き継いだ人は、いまどこで止まっていて次に誰が処理するのかを、経緯を追い直さずに読めます。案件で確かめて人がレビューした方法だけが、雛形と検査の規則に書き戻されます。
同じ手順を当てる層と、効きどころ
層ごとに効く理由が違います。はじめは削減の大きいサービス層とデータアクセス層から入るのが目安です。
入力が条項になっているか、出力を機械で検証できるか、誤りを安く戻せるか、責任を負う人が要るか ── どれか一つでも満たさなければ、任せる度合いを一段下げます。決まった入力から決まった出力が出る作業は、AIではなくスクリプトで処理します。
度合いは四段です。契約からのCRUDの実装やDDLからのリポジトリ層はAIが主導し、複雑な業務ロジックはAIが七〜八割を起草して人が補い決めます。資金・権限・監査に関わる経路と既存システムとの接続は人が主導します。計画の確認と取り込みの承認は、精度にかかわらずAIに任せません。
計画の確認と取り込みの承認は人が行います。AIの出力はすべて下書きとして扱い、この二か所を省く設定は用意していません。
実装工程では単体テストを流しません。品質は設計との整合性で確かめ、テストケースとテストコードは次の単体テストの工程で作ります。
実装工程への導入の進め方と基準は、新規開発を前提にしています。既存システムの改修には調査と影響分析の入口がありますが、本ページの段階と基準は当てはまりません。
作業の進み具合を管理するFLOWは、現在は管理画面のデモの段階です。記録の永続化、権限の執行、自動の収集、CI/CDの結果との関連づけは、まだ検証中です。
ツールをお客様の環境で動かしても、モデルのサービスまで社内にあるとは限りません。送ってよいコードと文書の範囲、モデルの置き場所は、試行の前に決めます。
備わっているものと、導入の道筋
機能として備わっているものと、四つの導入段階それぞれの出口の基準を並べます。
備わっているもの → それが意味すること
| 備わっているもの | それが意味すること |
|---|---|
| 生成の前と後、二か所だけの人の確認 | 人の時間が、機械で判定できない判断に集まる |
| 機械検証の自動の往復 | コンパイルや起動で落ちるものが、人の確認まで届かない |
| 7つの観点での整合性の一次審査 | 設計と違う実装が、テストの前に見つかる |
| 共通の土台（CORE）と雛形（BUILD） | 案件の立ち上がりが早く、生成物の作法がそろう |
| 作業・版・確認の記録の結びつき（FLOW） | 担当が替わっても、止まっている所と次の担当が分かる |
| 版の付いた規約・雛形・教訓 | 案件で確かめた方法だけが、次の案件の規則になる |
当センターが整備した基盤の機能仕様（提案資料、2026年9月時点）。FLOWは現在、管理画面のデモの段階です。
導入の道筋 ── 四つの段階と出口の基準
| 段階 | やること | 出口の基準 |
|---|---|---|
| L0 人の作業（導入前） | コーディング規約・Golden Code・実行計画の雛形と文脈の資産を整える | 上位の資料がAIで使える状態になっている |
| L1 AIが補助（1〜2か月） | AIがコードの案を出し、人が判断して直す。レビューの基準を整える | 採用率が基準に達し、チームが運用できる （コードの採用率 35%以上・差し戻し率 65%以下・機械検証の一次通過率 50%以上） |
| L2 AIが主導（L1の後 3〜6か月） | 生成から機械検証、整合性の一次審査までをAIが主導する | 差し戻し率が安定し、品質の基準線が下がらない （採用率 55%以上・差し戻し率 50%以下・一次通過率 80%以上） |
| L3 CI/CD（L2の後 1年以上） | 設計の変更 → 計画 → 生成 → 機械検証 → 整合性の確認を自動でつなぐ | 契約と責任の体制を合わせて見直す |
提案資料の設計値（2026年9月時点）。期間は業界の目安で、試行の実績に合わせて調整します。採用率が基準を下回ったら規約とGolden Codeを整え直し、差し戻し率が基準を超えたら範囲を広げずに資産の整備を優先します。工数の削減率は業界の公開データからの推算で実測値ではないため、ここには載せていません。
NEXT
ご相談は、担当者までご連絡ください。
対象を一つ指定いただければ、成果物とその検証レポートを実物としてご提示します。
この方式が有効かどうかは、件数の説明ではなく、ご自身のシステムから出てきた成果を見ていただくのが最短です。
対象を一つお知らせいただくところから始まります。