はじめに 開発本部でデリッシュキッチンアプリ課金ユーザー向けの開発を担当している hond です！ 2025年6月から社内勉強会の一つとして開催している「AIツールを活用した開発効率化勉強会」が開催から半年かつ現状の参加メンバーで一周したので、そもそもどのような勉強会だったのかやアンケートの結果からどのような成果が得られたのかについて振り返ろうと思います。 AIツールを活用した開発効率化勉強会 現在エブリーの開発部では、入社時に振り分けられる勉強会グループで開催する定期的な勉強会と勉強会のテーマに興味があるメンバーが集まって行う任意の勉強会があります。今回紹介する「AIツールを活用した開発効率化勉強会」は後者にあたり、AIに興味があるメンバー18人ほどが集まり開催しているものになります。 勉強会の目的 勉強会の目的は以下の3点として運営しました。 AIに関するインプット意欲を向上 AIツールをとりあえず試すマインドの向上 実務の中で活用していく意欲向上 2025年4月に 開発部とPdMにCursorが導入されました 。当時はCursor以外にもClaude CodeやClineなど多様な選択肢があり、AIツールは進化が早く個人でのキャッチアップには限界がありました。 そこで勉強会では、参加メンバーの多角的な視点でいろいろなツールや活用方法を吸収できる場にしたいと考えました。 具体的には、ハンズオン形式で実際に使ってみることや、他のメンバーから便利なユースケースを共有してもらうことで、活用の促進とユースケースの増加を狙いました。 また、新しいツールの導入には一定のハードルがあるため、「とりあえず試す」ことでそのハードルを緩和することも意識しました。 実施形式 実施形式は以下のように設計しました。 隔週1回で開催 発表者は参加者で順番に行う 事例紹介形式&ハンズオン形式 導入してみたけどうまくいかなかった例、うまく導入できていない例紹介タイムを設ける Cursorに限らずClaude CodeやRoo Code、ClineなどもOK 目的にある「とりあえず試す」を実現するため、勉強会ではなるべくハンズオン形式を採用するよう設計しました。 基礎的な内容よりも「〇〇をしたら△△になる」といった具体的なユースケースにフォーカスすることで、実務への応用をイメージしやすくしています。 また、うまくいった事例だけでなく、うまくいかなかった事例も積極的に共有してもらうようにしました。変化が激しく簡単に正解に辿りつけるフェーズではないと感じていたので失敗例を参加メンバーで考察することで、より深い理解に繋げることを狙っています。 Coding Agentにはそれぞれ良し悪しがあるため、ツールを絞らずそれぞれの長所や短所を学び、自分が使っているツールにどう活かせるか考えられる場にしました。 発表内容 半年間で行われた発表テーマは以下の通りです。 発表日 テーマ 6/16 MCP使い倒してコンテキストスイッチ最小限に 6/30 Cursor × iOS開発私はこうやってます 6/30 A/Bテストの実験設定をcursorに任せてみる 7/14 Claude Codeは言語化ムズイがいい感じという話 7/14 MCPサーバーを自作してみる 7/28 KiroでSpec駆動開発 7/28 Claude Codeのサブエージェント 8/25 CodeRabbitについて調べてみた 8/25 LLMで爆速論文検索 9/8 spec-kitを使ってみよう 9/8 コンテキストエンジニアリング 10/20 Amazon Bedrock AgentCoreでエージェント開発を加速させよう 11/17 いろいろあるよ！AWS MCP Servers 11/17 コンテキストエンジニアリングについて真面目に考える 12/1 Google Workspace Flows アルファ版 12/1 AIカンパニーをつくって遊んでみる 12/15 AWS Transform Custom Kiroやspec-kitをはじめとする開発体験を向上するツールを試す発表や、普段業務で使っているClaude CodeやCodeRabbitについての深掘りなど、幅広いジャンルの発表が行われました。 Amazon Bedrock AgentCoreを実際に参加者全員で作ってみるハンズオン形式の回もとても好評でした。 発表テーマを振り返ると、改めてAIが開発に与えるインパクトの大きさを感じます。同時に、いろいろなツールが出過ぎて手探りな期間だったなとも思います。 これだけのテーマを個人でキャッチアップするのは難しいので、勉強会という形で吸収できてよかったです。 アンケート結果 勉強会の振り返りとして、参加メンバーにアンケートを実施しました。14人から回答があり、以下の3項目については5段階評価で回答してもらいました。また、いくつか自由記述を設けて今後の改善に向けた意見を募りました。 5段階評価については下記の結果が得られました。 項目 1 2 3 4 5 総合満足度 0人 0人 3人 7人 4人 AIツール活用の参考になったか 0人 0人 3人 5人 6人 開発効率化の助けになったか 0人 1人 2人 9人 2人 全体的に高評価でしたが、特に「AIツール活用の参考になったか」に関してはNPS 21.5%という高い数字を出すことができました。 自由記述でのポジティブな意見としては、「自分ではキャッチアップしきれない部分について情報をインプットすることができた」や「色々なAIツールがある中でどのようなものがあるのかを知るとっかかりになったのが良かった」といった声が上がりました。どちらも勉強会を開催するにあたって目的にしていた部分が反映できたことが確認できる意見でした。 一方で、改善点として「回を重ねるごとに難易度が上がっていき、発表ネタを作るのが大変になっていた」という意見が複数見られました。確かに、勉強会を開始した当初と比較すると新しいツールや大きな開発体験の変化を伴うことは減ってきたのでテーマ的に一歩深掘りしたものが必要になっていました。あくまで、任意の勉強会なので負担にならないようある程度コントロールできるとよかったのではないかと思っています。 まとめ 他の勉強会と比較してデファクトスタンダードが出ていなかったりとても変化が激しい期間の勉強会の運営だったので、参加メンバーが満足いくものに設計できるか不安でしたが満足度もそれぞれ目的としていた指標に対しても高い評価が得られた結果となりよかったです。 ハンズオン形式に関しては発表者教材を準備しないといけないので負荷になっていたとは思いますが、聞いた内容を確実にアウトプットする機会や勉強会中にメンバー同士で議論できる場の提供になりプラスに働いたのではないかと思っています。 今後はより各チームのメンバーのユースケースの共有を活性化することで、よりお互いに刺激し合える勉強会を設計していきたいと思います。 社内勉強会の設計や運営の参考になったら幸いです！

