規制業界での Kiro 運用 — dotkiro + Git で監査証跡を構造的に担保する

サマリ

• 規制業界で Kiro を運用する際、監査官から問われるのは「いつ・どの標準で・誰の承認のもとで・何が生成されたか」の追跡可能性
• dotkiro の「中央 Git リポジトリ + manifest」モデルは、Git のコミット履歴・PR・CODEOWNERS・branch protection を活用してこれを構造的に満たせる
• manifest を "Standards Bill of Materials" として commit することで、生成物と標準セットの対応が時系列で恒久化される
• AWS Audit Manager / Config / CloudTrail / Bedrock Logging / Security Lake と組み合わせれば、エビデンス収集からレポート生成までを自動化できる
• FISC・医療情報・ISMAP・電力・通信など国内主要ガイドラインへの適合を視野に入れた運用モデルを示す

はじめに — 配布の次にくる「証明」の要件

前回記事「dotkiro で Kiro の組織標準を配布する」では、標準リファレンス構成の配布効率を軸に dotkiro を評価した。

規制業界（金融・医療・電力・公共・防衛など）では、もう一段上の要件がのしかかる。

「そのコードが生成された時点で、どの組織標準に従っていたのか、監査官に証明できるか？」

これは効率ではなく、説明責任（accountability）と追跡可能性（traceability） の話である。「生成 AI を使った」が追跡を曖昧にする理由として、多くの規制業界では許容されない。

規制業界では「Kiro を使うこと自体の可否」が先立つ

本記事は「Kiro を規制業界で使う判断がすでに組織として下されている」前提で、監査証跡の設計論を展開する。Kiro の使用可否そのもの（LLM の非決定性、データ取り扱い、モデル学習対象など）は、組織のセキュリティ部門・コンプライアンス部門の評価が必須。

1. 監査で問われる典型的な 3 つの問い

規制業界の開発プロセスに対して、監査官（内部監査・外部監査・当局検査）が問う典型的な問いは以下に集約される。

• WHAT: 何の標準に従って作られたか（コーディング標準・セキュリティ標準・運用標準、バージョン、適用範囲）
• WHEN: いつの時点の標準が適用されたか（標準更新時の遡及適用、バージョン間の変更影響）
• WHO: 誰の承認のもとで標準が運用されているか（制定・改訂の権限者、承認プロセスの恒久記録）

これら 3 つに Git + dotkiro は構造的に答えられる。以降でそれを示す。

2. Standards Bill of Materials — 標準の部品表という考え方

SBOM（Software Bill of Materials）が「このソフトウェアは、どの部品から構成されているか」を機械可読形式で明示するように、AI 時代のコーディングでは 「このコードは、どの組織標準の、どのバージョンのもとで生成されたか」 を明示する仕組みが必要になる。

本記事ではこれを Standards Bill of Materials（本記事での造語）と呼ぶ。dotkiro の .dotkiro-manifest.json はまさにこの役割を果たしうる。

以下 3 情報が揃えば、任意の過去時点の「標準 × 生成物」ペアが復元可能:

1. 中央 Repo の特定コミット SHA（例: abc123）
2. 適用された types（例: ["lambda", "regulated"]）
3. manifest のスナップショット（生成時点のもの）

これらをプロジェクト Repo の Git 履歴に commit として残しておけば、監査時に「この時点で、どの標準に従っていたか」が検証可能になる。

3. 監査証跡を Git に集約する運用モデル

監査で問われる 3 つの問い（WHAT / WHEN / WHO）を、Git のどの機能でカバーするか。

3.1 中央 Repo

要素	監査観点	実現方法
Commit 履歴	WHAT, WHEN	git log で全変更履歴が追跡可能
Pull Request	WHO, WHY	レビュー・承認・議論の履歴が残る
CODEOWNERS	WHO	標準ごとの所管部署が明示される
Branch protection	WHO	必須レビュー数・ステータスチェックを強制
Signed commits / tags	Integrity	改竄検知、作成者の暗号的な担保
Release タグ	WHEN	標準のバージョン境界を明示（例: v2.1.0）

