はじめに こんにちは！ファインディのTeam+開発部でエンジニアをしている澁谷（ TENTEN11055 ）です。 普段はチームで Findy Context というプロダクトの開発に取り組んでいます。 prtimes.jp 2025年11月、AWS主催のAI-DLC Unicorn Gymに参加し、AI駆動開発の手法であるAI-DLCを実践しました。 学びはとても大きかった一方で、自分たちのチームにそのまま持ち込むには壁もあり、現場の実態に合わせて作り変える必要がありました。 Unicorn Gym参加時の様子はこちら。 tech.findy.co.jp AI-DLCはAIが作業を実行し、人間が監視と判断に集中する開発手法です。 要件・ストーリー・作業単位を整理する Inception 、設計・実装・テストを進める Construction 、IaCやデプロイを担う Operation の3フェーズで構成され、AIが提案する成果物をチーム全員で検証しながら進めます。 チームではそのうち実装に関わるInceptionとConstructionの2フェーズを採用しました。 詳細は次の記事を参照ください。 aws.amazon.com この記事ではAI-DLCをClaude Skill化し、Epic制開発フローの中で要件整理からテストまでを一人のメンバーが一貫して担えるようにした取り組みを紹介します。 はじめに チームが抱える課題 担当領域越境の必要性 AI-DLCをそのまま取り入れる難しさ Epic制開発フローの導入 AI-DLCの2フェーズと付随する作業をClaude Skill化する 1. フォーマットのばらつきが改善 2. 横展開を容易にする 3. ツールを利用してよりシームレスな設計ができる 4. 付随するスキルの精度が上がり、人間の負担を下げる スキル運用後の効果とまとめ チームが抱える課題 これまではPMやデザイナー、QAエンジニアといった専任者と分業する形で開発してきましたが、チーム構成の変化により、エンジニア自身が担当領域を越境していく必要が出てきました。 担当領域越境の必要性 チームのフロントエンド専任者が一人のため、フロントの設計・実装を全て頼るわけにもいきません。 また4月末でQAエンジニアが別プロダクトへ異動となり、実装者のみでのテスト設計、ケース実装を担うことになりました。 さらに専任のPMも他プロダクトを兼務しており割ける時間が限られるため、要件整理など本来PMの領域だった部分にも開発者が踏み込んでいく必要があります。 これらを加味し、エンジニア一人一人が担当領域を広げる必要が出てきました。 AI-DLCをそのまま取り入れる難しさ そこで越境を支援する手段として、これまで個々人で自由に行なっていたAI-DLCをチームの開発フローとして取り入れることを検討しました。 しかしInceptionフェーズは関係者が集まって仕様を決めていくスタイルであり、その実施には一定の同期コストが発生します。 作りたい機能の具体が曖昧であればあるほど全員参加は効果的になりますが、Epicイシューが作成された段階で既に一定の解像度がある場合は、PMも含め全員で擦り合わせをすると、得られる解像度向上に対して投入する時間（チーム全体の同期コスト）の方が目立ってしまいます。 Epic制開発フローの導入 これらの課題を解決する一環としてチームではEpic制を導入しました。 こちらはVPoEの ham さんが Findy Team+ 開発で実施した 個人アサインへのシフト に影響を受けています。 tech.findy.co.jp 各Epicにメンバーをアサインすることで要件整理から開発まで一貫して責任を持つようになり、ボトルネックも発生しづらくなります。 実際の運用としては、大まかに次の流れで開発を進めています。 Epic担当者はAI-DLCスキルを用いてInceptionドキュメントを作成する ワイヤーフレーム作成スキルに1のドキュメントを読み込ませ、HTMLでワイヤーを作成する 1と2を元にデザイナーとPMに確認をとる AI-DLCスキルでConstructionドキュメント、テスト設計、テストケースを実装する デザイン、実装、テスト 受け入れ確認、リリース チーム内ではこれらを用いたフローを AI-E-DLC (AI - Epic - Driven Development Life Cycle) と名付けており、今後も運用と改善を重ねていこうとしています。 ここからはこのフローの1と4で利用するAI-DLCスキルについて掘り下げていきます。 AI-DLCの2フェーズと付随する作業をClaude Skill化する 同じプロンプトを用いてドキュメントを作成しても、AIの成果物にはばらつきが生じる可能性があります。 そのためAI-DLCにおけるInceptionとConstructionのドキュメント生成をそれぞれスキル化し、潜在的な課題をいくつか改善することができました。 1. フォーマットのばらつきが改善 同じAI-DLCのプロンプトを使っても、書き手によって構成・粒度にばらつきが生じたり、必要な情報が抜けたりすることで、実装・テスト設計・レビューなどの工程でAIが読み取りにくいドキュメントが生まれていました。 この課題に対し、スキルで手順と出力フォーマットを固定し、誰が実行しても同じ骨格のドキュメントを出力できるようにしています。 ちなみにこのフォーマットの固定化が多くの改善の起点になっており、これなしでは後述の内容も実現しえませんでした。 2. 横展開を容易にする AI-DLCの手法を各メンバーが再現するには、フェーズ理解・プロンプト設計・観点整理の習熟が必要であり属人化しやすいものですが、スキル化により手順がガイドされるため、未経験者でも気軽に実践できる「型」として提供できます。 またFindy Contextが複数リポジトリで構成されるため、リポジトリ非依存で動くスキルにしています。 今まで各リポジトリに合わせたプロンプトを用意する必要がありましたが、どれにおいても同じスキルを呼べばOKな状態にしています。 汎用性の高いスキルにすることでどこでも誰でもAI-DLCに則ったドキュメントを作成できるようになりました。 3. ツールを利用してよりシームレスな設計ができる AIからの質問事項にはClaude Codeの AskUserQuestion ツールを必ず利用させています。 InceptionではAIから人間への質問フェーズが存在し、ドキュメントに記載された質問に対し人間が回答を書き込むのが基本でした。 これに対し選択 or 自由回答という形式をとり回答候補を提示してもらうことで一から考えることがなくなるため、回答作業だけでなく脳の負担も軽減されました。 他にも一部の難易度の高い作業をAgentに任せるなど、場面に適した設定を共有できるのもスキル化の利点の一つです。 AskUserQuestionを利用した際のサンプル 4. 付随するスキルの精度が上がり、人間の負担を下げる フォーマットのばらつきが改善されたことにより、 専用のテスト設計・ケース実装スキルとドキュメントレビュースキル も作成することができました。 テストをAIで用意する際、何を材料とするかが重要です。 もしコードを材料とした場合、そのコードが仕様に沿っていなければ誤ったテストとなってしまいます。 このテスト設計・作成スキルはInception・Constructionドキュメントを材料とし、エンジニア・PM・デザイナー間で認識が揃った仕様を前提とするため高い精度を出すことができます。 またドキュメントレビューに関してはAI-DLCの中で最も人間の負荷が高い作業です。 AI-DLCスキルで生成されるドキュメントは10ファイルを超え、全部均等にレビューしようとすると破綻します。 そこでレビュースキル側で、生成されたドキュメントを「核となるドキュメント（仕様の中核を担うもの）」と「補助となるドキュメント（核を支える補足）」に分類し、Epicイシューとも照らし合わせて齟齬や抜けがないかをチェックさせています。 これにより人間が熟読すべきドキュメントを明確にし、レビュー負荷を下げることができました。 スキル運用後の効果とまとめ 運用を始めて数日が経ちましたが、想像以上に強力なスキルとフローであると感じています。 チームの課題でもあった「役割の越境」に対して有効なアプローチとなり、これまで専任者（PM・デザイナー・QAエンジニアなど）に頼っていた作業の下地を実装者が担い、専任者はレビュー・判断に集中できるようになりました。 習熟度の壁を下げられたことも大きな成果で、スキル作成後に説明する場を設けなくても気づいた時には他メンバーが使っており、数日後にはスキルの改善PRも上げてくれていました。 レビューにおいてもAI-DLCを始めた頃によくあった「ドキュメントレビューしんどい...」という声は幸いまだ聞こえてきていません。 今回の取り組みはAI-DLCをそのまま導入するのではなく、チームの開発体制や課題に合わせて適応させる試みでした。 まだ運用を始めて間もないため改善の余地はありますが、その部分に誰もが参加できる間口を用意できるのもスキル化の利点かもしれません。 ファインディでは一緒に働くメンバーを募集中です！ よかったら覗いてみてください。 herp.careers