こんにちは。Findy Tech Blog編集長の高橋（ @Taka-bow ）です。 2012年にサポート終了したVisual SourceSafeが、いまだに利用率2位。この調査結果に私はとても驚きました。 前回の記事 では、開発生産性を阻む「組織の3大課題」として、要件定義、会議、コミュニケーションの問題を取り上げました。今回は、それらと深く関わる技術環境の世代差と、AI時代における影響を考えます。 【調査概要】 調査対象： ソフトウェア開発（組み込み開発を含む）に直接関わるエンジニア、プロダクトマネージャー、プロジェクトマネージャー、エンジニアリングマネージャー、開発責任者など 調査方法： インターネット調査 調査期間： 2025年4月2日(水)～2025年5月21日(水) 調査主体： ファインディ株式会社 実査委託先： GMOリサーチ&AI株式会社 有効回答数： 798名（95%信頼区間±3.5%） 統計的検定力： 80%以上（中程度の効果量d=0.5を検出） 調査内容： 開発生産性に対する認識 開発生産性に関する指標の活用状況 開発生産性に関する取り組み 開発環境・プロセス評価 組織文化と生産性 ソースコード管理ツールの利用状況 意外と多かったVisual SourceSafe AI時代に広がるソースコード管理ツールの影響 AI開発支援ツールとGit連携 ツールの差がAI活用の差になる CI/CDパイプラインへの低い満足度 なぜ従来型ツールから移行しないのか 開発プロセスの認識の課題 まとめ お知らせ ソースコード管理ツールの利用状況 意外と多かったVisual SourceSafe 今回の調査で、ソースコード管理ツールの利用状況を調べてみたのですが、私はVisual SourceSafeをアンケート回答の選択肢に入れるかどうか、最後まで悩みました。さすがにもう使われていないだろうと思い込んでいたからです。 それは、大きな間違いでした。 ソースコード管理ツールの利用状況 順位 ツール名 利用率 回答者数 備考 1位 GitHub 30.5% 243名 Gitベース 2位 Visual SourceSafe 15.8% 126名 2012年サポート終了 3位 Subversion 13.7% 109名 集中型VCS 4位 Azure DevOps (Repos) 8.4% 67名 Gitベース 5位 GitLab 8.0% 64名 Gitベース 6位 CVS 3.6% 29名 2008年開発終了 7位 TFVC 2.4% 19名 従来型 8位 Bitbucket 1.8% 14名 Gitベース 9位 Gitea 1.6% 13名 Gitベース 9位 SourceForge 1.6% 13名 ホスティング 11位 Perforce (Helix Core) 1.3% 10名 大規模向け 12位 Mercurial 0.4% 3名 分散型VCS - その他 11.0% 88名 - （N=798、単一回答） GitHubが1位であることは予想通りでしたが、Visual SourceSafeが2位に入っていたのです。 Subversion（13.7%）、CVS（3.6%）を加えると、約3割の組織が従来型のバージョン管理システムを使用しています。 AI時代に広がるソースコード管理ツールの影響 AI開発支援ツールとGit連携 2023年以降、AI開発支援ツールが急速に普及しました。 GitHub Copilot、Cursor、Claude Code、Devin、Clineなど、いずれもGitベースのワークフローを前提に設計されています。そのため、従来型ツールの環境ではこれらのツールを十分に活用できません。 AIがコードベース全体を把握できず、提案の精度が下がる（リポジトリ連携機能） 変更履歴や差分を活用したコード生成ができない（diff/commit統合） コードレビューやタスク管理の自動化が使えない（PR自動作成、イシュー管理） DevinやClineなどAIエージェント系ツールは、コード補完にとどまらず、プルリクエスト作成、コードレビュー、イシュー管理まで自動化します。これらはGitHub/GitLabのAPIを前提としているため、旧来のバージョン管理では活用できません。 このツール環境の差は、どのような影響をもたらすのでしょうか。 ツールの差がAI活用の差になる GitHub社の調査によると、Copilot利用者は特定のタスク（HTTPサーバー実装）において、非利用者より 55%速く完了した と報告されています。日常業務すべてで同じ効果が出るとは限りませんが、無視できない差です。 Visual SourceSafe（15.8%）とSubversion（13.7%）を合わせると約3割の組織が、こうしたAI開発支援ツールを十分に活用できない環境にあります。このようなツール環境の違いが、将来の生産性格差につながっていく可能性があります。 つまり、AI活用の有無が開発速度に影響する可能性があります。 CI/CDパイプラインへの低い満足度 次のグラフは、満足度が50%を下回った項目を抜粋したものです。 開発基盤の満足度（全7項目が50%未満、ワースト順） 項目 満足度 CI/CDパイプライン 14.2% ドキュメンテーション 17.5% タスク管理システム 18.2% コードレビュープロセス 19.2% 開発環境整備 24.7% チーム内意思決定 34.1% チーム内コミュニケーション 37.1% （N=798） CI/CDパイプラインの満足度はわずか14.2%で、最も低い結果となりました。 この低さは、ソースコード管理ツールの選択と無関係ではないと思います。現在主流のCI/CDツールはGitベースのバージョン管理を前提としており、Visual SourceSafeやSubversionとシームレスに連携することが難しいからです。 なぜ従来型ツールから移行しないのか 従来型ツールを使い続ける組織には、それぞれの事情があると考えられます。 基幹システムや業務システムとの連携が従来型ツール前提で構築されている 過去の履歴データ、ワークフロー、ビルドスクリプト等の移行に膨大な工数がかかる 長年使い続けたツールに習熟したメンバーが多く、再教育コストが高い 「動いているものは触るな」という保守的な判断が優先される ウォーターフォール型ではリリース頻度が低く、Gitベースのワークフローの恩恵を感じにくい 大規模組織ほど、これらの要因が重なり移行が難しくなります。 とはいえ、全面移行にはリスクが伴います。履歴データの損失、一時的な生産性低下、デリバリー遅延、メンバーの抵抗などです。一方で、現状維持にも見えないコストがあります。セキュリティリスクの増大、新しい技術との統合困難、採用市場での不利など、これらは時間とともに大きくなっていきます。 具体的な移行のロードマップは、最終回（第8回）で取り上げます。 開発プロセスの認識の課題 ソースコード管理ツールの選択は、組織の開発プロセスに対する認識とも関連しています。調査からは、開発プロセスの認識にも課題が見えてきます。 開発フレームワークの認識状況 開発フレームワーク 回答率 回答者数 ウォーターフォール 36.8% 294名 よくわからない 18.2% 145名 ウォーターフォールとアジャイルのハイブリッド 13.2% 105名 【アジャイル開発】決まったフレームワークはない 13.2% 105名 【アジャイル開発】スクラム 6.8% 54名 【アジャイル開発】XPのプロセス 3.8% 30名 【アジャイル開発】大規模スクラム：LeSS 2.4% 19名 【アジャイル開発】大規模スクラム：SAFe 1.3% 10名 【アジャイル開発】大規模スクラム：Nexus 1.3% 10名 【アジャイル開発】大規模スクラム：Scrum@Scale 0.8% 6名 【アジャイル開発】大規模スクラム：その他 0.8% 6名 リーン 0.4% 3名 カンバン 0.3% 2名 その他 1.0% 8名 （N=798） なんと、約5人に1人（18.2%）が自分の組織がどんな開発フレームワークを使っているか「よくわからない」と回答しています。 開発フレームワークを十分に理解できていないということは、 なぜそのプロセスで開発しているのか どのような改善が可能なのか 自分の役割がプロセス全体のどこに位置するのか こうしたことが把握しづらくなります。 この問題は、第3回で取り上げた「不明確な要件」の問題とも関連しています。開発プロセスが明文化・共有されていない組織では、要件定義も曖昧になりがちだと思われます。 まとめ 798名の調査から見えてきたのは、日本の開発現場における技術環境の世代差です。Visual SourceSafeが15.8%、Subversionが13.7%と、約3割の組織が従来型ツールを使い続けています。CI/CDパイプラインの満足度は14.2%にとどまり、18.2%は自組織の開発手法を「よくわからない」と答えました。 AI時代において、このツール環境の差はさらに広がっていくでしょう。最新のAI開発支援ツールはGitベースのワークフローを前提としているからです。ただし、ツールを入れ替えるだけでは解決しません。技術基盤の刷新と組織文化の変革、両方が必要です。 次回は「 なぜDevExは日本で知られていないのか ── 認知度4.9%が語る未開拓領域 」をお届けします。 第1回、日本の開発現場の「リアル」を数字で見る ── 798名の声から浮かび上がる衝撃の実態 調査全体について 第2回、開発生産性への意外な好印象 ── アジャイル実践者59.6%が前向きな理由 開発手法による意識の違いの本質 第3回、開発生産性を阻む「組織の3大課題」 ── 要件定義、会議、コミュニケーションの問題 取り組みが失敗する本当の理由 第4回、AI時代の技術格差 ── Visual SourceSafe 15.8%が示す変革への壁 なぜ従来型ツールから移行できないのか 第5回、なぜDevExは日本で知られていないのか ── 認知度4.9%が語る未開拓領域 日本の開発者が本当に求めているもの 第6回、なぜDORA指標は日本で普及しないのか ── 認知度4.3%の背景と打開策 数値化への懸念と向き合う方法 第7回、生産性向上を阻む組織の壁 ── 37.8%が未着手の深刻な理由 経営層を説得する具体的な方法 第8回、既存システムから次世代への変革 ── 日本の開発現場が立つ分岐点 品質文化を強みに変える改革のロードマップ お知らせ 「 Development Productivity Conference 2026 」が2026年7月22日〜23日に開催されます。継続的デリバリー（CD）の先駆者であり『継続的デリバリーのソフトウェア工学』著者のDave Farley氏が初来日。日本からはテスト駆動開発の第一人者・和田卓人氏が登壇します。 prtimes.jp ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。 興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

