CMMI AIMは何をチェックするのか。それをドメイン別に並べて、各観点を現場がKiro IDEでどこまで実装できるか見ていきます

目次

目次 

- はじめに 

- 結論を先に：どこまで作れて、どこからは無理か 

- 前提（この記事の読み方） 

- この記事の地図 

- Part 1. CMMI AIMは何をチェックするのか 

- Part 2. 各観点をKiro IDEでどう実現するか（ドメイン × 3段階） 

- Part 3. どのドメインから、どの順で手をつけるか 

- Part 4. で、どこまで作れて、どこからは無理なのか 

- 空いているセルには2種類ある 

- まとめ 

- 関連記事 

- 参考リンク（出典） 

1. はじめに

2026年5月21日、CMMI®の最新版「V4.0」が出ました。目玉が CMMI AIM™（Artificial Intelligence Maturity） です。AIの導入・運用・統合を成熟度モデルで管理する枠組みで、31あるプラクティス領域の全部にAI関連の記述が足されました。

CMMI AIMの記事は探せば何本かありますが、どれも経営層向けで「対応すべきか」「何のフレームワークか」という話が中心です。でも現場が知りたいのは、たぶんこの3つです。

- CMMI AIMって、そもそも何をチェックされるのか？
- それに対応するために、現場は何を作ればいい？
- その作業、いつものKiro IDEでできる？

この記事は、この順番で答えていきます。

結論を先に：どこまで作れて、どこからは無理か 
長い記事なので、先に結論だけ出します。CMMI AIM対応に必要なものは4層あり、Kiro IDEが効くのは「③実装」の一部です。 

層  必要なもの  入手方法  Kiro IDEで作れる？ 
① 理解する  CMMI AIMの目的・成熟度の考え方・改訂ポイント  無料  — 読むだけ 
② 要求を正確に知る  モデル本体（Model Viewer Plus）  有料  ❌ 買わないと読めない 
③ 実装する  AI利用ルール・規約チェック・品質ゲート・参照データ管理など  Kiro IDEの出番（一部）  △ 現場実装の一部を強く支援 
④ 認定される  トレーニング・資格・正式アプレイザル  有料・パートナー契約  ❌ 自己申告では名乗れない 

前提（この記事の読み方） 

この記事は、無料で読める情報だけで書いています（公式FAQ・Executive Summary・公式パートナー解説など）。有料のモデル本体は見ていないため、チェック観点や各記事の位置づけは筆者の推定であり、CMMIの公式見解ではありません。 

本文は4つのPartで進みます。CMMIの説明だけ読みたい人はPart1、Kiro IDEでの実装だけ知りたい人はPart2、という拾い読みができる構成です。 

Part  内容  こんな人向け 
Part1  CMMI AIMは何をチェックするのか（CMMI単体の説明）  まずCMMI AIMを知りたい 
Part2  各観点をKiro IDEでどう実現するか  手を動かす現場担当 
Part3  どのドメインから、どの順で手をつけるか  着手順を知りたい 
Part4  どこまで作れて、どこからは無理か（結論の詳細）  線引きを正確に 

そして本文全体で、次の「2つの軸」を使って整理します。この2軸は Part2 のマトリクスの縦と横になります。 

  • 軸1：8ドメイン（何の領域か） — ドメインが違うと打ち手も参考記事も変わる。だからドメインを縦軸にする 

  • 軸2：AI利用の段階（どこまでAIに任せるか） — 人が主導する段階から、AIが実行し人が監督する段階、完全にAIに任せる段階へと深まります。この具体的な段階名はPart1で定義します。これを横軸にする 

Part 1. CMMI AIMは何をチェックするのか

まず、この記事で使う2つの軸の中身を具体的に説明します（全体像は「この記事の地図」を参照）。 

軸1：8ドメイン（何の領域か）

CMMI AIMは8つのドメインにまたがります。開発・サービス・供給者・セキュリティ・セーフティ・データ・バーチャル・ピープル。このうちAIMで重い扱いなのが 開発・サービス・セキュリティ・データ の4つです。評定でもセキュリティとデータが中心で、開発かサービスが加わる、と公開情報からは読めます（正式な評定要件の確定表現ではなく、正確な適用条件は有料モデルや認定パートナーへの確認が前提です）。