Signed commits の推奨

中央 Repo の全コミットに GPG または SSH 署名を要求するポリシーが現実的。GitHub では Require signed commits を branch protection で設定できる。「誰がコミットしたか」が否認防止（non-repudiation）付きで担保される。

3.2 プロジェクト Repo

記録すべき要素:

• .dotkirorc: 参照中央 Repo と types、branch（タグ）を明示
• .kiro/steering/, .kiro/skills/: 同期されたファイルをそのまま commit
• .dotkiro-manifest.json: 規制業界では commit する（dotkiro の通常推奨と異なる）

規制業界では .dotkiro-manifest.json を commit する

通常開発では manifest はローカル状態だが、規制業界では commit して Standards Bill of Materials を恒久化 する。「この時点で、このプロジェクトは、中央 Repo のこのバージョンを参照していた」が Git に恒久的に残る。開発者ごとの types 差異が出しにくくなるが、規制業界ではむしろ望ましい制約。

3.3 Kiro 生成物と標準セットの紐付け

requirements.md / design.md / tasks.md / コードは通常どおりコミットする。重要なのは 生成物とその時点の標準セットを紐付ける こと。

# 1. 標準を同期、中央 Repo の SHA をコミットメッセージに明示
git commit -am "chore: sync kiro conventions from kiro-conventions@abc1234"

# 2. その後 Kiro で生成、生成物をコミット
git commit -am "feat: add user registration spec"

監査時は、生成物コミットの直前の「Standards 同期コミット」を辿ることで、当時の標準セットが特定できる。

3.4 CI: 標準適用の継続性を証明する

# .github/workflows/kiro-standards-check.yml
name: Kiro Standards Compliance Check
on: [push, pull_request]

permissions:
  id-token: write
  contents: read

jobs:
  verify:
    runs-on: ubuntu-latest
    env:
      DOTKIRO_VERSION: v0.3.0  # 運用ポリシーで pin する
    steps:
      - uses: actions/checkout@v4

      - name: Install dotkiro (pinned version)
        run: |
          git clone --depth 1 --branch "${DOTKIRO_VERSION}" \
            https://github.com/kirodotdev-labs/dotkiro.git /tmp/dotkiro
          (cd /tmp/dotkiro && npm install --production && npm install -g .)

      - run: dotkiro update

      - name: Verify no drift
        run: |
          [[ -z "$(git status --porcelain .kiro/)" ]] || { git diff .kiro/; exit 1; }

      - name: Upload manifest to GitHub (短期、90 日)
        uses: actions/upload-artifact@v4
        with:
          name: dotkiro-manifest-${{ github.sha }}
          path: .dotkiro-manifest.json
          retention-days: 90

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.AUDIT_EVIDENCE_ROLE_ARN }}
          aws-region: ap-northeast-1

      - name: Archive manifest to S3 (長期、組織規定に従い 7〜30 年)
        run: |
          aws s3 cp .dotkiro-manifest.json \
            "s3://audit-evidence-bucket/kiro-manifests/${{ github.repository }}/${{ github.sha }}.json" \
            --metadata "commit=${{ github.sha }},ref=${{ github.ref }}"

設計上の要点:

• dotkiro のバージョン pin: npm link は開発向けの動的リンクで CI では不安定。--depth 1 --branch <tag> で特定バージョンをチェックアウトし npm install -g . で固定インストールする。社内 npm registry が整備されていれば npm install -g @your-org/dotkiro@<version> の方がさらに単純
• 短期保管は GitHub Actions、長期保管は S3: GitHub Actions のアーティファクト保持は実質最大 90 日（public）/ 400 日（private・internal）で、規制業界の数年〜数十年要件には届かない。S3 に早期にオフロードし、ライフサイクルポリシーで Glacier / Glacier Deep Archive に階層化する構成が本命
• OIDC フェデレーションで認証: アクセスキーを GitHub シークレットに置かず、GitHub OIDC を使って IAM Role を assume する
• S3 側の保全: アップロード先バケットには Object Lock（compliance mode）と SSE-KMS、バージョニング、アクセスログ記録を適用し、「一度書き込まれたら改変・削除できない」状態を担保する

