3行まとめ
このテーマをもう少し広げて見るなら、Android CLI 1.0の導入判断：Antigravity連携、Android Skills、Android Benchで確認すること と Google Cloud Open Knowledge Formatの導入判断：OKF v0.1でAIエージェントに渡す知識をどう整えるか も合わせて確認してください。AI支援開発のROIを、CLIやエージェント導入時の実務フローとつなげて考えられます。
レビュー、テスト、セキュリティ確認、承認待ちまで含めて、現在の開発フローをベースライン化する。
学習、検証負荷、パイプライン調整による初期の落ち込みを、PoC期間と停止条件に反映する。
StandardとEnterpriseは価格だけでなく、private code repositories、Google Cloud連携、データ条件で判断する。
ROIは導入後の感想ではなく、導入前に測る指標と費用範囲を決めてから評価する。
Google Cloudは2026年6月10日、DORAのAI支援開発ROIに関する考え方を紹介し、DORAのROI calculatorやレポートへ誘導しました。Gemini Code AssistのようなAIコーディング支援は、導入後の感想ではなく、導入前の開発フロー、レビュー、テスト、セキュリティ確認、費用を測れる状態にしてから評価する必要があります。
DORAが示すJ-Curveは、AI導入初期に学習、検証、パイプライン調整で一時的な落ち込みや不安定さが起き得るという見方です。これは「必ず成功するまで待つ」という免罪符ではなく、PoC期間、予算、停止条件を先に決めるための材料として読むべきです。
Gemini Code AssistのStandardとEnterpriseは、価格だけでなく、private code repositoriesに基づくカスタマイズ、Google Cloudサービス連携、利用量、Customer DataとService Dataの扱いまで含めて判断します。この記事は投資助言ではなく、Alphabet Watch Japanによる非提携の製品・導入判断メモです。
Gemini Code AssistのROIは導入後ではなく導入前に測る
- 1現状の開発フロー
仕様確定、実装開始、レビュー待ち、CI失敗、セキュリティ承認、リリース前作業を分けて測る。
- 2改善したい指標
変更リードタイム、レビュー滞留、CI失敗率、再レビュー回数などから、PoCで見る指標を2つか3つに絞る。
- 3ROI calculatorの入力
対象人数、時間単価、短縮したい作業、検証に必要な時間を、組織ごとの前提として集める。
- 4検証工程の副作用
生成コードが増えた分のレビュー、テスト、セキュリティ確認、手戻りを費用として扱う。
実装速度だけを測ると、レビューやCIの詰まりを見落としやすい。
AI支援開発のROIを測るとき、最初に見たいのは「何分短縮できたか」ではありません。導入前に、今の開発フローがどこで詰まり、どの工程に人の時間が消えているかを測れているかです。
Gemini Code AssistのようなAIコーディング支援は、コード補完、チャット、IDE内の支援、Google Cloud上の開発支援にまたがります。便利さは体感しやすい一方で、組織としてのROIは体感だけでは説明できません。DORAのROI calculatorも、組織ごとの前提を入力して潜在的な投資対効果を測るための道具であり、どの会社にも同じ結果を保証する資料ではありません。
まず現在の開発フローをベースライン化する
導入前に測るべきものは、AIツールの利用率よりも、今の開発フローです。たとえば、仕様確定から実装開始までの待ち時間、レビューの滞留、テスト失敗後の戻り、セキュリティ承認、リリース前の手作業を分けます。
AI支援で実装速度が上がっても、レビューとCIが詰まれば全体のリードタイムは短くなりません。生成コードが増えた分だけ確認負荷が増えれば、むしろ変更失敗率や手戻りが悪化する可能性もあります。ROIを測るなら、AIが触れる工程だけではなく、その後ろにある検証工程まで同じ線上に置く必要があります。
確認項目
- 直近1から3か月の変更リードタイム、レビュー待ち時間、CI失敗率、再レビュー回数を出せるか。
- 開発者が実装以外に使っている時間を、調査、環境構築、テスト修正、レビュー対応、承認待ちに分けられるか。
- AI支援を使うチームと使わないチームを比較する場合、プロダクト規模、リリース頻度、品質基準の違いを補正できるか。
- PoCで改善したい指標を、導入前に2つか3つに絞っているか。
ROI calculatorに入れる数字を先に集める
DORAのROI calculatorは、AI支援開発の潜在的な投資対効果を測るための公式ツールです。DORAのページでは、これはROI of AI-assisted Software Development reportと組み合わせて使う計算ツールと説明され、入力内容や個人情報を保存しないとも案内されています。
ここで大事なのは、計算結果をそのまま社内稟議の結論にしないことです。入力する人数、給与、ツール費用、学習期間、時間短縮、品質改善、リリース遅延の削減などは、組織ごとの前提に左右されます。入力値が粗ければ、結果も粗くなります。
AI採用率とROIを混同しない
Google Cloud Blogは、DORAのstate of AI-assisted software development reportに基づき、DORA調査回答者の90%が仕事でAIを使っていると紹介しています。ただし、同じ記事は、採用が広がっても実際の財務影響は組織によって分かれるとも述べています。
この点は、Gemini Code Assist導入でも同じです。利用率が高い、補完の受け入れ率が高い、生成行数が増えた、という数字だけではROIになりません。価値に変わるのは、不要な手戻りが減る、レビューが速くなる、復旧が早くなる、セキュリティ確認が標準化される、開発者が価値の高い作業へ戻れる、といった変化です。
DORAのJ-Curveは失敗サインではなく初期投資として読む
- 導入前
現在の指標、品質基準、利用範囲、禁止入力、レビュー観点を先に固定する。
- 学習期
promptだけでなく、context、intent、社内コードベース、品質基準の扱い方をチームで合わせる。
- 検証負荷
生成コードが増えるほど、レビュー、テスト、設計適合、セキュリティ確認の時間が必要になる。
- パイプライン適応
CI、レビュー担当、テストデータ、承認、リリース判定の詰まりを見つけ、全体の流れに戻す。
- 定着判定
初期の落ち込みと改善兆候を分け、継続、見直し、中止の基準で判断する。
J-Curveは改善を待つための言い訳ではなく、PoC期間、予算、停止条件を決めるための考え方。
Google Cloud Blogは、AI支援開発の価値実現が直線ではなく、初期に一時的な生産性低下や不安定期を伴うJ-Curveになり得ると説明しています。主な理由として、learning curve、verification tax、pipeline adaptationが挙げられています。
この見方は、導入初月の数字が悪いから即失敗、という判断を避ける助けになります。一方で、何か月たっても改善しない状態を「J-Curveだから」と放置する理由にはなりません。J-Curveは、初期費用を見える化し、見直し条件を決めるための概念です。
learning curveはpromptからcontextとintentへ移る時間
AI支援開発では、最初はプロンプトの書き方に目が向きます。しかし組織導入では、単発の指示文よりも、どのリポジトリ文脈を渡すか、どのアーキテクチャ制約を守るか、どの品質基準で出力を受け入れるかが重要になります。
Gemini Code Assist Enterpriseでは、private source code repositoriesに基づくカスタマイズを使えると公式ドキュメントが説明しています。これは便利な一方で、組織固有の文脈をAIに扱わせる準備が必要になるということでもあります。学習時間は、開発者がAIに慣れる時間だけでなく、チームが「何を渡して、何を渡さないか」を合意する時間です。
verification taxは生成コードが増えるほど重くなる
Google Cloud Blogは、AIが生むコード量が増えると、生成物を厳密に確認するための追加時間が必要になると説明しています。ここを見落とすと、実装だけ速くなり、レビュー、テスト、セキュリティ確認が詰まります。
特に、既存の設計原則、内部ライブラリ、監査要件、ログ出力、例外処理、認可チェックがある組織では、AIが書いたコードを「動いたから良い」とは扱えません。生成コードは、通常のコードと同じ品質ゲートを通す必要があります。
pipeline adaptationは下流工程の詰まりを見つける作業
AI支援で個々の開発者が速くなると、下流工程が目立つようになります。CIの待ち時間、レビュー担当者不足、テストデータ準備、変更承認、セキュリティスキャン、リリース判定が詰まるなら、AIツール単体の費用対効果は伸びにくくなります。
Kaggle Benchmarksローカル作成の記事で扱ったように、AI導入では評価タスクを作る側の設計も必要です。Gemini Code Assistでも、単に導入するのではなく、どのタスクで改善を測るかを先に決めておく方が、J-Curveの中身を説明しやすくなります。
費用はライセンス料だけでなく検証と運用を含める
価格ページの金額は出発点であり、稟議では為替、請求通貨、契約条件、販売パートナー経由の条件も確認する。
Gemini Code Assistの公式製品ページでは、価格はユーザー単位の月額ライセンスで、月次または年間コミットメントの条件が示されています。2026年6月11日に確認した範囲では、Standardの月次は1ユーザーあたり月22.80ドル、年間コミットメントは月19ドル、Enterpriseの月次は月54ドル、年間コミットメントは月45ドルです。月次プランには最大50ユーザーまでの30日無料トライアルも案内されています。
この価格はROI計算の出発点ですが、全体費用ではありません。社内導入で効いてくるのは、ライセンス以外の初期費用と運用費です。
見える費用は契約、ユーザー数、期間で決まる
見える費用は比較的扱いやすい数字です。利用者数、StandardかEnterpriseか、月次か年間コミットメントか、トライアル後に誰を対象にするかを決めれば、一定の見積もりができます。
ただし、価格ページは更新される可能性があります。USD以外の通貨ではCloud Platform SKUsに記載される価格が適用されるという説明もあります。日本の組織が稟議に使う場合は、為替、請求通貨、Google Cloud契約、販売パートナー経由の条件を別途確認する必要があります。
隠れた費用は学習、レビュー、管理、監査に出る
隠れた費用は、PoCの途中で見え始めます。たとえば、開発者向けの利用ガイド作成、IDE設定、権限付与、ログ確認、プロンプトに入れてよい情報の線引き、生成コードレビューのルール作り、セキュリティチームへの説明です。
AI支援によって実装速度が上がっても、レビュー担当者が足りなければコストはレビュー待ちに移ります。テストが弱ければ、後工程で不具合対応に変わります。ROIを計算するときは、ライセンス費を支出欄に入れるだけでなく、こうした検証と運用の時間を費用として扱う方が現実に近くなります。
費用に入れたい項目
| 項目 | 見る理由 |
|---|---|
| ライセンス費 | StandardとEnterprise、月次と年間コミットメントで費用が変わるため |
| 初期教育 | 開発者が単発のpromptからcontextとintentを扱う運用へ移るため |
| レビュー時間 | 生成コードの正確性、設計準拠、セキュリティを確認するため |
| テストとCI | コード量増加で下流工程が詰まらないかを見るため |
| 管理者運用 | 権限、ログ、利用状況、ガイドラインを保守するため |
| セキュリティ確認 | Customer Data、Service Data、private codebaseの扱いを合意するため |
StandardとEnterpriseは価格差より適用範囲で分ける
Enterpriseが常に優位という話ではなく、private codebaseとCloud連携がROIに効く条件かどうかを確認する。
Gemini Code Assistの公式ドキュメントは、StandardとEnterpriseを分けて説明しています。Standardは、エンタープライズグレードのセキュリティを備えたAI coding assistanceとして、アプリケーションの構築と運用を支援します。EnterpriseはStandardの機能に加えて、private source code repositoriesに基づくカスタマイズや、より広いGoogle Cloudサービス連携を含む位置づけです。
したがって、比較の軸は「高いか安いか」だけでは足りません。組織のコードベース、開発プロセス、Google Cloud利用範囲、セキュリティ要求に照らして、どちらの適用範囲が必要かを決めるべきです。
Standardが合うのは共通支援を早く始めたいチーム
Standardは、IDEでのコード支援、チャット、一般的なコーディング支援を、まずチームへ広げたい場合に検討しやすい選択肢です。既存の開発標準が比較的明確で、AIに社内リポジトリ固有の文脈を深く反映させる必要がまだ小さいなら、PoCの第一段階として扱いやすくなります。
ただし、Standardでも管理とセキュリティの確認は必要です。誰にライセンスを配るか、どのIDEで使うか、どのリポジトリで使うか、ログや利用状況をどう見るかを決めないまま広げると、導入後の評価が曖昧になります。
Enterpriseが合うのはprivate codebaseとCloud連携が効く組織
Enterpriseは、private source code repositoriesに基づくカスタマイズ、ApigeeやApplication Integrationなどへの支援、追加のGemini Cloud Assist機能、より多いagent modeやGemini CLI利用量が示されています。複数チーム、複数サービス、共通プラットフォームを持つ組織では、Enterpriseの差分がROIに影響する可能性があります。
一方で、Enterpriseの価値は「上位プランだから自動的に高い」わけではありません。社内コードベースが整理されていない、所有者が曖昧、ドキュメントが古い、テストが弱い、といった状態では、AIに渡す文脈そのものが不安定になります。DORAのJ-Curveでいうlearning curveとpipeline adaptationを短くする準備が必要です。
Gemini CLIやAntigravityの話題と分ける
最近の開発者向けAIでは、Gemini CLIからAntigravity CLIへの移行のように、ツール名や提供条件の変化も追う必要があります。詳しい対象や期限は、Gemini CLIからAntigravity CLIへの移行記事で整理しています。
ただし、この記事の主題は、Gemini Code Assist StandardとEnterpriseをチーム導入するときのROI測定です。個人向けCLIの移行条件、Google AI ProやUltraの文脈、Google Cloud契約下のCode Assist評価を混同しないことが大切です。
DORA指標でAI支援の効果と副作用を同時に見る
PR件数や補完accept率だけでは、ユーザーへ届く価値と運用品質を説明しにくい。
DORAのソフトウェアデリバリー指標は、AI支援の効果を見るときにも使えます。DORAの公式ガイドは、ソフトウェアデリバリー性能をthroughputとinstabilityに分け、変更がどれだけ安全かつ効率よく本番へ届いているかを見る枠組みを示しています。
AI導入では、throughputだけを追うと危険です。コード作成が速くなったように見えても、change fail rateやdeployment rework rateが悪化すれば、ユーザーへの価値は下がります。速度と不安定さを同時に見て、初めてROIの議論に近づきます。
throughputは速度だけでなく詰まりを見る
DORAのガイドは、throughputの要素としてchange lead time、deployment frequency、failed deployment recovery timeを説明しています。AI支援で期待しやすいのは、調査、実装、テスト修正、ドキュメント作成の時間短縮です。
ただし、deployment frequencyが増えても、リリース後の手戻りが増えるなら健全ではありません。change lead timeが短くなっても、レビューの質が落ちたら副作用が出ます。AI支援のPoCでは、単に「何件のPRが増えたか」ではなく、どこで待ち時間が減ったかを見ます。
instabilityはAIの副作用を映す
DORAの公式ガイドは、instabilityの要素としてchange fail rateとdeployment rework rateを挙げています。AI支援で生成コード量が増えると、不十分な検証のまま変更が流れるリスクも増えます。
PoCでは、変更失敗率、ロールバック、ホットフィックス、緊急対応、セキュリティレビュー差し戻しを追うべきです。AI支援で開発者体験が改善しても、運用チームやレビュー担当者の負荷が増えていれば、組織全体のROIは下がるかもしれません。
評価セットを作ると数字がぶれにくい
AI支援開発のPoCでは、普段のチケットだけで測ると、タスクの難易度差に引っ張られます。バグ修正、テスト追加、リファクタリング、API追加、ドキュメント更新など、代表的なタスクを小さな評価セットにしておくと、比較がしやすくなります。
これは、Vertex AI生成AI SDK移行の記事で扱ったような移行作業にも似ています。移行対象、期限、API差分、テスト範囲を分けて測ることで、AI支援がどこに効いたかを説明できます。
セキュリティとデータ条件はPoC前に合意する
prompt data、response data、会話履歴、開いているファイルや隣接ファイルのsnippets、カーソル位置を確認する。
requestやresponseを受けた事実、応答への反応、受け入れたsuggestionの文字数、UI操作などを分けて見る。
promptsとresponsesを保存しない説明と、Cloud Logging bucketに保存する設定の要否を切り分ける。
顧客のコード、入力、生成されたrecommendationsがshared modelsのtrainingや製品開発に使われない条件を確認する。
設計原則、セキュリティ基準、ライセンス、テスト、レビュー、運用影響はチーム側で確認する。
セキュリティとデータ条件は単純な勝敗ではなく、利用範囲、ログ保存、IAM、監査要件との組み合わせで決める。
Gemini Code Assistは開発者のIDEやコード文脈に近い場所で使われます。そのため、ROIを測る前に、セキュリティ、プライバシー、データ処理条件を確認する必要があります。
Google Cloudのセキュリティとプライバシードキュメントでは、Gemini Code Assist StandardとEnterpriseが扱うCustomer Dataの例として、prompt data、response data、会話履歴、開いているファイルや隣接ファイルのsnippets、カーソル位置などが示されています。これは、開発者の入力だけでなく、開発環境の文脈も評価対象に入るということです。
Customer DataとService Dataを分ける
Customer Dataは、開発者のquery、Gemini Code Assistのresponse、IDE内の文脈など、利用時に直接関わるデータです。公式ドキュメントは、Gemini Code Assist StandardとEnterpriseはstateless Google Cloud servicesであり、promptsとresponsesをGoogle Cloudに保存しないと説明しています。必要な場合は、Cloud Logging bucketに入力と応答を保存する設定も案内されています。
Service Dataは、ユーザー分析、telemetry、Google feedbackなどです。telemetryの例には、requestが行われたこと、responseを受けたこと、応答への反応、受け入れたsuggestionの文字数、UI操作などが含まれます。公式説明では、requestやresponseの中身そのものではなく、技術的な運用や利用状況に関するデータとして例示されています。
モデル学習への利用条件を確認する
Gemini Code Assistの製品ページは、顧客のコード、入力、生成されたrecommendationsがshared modelsのtrainingや製品開発に使われないことをデータガバナンス方針として説明しています。これは導入判断で重要な安心材料です。
それでも、社内のセキュリティ審査では、公式文書の表現をそのまま貼るだけでは足りません。どのリポジトリで使うか、機密情報を含むファイルをどう扱うか、ログ保存を有効にするか、feedback送信をどう扱うか、VPC Service ControlsやIAMの設定が必要かを具体的に決める必要があります。
生成コードの責任はチームに残る
AIが生成したコードでも、責任は導入組織に残ります。設計原則、セキュリティ基準、ライセンス、テスト、レビュー、運用影響は、人間の開発プロセスで確認する必要があります。
ここを曖昧にしたままROIを測ると、短期的な実装速度だけが前に出て、後から監査、脆弱性修正、再設計の費用が出ます。セキュリティ観点では、Google AI Threat Defenseの記事も合わせて読むと、AI支援と防御側の確認点を分けやすくなります。
PoCでは継続、拡大、中止のラインを先に決める
- 開始前
対象チーム、対象タスク、DORA指標、セキュリティ条件、費用範囲、停止条件を文章化する。
- 30日
初期設定、利用開始、開発者の反応、よく使うタスク、レビューでの違和感、セキュリティ上の疑問を見る。
- 90日
レビュー滞留、CI失敗、変更失敗率、復旧時間、手戻り、開発者体験を見て、J-Curveの中身を分ける。
- 継続
リードタイム短縮やレビュー滞留減少があり、失敗率の悪化がない場合は、対象チームを限定して続ける。
- 拡大または中止
複数タスクで再現性があれば拡大し、副作用や運用負荷が大きければ利用範囲や条件を見直す。
PoCの目的は万能なROIを証明することではなく、自社の開発フローで効く工程と副作用を見つけること。
Gemini Code AssistのPoCを行うなら、開始前に「成功」「要改善」「中止」のラインを決めておくべきです。導入後に数字を見ながら基準を作ると、良い数字だけを拾いやすくなります。
PoCの目的は、万能なROIを証明することではありません。自社の開発フローにおいて、どの工程にAI支援が効き、どこに副作用が出るかを見つけることです。
30日で見るものと90日で見るものを分ける
公式ページでは、月次プランに最大50ユーザーまでの30日無料トライアルが案内されています。30日で見られるのは、初期設定、利用開始、開発者の反応、よく使うタスク、レビューでの違和感、セキュリティ上の疑問です。
一方で、DORA指標やリリース品質への影響は、30日だけでは見えにくい場合があります。90日程度の期間で、レビュー滞留、CI失敗、変更失敗率、復旧時間、手戻り、開発者体験を見た方が、J-Curveの一時的な落ち込みと定着後の改善を分けやすくなります。
継続ラインは価値と副作用をセットにする
継続ラインは、改善だけでなく副作用も含めて決めます。たとえば、変更リードタイムが短くなっても、change fail rateが悪化したら拡大しない。レビュー待ちが減っても、セキュリティ差し戻しが増えたらプロンプトや利用範囲を見直す。開発者満足度が上がっても、運用チームの負荷が増えたら導入範囲を絞る。
このように、価値と副作用を同じ表で見ると、導入判断が感想から離れます。
| 判断 | 見る数字 | 次の行動 |
|---|---|---|
| 継続 | リードタイム短縮、レビュー滞留減少、失敗率悪化なし | 対象チームを限定して継続 |
| 拡大 | 複数タスクで再現性があり、下流工程も詰まらない | 利用範囲、管理、教育を整えて拡大 |
| 見直し | 生成量は増えたがレビューやCIが詰まる | タスク選定、テスト、レビュー基準を調整 |
| 中止 | 品質悪化、セキュリティ懸念、運用負荷増が続く | ライセンス対象や導入目的を再設計 |
社内説明ではDORAと費用を一枚にする
社内説明では、DORA指標、ツール費用、学習費用、セキュリティ条件を別々に出すと伝わりにくくなります。PoC開始前、PoC中、定着後の3段階に分け、各段階で見る数字を決めると、意思決定者が判断しやすくなります。
2026年6月のGoogle CloudやGemini関連の更新は、月次まとめでも追っています。AI支援開発はモデル、CLI、Cloudサービス、セキュリティ機能が連動して変わるため、単発の価格表だけでなく、周辺アップデートも合わせて確認するのが安全です。
まとめ：ROIを語る前に測る設計を持つ
開発フロー、レビュー、テスト、セキュリティ、運用の現状を先に出す。
learning curve、verification tax、pipeline adaptationを、J-Curveの中の費用として扱う。
StandardとEnterpriseは、private codebase customization、Google Cloud連携、データ条件まで含めて判断する。
改善指標と副作用を同じ表で見て、拡大、見直し、中止を決める。
ROIはツール導入だけで自動的に出るものではなく、測る設計を持つことで説明しやすくなる。
Google Cloud Blogが紹介したDORAのAI支援開発ROIは、Gemini Code Assist導入を考える組織にとって、便利な宣伝文句ではなく、測定設計を作るための材料です。J-Curve、learning curve、verification tax、pipeline adaptationを先に理解しておくと、初期の落ち込みや下流工程の詰まりを、感情ではなく数字で扱いやすくなります。
導入前に見るべき順番は、まず現在の開発フロー、次にAI支援が触るタスク、続いてレビュー、テスト、セキュリティ、運用の副作用です。StandardとEnterpriseは、価格差だけでなく、private codebase customizationやGoogle Cloud連携、データ条件まで含めて判断します。
ROIは、ツールを入れれば自動で出るものではありません。測る指標を決め、初期費用を見える化し、継続と中止のラインを先に置くことで、Gemini Code Assistを試す意味がはっきりします。
次に読むなら
参照した主な情報源
- Google Cloud Blog「How to unlock true ROI in software development – a deep dive into the latest DORA research」
https://cloud.google.com/blog/products/ai-machine-learning/how-to-measure-the-business-value-of-generative-ai 確認日: 2026年6月11日
- DORA「ROI of AI-assisted software development calculator」
https://dora.dev/ai/roi/calculator 確認日: 2026年6月11日
- DORA「DORA’s software delivery performance metrics」
https://dora.dev/guides/dora-metrics/ 確認日: 2026年6月11日
- Google Cloud「Gemini Code Assist for teams and businesses」
https://cloud.google.com/products/gemini/code-assist 確認日: 2026年6月11日
- Google Cloud「Gemini for Google Cloud pricing」
https://cloud.google.com/products/gemini/pricing 確認日: 2026年6月11日
- Google Cloud Documentation「Gemini Code Assist Standard and Enterprise overview」
https://cloud.google.com/gemini/docs/codeassist/overview 確認日: 2026年6月11日
- Google Cloud Documentation「Security, privacy, and compliance for Gemini Code Assist Standard and Enterprise」
https://cloud.google.com/gemini/docs/codeassist/security-privacy-compliance 確認日: 2026年6月11日
更新履歴
- 2026年6月11日
Google Cloud Blog、DORA calculator、DORA metrics、Gemini Code Assist product/pricing/overview/security docsを確認し、初版を作成。
価格、提供条件、セキュリティ説明は更新される可能性があるため、導入判断では最新の公式情報を確認する。
- 2026年6月11日: Google Cloud Blog、DORA calculator、DORA metrics、Gemini Code Assist product/pricing/overview/security docsを確認し、初版を作成。