AI・DX

AIコーディングを全社配布する前に｜利用率・トークン・失敗・コストセンターを測る9項目

2026年8月20日16分で読める

READ LATER / FREE NEWSLETTER

今すぐ読み切れなくても、判断材料を逃さない

あとで読む保存は登録不要。無料メルマガはメール1項目で仮登録でき、この記事に近いテーマの判断チェックを受け取れます。

保存はこの端末だけ・メール不要／メルマガは営業電話なし・確認メール承認後に開始

GXO COLUMN

AI・DX

結論：トークン量とコード行数を成果にしない

AIコーディングを導入すると、最初に見えるのはアクティブユーザー、会話数、APIリクエスト、トークン量です。これらは利用実態を知るうえで必要ですが、売上、納期、品質、粗利を直接表しません。使うほど不要なコードやレビューが増えれば、利用量が上がっても利益は悪化します。

AWSは2026年8月6日、Amazon Bedrock上のCodexからOpenTelemetry（OTel）でテレメトリを出し、ローカルコレクターを介してAmazon CloudWatchで可視化する実装例を公開しました。IAM Identity Centerを使い、利用者、チーム、部門、組織、コストセンター別に、アクティブユーザー、会話、APIリクエスト、トークン利用などを見る構成です。

これはAWSサービスを使った一つの実装パターンであり、すべてのAIコーディング製品に同じ機能があることや、この構成だけで生産性を測れることを意味しません。重要なのは、製品を問わず「利用」「変更」「品質」「費用」を同じ業務単位へ結び付ける考え方です。

経営者、CTO、開発責任者は、全社配布の前に9つの計測項目、基準値、所有者、停止条件を決めてください。ダッシュボードを作ることが目的ではなく、追加投資、対象限定、運用改善、停止を同じ証拠で決めることが目的です。

INSTANT ESTIMATE

計算式より、60秒で概算を出しませんか？

システム種別・規模・連携先を選ぶだけで、開発費用・期間・月額運用費の概算をその場で表示します。

60秒で見積もる

AWS公式例から確認できる範囲

横にスクロールして確認できます

公式例で示されたこと	実務で使える点	そのまま断定できないこと
CodexのOTelデータをCloudWatchへ送る	既存の観測基盤へAI利用を統合する選択肢	どの環境でも同じ項目・粒度で取得できる
IAM Identity Centerによる識別	利用者、チーム、部門、コストセンターへ帰属できる	共有IDや外部委託を自動で正しく分類できる
active users、conversations、API requests、tokensを可視化	導入・利用・費用の基礎データになる	トークン増が生産性、品質、ROIの向上を意味する
ダッシュボードの実装例	小さく観測を始める参考になる	AWS構成が唯一または全社最適な方法である

導入稟議では、AWS公式例を機能確認に使い、自社の開発KPIと費用は自社データで検証します。

AIコーディングで起きる4つの「見える化の錯覚」

錯覚1：アクティブ率が高ければ定着した

ログインや会話が多くても、検索、雑談、低価値な補完だけかもしれません。対象業務カバー率と、変更がレビュー・テスト・本番へ進んだ割合を分けます。

錯覚2：生成コード行数が多ければ生産性が上がった

コード行数は保守対象を増やすこともあります。削除、単純化、再利用が価値になるため、行数を報酬指標にしません。変更リードタイム、レビュー待ち、手戻り、障害で見ます。

錯覚3：トークン単価が安ければ総コストも安い

モデル利用費のほか、ログ、検索、ネットワーク、評価、セキュリティ、レビュー、再作業、ライセンス管理があります。コストセンターへ配賦し、業務成果と並べます。

錯覚4：ダッシュボードがあれば統制できる

観測は停止、権限、承認、教育を代替しません。異常を誰が何分以内に見て、どの単位で止めるかが必要です。取得漏れや共有IDも監査します。

FREE DOWNLOAD

AI導入チェックリスト（PoC 失敗要因 10項目）

情シス部門が PoC 前に押さえるべき失敗要因を10項目に整理した無料チェックリスト。

30分で相談するチェックリストをDL

全社配布前に測る9項目

1. 利用者・所属・雇用関係

