はじめに 　レバレジーズ株式会社 テクノロジー戦略室 SRE チームの中野です。レバレジーズでは「SRE 化を通して、Developer Experience の改善、事業の拡大への対応、お客様に信頼されるサービスの提供を実現する」をミッションとして、サービス改善の文化的土俵の構築や開発生産性の向上を進めています。 　過去記事 (= Terraform による IaC の標準化を通じた、全社規模の開発体験の向上への取り組み ) では、社内標準となる IaC ツールの選定と、IaC 化の作業負荷の軽減を狙ったライブラリ・テンプレートの作成についてご紹介しました。 　今回はその続編として、これらの製品を Template as a Service として提供する中で見えてきたユーザペインと、AI Agent Skills によるペインの解消・製品強化の取り組み、そして今後の展望についてご紹介します。 　現在、SRE・Platform Engineering の取り組みで Template as a Service を社内展開しているが、製品を使いこなすまでのハードルが高く製品普及が思う様に進まない。この様なペインを抱える開発組織の参考になれば幸いです。 　なお、本記事で紹介する取り組みは、2026年4月開催の AWS Container Platform Engineering Meetup のパネルディスカッションでご紹介した話の詳細版です。当日話し切れなかった部分を本記事でお伝え出来ればと思います。 背景 　現在は、下表の Template as a Service を提供中です。初めにインフラ作業の効率化・省力化を狙って Terraform Modules、GitHub Composite Actions、GitHub Repository Template を作成し、学習による知識強化も狙って Terraform Handson というハンズオン形式の学習教材も作成しました。これらの製品により、IaC 化推進の環境を整えてきました。 提供製品 概要 Terraform Modules (AWS Provider 向け) ELB・ECS・RDS 等の単体リソースに対応する Component Modules、CloudFront・WAF 等の複数のリソース群を組み合わせた Catalog Modules の2種類がある GitHub Composite Actions Terraform 用の CI/CD、アプリ用の CI/CD 等の共通処理をパッケージ化したものが多い GitHub Repository Template (Terraform 向け) Terraform Backend の環境構築、CI/CD 用の IAM リソース設定、Slack 関連設定、アラート用のリソース設定等の手順・設定を同梱しており、IaC 導入時の初期作業を低工数で済ませられる Terraform Handson Terraform 用のハンズオン教材であり、Terraform の基礎から発展までを短期間で学習出来る 　一方、製品利用が進むにつれて、製品の改善点が見え始めました。以下は、ヒアリングやフィードバックを通して得られた代表的なペインです。 　当初は Embedded SRE 等の手慣れたエンジニアを対象に製品のファンを増やすことを目的としていましたが、今後のユーザ拡大を考えると、ペインを解消して製品の使い勝手を強化することを優先すべきだと考えました。 Terraform Modules モジュールの使い方や必要な変数の組み合わせが、仕様や利用例だけでは判断しにくい モジュール毎の使い分け基準は書かれているが、どのモジュールを使うかの判断が難しい GitHub Repository Template 初期整備の手順資料・作業工程が多く、作業全体の流れや進捗を把握しにくい 設定項目が多く、必須なものが分からないため、何を埋めるべきか判断しにくい AI の活用方針の検討 　社内では AI Agent の利用が広がっており、これを活用すれば作成コストを抑えながらペインを十分に解消可能だと考えました。実際、社内要件・命名規則やクラウドのベストプラクティスに沿って提供製品が作り込まれており、AI による代行が十分に可能でした。そこで、AI Agent Skills の作成を決めました。 　次に、先述のペインを起点に Skill で解決可能なことを整理して製品案を考え出し、次の基準をもとに作成優先度を決めました。その結果、下表の「Terraform コード生成 Skill」及び「GitHub Repository Template の初期整備 Skill」を高優先で作成すべきだと判断し、これらの作成から始めることにしました。 作成優先度の決定基準 ペインの程度や発生頻度 負荷・コスト等の削減効果 直近の利用予定、社内要望 作成候補の優先度一覧 作成候補 優先度 対象者 判断理由 コード生成 Skill 高 ユーザ Terraform コードの実装・修正が他の作業よりも高頻度である 初期整備 Skill (GitHub Repository Template 用) 高 ユーザ IaC 関連の初期作業のみの利用だが、自動化の効果が大きい スタイルガイド Skill、 製品仕様ガイド Skill 中 ユーザ 運用フェーズでの実装・仕様把握の負荷を継続的に下げられる モジュール開発 Skill、 コードレビュー Skill 中 メンテナー 開発・レビューの作業負荷を下げ、省力化・体制分散に繋がる Terraform Ops Skill、 コスト試算 Skill、 インフラ構成図 Skill 低 ユーザ、メンテナー 発生頻度・現在の負荷が比較的小さく、将来の開発対象とする AI Agent Skills の作成 　ここでは、高優先で作成した「Terraform コード生成 Skill」及び「GitHub Repository Template の初期整備 Skill」の概要・ワークフローや設計・工夫についてご紹介します。 　前者は Terraform Modules の「使い方・使い分けの判断が難しい」というペインに、後者は GitHub Repository Template の「初期整備の工程が多く進捗や設定値の判断が難しい」というペインに、それぞれ対応するものです。 Terraform コード生成 Skill (AWS / Google Cloud) 概要・ワークフロー 　Terraform コード生成 Skill とは、ユーザへのヒアリングに基づいて Terraform コードを生成する Skill です。AWS・Google Cloud の Provider 毎に Remote Skill (= terraform-codegen-aws / terraform-codegen-google ) として提供しており、EC2・RDS 等の単体サービスから、静的サイト (CloudFront・WAF・S3) や Web システム (ALB・ECS・RDS 等) といったインフラ構成のコードまで生成出来ます。処理フローは次の通りです。 No ステップ 概要 1 ユーザへのヒアリング サービス名・環境名・リージョン等の要件情報を聞き出し、必要なインフラリソースを洗い出した上でリソース設定の追加確認を行う 2 Terraform コードの生成 ヒアリング結果に基づき、必要なインフラリソースに関する Terraform コードを生成し、実行場所にコードを書き込む 3 Terraform コードの検証 生成したコードに対して terraform fmt/validate のコマンドを実行し、エラーが無くなるまで検証・修正のサイクルを繰り返す 4 完了報告と追加確認 設定の判断理由を含めて作業結果を報告し、コードの追加・修正の要望を確認する 　ヒアリングでは、推測可能な情報は聞かないことを原則として、要件等の推測が難しい情報だけを AI Agent がユーザへ確認します。また、どのリソース・モジュールを用いるか、変数設定をどう組み合わせるか等のコード生成に必要な判断を AI Agent が担います。この様な設計により、ユーザの確認負荷を抑えています。 　コード生成では、下記の優先順位で生成方法を選択します。terraform-codegen-aws は、該当する社内向け Terraform Modules があれば必ず利用し、無い場合はモジュールを用いずに生成します。一方、terraform-codegen-google は、社内向け Terraform Modules を提供していないため、モジュールを用いない生成を基本としています。 　なお、Public Modules の利用については、両方の Skill に共通で、バージョン更新時の追従負荷を考慮して要望があった場合のみ利用可能なオプションとしています。 terraform-codegen-aws の生成方法の優先度 (a) 社内向け Terraform Modules を利用する (b) モジュールを用いずにコードを生成する (c) Public Modules を利用する (要望時のみ) terraform-codegen-google の生成方法の優先度 (a) モジュールを用いずにコードを生成する (b) Public Modules を利用する (要望時のみ) 　この優先順位には、社内標準の資産を AI のコード生成経路そのものに組み込む狙いがあります。ユーザが社内モジュールの存在や使い分けを知らなくても、生成されるコードは自然と社内標準に沿ったものになり、個々のエンジニアの習熟度に依存していた社内標準への準拠を仕組みの側で担保出来ます。 設計・管理のポイント 　各々の Terraform コード生成 Skill に共通する設計・方針の枠組み (= SSoT の管理方針、検証の実施方針等) を定めており、これに基づいて各 Skill が作り込まれています。 　まず、Skill では SSoT の管理方針を明確に決めています。モジュールの仕様・バージョン等は外部情報として Skill 内で持たずに CLI コマンドで取得し、ヒアリングの進め方・コーディング規約・組織固有の情報等は Skill 内で参照情報やテンプレートとして管理します。この方針で外部情報の更新への Skill の追従が最小限になり、Skill の管理・運用のコストを抑えられました。 　また、参照情報を取得出来なかった場合に AI が推測で値を埋めることを禁止しており、ユーザへの確認に基づくコード修正かプレースホルダの残置に必ず倒す設計としています。 　コード検証では、 terraform plan の実行を意図的にスコープ外としています。コード生成の段階では静的なコード検証さえパスすれば問題無く、クラウド上での検証までスコープを広げると検証が複雑になり、副作用のリスクが生まれると考えたからです。そのため、 terraform fmt/validate の実行によるコード検証として設計しています。 動作検証時の挙動改善 　動作検証で、簡単なコード生成でも一律に時間・トークンを大きく消費するという挙動面の課題が判明しました。実測したところ、主な原因は「参照情報を何度も取得しに行っていること」及び「簡単なコード生成でも複雑な手順で処理していること」にあり、次の改善を行いました。 　これらを「修正、検証、品質チェック」の処理サイクルで適用したところ、ユーザの入力・待機等を除いた処理自体の所要時間やトークン消費を、改善前よりも 30% 〜 40% 程度削減出来ました。 参照情報の取得方法の見直し 参照の度に発生していた取得処理を、最初に一括で取得・保存する方式に変更した 参照情報の取得の繰り返しを防ぎつつ、必要な情報を適切・十分に参照可能にした 生成内容に応じた処理の使い分け コード生成の進め方に応じた処理群のパターン分けを、生成モードとは別に設けた 生成処理の複雑さに応じて処理パターンを当てはめ、適切な処理をさせる様にした 機械的なチェックへの移行 文章ルールに基づくチェックを、スクリプトを用いたチェック処理に置き換え、照合のやり取りを削減した チェックルールは機械可読な一覧表で管理し、ルールの追加・変更が表の編集だけで済む様にした AI モデルの能力や実行毎のばらつきに品質が左右されにくくなり、安定化に繋がった GitHub Repository Template の初期整備 Skill 概要・ワークフロー 　初期整備 Skill は、Terraform 向け GitHub Repository Template から作成した GitHub Repository の初期整備を AI Agent が代行する Skill です。現在提供中の4種類の Repository Template に Local Skill (= terraform-repo-init ) として導入しており、Repository の作成後に Skill を発動するだけで初期整備を簡単に進められます。 　この Skill により、人間が対応すべき箇所は「ヒアリングへの応答、残りの限られた手動作業の消化」だけに絞られ、その他の作業を AI Agent が代行してくれます。手順書に沿った作業で起きがちなミスも、スクリプトを用いた機械的なチェックにより極力発生しない様にしています。処理フローは次の通りです。 No ステップ 概要 1 ユーザへのヒアリング 構成・仕組みの要否 (= 開発環境、定期チェック、通知設定) や設定値等の初期整備で決めるべき情報を冒頭で一括して確認する 2 クラウド認証の確認・実施 実行環境やクラウド認証の状態を確認し、未認証だった場合に認証コマンドを実行する 3 初期整備の自動実行 雛形の削除、テンプレート情報の置換、Terraform Backend の環境構築、GitHub Repository Secrets の登録、CI/CD の有効化、作業のセルフチェック等の自動化可能な作業を実行し、GitHub PR の作成まで進める 4 残作業リストの出力 実行するだけで済む様な文面・スクリプト等を用意した上で、残りの手動作業に関するチェックリストを出力して終了する 設計・管理のポイント 　Repository の初期整備には、自動化が難しい作業 (= 外部への依頼・承認等) や、統制の観点から人間が担うべき作業 (= 秘匿情報の設定、PR のマージ判断等) が含まれます。そこでまず、AI Agent とユーザの作業分担を明確に定めました。 　具体的には、環境検証・テンプレート置換・Backend 構築・Secrets 登録・PR 作成までを AI Agent が実行し、それ以外の作業は意図的に人間側に残しています。この線引きが、AI による作業代行を安心して組織展開するための前提だと考えています。 　この分担を前提に、自動化可能な作業を先に進めて手動作業を最後にまとめる形へ作業全体の流れ・手順資料を再整理し、初期整備の自動実行とユーザへの残作業の提示を AI Agent に行わせる Skill を作りました。どの工程でも開始時に完了状態・前提条件・スキップ条件等を確認してから進行させる様になっており、途中で中断した場合でも安全に再開出来ます。 　なお、コード生成 Skill と同様に SSoT の管理方針も定めています。手順・コマンド等の具体値は Repository Template の資料・スクリプトを SSoT として参照し、Skill 自体は判断ロジックと工程の順序のみを持つ構成としています。 Skills の管理・配布 　Terraform コード生成 Skill は、特定の GitHub Repository に依存しない用途のため、Skill 専用の GitHub Repository で Remote Skill として管理しています。一方、GitHub Repository Template 用の初期整備 Skill は、Template 内の手順資料・スクリプトと一体で動く用途のため、Template 内で Local Skill として管理しています。 　配布についても、管理方式に合わせて分けています。Terraform コード生成 Skill は GitHub CLI コマンド ( gh skill install ) で利用可能にしており、GitHub Copilot・Claude Code 等の AI Agent 間の仕様差異を GitHub CLI が吸収してくれるため、統一的な手順で配布出来ます。初期整備 Skill は、Template から Repository を作成した時点でそのまま利用可能なため、配布作業が不要です。 今後の展望 　今後は、作成候補の優先度一覧で中優先以下とした Skill を順次作成し、ユーザ向けのインフラ作業のペイン解消だけでなく、製品メンテナーの開発・改善における作業負荷の軽減にも AI を活用していく予定です。これにより、Template as a Service の提供サイクルを現在の開発体制でも十分に回せる様に強化したいと考えています。 　過去記事では「Template as a Service を作り、IaC 化を推進する」をご紹介しました。今回は「AI Agent が Template as a Service を使いこなし、エンジニアの代わりに作業する」への進化をご紹介しました。Template as a Service × AI の組み合わせで、AI を前提としたゴールデンパスを引き続き提供し、利用の障壁の無いプラットフォームへと育てていきます。 最後に 　レバレジーズでは、全社の SRE・プラットフォームエンジニアリングの推進に向けて、開発生産性の向上に一緒に取り組んでいただけるエンジニアを募集しています。 　SRE の文化・体制に興味があったり創っていきたい方や、プラットフォームエンジニアリングの実践による開発生産性の向上に興味がある方は、是非ともご応募をお待ちしております。