同じ「開発」の中でも、要件定義を固める作業とテストを固める作業では使うKiro IDEの機能が別物です（詳細はPart2）。 

軸2：AI利用の3段階（どこまでAIに任せるか）

もう1つが、AIをどこまで任せるかの段階です。各ドメインで「どこまで踏み込むか」の深さになります。

段階

意味

例

Support Augmentation（支援拡張）

人間の作業をAIが補助

人が書いたコードをAIがレビュー

Verified Augmentation（検証済み拡張）

AIが実行し、人が監督

AIがコードを書いて人がレビュー

Fully Autonomous AI（完全自律型）

システムが自律的に実行

AIが自分で成果物を仕上げる

正直、たいていの現場はまだ Support 〜 Verified のあたりです。

チェックされそうな観点（重点4ドメイン） 
重点4ドメインを中心に、V4.0の改訂で表に出たキーワード（HITL＝Human-in-the-loop、データ品質、検証重視の表現変更など）から逆算すると、チェックされそうな観点はこのあたりに落ち着きます。 

ドメイン  チェックされそうな観点  V4.0改訂で見えたサイン 
データ（必須）  AIに渡す／AIが使うデータの品質・分類・来歴・機微情報の扱い  データ関連の記述が複数プラクティスに追加。データ品質が独立した関心事に 
セキュリティ（必須）  AI利用・AI生成物に伴う脅威と脆弱性への対応  セキュリティ関連の記述が統治・計画・脅威管理などに追加 
開発  要件の統制、規約の遵守、成果物の検証、過剰実装やハルシネーションへの備え  「生成AI」「LLM」「AIハルシネーション」が用語集入り 
サービス  AIを組み込んだサービス提供プロセスの品質と継続改善  サービス関連の記述が複数プラクティスに追加 
全ドメイン横断  人間の関与（HITL）が設計されているか。AIに任せきりにしていないか  HITLが用語集入り。表現が「ensure（確保する）→ verify/confirm（検証する）」へ 

改訂ポイントで一番効くと思ったのが、最後の行です。プラクティス文の言い回しが「ensure（確保する）」から「verify / confirm（検証する・確認する）」に、けっこうな数で変わりました。


「ちゃんとやります」じゃなくて「ちゃんとやったか検証する仕組みがあるか」を問う方向に振れている、ということです。仕組みで検証を回す話なので、Kiro IDEのHooks（自動チェック）やSpec（要件の検証）がそのまま効く領域でもあります。


また HITL（Human-in-the-loop／人間をループに残す） が公式用語になり、全ドメイン横断で「人の判断箇所を設計しているか」が問われるようになりました（以降は「HITL」と略記します）。 

Part 2. 各観点をKiro IDEでどう実現するか（ドメイン × 3段階）

ここからが本題です。Part 1のドメインごとに、3段階のどこまで進めるかで、やることが変わります。各セルに、使うKiro IDE機能・参考になる連載記事・そして ★ここは作り替えが要る という差分を入れました。


連載記事はJava・AWS・命名規約などの具体例です。そのまま使える万能テンプレートではないので、各表に「★作り替えが要る点」を添えます。 

2-1. データドメイン — AIに渡すデータをどう統制するか

目指す状態：CMMI AIMではデータが独立した重点ドメインになっています。狙いは「AIに渡す／AIが使うデータの品質・出所・扱いが管理されていること」。ゴミを食わせればゴミが出る、を組織として防げる状態です。


現場のゴール：AIに渡すデータを、場当たりでなく構造化して管理し、機微情報の混入を防ぐこと。


例えば、こういう状態を避けたいわけです。「AIに設計を手伝わせようとして、過去の議事録をそのままチャットに貼ったら、顧客名や個人情報が丸ごとAIに渡っていた」。あるいは「参照させた仕様書が3年前の古い版で、AIが古い前提で設計を出してきた」。こういう事故を、仕組みで防げているか——が問われます。
 

段階 

現場でやること 

Kiro IDE機能 

参考記事 

★作り替えが要る点 

Support 

AIに渡す参照データを構造化して管理 

Skills（generate-onboarding）＋Steering 

Skills入門・AIオンボーディング生成（第7.5回） 

分類・来歴・保持期限のルールを足す 