個人、チーム、部門、コストセンター、社員・委託先、上長を記録します。共有APIキーでは個人の成果も事故も追えません。退職・契約終了と連動して失効し、所属変更後の費用帰属も更新します。

2. 対象業務とリポジトリ

「開発で利用」では粗すぎます。新機能、保守、テスト、移行、調査、文書化などの業務と、リポジトリ、サービス、環境を結びます。顧客案件では契約上AI利用が許可されているか確認します。

3. 利用量

アクティブ日、会話、APIリクエスト、入力・出力・キャッシュのトークン、モデル、応答時間、失敗を取得します。製品やモデルの変更で定義が変わるため、単位と収集版を記録します。

4. 変更成果

提案だけ、採用、コミット、PR、マージ、本番反映を区別します。AI寄与を厳密に1行ごと帰属させるより、AI利用タスク群と非利用の基準値を比較し、測定コストを抑えます。

5. 品質・セキュリティ

テスト失敗、レビュー差戻し、静的解析、依存脆弱性、秘密情報、ライセンス、アクセシビリティ、性能を測ります。重大な脆弱性や本番障害は、平均点で相殺しない停止ゲートです。

6. リードタイムと処理能力

着手からPR、レビュー、マージ、デプロイまでを分けます。生成が速くてもレビュー待ちが増えれば全体は速くなりません。完了件数とWIP（仕掛かり）を同時に見ます。

7. 再作業・障害

差戻し回数、revert、hotfix、変更失敗率、障害復旧時間、顧客問い合わせを追います。AI利用の有無だけで原因を断定せず、変更規模、担当経験、サービス難易度を併記します。

8. 総コスト・粗利

ライセンス、トークン、基盤、ログ、評価、レビュー時間、教育、事故対応をコストセンターへ配賦します。受託開発では案件粗利、内製では事業価値または回避工数と比較します。

9. 権限・例外・停止

読取、編集、コミット、PR、デプロイ、Secret、クラウド操作を分け、許可外の利用を検知します。費用超過、異常呼出し、重大脆弱性、ログ欠落、誤操作を停止条件にし、解除承認を残します。

イベント設計：1回のAI利用を業務へつなぐ

テレメトリには、機密コードやプロンプト全文を必要以上に保存せず、判断に必要な属性を持たせます。

横にスクロールして確認できます

属性	例	目的
actor	user_id、team、employment_type	利用者・委託先・所属の追跡
work	project、repo、service、ticket	業務成果への接続
model	provider、model、version	費用・品質の比較
usage	request、input/output/cache tokens、latency	利用量・性能・失敗の把握
action	read、generate、edit、commit、deploy	権限と影響の分類
result	accepted、rejected、error、cancelled	採用率と失敗の把握
control	approval、policy、exception	承認・例外の証拠
cost	amount、currency、cost_center	総コストと配賦
trace	trace_id、PR、build、deployment	品質・本番影響との関連付け

プロンプトやコード本文を保存する場合は、利用目的、アクセス権、保持期間、マスキング、顧客契約を決めます。本文なしでも、trace_idから権限を持つ担当者だけが必要な原記録へ到達できる設計が可能です。

経営・開発・セキュリティで画面を分ける

経営画面

部門別の総コスト、対象業務カバー率、変更リードタイム、処理能力、変更失敗率、案件粗利を月次で示します。個人ランキングは萎縮やゲーム化を招くため、目的と公平性を確認せず公開しません。

開発責任者画面

リポジトリ別の採用・差戻し、レビュー待ち、テスト失敗、revert、モデル別失敗、未処理の警告を週次で見ます。利用量が多いのに成果へ進まないチームは、教育、タスク分割、コードベース、CIの問題を調べます。

セキュリティ・運用画面

許可外リポジトリ、機密検知、高権限ツール、共有ID、異常なトークン増、ログ欠落、例外期限切れを日次で見ます。アラート件数ではなく、初動時間、是正完了、再試験まで追います。

100点のAIコーディング計測診断

横にスクロールして確認できます