こんにちは。ファインディ株式会社でプリンシパルエンジニアをしている戸田です。 2026年8月5日(水)に、Findy AI Meetup in Fukuoka #7を福岡で開催しました。当日参加くださったみなさま、ありがとうございました！ findy-inc.connpass.com 今回のテーマは「AI開発の"今まで"と"これから"を語り尽くそう」です。 皆さまの熱いご支援のお陰で、Findy AI Meetup in Fukuokaは今回で1周年を迎えました。節目となる今回は、AI開発のこれまでを振り返りつつ、これからを見据える内容の登壇が揃いました。 この記事では、ファインディメンバーによる2つの登壇を振り返ります。 Findy AI Meetup in Fukuokaについて え？フロントエンドエンジニアのワイがインフラも！？ 「開発は一人です」から始まった新規サービス 武器は社内に揃っていた 2つの誤算 変わったこと、変わらなかったこと VibeCodingからAgenticWorkflowへ 速くなったのは開発工程ではなくコード生成 レベル1「速く作る」— VibeCodingと現場の課題 レベル2「正しく作る」— 協働から委任へ ターミナルへの回帰 — 開発環境そのものが変わった 順番を間違えない — 基本が先、AI活用は後 まとめ Findy AI Meetup in Fukuokaについて Findy AI Meetupは、ファインディのエンジニアが主催する技術系オフラインイベントです。 生成AIやAIエージェントの活用を通じた開発生産性の向上をテーマに、社内での実践事例の紹介やエンジニア同士の交流を目的としています。 福岡での開催は今回で7回目、そして1周年となりました。この1年でAI開発の景色は大きく変わりましたが、回を重ねるごとに参加者同士の交流も深まり、福岡のエンジニアコミュニティとして根付いてきたことを実感しています。 え？フロントエンドエンジニアのワイがインフラも！？ まずは、フロントエンドテックリードの新福による登壇です。フロントエンドエンジニアが生成AIとともに専門外の領域へ越境した実体験をお話ししました。 speakerdeck.com 「開発は一人です」から始まった新規サービス きっかけは、新しいサービスの立ち上げでした。ファインディでは生成AI時代のプロダクトが次々に生まれており、立ち上げ期のプロダクトは少数精鋭・スピード重視で職種の枠に囚われないフルサイクル志向となることが多いです。 そんな中で、新規サービス開発を任されることになりました。ただし、人員の確保が難しいため開発は一人です。これまでなら、良いアイデアがあっても専任のメンバーが足りなければ諦めるしかありませんでした。 しかし、生成AI時代ならそれも可能かもしれません。そう考えて、フロントエンドはもちろん、バックエンド、そして完全に初見のインフラ（AWS/Terraform）まで、全部を一人で担当することにしました。 領域 内容 フロントエンド 本来の専門領域 バックエンド Honoを採用、テーブル設計などは専門メンバーによるレビュー インフラ（AWS/Terraform） IAM、VPC、ECS、RDSなど、SREチームによるレビュー 武器は社内に揃っていた 挑戦を支えたのは、弊社SREチームが整備していた社内資産でした。Terraformやバックエンド側APIのスターターキット、社内標準の構成を再利用可能な形にまとめたAWS汎用モジュール、そして環境構築を手助けするエージェントスキルです。 これらの社内資産を活用し、社内の作法に沿ったやり方でAIが書き、人間がレビューして判断するという流れで開発を進めました。 結果、アプリケーション（フロントエンド+バックエンド）に約1ヶ月、完全に専門外のインフラに約1ヶ月、合計約2ヶ月で一人で作り上げることができました。 2つの誤算 一方で、やってみて見えてきた誤算もありました。 1つ目の誤算は「時間」です。 当初は生成AIによる開発期間の短縮を見込んでいましたが、実際は専門メンバーやSREチームによるレビュー待ち、そして試行錯誤のたびに発生するTerraformの反映待ちが作業時間の相当部分を占めました。フィードバックを待つ必要があるものはAIでの高速化が難しく、AIが圧縮したのはあくまで「人間が考える時間」だったのです。 2つ目の誤算は「理解」です。 自分で書いていたときは、仕組みや依存関係を把握しなければそもそも書けないため、両者は常にセットで、疑う機会すらありませんでした。ところが生成AIに書かせると、内容を把握せずとも書けてしまいます。そのまま進めると、なぜ動くか、あるいは動かないかがわからず、インフラでこれは致命的となり得ます。だからこそ、浮いたはずの時間の一部を使って、生成AIの出力を読んで理解する時間を確保する必要がありました。まさに「思考は外注できるが、理解は外注できない」を実感した経験となりました。 変わったこと、変わらなかったこと 生成AI時代では、着手するまでの意思決定コストが下がりました。これまで人員確保がネックになっていた部分も、生成AIが実装や意思決定のコストを下げたことで、諦めなくても良くなったのです。 逆に変わらなかったのは、最終的な責任を持つのは人間だということです。生成AIの出力を判断するためには、結局のところ実装者自身が仕組みを理解し、専門知識を身につけなくてはいけません。 生成AIの発展により、越境しやすい環境になりましたが、専門知識の価値は変わりません。「理解は外注できない」という事実をしっかりと頭に留め、基礎を大事にするというのがこの挑戦から得られたものでした。 VibeCodingからAgenticWorkflowへ 続いて戸田からは、ファインディがこの1年で歩んできたAI活用の変遷を「VibeCodingからAgenticWorkflowへ」と題してお話ししました。 speakerdeck.com 速くなったのは開発工程ではなくコード生成 出発点は、AIを導入して見えてきた現実です。AIが高速化したのは「コードを書く」工程だけで、レビューや検証といった「正しいか」の確認に時間がかかり、開発フロー全体のスループットは横ばいのままでした。これは体感ではなく、可視化した数値が示した事実です。 速くコードを書けても、理解せずに生成されたコードは質が落ち、レビューでの指摘が増え、結局速さの恩恵が消えてしまう。この連鎖を断ち切るために、ファインディでは「正しい作り方と手順」をハーネス化する開発フロー改革に取り組み、AI活用レベルを3段階に分けて段階的に進めてきました。 レベル テーマ 内容 レベル1 速く作る コード生成の自動化 レベル2 正しく作る モノ作り全体の再設計 レベル3 必要なものを作る 他領域への越境 先ほどの新福の登壇は、まさにこのレベル3「他領域への越境」を体現した実例です。ここからは、そこへ至るまでのレベル1とレベル2の道のりを紹介します。 レベル1「速く作る」— VibeCodingと現場の課題 レベル1は、VibeCodingでコードを生成し、Pull requestを作成してレビュー依頼を投げるところまでをAIで自動化するフェーズです。 ただしこのフェーズでは、現場で次のような課題が起きていました。活用レベルの個人差が大きい、AI出力の合否判断ができないまま理解せずにレビュー依頼を出してしまう、Pull requestの質が低下してリードクラスのレビュー負担が増える、そしてAI主導になり人間側の理解が追いつかない「AIに使われている」状態です。 この課題に対して、まずAIが参照するドキュメントやルールを整えるガードレール整備を行いました。READMEやプロジェクトドキュメントで前提や運用ルールを記述し、AGENT.mdやrulesでコード規約・命名規則・テスト方針をAIに参照させ、よくある作業はカスタムコマンドとして規格化する。ガードレールがあって初めて、AIは「使い物になるコード」を出してくれます。 レベル2「正しく作る」— 協働から委任へ レベル2では、正しい方法と手順を用意して、AgenticWorkflowに委任します。 このフェーズの課題は、要件を実現する手順がAIフレンドリーではないことでした。タスクの粒度や手順を誰も決めておらず、生成AIへ何を渡せば精度よく動くかが属人化している。つまり、明確で簡潔なステップ構造、AIに渡す「設計図」が必要だったのです。 そこで、AIが処理しやすい単位へのタスク分解、構造化された設計図を親子Issueで表現するIssue作成、そしてAIと人間でレビュー領域を分割するコードレビューの再定義に取り組みました。人間はレビューで「作り方と実現方法が合っているか」を検証し、設計図にフィードバックする。タスク分解の品質が、そのままアウトプットの品質を決めます。 このレベル1からレベル2への移行は、AIとの関係性の変化でもあります。登壇では「協働」して書くVibeCodingと、「委任」して任せるAgenticWorkflowの違いを次のように整理しました。 観点 AIとの協働（レベル1 VibeCoding） AIへの委任（レベル2 AgenticWorkflow） 関係性 隣で並走するパートナー タスクを任せる実行者 人間の役割 ハンドルを握る運転手 行き先を決める指揮者 AIの役割 助手席のナビゲーター 自走する実行エージェント 任せる粒度 1行〜1関数 タスク/PR/フロー全体 AgenticWorkflowとは、人間がゴールと制約を与え、AIエージェントが計画・実行・自己検証までを自律的に進める開発スタイルです。ゴール指向、計画と分解、ツール使用、自己検証ループという4つの自律性を備えており、人間の仕事は成果物に対するレビューへと移っていきます。 ターミナルへの回帰 — 開発環境そのものが変わった AI委任の並列性は、開発環境そのものも変えました。2026年からファインディではメインツールがIDEからターミナルへ移行しています。 1ウインドウで1タスクずつ進めるスタイルから、複数ウインドウ・ペインで同時にAIへ委任するスタイルへ。IDEの役割は「すべての開発作業を行う場所」から「広域に渡るコードリーディングで理解を深めるとき」に使うものへと変化しました。AIに並列で任せる前提に合わせて、開発環境が「並列委任しやすいもの」へ変わってきているのです。 順番を間違えない — 基本が先、AI活用は後 最後に強調したのは、順番を間違えないことです。土台が弱いと、ガードレールもAIも成果を出せません。 統一規約・型定義・テストコードといったコード品質をまず充実させ、Pull requestの粒度やレビュー文化といった開発文化を育てる。その上でガードレール・ハーネスを整備し、最後にAI SkillやPluginを横展開して組織全体でAI活用を加速させる。基本が固まってからAI活用を載せる、この順番が重要です。 AI時代の本丸は「速く作る」ではなく、「正しく作る」「必要なものを作る」への段階的な越境です。人間の役割はコードの読み書きから、何をどう作るかの判断へと上流に移っていきます。それでも、やるべきことはAI以前から変わりません。基本の徹底こそがAI活用の大前提なのです。 まとめ 今回のテーマは「AI × これまでと、これから」でした。 2つの登壇に共通していたのは、AIによって変わったことと変わらないことの整理です。変わったのは、AIに任せられる範囲です。職種の壁を越えることが現実的な選択肢になり、協働から委任へと関係性も進化しました。変わらないのは、理解と責任が人間に残ることです。AIにどれだけ委任しても、出力を判断する専門知識と基本の土台がなければ、AIは成果を出せません。 この1年でVibeCodingという言葉が当たり前になり、いまはAgenticWorkflowへの移行が始まっています。これからも変化は続きますが、基本を固め、理解を手放さず、段階的に任せる範囲を広げていく。この姿勢は変わらないと考えています。 なお、登壇でも紹介したファインディの開発知見は、ドキュメントサイト「Findy Library」で公開しています。開発の基本からVibeCodingやAgenticWorkflowの実践まで、今回の登壇のベースになっている知見をまとめていますので、ぜひ活用してみてください。 lib.findy.co.jp そして早くも次回開催が決定しました！2026年11月12日(木)に開催予定です。次回は「AI × 並列開発 AIに委任して変わりゆく開発手法」と題しまして、AIへの委任で変わっていく開発手法について語り合う会にしたいと思っています。今回の登壇でも触れた「並列委任」をさらに深掘りするテーマです。ぜひご参加ください。 findy-inc.connpass.com ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