Verified 

参照データの機微情報除去・レビューをプロセス化 

Skills＋PRレビュー 

Skills入門・AIオンボーディング生成（第7.5回） 

「育てるサイクル」を承認者を決めた正式レビュー工程に格上げ 

Fully 

学習/RAGデータパイプラインの品質・来歴の自動管理 

普段使いのKiro IDEの範囲外 

— 

完全自律は別レイヤー（後述） 

2-2. セキュリティドメイン — AI利用・生成物の安全性

目指す状態：AIを使うこと・AIが作ったものに伴う脅威と脆弱性に、ちゃんと対処できていること。AIM評定でも必須ドメインです。


ここは範囲が広いので、3つの観点に分けます。生成物のセキュリティだけ見ていると、抜けます。
 

(a) AIが生成したコード・設計の脆弱性

例えば「AIが生成したコードに、ハードコードされた認証情報や脆弱な暗号化設定が紛れていたが、誰も気づかずマージされた」。これはKiro IDEで仕組み化しやすい領域です。

段階

現場でやること

Kiro IDE機能

参考記事

★作り替えが要る点

Support

生成コードに軽くセキュリティ観点のチェックをかける

Hooks（fileEdited + askAgent）

Hooksで命名規約チェック（第7回）の応用

命名規約チェックの仕組みを、セキュリティ観点のプロンプトに差し替える

Verified

設計・実装のセキュリティレビューを自動で起動、人が承認

Hooks + Power（MCP連携）

―

AIを含むシステムなら脅威モデリングの観点を追加

(b) AI利用時の情報漏洩（プロンプト・MCP・学習利用）

「プロンプトに社内機密を貼ったら外部モデルに送られ学習に使われた」「MCPで社内システムに繋いだら非公開データが外に出る経路ができた」。OWASPのLLMリスクでいう機微情報漏洩です。この層はKiroKiro IDEで「作る」より、設定と運用で防ぐ部分が大きいです。 

観点

どう防ぐか

Kiro IDEで作れる？

入力データが学習に使われる（オプトアウト）

利用ツール側のポリシー設定でオプトアウト。GitHub Copilotは2026年4月からデフォルトで学習利用に変わったので要注意（企業はエンタープライズポリシーで制御）

❌ ツール設定・組織ポリシーの領域

プロンプトに機密を貼ってしまう

Steeringで「何を貼っていいか」のルールを明文化＋Hooksで機密パターンを検知

△ ルール化・検知は可能。完全防止は運用次第

MCP連携で非公開データが外に出る

接続先MCPの範囲を絞る。何に繋ぐかの承認プロセス

△ 設計・運用の領域。Kiroは繋ぐ側

(c) AIへの攻撃（プロンプトインジェクション等）

例えば「外部から読み込ませたデータに『これまでの指示を無視しろ』という命令が仕込まれていて、AIが乗っ取られた」。OWASP LLM Top 10の筆頭（プロンプトインジェクション）です。


これは主にAIを組み込んだプロダクト側の設計論で、Kiro IDE（開発ツール）で直接どうこうする話とは少しずれます。ただし「外部から来たデータは信用しない」「取り返しのつかない操作は人間承認（HITL）を挟む」といった原則は、Steeringのルールや後述のHITL設計につながります。


まとめると、セキュリティドメインは (a) はKiro IDEで仕組み化しやすく、(b)(c) はツール設定・組織ポリシー・プロダクト設計の比重が大きい。「セキュリティ＝全部Kiro IDEで」ではない、というのが正直なところです。
 

2-3. 開発ドメイン — 要件・規約・検証

目指す状態：AIを使った開発でも、要件が曖昧なまま進まない・規約が守られる・成果物がちゃんと検証される、という状態。AI特有の事故（過剰実装、ハルシネーション由来のコード）に備えられていること。


現場のゴール：AIに任せた部分ほど「本当に意図通りか」を検証する仕組みを持つこと。V4.0が「ensure（確保する）」から「verify（検証する）」へ表現を変えたのは、まさにこの方向です。


例えば、「曖昧な要件のままAIに実装させたら、2人の開発者が全然違う解釈で作ってしまった」。あるいは「AIが気を利かせて要件にない機能まで作り込んでいた（過剰実装）」「存在しないライブラリのメソッドを、それらしく呼び出すコードを書いていた」。こういうものを、コードになる前・完了前に捕まえられるか、です。