本ブログは 2025 年 12 月 8 日に公開された AWS Blog “ IAM Policy Autopilot: An open-source tool that brings IAM policy expertise to builders and AI coding assistants ” を翻訳したものです。 本日 (2025 年 12 月 8 日)、AWS は IAM Policy Autopilot を発表しました。これは、AI コーディングアシスタントがベースラインとなる AWS Identity and Access Management (IAM) の IAM ポリシーを迅速に作成できるよう支援するオープンソースの静的解析ツールです。作成されたポリシーは、アプリケーションの成長に合わせて継続的にレビュー・改善できます。IAM Policy Autopilot はコマンドラインツールおよび Model Context Protocol (MCP) サーバーとして利用可能です。アプリケーションコードをローカルで解析し、アプリケーションにアタッチする IAM ロールのアクセスを制御するアイデンティティベースのポリシーを作成します。IAM Policy Autopilot を導入することで、ビルダーはアプリケーションコードの作成に集中でき、 Amazon Web Services (AWS) での開発を加速し、IAM ポリシーの作成やアクセス問題のトラブルシューティングにかかる時間を節約できます。 AWS で開発するビルダーは、開発を加速してビジネスにより早く価値を届けたいと考えており、そのために Kiro、Claude Code、Cursor、Cline などの AI コーディングアシスタントをますます活用しています。IAM 権限に関して、ビルダーには 3 つの課題があります。1 つ目は、ビルダーは権限の理解、IAM ポリシーの作成、権限関連のエラーのトラブルシューティングに時間を取られ、アプリケーション開発に集中しづらいことです。2 つ目は、AI コーディングアシスタントはアプリケーションコードの生成には優れていますが、IAM の細かなニュアンスには苦労しており、複雑なクロスサービス依存関係の権限要件を捉えた信頼性の高いポリシーを生成するためのツールを必要としていることです。3 つ目は、ビルダーと AI アシスタントの両方が、AWS ドキュメントを手動で確認することなく、最新の IAM 要件と統合アプローチを把握し続ける必要があることです。理想的には、IAM の専門知識を常に最新に保つ単一のツールを通じて実現できることが望ましいです。 IAM Policy Autopilot は、これらの課題に 3 つの方法で対処します。まず、アプリケーションの決定論的コード解析を実行し、コードベース内の実際の AWS SDK 呼び出しに基づいて必要なアイデンティティベース の IAM ポリシーを生成します。これにより、初期のポリシー作成プロセスが高速化され、トラブルシューティング時間が短縮されます。次に、IAM Policy Autopilot は MCP を通じて AI コーディングアシスタントに正確で信頼性の高い IAM ポリシーを提供し、ポリシーエラーにつながることが多い AI のハルシネーションを防ぎ、生成されたポリシーが構文的に正しく有効であることを検証します。3 つ目に、IAM Policy Autopilot は定期的に更新され、新しい AWS サービス、権限、サービス間連携のパターンに対応します。そのため、ビルダーも AI アシスタントも、ドキュメントを手動で調べることなく最新の IAM 要件にアクセスできます。 本ブログでは IAM Policy Autopilot を使って開発中にコードを解析し、アイデンティティベースの IAM ポリシーを生成する流れを紹介します。IAM Policy Autopilot が AI コーディングアシスタントとシームレスに統合してデプロイ時に必要なベースラインポリシーを作成する方法と、ビルダーがコマンドラインインターフェイス (CLI) ツールを通じて IAM Policy Autopilot を直接使用する方法も説明します。また、IAM Policy Autopilot を開発ワークフローに組み込むためのベストプラクティスと考慮事項についてもガイダンスを提供します。IAM Policy Autopilot のセットアップは、GitHub リポジトリにアクセスして行えます。 IAM Policy Autopilot の仕組み IAM Policy Autopilot は、アプリケーションコードを解析し、アプリケーション内の AWS SDK 呼び出しに基づいてアイデンティティベースの IAM ポリシーを生成します。テスト中に権限がまだ不足している場合、IAM Policy Autopilot はこれらのエラーを検出し、解消するために必要なポリシーを追加します。IAM Policy Autopilot は、Python、Go、TypeScript の 3 つの言語で記述されたアプリケーションをサポートしています。 ポリシーの作成 IAM Policy Autopilot のコア機能は、一貫性のある信頼性の高い結果でアイデンティティベースの IAM ポリシーを生成する決定論的コード解析です。SDK から IAM へのマッピングに加えて、IAM Policy Autopilot は AWS サービス間の複雑な依存関係を理解します。 s3.putObject() を呼び出す場合、IAM Policy Autopilot は Amazon Simple Storage Service (Amazon S3) の権限 ( s3:PutObject ) だけでなく、暗号化シナリオで必要になる可能性のある AWS Key Management Service (AWS KMS) の権限 ( kms:GenerateDataKey ) も含めます。IAM Policy Autopilot はクロスサービス依存関係と一般的な使用パターンを理解し、この初期パスで PutObject API に関連するこれらの権限を意図的に追加するため、暗号化設定に関係なく、最初のデプロイからアプリケーションが正しく機能します。 Access Denied のトラブルシューティング 権限が作成された後、テスト中に Access Denied エラーが発生した場合、IAM Policy Autopilot はこれらのエラーを検出し、即座にトラブルシューティングを提供します。有効にすると、AI コーディングアシスタントは IAM Policy Autopilot を呼び出して拒否を分析し、対象を絞った IAM ポリシーの修正を提案します。分析と提案された変更をレビューして承認すると、IAM Policy Autopilot が権限を更新します。 MCP と CLI のサポート IAM Policy Autopilot は、さまざまな開発ワークフローに適合するように 2 つのモードで動作します。MCP サーバーとして、 Kiro 、 Amazon Q Developer 、Cursor、Cline、Claude Code などの MCP 互換コーディングアシスタントと統合します。また、IAM Policy Autopilot をスタンドアロンの CLI ツールとして使用して、ポリシーを直接生成したり、不足している権限を修正したりすることもできます。どちらのアプローチでも同じポリシー作成とトラブルシューティング機能が提供されるため、ワークフローに最適な統合方法を選択できます。 IAM Policy Autopilot 使用のウォークスルー このセクションでは、実践的な例を通じて IAM Policy Autopilot の MCP サーバー機能を紹介します。AWS KMS のカスタマーマネージドキーを使用したサーバーサイド暗号化で Amazon S3 にドキュメントを保存するファイルアップロードアプリケーションを作成します。このブログでは Cline を使用しますが、IAM Policy Autopilot は MCP 互換のコーディングアシスタントで動作します。 前提条件とセットアップ IAM Policy Autopilot は uv または pip を使用してインストールできます。最も簡単な方法は、 uvx iam-policy-autopilot を実行して uv でインストールし、MCP クライアント設定ファイルで MCP サーバーを以下のように設定することです。 pip を使用して IAM Policy Autopilot をインストールする場合、MCP 設定は異なることに注意してください。 { "mcpServers": { "iam-policy-autopilot": { "command": "uvx", "args": ["iam-policy-autopilot", "mcp-server"], "env": { "AWS_PROFILE": "your-profile-name", "AWS_REGION": "us-east-1" } "disabled": false, "autoApprove": [] } } } 安全なファイルアップロード Lambda 関数の作成 このセクションでは、アプリケーションをゼロから作成する手順を説明します。開発者、Cline、IAM Policy Autopilot 間のやり取りを紹介し、Cline へのガイダンスの提供方法と、Cline がバックグラウンドで IAM Policy Autopilot を呼び出して IAM ポリシーを生成し、アプリケーションをデプロイする流れを紹介します。 訳注: 以下のやり取りでは、「ユーザー:」は開発者が AI コーディングアシスタントに入力するプロンプトを、「Cline:」は AI アシスタントからの応答を示しています。 1. ビルダーが要件を説明する ユーザー: S3 にファイルをアップロードする Lambda 関数を作成したいです。ファイルは AWS KMS のカスタマーマネージドキーで暗号化する必要があります。構築を手伝ってもらえますか? 2. Cline がソリューションの計画を開始する Cline: 安全なファイルアップロード Lambda 関数の作成をお手伝いします。以下のように分解してみましょう。 ファイルアップロードを処理する Lambda 関数を作成する AWS KMS のカスタマーマネージドキーで暗号化を使用した S3 統合をセットアップする 必要な IAM 権限を作成する AWS CDK を使用してインフラストラクチャを構築する まず Lambda 関数のコードを書くことから始めましょう。 3. Cline が AWS Lambda 関数のコードを作成する Cline は、パーティション、AWS リージョン、AWS アカウント ID など、デプロイに必要な認証情報の入力も求めます。 次に Cline は uploadHandler.js ファイルを作成します。 const { S3Client, PutObjectCommand } = require('@aws-sdk/client-s3'); const s3Client = new S3Client({ region: 'us-west-2' }); exports.handler = async (event) => { const { fileName, fileContent } = JSON.parse(event.body); const putObjectParams = { Bucket: process.env.BUCKET_NAME, Key: fileName, Body: fileContent, ServerSideEncryption: 'aws:kms', SSEKMSKeyId: process.env.KMS_KEY_ID }; try { await s3Client.send(new PutObjectCommand(putObjectParams)); return { statusCode: 200, body: JSON.stringify({ message: 'File uploaded successfully' }) }; } catch (error) { return { statusCode: 500, body: JSON.stringify({ error: error.message }) }; } }; 4. Cline が IAM ポリシーの作成が必要だと判断し、IAM Policy Autopilot を検出する Cline: 次に、この Lambda 関数に適切な権限を持つ IAM ロールを作成する必要があります。IAM ポリシーの作成に役立つツールが利用可能かどうか確認してみましょう。 Cline は IAM Policy Autopilot MCP サーバーにポリシー作成機能があることを検出し、それを呼び出します。 Request Type: CallToolRequest Method: CallToolRequestMethod Params: Name: "generate_application_policies" Arguments: account: "123456789012" partition: "aws" region: "us-west-2" source_files: [ "/Users/user/workspace/uploadHandler.js" ] Extensions: Extensions 5. IAM Policy Autopilot がコードを解析してポリシーを生成する IAM Policy Autopilot はコードをスキャンし、アプリケーションコード内の PutObjectCommand を識別します。これは Amazon S3 API コールとして認識されます。AWS のお客様の一般的な使用パターンに基づいて、IAM Policy Autopilot は暗号化権限と CloudWatch ログ権限も提案します。 IAM Policy Autopilot は、暗号化シナリオで必要になる可能性のある AWS KMS 権限を含む、Amazon S3 PutObject に必要な権限を含むアイデンティティベースの IAM ポリシーを生成します。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:PutObject" ], "Resource": "arn:aws:s3:::*/*" }, { "Effect": "Allow", "Action": [ "kms:Encrypt", "kms:GenerateDataKey" ], "Resource": "arn:aws:kms:us-west-2:123456789012:key/*" }, { "Effect": "Allow", "Action": [ "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents" ], "Resource": "arn:aws:logs:us-west-2:123456789012:*" } ] } 6. Cline が完全な CloudFormation インフラストラクチャを作成する Cline: 完璧です! IAM Policy Autopilot が Lambda 関数に必要な包括的な権限を生成しました。S3 PutObject 権限、暗号化シナリオに対応する KMS 権限、関数実行用の CloudWatch Logs 権限が含まれています。次に完全な CloudFormation テンプレートを作成します。 Cline は IAM Policy Autopilot が提供した権限を使用して AWS CloudFormation テンプレートを生成します。 AWSTemplateFormatVersion: "2010-09-09" Resources: UploadEncryptionKey: Type: AWS::KMS::Key Properties: KeyPolicy: Statement: Effect: Allow Principal: AWS: !Sub "arn:aws:iam::123456789012:root" Action: "kms:*" Resource: "*" SecureUploadBucket: Type: AWS::S3::Bucket UploadLambdaRole: Type: AWS::IAM::Role Properties: AssumeRolePolicyDocument: Version: "2012-10-17" Statement: Effect: Allow Principal: Service: lambda.amazonaws.com Action: sts:AssumeRole Policies: - PolicyName: UploadPolicy PolicyDocument: Version: "2012-10-17" Statement: - Effect: Allow Action: - s3:PutObject Resource: !Sub "${SecureUploadBucket}/*" - Effect: Allow Action: - kms:Encrypt - kms:GenerateDataKey Resource: !GetAtt UploadEncryptionKey.Arn - Effect: Allow Action: - logs:CreateLogGroup - logs:CreateLogStream - logs:PutLogEvents Resource: "arn:aws:logs:*:*:*" UploadHandler: Type: AWS::Lambda::Function Properties: Runtime: nodejs18.x Handler: uploadHandler.handler Code: ZipFile: | // Lambda function code would be deployed separately Role: !GetAtt UploadLambdaRole.Arn Environment: Variables: BUCKET_NAME: !Ref SecureUploadBucket KMS_KEY_ID: !Ref UploadEncryptionKey この例は、IAM Policy Autopilot が開発ワークフローにシームレスに統合され、呼び出し時にコーディングアシスタントに最新かつ正確な IAM ポリシーを提供し、ユーザーの作業負担を軽減する様子を示しています。 今回のウォークスルーでは、IAM Policy Autopilot に解析用の単一ファイルを渡していますが、静的コード解析を実行して IAM ポリシーを作成する際には複数のファイルを取り込むことができます。 CLI の直接使用: シンプルなポリシー作成 CLI を使えば、AI コーディングアシスタントなしでも同じ解析機能を直接利用できます。 1. 既存のコードから IAM ポリシーを生成する この例では、同じ uploadHandler.js ファイルがあり、デプロイ用のアイデンティティベースの IAM ポリシーを生成したいとします。 $ iam-policy-autopilot generate-policy --region us-west-2 --account 123456789012 --pretty Users/user/workspace/uploadHandler.js 2. IAM Policy Autopilot がコードを解析してポリシーを出力する { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:PutObject" ], "Resource": "arn:aws:s3:::*/*" }, { "Effect": "Allow", "Action": [ "kms:Encrypt", "kms:GenerateDataKey" ], "Resource": "arn:aws:kms:us-west-2:123456789012:key/*" }, { "Effect": "Allow", "Action": [ "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents" ], "Resource": "arn:aws:logs:us-west-2:123456789012:*" } ] } 3. ビルダーが生成された IAM ポリシーを使用する このポリシーを CloudFormation テンプレート、 AWS Cloud Development Kit (AWS CDK) スタック、または Terraform 設定に直接コピーできます。 この CLI アプローチは、MCP サーバーと同じコード解析とクロスサービス権限検出を提供しますが、コマンドラインワークフローや自動化されたデプロイパイプラインに適しています。 ベストプラクティスと考慮事項 開発ワークフローで IAM Policy Autopilot を使用する際は、以下のプラクティスに従うことで、セキュリティのベストプラクティスを維持しながらメリットを最大化できます。 IAM Policy Autopilot で生成されたポリシーから始めて改善する IAM Policy Autopilot は、最小権限よりも機能性を優先したポリシーを生成し、最初のデプロイからアプリケーションが正常に動作するよう支援します。これらのポリシーは、アプリケーションが成熟するにつれて改善できる出発点となります。デプロイ前に、生成されたポリシーがセキュリティ要件に合致しているかレビューしてください。 IAM Policy Autopilot の解析範囲を理解する IAM Policy Autopilot は、コード内の直接的な AWS SDK 呼び出しの識別に優れており、ほとんどの開発シナリオに対応した IAM ポリシーを提供します。ただし、いくつかの制限があることを覚えておいてください。例えば、コードが s3.getObject ( bucketName ) を呼び出し、 bucketName がランタイムで決定される場合、IAM Policy Autopilot は現在どのバケットにアクセスされるかを予測しません。AWS SDK をラップするサードパーティライブラリを使用するアプリケーションでは、IAM Policy Autopilot が生成した解析を手動のポリシーレビューで補完する必要がある場合があります。現在、IAM Policy Autopilot は IAM ロールとユーザーのアイデンティティベースのポリシーに焦点を当てており、S3 バケットポリシーや KMS キーポリシーなどのリソースベースポリシーは作成しません。 既存の IAM ワークフローと統合する IAM Policy Autopilot は、包括的な IAM 戦略の一部として最も効果を発揮します。IAM Policy Autopilot を使用して機能的なポリシーを迅速に生成し、継続的な改善には他の AWS ツールを活用してください。例えば、 AWS IAM Access Analyzer は、時間の経過とともに未使用の権限を特定するのに役立ちます。この組み合わせにより、迅速なデプロイから最小権限の最適化までのワークフローが実現します。 IAM Policy Autopilot とコーディングアシスタントの境界を理解する IAM Policy Autopilot は、コードの決定論的解析に基づいて特定のアクションを含むポリシーを生成します。MCP サーバー統合を使用する場合、AI コーディングアシスタントはこのポリシーを受け取り、Infrastructure as Code (IaC) テンプレートを作成する際に変更を加える場合があります。例えば、アシスタントがコードの追加コンテキストに基づいて、特定のリソース Amazon Resource Name (ARN) を追加したり、KMS キー ID を含めたりすることがあります。これらの変更は、IAM Policy Autopilot が提供する静的解析からではなく、コーディングアシスタントがより広いコードコンテキストを解釈した結果です。デプロイ前に、コーディングアシスタントが生成したコンテンツがセキュリティ要件を満たしているか必ずレビューしてください。 適切な統合アプローチを選択する 開発中の会話でシームレスにポリシーを作成するために AI コーディングアシスタントと連携する場合は、MCP サーバー統合を使用してください。CLI ツールは、バッチ処理や直接的なコマンドライン操作を好む場合に適しています。どちらのアプローチも同じ解析機能を提供するため、ご自身の開発ワークフローに合わせて選択してください。 まとめ IAM Policy Autopilot は、IAM ポリシー管理を開発上の課題から、既存のワークフロー内でシームレスに機能する自動化された機能へと変革します。IAM Policy Autopilot の決定論的コード解析とポリシー作成機能を活用することで、ビルダーは AWS で正常に実行するために必要な権限があることを確信しながら、アプリケーションの作成に集中できます。 MCP サーバー統合を通じて AI コーディングアシスタントと連携する場合でも、CLI を直接使用する場合でも、IAM Policy Autopilot は同じ解析機能を提供します。このツールは、AWS KMS 暗号化を伴う S3 操作などの一般的なクロスサービス依存関係を識別し、構文的に正しいポリシーを生成し、AWS が提供する拡大するサービスカタログに対応して最新の状態を維持するため、ビルダーと AI アシスタントの両方の負担を軽減します。 IAM Policy Autopilot を使えば、ビルダーが IAM の専門家になる必要はなく、わかりにくい権限エラーに悩まされることもありません。AWS 開発がより身近で効率的になります。その結果、デプロイサイクルが短縮され、権限関連の不具合が減少し、アクセス問題のデバッグではなくビジネス価値の創出により多くの時間を費やせるようになります。 開発ワークフローにおける IAM ポリシー作成の手間を減らしませんか？IAM Policy Autopilot は追加費用なしで今すぐ利用可能です。 GitHub リポジトリ からダウンロードして IAM Policy Autopilot を始め、自動化されたポリシー作成が AWS 開発をどのように加速できるかを体験してください。IAM Policy Autopilot の機能とカバレッジを拡大し続ける中で、みなさまからのフィードバックとコントリビュートをお待ちしています。 Diana Yin Diana は AWS IAM Access Analyzer のシニアプロダクトマネージャーです。顧客インサイト、製品戦略、テクノロジーの交差点で問題を解決することに注力しています。仕事以外では、水彩画で自然の風景を描いたり、ウォーターアクティビティを楽しんでいます。University of Michigan で MBA を、Harvard University で教育学修士号を取得しています。 Luke Kennedy Luke は AWS Identity and Access Management (IAM) のプリンシパルソフトウェア開発エンジニアです。Rose-Hulman Institute of Technology でコンピュータサイエンスとソフトウェアエンジニアリングの学位を取得後、2013 年に IAM 組織に加わりました。AWS 以外では、猫と過ごしたり、ホームラボやネットワークを過度に複雑にしたり、パンプキン味のものを追求したりすることを楽しんでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。