こんにちは、株式会社タイミーでMLOpsエンジニアをしているKYです。普段はMLプラットフォームの構築・運用を担当しています。 実務の中でコンテナイメージのサプライチェーンセキュリティ強化を進めており、その一環として Docker 社が提供する「Docker Hardened Images（DHI）」の実装を辿る機会がありました。 その際、実際の定義ファイルを見て、少し驚きました。コンテナのビルド定義といえば「Dockerfile」が当たり前だと思っていたのですが、DHI の定義はなんと YAML で書かれていたのです。 「なぜ Dockerfile ではないのか？」と定義の読み方を追いかけていくうちに、BuildKit のアーキテクチャに行き着きました。この記事では、DHI の仕組みを通じて、私たちが普段の Dockerfile 運用で押さえるべきポイントを再確認したいと思います。 ビルド定義の主役は「Frontend」 BuildKit は、「定義を解釈する部分（Frontend）」と「実際にビルドを実行する部分（Backend）」に分離しています。Frontend は、入力（Dockerfile や YAML）を BuildKit の中間表現（LLB）に変換する役割を持ちます。 ここで鍵になるのが、ファイル先頭のコメント行 # syntax=... です。BuildKit はまずこの1行を読み、どの Frontend で後続を解釈するかを決めます。つまり、Docker 公式が推奨しているのに見落とされがちな以下の1行は、単なるコメントではなく「このファイルは公式の Dockerfile Frontend で解釈してほしい」という宣言です。 # syntax=docker/dockerfile:1 一方で DHI の定義ファイルを開くと、YAML の1行目に次の指定があります。 # syntax=dhi.io/build:2-debian13 YAML も # をコメントとして扱うため、BuildKit から見れば「 # syntax= から始まるビルド定義」という意味で入口は同じ。その後の中身を YAML として解釈するのは、差し替えられた DHI Frontend の仕事 というわけです。 DHI は何をしているのか：YAML をコンパイルする DHI の定義ファイル（YAML）は、 RUN apt-get... のようにといった手順を重ねるのではなく、「最終的に何を入れるか」という状態を宣言します。 【DHI の YAML 定義例（実際の定義ファイルからの抜粋）】 # syntax=dhi.io/build:2-debian13 name : Debian 13 Base image : dhi.io/debian-base variant : runtime platforms : - linux/amd64 - linux/arm64 dates : release : "2025-08-09" end-of-life : "2028-08-09" contents : packages : - '!libelogind0' - '!mawk' - '!original-awk' - base-files - bash - ca-certificates - coreutils # ... 以下、ベースに含めるパッケージの列挙が続く accounts : run-as : nonroot users : - name : nonroot uid : 65532 gid : 65532 cmd : - /bin/bash いくつかのフィールドに注目してみます。 contents.packages : !mawk のように ! プレフィックスを付けると「明示的に含めない」パッケージを宣言できます。削除手順を書くのではなく、最初から「入れない」と表明する点が Dockerfile との大きな違いです。 accounts.run-as: nonroot : 実行ユーザーを非 root に固定する宣言で、Dockerfile の USER 命令に相当します。Dockerfile のように RUN useradd ... といったユーザ作成手順を書く必要はなく、「誰で動かすか」という状態だけが残る点が特徴です。 dates.end-of-life : イメージのライフサイクル終了日まで定義に含まれており、運用上の管理情報もビルド定義の一部として扱われています。 このように、DHI の YAML は「どう作るか」ではなく「何が入っていて、誰が動かすか」を宣言しています。そしてここで重要なのは、 BuildKit が YAML を直接ビルドしているわけではない という点です。 DHI の Frontend がこの YAML を読み込んで中間表現（LLB）へコンパイルし、あとは通常通り BuildKit がビルドを実行します。つまり、DHI の YAML は「別言語」ではなく、 Frontend を差し替えて得た “別の入力形式” なのです。 たとえば不要パッケージの除外ひとつとっても、Dockerfile では apt-get remove → autoremove → キャッシュ削除と手順を重ねる必要があります。一方、DHI なら - '!mawk' の1行で意図が完結します。手順（How）ではなく意図（What）だけが残るため、セキュリティ監査や再現性の面で有利です。DHI が宣言的定義を採用しているのは、こうした相性の良さがあるからです。 忘れられがちな Dockerfile の公式推奨設定 今後、DHI のような宣言的フロントエンドがすぐに主流になるかは未知数であり、当面は既存の Dockerfile 運用が続くでしょう。 しかし、DHI が示す「Frontend は明示し、選ぶものである」という観点は重要です。まずは Docker 公式が推奨する以下の2行を、忘れずに Dockerfile の先頭へ記述しましょう。 # syntax=docker/dockerfile:1 # check=error=true # syntax=... 使用する Frontend を固定し、手元の環境と CI の違いによるビルド結果の揺れを防ぎます。 # check=error=true BuildKit の静的解析（lint）を強め、警告レベルの記述を CI で弾けるようにします。 これらを習慣づけるだけで、「Frontend を明示し、品質を保つ」文化に確実に近づきます。 まとめ DHI から学べる本質は、 BuildKit は Frontend を自由に差し替えられる という点にあります。この視点を持つと、DHI は単なるセキュアなベースイメージではなく、ビルド定義の抽象度を一段上げる試みとして見えてきます。 「手順を書く」から「状態を宣言する」への移行は、Infrastructure as Code で何度か見てきた流れと重なって見えます。DHI を触ってみて、その発想がコンテナビルドの入力形式にも持ち込まれていることを実感しました。 将来的にビルドのパラダイムがどう変わるにせよ、まずは見逃されがちな # syntax=... と # check=... をきちんと置くこと。タイミーでも Cloud Run / Vertex AI Pipelines の DHI 移行を進める中で、Frontend 指定の差がビルド結果の揺れに直結する場面に何度か遭遇し、この2行の重要性を改めて感じました。DHI がもたらした視点を持ちつつ、足元の運用を公式のベストプラクティスで堅牢にする。これが、現実的で安全なコンテナ運用の第一歩です。 参考文献 Docker Hardened Images - カタログリポジトリ Debian 13 Base 定義ファイル（13.yaml） — 記事中の YAML 定義例の抽出元 Custom Dockerfile syntax - Docker Docs Build hardened images - Docker Docs We're Hiring! サプライチェーンセキュリティや ML 基盤の足回りに興味を持っていただけたなら、ぜひ一緒に働きませんか。タイミーでは、ML プラットフォームの構築・運用やサプライチェーンセキュリティの強化に取り組むエンジニアを募集しています！ 少しでも興味を持っていただけましたら、ぜひ以下のリンクから詳細をご覧ください。 MLOpsエンジニア シニアMLOpsエンジニア 募集ポジション一覧