みなさん、こんにちは。AWS ソリューションアーキテクトの三厨です。 8 月 4 日（火）に、半導体業界向けのイベント EDA on the Cloud 2026 – Tokyo を AWS 麻布台オフィスで開催します。EDA ワークロードのクラウド活用に加えて、Cadence AI Super Agent による設計・検証フローや、Anthropic Japan による「半導体のためのフロンティア AI」など、AI 関連のセッションが揃っています。ソニーセミコンダクタソリューションズ株式会社様による「ソニー半導体 EDA 基盤の Cloud Journey」の講演も予定されています。定員 100 名、参加費無料です。ご興味のある方はお早めにご登録ください。 それでは、7 月 20 日週の生成 AI with AWS 界隈のニュースを見ていきましょう。 さまざまなニュース 寄稿：弁護士ドットコムにおける AWS DevOps Agent の活用事例 – インシデント対応の自動化と属人化の解消 弁護士ドットコム株式会社 様は、法律相談ポータル「弁護士ドットコム」や電子契約サービス「クラウドサイン」を運営する企業です。サービスの拡大とともにアラートが増える一方、調査は一部の熟練エンジニアに依存していました。これを解決するために、Datadog Monitor のアラートを起点に AWS DevOps Agent が自動で調査を始める構成を組み、Skills と Jira の MCP で起票までつなげました。その結果、あるレイテンシ障害では、従来 30 分ほどかかっていた根本原因の特定を約 10 分で終えています。今後は、繰り返すアラートへの予防策を提案する Proactive Incident Prevention の活用を本格化させるそうです。 ブログ記事「9 社合同 AI-DLC Unicorn Gym：AI と作った 2 日間で見えた、「書く」から「決める」への転換」を公開 9 社 11 チーム・約 90 名が自社の実課題を持ち込み、 Kiro と Claude Code で AI 駆動開発ライフサイクル（AI-DLC）を 2 日間走り切った合同ワークショップのレポートです。「Kiro は 1 ヶ月と見積もった。私たちは 2 日で 80% 終わった」という声の一方で、生成物の正しさを判断し続ける負荷が人間に集中したという指摘も率直に載っています。満足度は 4.7/5.0、体感の工数削減率は平均 74.0%。クロージングの一言「Don’t write code, Write construct.（コードを書くな、構造を作れ）」に、2 日間の学びが凝縮されています。 ブログ記事「22社51名の参加者が2時間で業務アプリを自作し発表 ！Claude ・Kiro実践ワークショップの記録」を公開 22 社 51 名が 2 時間のハンズオンで自分の業務課題を題材にアプリを作り、その場で発表したワークショップの記録です。日本曹達株式会社様の広報課の方が、過去の問い合わせ回答を検索できる農業化学品 FAQ アプリを作られた例が取り上げられています。「このアプリを作ってください」というお題をあえて出さない設計が、満足度 100% につながったようです。社内で同じような会を企画される方のヒントになりそうです。 ブログ記事「【開催報告】AWS Summit Japan 2026 – AWS for Telcom 展示ブース」を公開 通信業界向けの 7 ブースをまとめた開催報告です。株式会社NTTドコモ様は AWS 上の 5G コアを国内初のハイブリッドクラウド構成で商用化し、 Amazon Bedrock AgentCore 上のエージェントと GitOps による構築自動化でリードタイムを 80% 短縮されました。100 万台超の機器を扱うネットワーク保守 AI エージェントでは、障害復旧時間を 50% 以上縮めています。KDDI株式会社様は基地局制御基盤の内製開発に AI-DLC を導入して開発期間を 70% 削減、ソフトバンク株式会社様は Amazon Neptune でネットワークトポロジーを時系列管理する様子を展示されました。 ブログ記事「スマートグラス × 音声 AI エージェントで実現する店舗業務のハンズフリー支援」を公開 「あの商品どこ？」に新人スタッフが即答できない、という店舗の困りごとをスマートグラスと音声 AI エージェントで解く展示の解説記事です。音声をそのまま受けて音声で返す Amazon Nova 2 Sonic がモデル内で Tool Use まで済ませ、Amazon Bedrock AgentCore Gateway に登録した 5 つの Lambda を MCP 経由で呼び出します。自店舗に在庫がなければ近隣店舗や EC まで自律的に探しにいく挙動が読みどころです。手が塞がる現場での情報アクセスという課題は、製造や物流にもそのまま当てはまります。 ブログ記事「【開催報告】AWS Summit Japan 2026 — 物流異常を Amazon Quick が自動解決：配送在庫の異常検知〜問合せまで一気通貫」を公開 複数システムにデータが散らばり、日次レポートの目視確認で異常発見が数日遅れる。そんな物流現場の課題に Amazon Quick で応える展示の紹介です。Quick Automate が業務システムを横断監視して Microsoft Teams へ通知し、Quick Sight で滞留状況を確認、Chat Agent が基幹データと過去報告書をまたいで原因を掘り、Connectors で業者へのメール送信まで完結します。半日かかっていた原因追及が数分になる流れを、4 ステップで追えます。 ブログ記事「AWS Japan Summit 2026 スマートマシンデモ ー自律診断とリアルタイム安全監視ー 展示報告」を公開 建設機械 20 台のフリート管理を題材に、同じデータへの 3 つの異常検知アプローチを並べて比べた展示報告です。人手による報告、 Amazon SageMaker AI の古典的な機械学習、そして Amazon Bedrock AgentCore と Strands Agents によるエージェント型。「異常スコアは出るが、なぜ起きたのか、何をすべきかは分からない」という機械学習の限界に対して、対処指示まで含むアラートを返せる差が具体例つきで示されます。機械を止める判断は人間に残す、という線引きの考え方も参考になります。 ブログ記事「AWS Summit Japan 2026 に見る Resilience at AWS」を公開 レジリエンス関連のセッション 4 本とブース展示 6 本のまとめです。生成 AI 視点では、AI 駆動カオスエンジニアリング、AWS DevOps Agent による「調査は AI、判断は人」のインシデント対応、Kiro と AWS Resilience Hub を組み合わせて、マルチリージョン化の提案レポートから CloudFormation テンプレートの改修まで生成するデモが目を引きます。ナレッジを整えたことで DevOps Agent の根本原因到達が 6 分 32 秒から 3 分 38 秒に縮んだ、という実測値も載っています。 ブログ記事「【開催報告】Neuron Community – 2026 Vol.1」を公開 AWS Trainium / Inferentia と AWS Neuron の知見を共有するコミュニティイベントの開催報告です。カラクリ株式会社様は、Amazon EKS 上の Neuron 分散学習プラットフォームと、NKI カーネル開発を自律的に進めるエージェントを発表されました。AWS 側からは、デバイス指定を変えるだけで PyTorch のコードを Trainium で動かせる Native PyTorch support（ベータ）や vLLM on Trainium、Neuron 2.31 の NKI 強化が共有されています。Project Rainier では 140 万個超の Trainium が稼働中とのことです。 ブログ記事「AI エージェントが変える AWS 運用の未来【AWS DevOps Agent & AWS サポート ランチタイムセミナー開催レポート】」を公開 「深夜にアラートが鳴っても調査する人手が足りない」というスタートアップの悩みに向けたランチタイムセミナーのレポートです。Amazon ECS の 500 エラーを題材にした AWS DevOps Agent のデモに加えて、一次調査はエージェント、判断が必要なところは AWS サポートの専門エンジニアへ、という組み合わせ方が解説されています。DevOps Agent からサポートチケットを直接起票できる点と、AWS Business Support+ や AWS Activate クレジットといったコスト面の選択肢も整理されています。 ブログ記事「今月の AWS オブザーバビリティ – 2026年6月」を公開 6 月に発表された Amazon CloudWatch と AI 駆動型オペレーションの新機能のまとめです。OpenTelemetry メトリクスと PromQL クエリの一般提供、Logs Insights への 23 コマンド追加、AWS DevOps Agent のカスタム SRE エージェントと MCP / A2A 対応などが並びます。Amazon EKS 上の AI/ML ワークロードを namespace やチーム単位で GPU コスト配賦するリファレンスアーキテクチャ、Claude Code のトークン消費量を追跡するパターンまでカバーしています。 ブログ記事「AWS Certified Machine Learning Engineer – Associate アップデート (MLA-C02) のお知らせ」を公開 AWS Certified Machine Learning Engineer – Associate が MLA-C02 に更新されます。ドメイン構成は変えずに、基盤モデルのファインチューニングや RAG アーキテクチャの実装、エージェンティック AI、 Amazon Bedrock のカバレッジ、責任ある AI の実践が加わります。ベータ版試験（英語のみ、170 分、85 問、75 USD）の予約は 9 月 1 日開始、現行 MLA-C01 の英語での最終受験日は 9 月 28 日です。日本語はベータ期間中も MLA-C01 で受験でき、全言語対応の標準版は 2027 年初頭の予定です。 ブログ記事「Claude Opus 5 が Kiro で利用可能になりました」を公開 （ changelog ） Kiro の IDE / CLI / Web すべてで Claude Opus 5 が使えるようになりました。時間のかかる作業に強くなり、並列で動かしたエージェントが互いの成果を上書きしてしまうケースが減っています。スタブやプレースホルダを残さずタスクを完走する点、コードレビューで誤検知を抑えつつ実バグを拾う点が Opus 4.8 からの差分です。あわせて、 Kiro で GPT-5.6 が利用可能に なった記事（前号で触れた英語版の日本語訳）も出ています。 サービスアップデート Claude Opus 5 が AWS で利用可能に Anthropic の Claude Opus 5 が AWS で利用可能になりました。数時間から夜通し動き続けるエージェント、コードベースを理解しながら戦略を組み替えるコーディング、長文ドキュメントの推論が強みです。ドキュメント中心の業務で最も伸びが大きいと説明されています。Amazon Bedrock 経由（ゼロデータ保持がデフォルト有効）と Claude Platform on AWS 経由（ゼロデータ保持はリクエストベース）の 2 つから選べます。 Amazon Bedrock AgentCore がトレースとログを単一ロググループにまとめた統合オブザーバビリティを提供 Amazon Bedrock AgentCore が、トレース・プロンプト・構造化ログ・標準出力をエージェントごとの単一の CloudWatch ロググループへ配信するようになりました。これまではトレースが共有の aws/spans、イベントログが別のロググループに分かれており、1 回の呼び出しをデバッグするために複数のロググループを探す必要がありました。エージェント単位で IAM ポリシーとカスタマー管理キーによる暗号化を適用できるようにもなっています。7 月 20 日以降に作ったエージェントはデフォルトで有効、既存分は環境変数と ADOT 0.17.1 以降への更新で移行できます。 Claude Sonnet 5 が AWS GovCloud (US) の Amazon Bedrock で利用可能に AWS GovCloud (US) の Amazon Bedrock でも Claude Sonnet 5 が使えるようになりました。Claude Opus 4.8 とあわせて、GovCloud (US-West / US-East) の bedrock-runtime と、GovCloud (US-West) の次世代推論エンジン bedrock-mantle の両エンドポイントから呼び出せます。 Amazon SageMaker AI 推論の GPU インスタンスが拡充、G7e が東京リージョンでも利用可能に NVIDIA RTX PRO 6000 Blackwell を最大 8 基積む G7e インスタンスが、Amazon SageMaker AI 推論のアジアパシフィック（東京 / ソウル）、欧州（ロンドン）に広がりました。合計最大 768 GB の GPU メモリで、FP8 なら最大 70B パラメータのモデルをマルチノードなしで載せられます。推論性能は G6e 比で最大 2.3 倍。国内のユーザーに大きめのモデルを低レイテンシーで届けたいときの選択肢になります。同じ週に G7 インスタンス （米国 3 リージョン、G6 比で最大 4.6 倍、7B〜30B 向け）と G6 の AWS GovCloud (US-East) 対応 も発表されています。 Amazon SageMaker Unified Studio が Amazon OpenSearch をサポート Amazon SageMaker Unified Studio が Amazon OpenSearch をデータソースとして扱えるようになりました。プロジェクトに接続を追加すると data explorer に OpenSearch のデータが並び、クエリエディタやノートブック、ビジュアル ETL ジョブから Amazon Redshift や Amazon S3 のデータと突き合わせられます。アプリケーションログとトランザクションデータを、ツールを行き来せずに見たいときに便利です。Unified Studio が使えるすべてのリージョンが対象です。 Kiro IDE 1.0.182 と CLI 2.14.0 が公開 Kiro IDE 1.0.182 では、ユーザーレベルのグローバル hooks と検索できるセッション履歴パネルが加わり、企業プロキシ環境での安定性が上がりました。応答が中断したときの自動復帰と、MCP ツールの動的な再読み込みにも対応しています。CLI 2.14.0 では、V2 のカスタムエージェント設定を V2 / V3 共通の形式へ移す /upgrade-agent コマンドが入りました。 Kiro が AWS GovCloud (US) で Opus 4.8 / Sonnet 5 とユーザーアクティビティモニタリングに対応 AWS GovCloud (US) の Kiro IDE / CLI で、Claude Opus 4.8（1M コンテキスト、クレジット倍率 2.2 倍）と Claude Sonnet 5（実験的サポート、同 1.3 倍）が使えるようになりました。あわせて管理者向けに、利用状況ダッシュボードと、クレジットやモデル利用の日次 CSV を自分の S3 バケットへ配信するレポート、任意のプロンプトログが提供されます。データは自社アカウントに残り、S3 のストレージ以外の追加料金はかかりません。 Amazon CloudWatch がコーディングエージェントインサイトを発表 Amazon CloudWatch に、AI コーディングエージェントの利用状況を可視化するコーディングエージェントインサイトが加わりました。Claude apps gateway for AWS と統合されているため、計装なしで Claude Code のテレメトリが集まります。Codex や GitHub Copilot も対象です。トークン支出の傾向を追ってアラートを設定できます。エージェントの導入率とコミットやプルリクエストの速度との相関、費用対効果の高いモデルの見極めにも使えます。中東（UAE / バーレーン）とイスラエル（テルアビブ）以外のすべての商用リージョンで使えます。 AWS Data Exports が Amazon Bedrock の標準化された製品メタデータを提供 AWS Data Exports が、Amazon Bedrock のコストにモデルプロバイダー、モデル名、料金単位、推論タイプ、オンデマンドやバッチといった機能区分を、標準化された属性として付けるようになりました。Bedrock のコストは統一の「Amazon Bedrock」製品ファミリー名にまとまります。CUR 2.0 のメタデータを解析する自作ロジックなしで支出を配賦できます。追加料金なしで、デフォルトで適用されます。 AWS が AI エージェント向けのオープンソースベンチマーク aws-bench を発表 AI エージェントが実際の AWS タスクをどれだけ正確に、どれだけ効率よく片づけられるかを測るオープンソースのベンチマーク aws-bench が、リサーチプレビューで公開されました。テストケースは調査・トラブルシューティング・インフラ作成の 3 領域。自然言語のクエリ、クラウドリソースの状態、正解を組にしてあるので、任意のエージェントやモデルを同じ基準で採点できます。エージェントの実行基盤を自作している方は、改善の物差しとして試してみてはいかがでしょうか。 Amazon Connect のエージェンティック音声が 50 以上の言語に対応、日本語もサポート Amazon Connect のエージェンティック音声が、日本語を含む 50 以上の言語と 100 を超える音声オプションに対応しました。不自然な間を埋める応答ペーシング、同時発話を避けるターンテイキングの改善、速度・音量・感情の制御も入っています。日本語で自然な音声セルフサービスを組みたいコンタクトセンターには、大きな一歩です。 AWS パートナーセントラルのエージェントが資金調達ガイダンスをすべてのプログラムに拡大 AWS パートナーセントラルのエージェントが、すべての資金調達プログラムに対応しました。今回の拡張で戦略的協業契約（SCA）と AWS Growth Initiative（AGI）が加わっています。資格要件や申請プロセスについては、公式ドキュメントに基づく回答が数秒で返ります。適格性の検証、提出書類の要件照合、必要項目が埋まった申請書ドラフトの作成もエージェントが行うため、手入力とチェック漏れを減らせます。 生成 AI を活用したビジネス課題の解決に取り組むお客様を支援する AWS ジャパン生成 AI 実用化推進プログラム は、通年で応募を受け付けています。戦略プランニング / モデルカスタマイズ / モデル活用の 3 コースから選べて、想定コストの半額を上限とした AWS クレジットの付与や技術支援も用意されていますので、ぜひご検討ください。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 三厨 航  (Wataru MIKURIYA) AWS Japan のソリューションアーキテクト (SA) として、ヘルスケア・ハイテク製造業のお客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援しています。クラウドガバナンスや IaC 分野に興味があり、最近はそれらの分野の生成 AI 応用にも興味があります。最近の趣味はカメラです。 週刊 AWS の新しいサムネイルを撮影したので、是非ご覧ください。 a