AI Agent による実装のベストプラクティス - AI Coding Agent の効果証明と組織展開

2025/5開催「AI Agent 開発の"0→1" - AWS の実証事例に学ぶ、企画から組織展開までのメソッド」登壇資料
(2025/3公開の「AIコーディングエージェント勉強会」を短縮して新しいネタを少し足した程度ですのでご容赦ください)

Transcript

1. AI Agent による実装のベストプラクティス AI Coding Agent の効果証明と組織展開 @nasuvit_z
2. 2 AIコーディングエージェントとは
3. 3 AIコーディングエージェントとは AIがコードの自動生成、補完、デバッグ、ドキュメント作成などを支援するツール 手作業でコードを書く手間を削減し、生産性やコード品質の向上を図ることが可能 AIによって、わずか2年で、コーディング体験が劇的に変わっている 手作業で 全てのコードを書く AIが部分的に コードを補完する AIが全自動で 全てのコードを書く 2023年まで 2024年まで 2025年から 従来のIDE GitHub Copilot GitLab Duo Amazon Q Developer (旧名称: CodeWhisperer) Cline、Roo Code Cursor、Claude Code GitHub Copilot Agent Amazon Q Developer CLI
4. 4 ClineをAmazon Bedrockと組み合わせて使用する
5. 5 Cline
6. 6 Clineとは • 誰でも無償で、VSCodeの拡張機能としてインストールして利用可 • 推論の料金のみクラウド利用料として発生 • 現在利用中のAWS (Amazon Bedrock) と接続すれば、調達作業が不要 • コーディングに関連する様々な思考プロセスやタスクを自動化 • コードを考えて、書き、直すという一連のプロセスを自動化 • ターミナルでのコマンド実行も一連のプロセスに含めて自動化 • 動作確認や調査のためのブラウザ操作も自動化 • プロジェクト固有のルールや作法に基づいた作業が可能 (.clinerules)
7. 7 様々なツールがあるが、ClineとAmazon Bedrockをなぜ使う? • 正直、どのツールでも構わない • 選んでいる時間が無駄と思えるほど、出来ることは類似している • VSCode拡張のダウンロード数を見ると、Clineの利用規模は非常に大きい • ナレッジも大量かつ頻繁に飛び交っている • 先人の知恵を参考にしやすい • ClineとAmazon Bedrockの組み合わせは利用のハードルが低い • 多くの企業では、既にAWSの利用開始や支払いの業務プロセスが確立さ れているケースが多いと推察 • 社内で利用開始までが最も早かったのがこの組み合わせ
8. 8 実行の構成 プラグイン として導入 アクセスキーか セッショントークンで 接続 推論にかかる 料金が発生
9. 9 アプリケーションの開発方法 チャットで 指示を入力
10. 10 アプリケーションの開発方法 手作業で1文字も コードを書いていないのに アプリケーションが完成
11. 11 今、皆さんが思っているであろうことの言語化 • デプロイまで自動でやってくれそう • リファクタリングを自動でやってくれそう • パフォーマンス改善もできそう • 依存関係の調査をしなくても自動でやってくれそう • パッケージング作業も自動でやってくれそう • インフラが完全に自動で構築できそう • OSやソフトウェアのインストールコマンド、シェルスクリプト、 設定ファイルも全自動で作れそう • 実機からドキュメントやパラメータシートを逆起こしできそう • フレームワークやライブラリが気にならなくなりそう • ペアプロの相手が人間ではなくなりそう
12. 12 今までと何が変わるのか 作業のやり方の変化 • 自然言語プロンプトで指示し、AIが即時にコードを提案 • デバッグ、リファクタリング、ドキュメント作成も自動化 エンジニアの役割の変化 • 「コードを書く」作業から「AIに意図を正確に伝える」作業へ • その上で、AIが出力したコードの検証や最適化(手直し)が重要に • ネットで言われる「ドライバーの交代」はこれらをわかりやすく説明したもの • プロンプトの設計力と言語化力の向上がより重要に • 要件定義やアーキテクチャ設計の重要性がより高まる
13. 13 MCP Server Clineに、リソース（データ、ツール、サービス）へのアクセス手段を与えて 何かのドメインに特化した回答を得る、または外部サービスを利用するための機能 (実際の使用に基づく意訳です) 出典: https://modelcontextprotocol.io/introduction • 外部サービスからAPIを介して情 報を取得し、コーディングに活用 する (AWS Documentation MCP Serverが活用の好例) • Clineと組み合わせて使用する • Clineでは、VSCodeのプラグイン をインストールするような操作で 利用を開始可能 • 外部サービスの通信時、認証情報 が必要となる場合あり
14. 14 プロジェクト固有のルールや作法を守らせる機能 様々なルールや作法を予め文書化しておき、その指示に従った成果物を生成可能 例: Clineの場合は「.clinerules」に指示を文書化しておく 出典: https://github.com/henryalps/OpenManus/blob/main/.clinerules
15. 15 過去の会話や作業履歴を保存し、次に活かす機能 記憶するファイル名 内容 productContext.md プロジェクトの目的、解決する問題、 期待される挙動 activeContext.md 現在作業中の内容、最近の変更点、 次のステップ（最重要） systemPatterns.md システムの構成、技術的判断、設計 パターン techContext.md 使用技術、開発環境、技術的制約 progress.md 完成済みの機能、残作業、進捗状況 タスクの状況や結果を文書化して保存し、会話(タスク)を跨いで活用することが可能 例: Clineの場合は、Custom Instructions (任意の指示を書く場所) に、Memory bank の機能を使う (構築する) ための指示をプロンプトで書くことによって使用可能 プロンプトで 記憶を指示
16. 16 プロンプトキャッシュ機能 (対応するモデルのみ) 繰り返し同じプロンプトを送信するケースで、コストを削減することが可能 プロンプトキャッシュOFF プロンプトキャッシュON 過去の指示履歴は キャッシュヒット/ 指示あたりのコストを 大幅に削減 ※これはあくまで例
17. 17 検証している Cline×Amazon Bedrock の効果的な使い方
18. 18 指示は具体的に書く方が良い HTMLとJavaScriptを使って、画面上に「パスワード生成」ボタンを表示し、クリックす るとランダムかつ強力なパスワード（大文字・小文字・数字・記号を含む）を10個生成し て、画面上のリストに表示するWebアプリを作ってください。 パスワードの長さは12文字程度とし、ページ遷移なしで動作するシンプルなUIにしてくだ さい。生成されたパスワードは見やすいように整列して表示してください。 HTMLをベースに、画面上でボタンを押すと、ランダムかつ強力なパスワードを 10個生成して表示するアプリケーションを開発したいです。 指示は曖昧でも、作業は進む (最終的に物ができないことはない) が、 初めからこう書けると、イメージ通りの成果物が素早くできる可能性が高まる やり直しが多くなると、前述のようにコストが高くなる
19. 19 初めは小さく作り、継ぎ足していくのが良い • 詳細化はしても良いが、範囲は広げてはいけない (むずかしい) • 最後にテスト工程があるとは言え、人間は普段、細かい粒度でコードを書いて はローカルで実行し、動作確認することを繰り返して、コードを仕上げていく • 一方でClineなどは、指示に従い、一瞬でアプリケーション全体を開発してし まうため、人間は初めから出来上がった物の全体を確認することになる • これらの新旧の体験の間には、大きなギャップがある • 一度の指示で全体を作ろうとすると、うまくいかなかった時にそのコード全体 を破棄することになり、破棄したコードに費やしたコストが全て無駄になる • 少しずつ作ってはコミットして保存し、万が一の時に戻せるようにする
20. 20 少しずつ機能を継ぎ足していく例 (ロールバックを容易にする) HTMLとJavaScriptを使って、画面上に「パスワード生成」ボタンを表示し、クリックす るとランダムかつ強力なパスワード（大文字・小文字・数字・記号を含む）を10個生成し て、画面上のリストに表示するWebアプリを作ってください。 パスワードの長さは12文字程度とし、ページ遷移なしで動作するシンプルなUIにしてくだ さい。生成されたパスワードは見やすいように整列して表示してください。 このアプリケーションに機能を追加します。画面上でパスワードの桁数をプルダウンで選択 し、「パスワード生成」ボタンをクリックした時に、選択した桁数でパスワードを生成する ように機能を追加および改修してください。 次に、画面上でパスワードの複雑さを選択できるようにしたいです。大文字・小文字・数 字・記号を含むかどうかを、画面上でチェックして決められるようにしてください。 MUST (絶対欲しい) 機能を確実に作る WANT (あったら良い) 機能を作る
21. 21 .clinerules を詳細化する • Clineでは、設計標準やコーディング規約と戦略、テスト方法などをマークダ ウンに書き起こして .clinerules に細かく表現するようにする • しかし、それでも、生成AIの出力は不確実である (100%ではない) • .clinerules は人間によるやり直しや手直しの作業を極力減らすために書くも のであり、確認作業を放棄できるものではないことに注意する • 個人や社内でこれまで積み上げた、数多くの知恵を言語化しつつ、トライアン ドエラーを繰り返して調整する • 先人の知恵に感謝し、優れたプラクティスを参考にする • ただし長すぎてもいけない (後述の中断リスク)
22. 22 Cline×Amazon Bedrock の注意ポイント
23. 23 コストは気にしよう あっという間に積み上がっていくコスト
24. 24 ブラウザ機能は使いすぎない • Clineなどが持つ内部ブラウザの機能は、チャット内でブラウザを開いて画面を確認する が、裏側ではスクショして画像をモデルに送り、マルチモーダルで推論している • そのスクショが一定数を超えるとエラーになり、後戻りできなくなる ←苛立ちがプロンプトに出ている。。
25. 25 APIの制約に関わるエラーが出るとタスクが中断する • 先ほどのエラーが出ると、そのタスク自体を破棄しなければならず、 作業結果とコストが無駄になる • 作業結果をこまめにコミットに保存したり、Memory bankの機能を活 用するなどして、中断するリスクに備えるのが良い • 何度リトライしても結果は同じ • しかも、この状態では、チャットに 指示を入力し直すことができない (詰み) ← 書けないし押せないメッセージ入力欄。どうしようもない
26. 26 多くの情報が自動で走査され、推論に使用される どこにデータを送信しているのかを気にして使用する 出典: https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/d2a5 bbd2-ae8f-450c-adaa-33979181d26a/e7bfeba7/20250206_councils_social- promotion-executive_outline_01.pdf
27. 27 リスクを軽減するために、AWSを利用する • Amazon Bedrockのモデルは、AWSのインフラストラクチャ上で実行されて おり、リクエストはAWSに送信される • 同じDeepSeekでも「DeepSeek社がホストするモデル」と「AWS社がホスト するモデル」では、モデルを実行している場所も違えば、適用される法律も規 約も異なる • 詳しい情報はAWSのService Termと、モデルごとに存在するEULAを確認する ここ ↓モデルアクセスを設定する画面
28. 28 AWSではオプトアウトが可能 • AWS Organizationsでオプトア ウトポリシーを有効化
29. 29 Cline×Amazon Bedrock コーディング以外の実践的な活用術
30. 30 コードからドキュメントを逆に書き起こす • 例えばgit cloneした後に、ディレクトリを全て走査して構造を洗い出し、 コードの解説を分かりやすく書き起こすことが可能 • ブラックボックスと思われていたプロジェクトを短時間で解読できる可能性
31. 31 プロジェクト全体の脆弱性やリスクを検査させる • コードが存在するディレクトリを走査できるため、依存関係を含めて潜在する脆弱性を 検査させ、修正対応を指示可能 (セキュリティ診断をセルフで実施可能)
32. 32 <NEW> Amazon Q Developer CLI Agent
33. 33 Amazon Q Developer CLI Agentとは? 主な機能 • ローカルファイルシステムの操作 • ファイルの読み書き • ディレクトリの一覧表示 • AWS CLIコマンドとBashコマンドの実行 • AWSリソースの管理 • コードの作成や修正 • インフラストラクチャのコードや設定ファイルの作成支援 • ベストプラクティスの提案 • トラブルシューティング AWS CLIを通じて利用できるAIアシスタント コマンドライン上で動作し、AWSを直接参照するタスクや質問に対応
34. 34 Amazon Q Developer CLI Agent をコマンドラインから使用 日本語でガイドが表示される 様々なことができる
35. 35 Amazon Q Developer CLI Agentの活用例
36. 36 環境情報の確認 このように情報を確認するのは序の口 コンテキストがAWSアカウントであり、 リソースの参照や変更の操作がとても容易
37. 37 コスト最適化レポートの出力 無駄と思われるリソースを 可視化し、コスト削減提案を 得ることが可能
38. 38 セキュリティ監査への対応 アクセスキーのローテーションも可能 人手の承認が必要なタスクも自動判別
39. 39 Amazon Q Developer CLI Agent で構成図を図示 diagrams.net (draw.io) 用の XMLで出力してと依頼し、出力されたXMLを diagrams.net で開いた結果、精度の高い構成図が表示された 少し修正するだけで完成しそうな出来
40. 40 Amazon Q Developer CLI Agent で推進および検証中の事柄 # 検証中の事柄 具体的な使い方の例 確認したもしくは期待する効果 1 問題や課題の分析 「このEC2が高 CPU なのはなぜ？」と聞く → CloudWatch Logs とメトリクスを収集する コマンドを生成・実行し、原因候補と一次 対応コマンドまで返してもらう 複数ソースを跨ぐ調査時間を90%以上削減 人的ミスを削減し、初動対応を短縮 2 手作業で残る運用のスクリプト化 “未使用 EBS を一覧取得して CSV に保存” などを自然言語で指示 → 将来的な定期運用化を見越してCron＆AWS CLI スクリプト化 定型作業をコード化し、自動化率を向上 (検証中だが殆どのケースをカバー可能と推測) 3 コスト最適化レポートの生成 「東京リージョンのEC2とEBSをサイズ別・稼働率付きで列挙して、 非稼働時間を推定して」→ コスト最適化提案付きレポート出力 削減額を可視化し、コストレビューの高速化 サマリレベル表示までの作業時間を90%以上削 減 4 ランブック（運用手順書）の自動作成 障害シナリオを説明すると、手順を Markdown で生成し、必要な CLI コマンドを即テスト 属人化を防ぎ、ナレッジの最新化を継続的に維 持 5 IaC（Infrastructure as Code）生成 「このVPCの通信をXXXエンドポイントを経由するようにして」→ 独自の標準に合わせたコードを生成 → さらに横展開 様々な標準等への準拠対応スピードの向上 6 セキュリティ検査＆修復のワンライナー化 「公開S3バケットを検出してprivate化するスクリプト作って」→ 実行 → さらに結果レポートまで自動生成 監査対応の工数を80%以上削減 7 タグ準拠率チェック & 強制タグ付け 「運用タグのないリソースを全部列挙して推奨タグを付与するスク リプトを作成・実行」 資産管理と部門別コスト配賦の精度向上 8 自動ドキュメンテーション & 環境可視化 「現在の AWS 構成図を draw.io で出力して」→ 生成した図をリ ポジトリへコミット 構成図作成にかかる作業時間を30%削減 最新構成の共有とレビューが即日可能 9 新人オンボーディングガイドの生成 例えば「当環境においてS3バケットを作って静的サイトを公開する 手順を教えて」と入力 → コマンドと背景知識の解説付きで回答 学習コスト削減とオペレーションの標準化促進 AWSを操作する様々なシーンで作業効率を上げる効果、または可能性を確認
41. 41 終わりに
42. 42 プログラマが職を失うのではなく、やり方が変わる 出典: https://www.oreilly.com/radar/the-end-of-programming-as-we-know-it/ <引用> AI はプログラマに取って代わることはありませんが、プログ ラマの仕事は変わります。 (中略) 熟練プログラマであり、先見の明のある技術観察者である Steve Yegge 氏は、置き換えられるのはジュニアおよび中級レ ベルのプログラマではなく、新しいプログラミング ツールや パラダイムを受け入れず過去に固執するプログラマであると 指摘しています。新しいスキルを習得または発明する人への 需要が高まります。AI のツールを習得したジュニア開発者 は、習得していないシニア プログラマよりも優れたパフォー マンスを発揮できます。Yegge 氏はこれを「頑固な開発者の 終焉」と呼んでいます。
43. 43 どうやって社内 (大きな組織) で推進するのか • 検証成果を超速で社内Slackやコミュニティに共有する – 簡単なデモ動画か手順と、見た人が自分ごとと捉えやすい活用例を数多く発信する – 「あれもこれも出来そう」と、手を動かして試してみると、意外な発見がある • 社内の情シス組織と、標準利用に向けた会話を繰り返す – リスク管理、セキュリティ管理、データ管理の話 • 社内で危機感を正しく煽る – 知っているか知らないかでは、天と地ほど生産性が変わる – 知らないや使えないでは済まされない技術である – 知っている人との能力差が歴然たるものとなるため、絶対に無視することはできない – SIerにとっては見方によっては追い風とも言え、すぐにキャッチアップすべし • 要件定義やドキュメンティングが得意なら、使いこなせるはず • しかし、それも使い方を知らなければ、永遠に気づくことはない • 会社で誰か教えてくれたのだろうか、いつ知っていたんだろうかと想像すると、背筋がぞっとす るほど恐ろしい • 最新情報は自分の目と耳でキャッチアップして語れるようにしていかなければならない
44. 44 完全版はこっちに https://speakerdeck.com/nasuvitz/aik odeinguezientomian-qiang-hui
45. 45 END