この構成で、逸脱検出・証跡の自動アーカイブ・実行履歴の時系列記録を継続的に担保できる。

4. 署名とブランチ保護

Git にコミットが残っているだけでは改竄可能性が残るため、暗号的仕組みで補強する。

中央 Repo main ブランチの branch protection 設定例:

• Require a pull request before merging + Require approvals（2 以上推奨）
• Require review from Code Owners
• Require status checks to pass
• Require signed commits
• Include administrators（管理者もバイパス不可）

タグベースのセマンティックバージョニング:

git tag -s v1.0.0 -m "Release v1.0.0 - approved by CCoE board 2026-05-01"
git push origin v1.0.0

プロジェクト側で .dotkirorc の branch にタグ名を指定すれば、immutable な標準スナップショット に pin される。いつ v2.0.0 に上げるかは事業部が計画的に判断する。

{
  "repo": "https://github.internal.example.com/platform/kiro-conventions.git",
  "branch": "v1.0.0",
  "types": ["lambda", "regulated"]
}

5. 監査官に見せるエビデンスパッケージ

監査対応で提示すべきアーティファクト:

• 中央 Repo 側: README・types 一覧・CODEOWNERS、git log、マージ PR リスト（approver 含む）、署名検証結果、branch protection 設定
• プロジェクト Repo 側: .dotkirorc と Git 履歴、.dotkiro-manifest.json の各時点スナップショット、CI 実行履歴
• Kiro 生成物側: spec・コードの Git 履歴、生成直前の Standards 同期コミット SHA

以下のような統合ドキュメントにまとめると説明がスムーズ。

# System X - Kiro 運用エビデンスパッケージ (2026Q2)

## 適用組織標準
- 中央 Repo: kiro-conventions @ v1.2.0 (2026-04-15 承認)
- 適用 types: lambda, regulated
- CODEOWNERS: @org/runtime-team, @org/compliance-team

## 主要生成物
- requirements.md (commit: def5678, 2026-04-22)
- 実装 PR #42 (merged 2026-04-30)

## 逸脱検出 CI 結果
- 全ビルド: 57 回 / 逸脱検出: 0 件

## 添付
- 中央 Repo 署名検証レポート / manifest 履歴 / CI アーカイブ（7 年保存）

6. 国内ガイドラインへの適合視点

dotkiro + Git の監査証跡モデルは、国内主要ガイドラインの要求事項に基本構造でかなり対応できる。

6.1 FISC 安全対策基準（金融）

開発標準の整備と遵守、変更管理、監査証跡が要求される。中央 Repo での一元管理、PR ベース変更管理、署名付き commit / tag、Git 全履歴 + manifest アーカイブで対応可能。

6.2 医療情報システム安全管理ガイドライン

責任の所在・手順書との整合性・変更記録の保全に、CODEOWNERS・steering 本体・Git 全履歴の組み合わせで対応可能。

6.3 電力制御システムセキュリティガイドライン

電力業界は IT 系と OT 系（電力制御システム）の分離 が厳格で、OT 系への Kiro 適用はエアギャップ・ネットワーク分離などの制約から現実的でない。対象は電力会社の IT 系開発プロセス（電気契約・料金計算、スマートメータ分析、再エネ連系計算、託送業務、顧客向けポータルなど）。

dotkiro モデルの効きどころ:

• IT/OT 境界を types 命名規則で明示（it-* のみ Kiro 対象、ot-* は対象外）
• 発送電分離に伴う情報遮断を、託送・小売・発電の業務別 types で表現
• 電力監督指針の変更管理要件に Git ベースの PR 履歴で応える

OT 系への生成 AI 適用は本記事スコープ外

発電所制御・系統運用システムなど重要インフラへの生成 AI 適用は、認証・ネットワーク分離・物理セキュリティ・規制当局協議を含む別次元の検討が必要。

6.4 情報通信ネットワーク安全・信頼性基準（通信）

通信業界では、憲法 21 条・電気通信事業法 4 条による 通信の秘密 の保護が最強レベルの機密統制として課される。

dotkiro モデルの効きどころ:

• 通信の秘密に関わる steering を shared（逸脱不可） として全プロジェクトに配布
• サービスライン別（固定・移動・IoT・法人）の types 分類で個別統制
• CI で禁止事項を含むコードを正規表現ベースで検出（skill として配布）

6.5 ISMAP 管理基準（政府クラウド）

NIST SP 800-53 ベースの管理策集。主要コントロール CM-3（構成変更制御）/ CM-4（影響分析）/ AU-3（監査レコード内容）/ AU-11（保持）に対し、PR ベース変更管理と Git + manifest + CI artifact で対応可能。

6.6 業界横断一覧

業界	代表的ガイドライン	dotkiro モデルの効きどころ
金融	FISC 安全対策基準	変更管理・監査証跡
医療	医療情報システム安全管理ガイドライン	責任所在・変更記録
電力（IT 系）	電力制御システムセキュリティガイドライン	IT/OT 境界・業務境界の types 分離
通信	情報通信ネットワーク安全・信頼性基準	逸脱不可標準の強制・サービスライン別 types
公共	ISMAP 管理基準	構成変更制御・監査レコード
製造	IEC 62443	変更管理・完全性担保

監査観点の根幹（WHAT / WHEN / WHO / 完全性）は業界横断で共通する。

7. AWS マネージドサービスで監査レポート生成を省力化する

大規模・高頻度の監査対応では、AWS のマネージドサービスを組み合わせて エビデンス収集からレポート生成まで自動化 できる。

7.1 全体アーキテクチャ

[中央 Repo] ──┐
[プロジェクト Repo] ──┤
              ▼
         [CI: dotkiro update + 逸脱チェック]
              │
              ├─► [S3: manifest / 差分 / CI ログを長期保存]
              │            │
              │            ▼
              │   [AWS Audit Manager]
              │   カスタムフレームワーク / エビデンス自動収集 / PDF 出力
              │
              └─► [IaC デプロイ]
                        │
                        ▼
              [AWS Config]     リソース構成の継続監査
              [CloudTrail]     API 操作の完全記録
              [Bedrock Logging] Kiro 生成時のプロンプト / レスポンス
              [Security Lake]  長期統合ストレージ
                        │
                        ▼
              [Audit Manager にエビデンスとして取り込み]

Kiro 運用証跡（Git 側） と AWS 環境の運用証跡（Config / CloudTrail 側） を Audit Manager で合流させる。「標準に従って書かれた → 標準に従ってデプロイされた → 標準に従って運用されている」の 3 段が 1 レポートに集約される。

7.2 AWS Audit Manager — 中核

AWS Audit Manager は、事前定義フレームワーク（NIST SP 800-53・PCI DSS・SOC 2・ISO 27001・HIPAA・GDPR など）と カスタムフレームワーク に基づき、AWS サービスからエビデンスを自動収集する。

規制業界での使い方:

• カスタムフレームワーク「Kiro Standards Compliance」を定義。コントロール例: "全プロジェクトが中央 Repo から conventions を sync している", "Kiro 生成コードは人間の承認を経ている", "参照標準はタグで pin されている"
• エビデンスソース: S3 の dotkiro manifest、CI の逸脱チェック結果、CloudTrail ログ
• アセスメント: Audit Manager が定期収集し、レビュアーが承認、監査官向け PDF を 1 クリックで出力