項目	配点	満点条件
ID・所属	10	個人、部門、委託、失効、配賦が一致
業務・資産	10	ticket、repo、service、環境へ関連付く
利用量	10	定義と版があり、失敗・遅延を含む
変更成果	10	提案から本番まで段階を区別
品質・安全	15	テスト、レビュー、脆弱性、重大ゲートあり
リードタイム	10	生成だけでなくレビュー・デプロイを測る
再作業・障害	10	revert、hotfix、失敗率、復旧を追う
総コスト・粗利	15	人のレビューと基盤を含め部門・案件へ配賦
権限・停止	10	操作別権限、例外、停止・解除を試験
合計	100	85点以上でも重大ゲート未達なら拡大しない

70点未満は全社配布を止め、対象業務とIDを整理します。70〜84点は3チーム以内で90日計測、85点以上は高リスク操作を除いて段階拡大します。点数は製品比較ではなく、自社の計測・判断能力を評価します。

90日の導入計画

0〜30日：基準値と3チームを決める

AI導入前のPRリードタイム、レビュー時間、変更失敗率、障害、案件原価を取得します。新規開発、保守、レガシーのように性質の異なる3チーム以内を選び、禁止リポジトリ、高権限操作、顧客契約を確認します。

31〜60日：利用と成果をtraceでつなぐ

OTelなどの仕組みでAI利用イベントを収集し、ticket、PR、CI、デプロイ、障害へ接続します。最初から完璧な個人帰属を求めず、欠損率を測りながら改善します。週次で誤検知、ログ量、保存費を見直します。

61〜90日：拡大・改善・停止を判定する

利用率ではなく、対象業務カバー、リードタイム、品質、再作業、総コスト、粗利を基準値と比較します。成果が出たタスク種へ広げ、成果が出ない領域はモデル追加の前に、テスト不足、レビュー待ち、古い依存、要件の曖昧さを直します。

ベンダーへ同条件で聞く12問

取得できるイベント、属性、粒度、遅延、欠損時の挙動は何か
OpenTelemetryなど標準形式で外部へ出せるか
個人、チーム、部門、委託先、コストセンターをどう識別するか
共有キーを禁止または検知できるか
プロンプト・コード本文を保存せずに何を測れるか
保存する場合の暗号化、権限、地域、保持、削除は何か
ticket、Git、CI/CD、障害管理、FinOpsへどう接続するか
トークン、キャッシュ、再試行、モデル変更をどう費用へ反映するか
許可外リポジトリ、高権限操作、秘密情報をどう検知・停止するか
ダッシュボード以外に、設定、スキーマ、クエリ、手順は納品されるか
製品解約時に履歴をどの形式で持ち出せるか
90日で成果が出ない場合の縮小・解約・データ削除条件は何か

利益を守る運用ルール

AI利用費を中央部門へ置いたままにすると、使う部門と払う部門が分かれ、無制限利用になりやすくなります。一方、全額を個人へ見せると試行を萎縮させます。探索枠、業務枠、高額承認枠に分け、コストセンター別の予算とアラートを置きます。

レビュー時間をゼロとしてROIを計算しないことも重要です。AIで生成が速くなった結果、シニアのレビューが詰まれば納期も粗利も改善しません。レビュー待ちと差戻しを見て、テスト自動化、設計の標準化、タスク分割へ投資します。

また、全チームへ同じモデルとルールを強制しません。機密、言語、リポジトリ規模、レイテンシ、費用で適合は変わります。ただしID、業務、品質、費用、停止の9項目は共通化し、比較可能にします。

GXOの支援

月次レビューで判断する4つの型

ダッシュボードを眺めるだけの会議を避けるため、チーム・業務ごとに次の4判定へ分類します。

横にスクロールして確認できます

判定	観測結果	次の行動
拡大	品質を維持し、リードタイム・処理能力・粗利が改善	同じリスクとコード特性を持つチームへ段階展開
基盤改善	利用は多いがレビュー待ち、テスト、古い依存が詰まる	モデル追加よりCI、テスト、設計、依存更新を優先
対象変更	利用量はあるが採用されず、業務価値が低い	文書化、テスト生成、移行など適合タスクへ絞る
停止	重大脆弱性、契約違反、費用超過、ログ欠落が解消しない	接続・リポジトリ単位で停止し、証拠保全と再審査