本ブログは、キヤノンIT ソリューションズ株式会社様と Amazon Web Services Japan が共同で執筆しました。 みなさん、こんにちは。AWS ソリューションアーキテクト木村、アカウントマネージャーの池田です。 本記事では、キヤノン IT ソリューションズ株式会社様が 、Amazon Q Developer を開発現場に導入し、3 か月間効果検証を実施した取り組みをご紹介します。コード生成やレビュー支援による効率化、現場での活用事例、そして検証から得られた知見について詳しく解説します。 なお、本ブログに登場する Amazon Q Developer は 2026 年 4 月 30 日に AI 駆動開発IDE「Kiro」へと進化的に統合されることが発表されています 。 本検証で培ったAI駆動開発のプラクティスやノウハウは、Kiro の仕様駆動開発（Spec-driven Development）へとそのまま活かせるものであり、キヤノン IT ソリューションズ様 の取り組みはまさにこの進化を先取りしたものと言えます。 背景/課題 キヤノンITソリューションズ株式会社様(以下、キヤノン ITS )では、生成 AI ツールの社内推進活動を積極的に実施しています。今後 SIer としての競争力を維持していくために、生成 AI の活用は不可欠です。しかし、個人レベルでの試行には限界があるため、企業として活用のための基盤整備や推進を進める必要がありました。 そこでキヤノン ITS 様は、2024年に「生成 AI ビジネス検討委員会」を立ち上げて、生成 AI ビジネスにおける 5 年後のありたい姿と戦略を策定し、その具体的な施策を推進するための「生成 AI ビジネス推進室」を発足。社内の利用ガイドラインの整備、生成 AI ツールの全社的な導入を推進してきました。 生成 AI ツールの導入後に現場への定着をいかに進めるかは、多くの企業にとって共通の課題です。キヤノン ITS 様は全社横断向けの複数回に渡るイベント形式で「AI 駆動開発の普及」を行うことで、より深い活用推進を実施しました。 なぜ Amazon Q Developer を選択したのか(導入当時) 全社利用が可能な生成 AI ツールは導入済みではありましたが、「AI 駆動開発の普及」という目的に対し、コスト・運用・性能のバランスに優れた選択肢であることから Amazon Q Developer を選択しました。 コスト: 月額ユーザー数の固定料金で予算計画が容易 同機能の固定費用で使えるサービスとしては最も安価 運用: 既存の AWS 環境（情報システム部門の管轄）でアカウント管理可能 AWS から導入・普及の支援を受けることができる 性能: Claude Sonnet 4（実施当時）による高精度の生成 MCP 対応による拡張性の高さ セキュリティ・脆弱性診断、モダナイゼーションなど SI に役立つ機能搭載 AI駆動開発の普及をする上での工夫ポイント 本施策が単なるツール導入だけで終わらぬよう、事前に懸念事項を洗い出し、キヤノン ITS 様と AWS にて、役割分担を行い施策設計をしました。 懸念事項 Amazon Q Developerのリリース・キックオフがなされただけで、ツールが使われない 事業部側での予算制限があり、積極利用がなされない ツールの認知はされているが、使い方が分からずに利用がされない AI駆動開発の取組自体が限られた少数のメンバーにしか知られない 対策 オペレーション整備 ツールを使ってもらえるような申請フローの整備（キヤノン ITS） 興味喚起 「このツールは面白い」と思ってもらえるイベント。継続するための仕掛けづくり（AWS） 障壁排除 ハンズオン/定期的なオフィスアワーを行うことで技術的な懸念点を払拭（キヤノンITS/AWS） イベント化 打ち上げ花火のようなオンラインイベントで終わらせず、興味喚起、ハンズオン研修、利用者のトラッキングを行いランキング発表等、全社向けの年末までのロードマップを敷いて継続施策として打ち出す（キヤノンITS/AWS） エグゼクティブスポンサー エグゼクティブスポンサーである、金澤社長からの支援と声かけを実施（キヤノンITS） ロードマップ全体像 AI駆動開発の社内展開に向けて、Amazon Q Developer の業務適用検証を実施しました。本取り組みは、9 月 5 日に開催した「AI Agent DAY」をキックオフとし、Amazon Q Developer を実際の業務に適用した際の有効性を約 3 か月間にわたり検証したものです。 キックオフイベントには約 250 名が参加し、100 名以上の技術者が Amazon Q Developer のハンズオンを体験しました。その後の業務適用検証フェーズでは、生成 AI ビジネス推進室がツール利用費を負担する形で施策を企画し、57 名が参加しています。検証期間中は、インフラおよびアプリケーションを対象としたハンズオンセッションやオフィスアワー、中間イベントを実施しました。あわせて、Teams 上の「生成 AI 交流広場」での情報共有やアンケートを通じた成果の可視化にも取り組んでいます。 最終的には、技術者向けイベント「CITS Day 2025」において、Amazon Q Developer を効果的に活用した取り組みを表彰しています。なお、表彰対象検討のための利用状況のデータ分析においても、Amazon Q Developer を活用しました。 Amazon Q Developer の利用状況を示すダッシュボード Amazon Q Developer へ利用率ランキングを集計するプロンプト CITS Day 2025 での表彰 活用事例 CITS Dayのイベント内では、複数の事例が共有されました。 事例1: 開発ツール×生成AI（佐野様の発表） 抱えていた課題 プログラミングの抽象化レイヤーの進化と開発ツールの変化への対応 開発業務の効率化と生産性向上 資料作成やアイデア整理などのコーディング以外の作業の効率化 導入した理由・きっかけ 新しい開発スタイルで「速さ」「安全性」「柔軟性」を実現するため Kiro との出会い（2024年夏）がきっかけ 生成 AI の柔軟性を活かしつつ、課題（コード品質のばらつき、非機能要件への対応不足など）を解決するため 導入して得られた結果 バイブコーディングモードを活用することで、マークダウン形式で効率的に資料作成が可能に レイアウト案をアスキーアートで事前確認するなど、視覚的な提示が可能に 仕様駆動開発モードではプロトタイプの迅速な作成が実現 バーコードスキャナーアプリの要件からタスク分解、実装まで効率的に進行 事例2: PoCでのAmazon Q Developer活用（可知様の発表） 抱えていた課題 SNS バズ検知を需給マネジメントに繋げるための PoC を短期間・低コストで実施 SNS API や可視化技術など、未経験の技術を習得して実装 技術検証フェーズに時間やコストをかけられない 導入した理由・きっかけ 社内からの提案で、生成 AI の活用が適した題材と判断 低コスト（$19/月）で社内環境も整備されていたため 短期間での技術獲得とプロトタイプ開発、生成 AI 活用のノウハウ獲得を目指して導入 導入して得られた結果 新規技術（SNS API 活用技術、Streamlit によるアプリ開発技術）の習得が迅速に進んだ 開発スピードが約 3 倍に向上（通常 2 週間かかる作業が 3 日で完了） コスト削減（10 人日 → 3 人日＋$19の料金のみ、約 1/3 のコスト） 事例3: Amazon Q Developerを使用したインフラ構築（谷様の発表） 抱えていた課題 インフラ構築業務での効率化とエラー削減 Terraform の定義言語 HCL の習得や適切なコーディングの必要性 インフラコード化（IaC）におけるコードレビューと品質確保 導入した理由・きっかけ インフラ構築業務の流れが「パラメーター設計 → コード生成 → デプロイ → テスト」に変わる中で効率化を図るため コード生成からドライテスト、デプロイまでのプロセスを改善するため Claude Sonnet 4.5 が API 課金ではなく使える点が魅力的だった 導入して得られた結果 パラメーターシートやアーキテクチャ図を基に Terraform コードの自動生成が可能に AI によるコードレビューが人間のレビューを補完し、エラー検出が向上 validate、plan、apply の各段階でのエラー検出と修正が効率化 事例4: 仕様駆動開発の手引き（古川様の発表） 抱えていた課題 「仕様が主、実装が従」という本来あるべき開発の構図が逆転しがち 仕様書の陳腐化や実装との乖離の発生 vibe coding は業務で活用するには曖昧すぎる 導入した理由・きっかけ 自分で設計して自分で実装するケースが多く、生成 AI 導入の恩恵が大きいと考えたため 他の生成 AI ツールと Amazon Q Developer の比較検討を自分自身でやってみたかったため 仕様駆動開発が開発手法として確立しつつあり、業務に適用してみたかったため 導入して得られた結果 ルール制定 → README記述 → 設計書作成 → TODOリスト作成 → 実装という流れで社内用の小規模なツールを効率的に開発できた AI が設計図やタスク分解などを自動化し、人間はレビューと意図合わせに集中できる 仕様駆動開発の考え方を取り入れることで、開発の最初に充実したドキュメントを作れるようになった 事例5: Amazon Q Developer 活用事例紹介（鈴木様の発表） 抱えていた課題 製品機能設計に向けて AI エージェント技術の理解と実験環境構築が必要だった AgentCore や CloudFormation など、大量コードの読解や IaC 化の負荷が高い 新しい技術領域で情報が少なく、定義ミスやドキュメント解釈間違いが発生しやすい 導入した理由・きっかけ Amazon Bedrock AgentCore を使った機能検討のため、AI エージェントの仕組み理解と環境構築を効率化したかった GitHub の AgentCore サンプルを活用する中で、Q を使えばコード理解・修正・IaC 化まで一気に進められると判断 大量コードの理解、React アプリ実装など AI に向いている作業が多かったため Q 活用を決断 導入して得られた結果 AgentCore + Knowledge MCP + CloudFormation による再利用可能なAIエージェント実験環境を構築 React チャットアプリやブラウザ動作確認まで実装〜テストの大部分を Q が自動化 Rules 整備やレビューを通じて、Q を“正解を出す AI ”ではなく“協働する相棒”として運用する体制を確立 Try & Error の混乱を Git コミットや TODO 管理で整理し、AI と協働できる実践的な開発フローを確立 定量的な成果 3か月間の業務適用検証期間において、Amazon Q Developerを利用した取組は以下の定量的な成果を達成しました。 コード生成・開発効率 開発スピード 3 倍向上: 通常 2 週間かかる PoC 開発が 3 日で完了 工数削減 67%: 10 人日から 3 人日へ削減、コストは約 1/3 に コード生成数: 検証期間中、57 名の参加者が累計で数千行のコード生成を実施 レビュー・品質向上 レビュー時間短縮: AIによるコードレビュー支援により、人間のレビュー工数を削減しつつエラー検出精度が向上 エラー早期発見: validate、plan、apply の各段階でのエラー検出が効率化され、手戻りコストを削減 継続利用 参加率 95% : 募集定員 60 名に対し 57 名が参加し継続して利用 アクティブ利用: 検証期間中、定期的なオフィスアワーやTeams「生成AI交流広場」での活発な情報交換を実施 イベント参加: キックオフイベントに 250 名、ハンズオンに 100 名以上が参加 定性的なフィードバック（利用者の声） 検証期間中のアンケートやCITS Day 2025での発表から、以下のような利用者の声が得られました。 「SNS API や Streamlit など、未経験の技術を短期間で習得できた。新規技術獲得へのハードルが大幅に下がった」 「PoC の進め方が大きく変わることを実感。人は課題抽出やロジック検討、結果確認に注力できるようになった」 「生成 AI と開発の構造を組み合わせることで、柔軟性・速さと品質・一貫性の両立が可能になった」 「仕様書を起点に、AI エージェントに任せながら効率的に開発できる。仕様駆動開発が現実的な選択肢になった」 「パラメーターシートやアーキテクチャ図を基に Terraform コードの自動生成が可能になり、インフラ構築業務が大幅に効率化された」 検証の総括 キヤノンITS 様は、生成 AI ビジネス推進室を中心に Amazon Q Developer の展開を推進し、3 か月間の業務適用検証を通じて組織的な AI 駆動開発の定着を実現しました。エグゼクティブスポンサーの支援と予算負担の工夫により現場の参加障壁を排除し、専用 Teams チャネルでのコミュニティ形成、定期的なオフィスアワー、実践的なハンズオンセッションという段階的な学習支援を提供しました。 検証期間中、57 名の技術者が実務で Amazon Q Developer を活用し、開発スピード 3 倍向上、工数 67 %削減という具体的な定量効果を達成。Amazon Q Developer 自身で作成したダッシュボードにより利用状況を可視化し、CITS Day 2025 での表彰制度により 5 つの優秀事例を全社で共有しました。 成功の鍵は、生成AIビジネス推進室の設立による組織的な推進体制、単発イベントで終わらせない年間ロードマップに基づく継続的な支援施策、そして実ビジネスでの活用という 3 つの要素にあります。キックオフから始まり、ハンズオン、中間イベント、表彰へと続く一連の取り組みにより、SNS バズ検知システムなど実際の PoC 案件での成果を創出し、新規技術習得の加速、PoC プロセスの変革、インフラ構築の効率化など、多様な領域での効果を実証しました。 キヤノンITS 様からAmazon Web Services Japanへの期待 今回の取り組みを通じて、Amazon Q Developer を開発現場の生産性向上に有効活用できることが実感できました。PoC からインフラ構築、既存システムの改善まで、多様な領域で活用の可能性が広がっています。 今後は、今回の検証で得られた知見をもとに、社内での活用パターンの整理やナレッジの共有を進め、より多くのプロジェクトで生成AIを活かせる環境づくりを進めていきます。また、Amazon Web Services Japan 様と連携しながら、新機能の検証や他サービスとの組み合わせなど、さらなる活用領域の拡大にも取り組んでいく予定です。 生成AI が IT ライフサイクル全般の在り方を大きく変えつつある中、私たちは、現場の開発体験を改善するとともに、社会やお客様へ更なる価値提供に向けて積極的に活用していくための取り組みを継続して進めていきます。 執筆者 キヤノンITソリューションズ株式会社 生成AIビジネス推進室 石堂 きよみ Amazon Web Services Japan ハイテク&ヘルスケア事業本部 アカウントマネージャー Amazon Web Services Japan ソリューションアーキテクト 木村 直登(Naoto Kimura)