Audit Manager の最大の価値は「監査官が読む粒度の PDF が自動で出る」こと

§5 で示したエビデンスパッケージが、カスタムフレームワーク定義 1 回の投資で以降は自動生成される。年次・四半期監査の手作業コストを根本的に削減できる。

7.3 AWS Config — IaC デプロイ後のリソース監査

AWS Config は実環境のリソースが組織標準通りに構成されているかを継続評価する。

• Config Rules: 「S3 は暗号化必須」「IAM Role は最小権限」などを継続評価
• Conformance Packs: FISC / HIPAA / NIST 800-53 / PCI-DSS の業界別ルールセットを一括適用
• 連携: 中央 Repo の steering と Config Rule 実装（config-rules/ ディレクトリ）を 同じ PR で変更 することで、標準の記述と自動検証ロジックが同期する

「standards が steering に書かれている（コード側）」+「standards が Config Rule で検証されている（実環境側）」の両輪が Git で一元管理される。

7.4 AWS CloudTrail — 変更操作の追跡

AWS CloudTrail は全 API 呼び出しを記録する。Kiro 生成 IaC のデプロイ履歴、本番環境の変更（Console 手動操作含む）、IAM 権限変更履歴が残る。CloudTrail Lake で SQL クエリできるため、監査官の質問への即応にも使える。

7.5 Amazon Bedrock Model Invocation Logging

Kiro が Bedrock 経由で LLM 呼び出しする場合、Model Invocation Logging でプロンプトとレスポンスを S3 / CloudWatch Logs に記録できる。どの steering が展開されたか・どのモデル ID で生成されたかが残る。

プロンプトに機密情報が含まれるリスク

プロンプト全文が記録されるため、開発者が誤って機密情報を含めると、ログ自体が機密データになる。保管先 S3 バケットには KMS 暗号化・MFA 必須のアクセス制御・適切なライフサイクル・アクセスログ自体の CloudTrail 記録 を必須で適用する。

7.6 Security Lake と Security Hub

• Security Lake: CloudTrail・Security Hub findings などを OCSF 標準形式で S3 統合、Glacier 階層化で 10 年超の長期保存にも対応
• Security Hub: CIS / PCI DSS / NIST 800-53 の posture ダッシュボード

Audit Manager との役割分担: Audit Manager はレポート出力（PDF）、Security Hub は現状ダッシュボード。

7.7 省力化の効果

フェーズ	手動運用	AWS マネージド連携後
エビデンス収集	Excel / PDF を手作り	Audit Manager が自動収集
逸脱検出	目視	Config Rules + CI
長期保存	S3 に雑多に保管	Security Lake で標準化
レポート生成	数日〜数週間	Audit Manager の PDF 出力
監査官質問対応	担当者がログを探す	Athena / CloudTrail Lake クエリ

初期投資は必要だが、継続的に監査を受ける組織ほど ROI が大きい。

万能ではない

Config Rules は AWS リソースレベルで、コード内ロジックの逸脱検出は dotkiro + CI 側が担う。LLM 非決定性は AWS マネージドでも解決できない。Git + dotkiro + CI が土台、AWS マネージドがその上にエビデンス集約とレポート自動化の層として乗る 階層関係を意識する。

8. 導入時の考慮点

8.1 中央 Repo の可用性と完全性

• プライマリ + バックアップ Git ミラー、Bare repo を S3 Glacier Deep Archive にアーカイブ
• git push --force / タグの削除・再作成 / 管理者権限バイパスは 禁止。branch protection と組織ポリシーで二重に封じる
• 10 年超の監査期間を想定、RTO / RPO を明示的に定義

8.2 オフラインエビデンス

監査官が GitHub にアクセスできない状況に備え、git bundle create standards.bundle --all で完全オフライン版を事前用意できる構成を推奨。