開発は幅が広くて、「要件定義」と「テスト」でやることが全然違います。ここを一括りにすると雑になるので、作業別に分けます。
 

作業 / 段階

現場でやること

Kiro IDE機能

参考記事

★作り替えが要る点

要件（Support〜Verified）

設計に移る前に、要件の曖昧さ・矛盾・抜けを検出して直す

Spec + Analyze Requirements

Analyze Requirementsで要件の矛盾検出（第5回）

題材はAWSインフラ要件。AI固有の非機能要件（精度・応答時間・コスト上限・公平性）を足し、その矛盾も検出対象に

規約（Support）

AI生成コードの規約違反をその場で検出

Hooks（fileCreated + askAgent）

Hooksで命名規約チェック（第7回）

題材はJava命名規約。過剰実装・存在しないAPI呼び出し・方針逸脱などAI生成特有の観点へ広げる

検証（Verified）

完了前にテストを強制する品質ゲート

Hooks（postTaskExecution + runCommand）

Hooksで品質ゲート（第8回）

題材は決定的テスト（mvn test）。AIを含むシステムなら非決定的な出力の検証（LLM-as-Judge、ゴールデンデータ）が別に要る

ルール（全段階の土台）

AI利用ルールを明文化して組織に配る

Steering

ステアリング入門（第2回）・ステアリング設計思想（第6回）

題材はブログ執筆用ルール。「AIに何を任せ、どこから人間承認か」の利用シナリオ別ルールに書き換える

同じ開発ドメインでも 要件はSpec、規約と検証はHooks、土台はSteering と道具が変わります。 

2-4. サービスドメイン — 提供プロセスの品質と改善

目指す状態：AIを組み込んだサービス提供のプロセスが、一定の品質で回り、継続的に改善されていること。


現場のゴール：サービス提供に使う成果物（手順書・構成・運用ルールなど）の品質を保ちつつ、運用しながら育てていける状態。


例えば、「AIを使って運用手順を作ったが、一度作ったきり更新されず、実態と乖離していった」。あるいは「AIの使い方のノウハウが特定の人の頭にしかなく、その人がいないと回らない」。こういう属人化・陳腐化を、仕組みで防げているか、です。
 

段階

現場でやること

Kiro IDE機能

参考記事

★作り替えが要る点

Support

サービス提供物の品質チェック

Hooks（品質ゲート）

Hooksで品質ゲート（第8回）

テスト強制の仕組みを、手順書や構成などサービス提供物の検証に読み替える

Verified

運用ルール・ナレッジを継続的に更新

Steeringを育てる運用

ステアリング設計思想（第6回）・Skills入門（第7.5回）

「更新のシグナル」を運用の定例プロセスに組み込む

Fully

効果測定・ROIに基づく自律改善

普段使いのKiro IDEの範囲外

—

完全自律は別ツール（後述）の領域

2-5. 横断：HITL（Human-in-the-loop、人間をループに残す）

HITL（人間をループに残す）は、CMMI V4.0で正式に用語集入りした考え方です。「重要な判断は人が担う」という原則なので、どの作業にも共通してかかります。 


目指す状態：AIに任せきりにせず、重要な判断には人間が関与する仕組みがあること。


現場のゴール：「どこはAIに任せ、どこは人が承認するか」の境界が決まっていて、その通りに運用されていること。


例えば、「AIが自動で本番環境の設定を書き換えられる状態になっていて、誰のレビューも通らずに適用された」。逆に「全部人が確認していて、AIを入れた意味がないほど遅い」。この両極端の間で、どこに人の承認ポイントを置くかが設計されているか、です。
 

段階

現場でやること

Kiro IDE機能

参考記事

★作り替えが要る点

Verified

重要な操作で人間の承認を必須にする

Supervised mode + Spec承認フロー

―

「どの操作で承認を必須にするか」の設計は現場ごと。連載でも掘り切れていない。今後書く

Kiro IDEには Supervised モード（ファイル編集を含むターンごとに人が承認する動作モード）があります。HITL（Human-in-the-loop）の器としては使えます。ただ「どこに承認ポイントを置くか」は、結局その現場が決めるしかありません。

ここまでのまとめ

ドメイン

主に使うKiro機能

関連する回

データ

Skills ＋ Steering

第7.5回

セキュリティ

Hooks ＋ Power

第7・9回

開発

Spec / Analyze ＋ Hooks ＋ Steering

第5・7・8・2・6回

サービス

Hooks ＋ Steering

第8・6回

横断（HITL（Human-in-the-loop））

Supervised mode ＋ Spec

（今後）

現場の実態は Support 〜 Verified が大半で、そこは連載に手順が揃っています。ただしどのセルにも「題材そのままでは足りない差分」があります。

Fully Autonomous の列がほぼ空欄なのはなぜか

Fully Autonomousに近い運用は、普段使いのKiro IDE単体ではなく、Kiro Crewなどの自律実行レイヤーで扱う領域です。
Kiro Crewでは、セッションをまたいだ実行、スケジュール、チェックポイント、複数エージェント、承認、監査ログなど、自律運用に必要な仕組みがすでに提供されています。
ただし、これをCMMI AIM上の「Fully Autonomous」を満たす仕組みとみなせるかは別問題です。技術的に自律実行できることと、組織として統制・監査できることは分けて考える必要があります。

Part 3. どのドメインから、どの順で手をつけるか

マトリクスを見て「全部いっぺんは無理」と思ったなら、それが正しい反応です。全ドメイン・全段階をそろえるのがゴールではありません。困っているドメインから、土台 → 統制 → 拡張の順に積みます。

フェーズ 

やること 

Kiro IDEでの対応 

効きやすいドメイン 

Phase 1: 土台（効果大・コスト小） 

ルール・方針の明文化／参照データの共有 

Steering ／ Skills 

開発（ルール）・データ 

Phase 2: 統制（型が固まってから） 

規約チェック・品質ゲート・セキュリティレビュー 

Hooks ／ Power 

開発（規約・検証）・セキュリティ 

Phase 3: 拡張（対象が広がったら） 

大規模タスクの分割／外部ツール連携 

サブエージェント ／ MCP 

サービス・横断 

まずは Phase 1 の Steering か Skills から。「全部そろえたら合格」ではなく、「困っているところに効く道具を1個入れる」。

Part 4. どこまで作れて、どこからは無理なのか

冒頭の「結論を先に」で4層（①理解／②要求を知る／③実装／④認定）を示しました。ここでは、特に③実装と④認定の具体的なハードルを掘り下げます。 

③は「有料です」で片づけたくなりますが、実際のハードルはもう少し具体的です（2026年時点の公開情報より）。 

  • 中身を読むだけでも Model Viewer Plus が要る — モデルビュアーには通常版とPlus版があり、AIのガイドやISO規格とのクロスウォークが読めるのはPlus版だけ。個人ライセンスのPlus版で $225 くらい、組織の10人ライセンスで $2,400 くらいが目安 

  • 資格には前提がある — AI成熟度のコース（BAIM）を受けるには、先に組織能力構築のコースを受けPractitioner試験に合格している必要があります 

  • 日本語対応は移行途上
    2026年夏時点ではModel Viewer PlusやBAIMの日本語対応は限定的でした。日本語コンテンツへの移行も進められているため、最新の提供状況はCMMI Instituteの公式情報を確認してください。

つまり③は、お金だけでなく「前提資格」と「英語」のハードルもある領域です。現場がいきなりここに突っ込む必要はありません。 

実装の中身は今日から着手できます。

現実的には「まず自己診断、必要になったら正式評価」

  • 第1段：軽量な自己診断（無償） — 無料情報とPart 1のドメイン別観点を物差しに現在地を自己採点。四半期に1回くらい回して社内の改善サイクルに。ここはKiro IDE＋連載で回せます 

  • 第2段：正式評価（有償） — 経営報告や対外証明が要る段で、有料ライセンスと認定パートナーの評定を検討 

現場はまず第1段から。この記事が扱ってきたのもそこです。 

7. 空いているセルには2種類ある

マトリクスの空欄には、性質の違う2種類が混ざっています。ここを混同すると「そのうち全部書けます」という嘘になるので、分けておきます。