8.3 長期保存

Git リポジトリ自体は圧縮効率が高く、10 年分のコミット + manifest アーカイブ + CI ログでも数百 MB 〜数 GB に収まるケースが多い。ストレージコストは相対的に小さい。

CI アーティファクトの長期保存は以下の階層で組む:

• 短期（〜90 日）: GitHub Actions のネイティブ保持。直近ビルドへの即時アクセス用
• 中期（90 日〜数年）: S3 Standard-IA / Intelligent-Tiering。監査対応時の直近問い合わせに備える
• 長期（数年〜数十年）: S3 Glacier Deep Archive。組織の保存規定に応じて保持期間を設定

S3 側には Object Lock（compliance mode）+ バージョニング + SSE-KMS を適用し、書き込み後の改変・削除を構造的に封じる。加えて、バケットポリシーで「Principal * に対する DeleteObject / PutObject の拒否」を明記しておくと、管理者アカウントの誤操作や侵害時のリスクも下がる。

8.4 LLM の非決定性という根源的な課題

dotkiro で標準を完全に再現しても、Kiro 生成物は完全には再現できない。同じ steering + 同じプロンプトでも出力は厳密には同一でなく、モデルバージョンの更新で挙動も変わる。

現実解は以下:

• 生成物そのものを Git にコミット（再現ではなくスナップショットで担保）
• 人間のレビュー・承認記録を PR に残す（Kiro 出力を人間が確認した証跡）
• モデルバージョンの記録（生成時の Bedrock モデル ID など）

「どう生成したか」の再現性ではなく、「人間が何を確認して承認したか」 に説明責任の重心を置く設計が現実的。

9. 通常運用と規制業界運用の使い分け

本記事で示した規制業界向け運用は、前回記事で示した通常運用と排他ではなく、積み重ねの関係 にある。

観点	通常運用（前回記事）	規制業界運用（本記事）
主眼	配布効率	監査証跡
対象	全事業部	規制業界プロジェクト
中央 Repo 運用	通常 PR レビュー	署名 + 複数承認 + タグ運用
.dotkirorc の branch	main が多い	タグ（v1.0.0）で pin
manifest	commit しない	commit して Standards BoM として保全
CI	オプション	必須、長期アーカイブ
AWS マネージド連携	任意	Audit Manager / Config 連携推奨

「通常事業部は通常運用、規制業界事業部は本記事の運用」を、同じ中央 Repo で branch / tag 戦略を分けて両立できる。

まとめ

規制業界で Kiro を使うハードルは高いが、dotkiro モデルを適切に強化すれば「生成 AI を使いながらも監査に耐える開発プロセス」は構造的に成立しうる。土台は Git + dotkiro + CI、その上に AWS Audit Manager / Config / CloudTrail / Bedrock Logging / Security Lake が乗る階層構造で、エビデンス収集からレポート生成までを自動化できる。

ただし LLM 非決定性は本質的に残るため、「どう生成したか」の再現ではなく「人間が何を確認して承認したか」に説明責任の重心を置く設計が現実解。前回記事で示した通常運用の上に、本記事の規制業界向け強化を重ねることで、通常事業部と規制業界事業部を同じ中央 Repo で両立できる。

CCoE としてこうした運用モデルを先回りして整備しておくことで、事業部からの「規制業界でも Kiro を使いたい」という要請に応えられる体制が作れる。

参考リンク

dotkiro 関連

AWS マネージドサービス関連

• Amazon Bedrock Model Invocation Logging

規制・ガイドライン関連

• FISC 安全対策基準（金融情報システムセンター）
• 医療情報システムの安全管理に関するガイドライン（厚生労働省）
• 電力制御システム等におけるサイバーセキュリティ確保の考え方（経済産業省）
• 情報通信ネットワーク安全・信頼性基準（総務省）
• ISMAP 管理基準
• NIST SP 800-53 Rev.5

筆者の関連記事