(A) Kiro IDEで作れるが、連載でまだ書いていない
•    HITL（Human-in-the-loop）の人間承認の設計 — どの操作で承認を必須にするか。Supervisedモードで器はあるので、設計論として書ける
•    非決定的な出力のテスト設計 — AIを含むシステムの検証。従来の `assert` が効かない世界。Hooksの品質ゲートを応用する形で書ける
•    AI固有の観点への拡張 — 過剰実装やハルシネーション検出など、既存Hookのプロンプト差し替えで対応できる


これらは連載の宿題です。順次書いていきます。


(B) そもそも普段使いのKiro IDEの範囲外（＝待つしかない）
•    完全自律の運用そのもの — 人手を離れて回り続ける領域。前述の通り、これはIDEではなく Kiro autonomous agent や Kiro Crew といった別ツールの活用が必須。
•    自律実行の証跡・監査 — 上記が実運用に足るレベルになって初めて、本格的に問える話
 

8. まとめ

この記事は、これまで書いてきた連載記事がCMMI AIMのどこに当てはまるのかを整理したくて書きました。書いている本人も、点在していた記事が「CMMI AIMという地図の上ではここに乗る」と分かって整理がつきました。 

CMMI AIM対応で経営の判断を支えるのはコンサルの仕事です。でも現場の実装を支えるのはKiro IDEと、これまでの連載記事だと思っています。 

この記事でやったこと： 

  1. 何をチェックされるか — 重点4ドメイン（データ・セキュリティ・開発・サービス）＋横断のHITL 

  1. それをKiro IDEでどう作るか — ドメイン × 3段階のマトリクス。ドメインが違えば道具も記事も変わる 

  1. どこまで作れて、どこは無理か — 冒頭の結論と同じ4層で振り返ると、次のようになります 

層  どこまで作れるか 
① 理解する  無料情報で読める。この記事もそこを支援 
② 要求を正確に知る  有料のモデル本体（Model Viewer Plus）が要る。Kiro IDEの外 
③ 実装する  Support 〜 Verified の段階なら、Kiro IDE（連載＋現場向けカスタマイズ）で今日から着手できる 
④ 認定される  有料・前提資格・英語のハードルがある。Kiro IDEの外 

③のうち Fully Autonomous は今のKiro IDEの守備範囲外で、別レイヤー（Kiro autonomous agent / Kiro Crew）の成熟を待つ領域、という線も引きました。 

「全部作れる」とは言いません。ただ、現場が今日から着手できる範囲は思っているより広いはずです。自分の現場でいちばん弱いドメインを1つ選んで、Steeringか Skills でその土台を1枚作る。まずはそこからで十分です。 

CMMI AIMの取得は、一人が一つのプロジェクトで頑張って届くものではありません。組織全体・複数プロジェクトを横断して仕組みで統制を効かせる長い戦いです。この記事がそのヒントになれば幸いです。 

10. 参考リンク（出典）

  • CMMI Performance Solutions（ISACA）: https://www.isaca.org/enterprise/cmmi-performance-solutions
  • CMMI AIM（CMMI Institute）: https://cmmiinstitute.com/aim
  • CMMI AIM Provides Path for Responsible AI Integration（ISACA Now Blog / FAQ）: https://www.isaca.org/resources/news-and-trends/isaca-now-blog/2026/cmmi-aim-provides-path-for-responsible-ai-integration
  • CMMI V4.0 改訂ポイント解説（大和コンピューター）: https://www.daiwa-computer.co.jp/column/cmmi_267/
  • Capability Creates 2026・BAIMコースレポート（大和コンピューター）: https://www.daiwa-computer.co.jp/column/cmmi_268/
  • CMMI Model Viewer（ライセンス購入）: https://cmmiinstitute.com/products/cmmi/cmmi-model-viewer
  • Martin Fowler「Harness engineering for coding agent users」: https://martinfowler.com/articles/harness-engineering.html
  • Kiro公式ドキュメント: https://kiro.dev/docs/

 

本記事のCMMI AIMに関する記述は、上記の公開情報から筆者が要約・解釈したものです。正確な定義・要求事項は公式のモデル本体を参照してください。

CMMI®、CMMI AIM™ は ISACA / CMMI Institute の商標または登録商標です。本記事は同社と提携・監修関係にあるものではなく、記述内容は筆者独自の解釈です。