いまさら聞けない人のためのAIコーディングエージェント入門

生成AIを活用したコーディングはすっかり当たり前となり、モデルの進化とともに精度やできることも大きく広がっています。これまでは「次のコードを予測・補完する」形が主流でしたが、最近では目的やゴールを伝えるだけで自律的にコードを生成・実行する「AIエージェント」が主流になりつつあります。
一方で、普段何気なく使っているだけでは、エージェントの性能を十分に発揮できていないことも少なくありません。本勉強会では、AIコーディングエージェントの基本を整理し、これからより高度に使いこなしていくためのポイントを一緒に学んでいきましょう。

Transcript

1. いまさら聞けない人のための AIコーディング エージェント入門 日本仮想化技術株式会社 VirtualTech.jp 2026年10月7日 1
2. AIエージェントの中での位置づけ AIエージェント：幅広い仕事が対象 調査、資料作成、業務システムの操作など、幅広い仕事を対象にする総称です。 目的に向けて、必要な作業を判断しながら進めます。 コーディングエージェント：開発が対象 AIエージェントの中で、ソフトウェア開発を担当するものです。 開発に必要なコードベースやツールを扱う点が特徴です。 2
3. AI・ツールと、開発方法の呼び分け コーディングエージェント：作業を担うAI 依頼先となるAI・ツールを指す言葉です。 製品によって、使えるモデルやツール、操作方法が異なります。 エージェントコーディング：AIと進める開発 エージェントを使って開発を進める方法を指します。 どの仕事を任せ、どの場面で人が確認するかも含めて考えます。 3
4. AIコーディングは どう変わってきたのか コード補完から、タスク単位の支援へ 4
5. AIコーディングの進化 コードの一部を支援 コード補完は入力中の続きを提案しま す。従来のチャットでは、人間が質問 や依頼への回答を受け取り、コードを 取り込んで作業を進めます。 開発タスクをまとめて依頼 エージェントには「機能を追加する」 などの仕事を渡します。個々の作業を 指示する使い方から、ゴールを共有し て任せる使い方へ広がっています。 5
6. 検索機能を追加する依頼の例 依頼：「ユーザー一覧に検索機能を追加してください」 画面だけでなく、データの取得元や既存の検索処理も、変更を考えるための 材料になります。 6
7. 実行結果をもとに進めるループ まず方針を立てる 関連コードやテスト方法を調べ、 必要な変更と進め方を考えます。 実装して結果を確かめる ファイルを変更し、テストなどで 期待する動作になったかを確認します。 結果に合わせて見直す 失敗の原因を調べ、修正して再検証。 必要なら調査や計画にも戻ります。 7
8. クラウドモデルとローカルLLM クラウドモデルは、OpenAIなどのサービス経由で利用します。 ローカルLLMは、モデルを読み込み、手元の計算資源で動かします。 図は手元のエージェントから、それぞれを利用する構成例です。 8
9. モデルの違いとエージェントの能力 観点 クラウドモデルの利用 ローカルLLMの利用 能力・対応 提供モデルの能力を利用。 指示理解・ツール対応を確認 選んだモデルの能力に依存。 エージェントとの互換性を確認 扱える情報量 モデルやサービスの コンテキスト上限に依存 モデルとメモリ容量に依存。 設定により情報量が変化 計算資源 利用条件 推論用のGPU準備は不要。 通信・料金・利用上限を確認 GPU・メモリなどを用意。 速度は機材や設定に依存 情報の扱い 推論に必要な情報を送信。 サービスのデータ方針を確認 推論を手元で完結できる。 外部ツールの通信は別途確認 指示の理解やツールの選択は、モデルの能力と対応機能に関わります。 精度や速度は、クラウド／ローカルの区分だけでは決まりません。 9
10. 操作インターフェースの違い 種類 特徴・使いどころ ブラウザ Web画面から依頼し、結果を確認。 ブラウザ内で操作できる。 IDE コードと差分をエディタ上で確認。 人間が編集しながら対話しやすい。 CLI ターミナルから操作。GitやShell、 既存のコマンドと組み合わせやすい。 デスクトップ 専用アプリで依頼や差分を確認。 IDEを開かず、作業を管理できる。 インターフェースは、依頼・確認を行う画面や操作方法です。 機能と利用できるモデルは、製品・設定によって異なります。 10
11. 同じモデルでも振る舞いが変わる 判断の材料となる情報 コードや要件、プロジェクトのルールを把握できる範囲が、判断に影響します。 不足する情報を調べたのか、仮定したのかも確認します。 方針の確認と、仕事の手順 Planは実装前に方針を確認する機会を作ります。 Skillsは、仕事に必要な知識や手順を参照できるようにします。 実行して確かめられる環境 ファイル編集やコマンド実行のツールと、テストできる環境を用意します。 結果を確かめられる範囲が、エージェントに任せられる仕事に関わります。 11
12. デモで見てみたいこと どんなものができあがるか お願いした機能が、どんな形でできあがるかを見てみます。 実際に画面を動かしながら、使い心地や気になるところも見ていきます。 どうやって進めてくれるか どこを調べるのか、何を質問してくるのか、つまずいたらどうするのか。 検索ではPlanの有無、名簿CSVではSkillsを使った進め方を見てみます。 12
13. デモ1 まずはそのままお願いする 検索機能をお願いしてみる 「ユーザー一覧に検索機能を追加してください」 通常モードでお願いして、どう進めてくれるかを見てみます。 どこから手をつけるか 最初にどのコードを読むのか、似た処理を探すのかを見てみます。 実装やテストまで、どんな流れで進めてくれるでしょうか。 決まっていないことはどうするか 検索対象や操作方法は、まだ決めていない部分があります。 質問してくるのか、ひとまず考えて進めるのか、やり取りも見てみます。 13
14. Planの役割 Planで方針を共有し、実装前に人間が確認・調整します。 変更が大きいほど、着手前の確認が手戻りの防止に役立ちます。 ※ 上段は計画確認を挟まない例です。調査の工程は省略しています。 14
15. Planで相談できること どこに処理を書くか 検索処理をどこに置くつもりか、先に聞いてみます。 「既存のサービス層に合わせてほしい」と、作り方の希望を伝えられます。 今ある処理を使えるか 「プロジェクト検索の処理を使えそう？」と相談できます。 文字の正規化など、すでにある処理を活かす方向で考えてもらいます。 どこまで変更するか 「今回はAPIを変えずにできる？」と、変更する範囲を相談します。 実装を始める前なら、やりたいことや方針も調整しやすくなります。 15
16. デモ2 Planで相談してから進める 同じお願いをPlanモードで デモ1と同じお願いを、Planモードで進めます。 検索対象や操作方法は、やり取りしながら決めていきます。 どんな作り方を考えているか どこを変えるのか、今ある処理を使えるのか、計画を見てみます。 分からないことがあれば、質問に答えながら方針をそろえます。 希望を伝えてから実装へ 「その処理を使ってほしい」「今回はここまで」と、希望を伝えられます。 方向性が合ったら実装をお願いし、できあがった画面を触ってみます。 16
17. Skillsで活用する知識と手順 一般的な専門知識：モデルの弱い部分を補う モデルによって得意・不得意がある分野に、知識や確認手順を補います。 活用例：アクセシビリティの確認、テスト設計、セキュリティの点検。 プロジェクト固有の知識：共有しないと分からない決まり 構成・命名規則・共通部品など、このプロジェクトの決まりを伝えます。 活用例：機能追加や不具合修正を、既存の設計と検証手順に合わせる。 業務固有の知識：教えなければ知り得ない前提 社内の対象条件・計算ルール・帳票仕様などを明示します。 活用例：対象者の抽出、料金の計算、部門向けのCSVや帳票の出力。 17
18. デモ3 Skillsで名簿CSVをお願いする Skillsを用意してお願いする 「社内共有用の名簿CSVをダウンロードできるようにしてください。 用意したSkillsを使い、まず計画を作ってください」 仕事の決まりを先に伝えておく 在籍者だけ・3列・連絡先は除外、という架空の社内ルールを用意します。 出力する列は部署・名前・役割。Skillsにまとめて渡しておきます。 用意した知識や手順を使ってくれるか 名簿を出してみながら、ルールに沿った内容になっているかを見てみます。 文字の扱いやキーボード操作など、Skillsの手順をどう使うかも見ていきます。 18
19. デモで見た進め方 観察項目 検索・通常 検索・Plan CSV・Skills 最初の調査 自力で集めた情報 計画に示した根拠 手順が求める確認 方針の共有 途中の説明や報告 実装前の計画 計画と手順の整合 実装と検証 実際に行った作業 計画との一致 規約・手順の遵守 最終報告 結果と残る課題 計画からの変更 確認項目の実施 検索デモ1・2は同じ課題で、Planモードの有無を比較します。 名簿CSVデモ3は、固有のルールと確認手順の活用を観察します。 19
20. エージェントが仕事をする環境 情報とルール コードや関連情報が判断の材料です。 共通のルールや制約は、 Instructionsにまとめます。 方針と手順 Planで方針を確認します。 Skillsで仕事の知識や手順を 再利用します。 実行と検証 ツールで編集やテストを実行し、 結果を確認します。完了条件も 人間と共有します。 20
21. 実務で始めやすいタスク 対象を絞った調査やバグ修正 関連コードの調査や小さな不具合の修正から始めます。 範囲が狭い仕事なら、人間が結果を確認し、任せ方を調整しやすくなります。 テスト追加やリファクタリング 確認したい動作や、変えてはいけない振る舞いを明確にします。 既存のテストと実装パターンが、エージェントの判断とレビューを助けます。 ドキュメントの更新 コードの変更に合わせて、手順や説明を更新する仕事も候補です。 記載内容を実装と照合し、成果を評価できる単位で進めます。 21
22. 実務での基本的な進め方 1 ゴール・制約・完了条件を伝える 何を作り、どこまで変更してよいか、何を確認すれば完了かを定義します。 必要に応じて調査と計画を依頼し、人間が方向性を確認します。 2 実装と検証を進める エージェントが方針に沿って変更し、テストやコマンドで結果を確かめます。 失敗した場合は、原因を調べて修正し、もう一度確認します。 3 差分と結果をレビューする 人間が変更内容とテスト結果を読み、要件や完了条件を満たすか判断します。 動作することに加え、意図した範囲の変更になっているかを確かめます。 22
23. 使いながら環境を整える Instructions：共通のルールを残す 毎回伝えている制約や作業方針を、あらかじめ参照できる形に整理します。 共通のルールを、依頼のたびに説明する負担を減らします。 Skills：繰り返す仕事の手順を残す 特定の仕事で使う知識や手順をまとめ、必要なときに参照できるようにします。 実際の作業で足りなかった説明を加え、使いながら改善します。 ツール：確認作業を実行できるようにする テストやLintなどを、エージェント自身が実行できる環境にします。 人間が毎回手動で確認している作業から、少しずつ整えます。 23
24. 人間が担う判断 何を優先し、何を作るか 要件やビジネス上の優先順位を整理し、設計上の選択を行います。 コードから読み取れない目的や事情を、人間が伝える必要があります。 どこまで任せるか 変更してよい範囲と守るべき制約を決め、完了条件を共有します。 途中で確認が必要な判断も、あらかじめ明確にします。 成果を受け入れられるか 計画と差分、検証結果を確認し、要件に合う成果かを評価します。 テストが通ったことだけで判断せず、設計や変更の意図も確かめます。 24
25. 開発者の役割の変化 実装する力を、依頼とレビューにも使う コードを読む力や設計の知識は、仕事の切り分けや計画の確認にも役立ちます。 実装の一部を任せても、適切な変更かを判断する力が必要です。 仕事を定義し、結果を評価する ゴールと制約を整理して伝え、計画と成果を確認します。 参照する情報と検証できる環境を整えることも、開発者の仕事になります。 25
26. まとめ 任せる単位は、コードから開発タスクへ コーディングエージェントは、調査・実装・検証を連続して進めます。 実行結果を確かめながら、次の作業を判断します。 モデルと、周辺の条件を合わせて考える モデルに加え、情報やルール、Plan・Skills・ツールが振る舞いに関わります。 必要な知識や手順と、結果を検証できる環境を整えます。 人間が仕事を定義し、成果を評価する ゴール・制約・完了条件を伝え、計画と最終的な変更を確認します。 まずは結果を判断できる小さなタスクで、任せ方を試してみてください。 26
27. 会社概要 日本仮想化技術株式会社 概要 社名：日本仮想化技術株式会社 ベンダーニュートラルな 英語名：VirtualTech Japan Inc. 独立系仮想化技術の 設立：2006年12月 エキスパート集団 資本金：3,000万円 本社：東京都渋谷区渋谷1-8-1 取締役：宮原 徹（代表取締役社長兼CEO）、伊藤 宏通（取締役CTO） スタッフ：9名（うち、8名が仮想化技術専門エンジニアです） URL：http://VirtualTech.jp/ 仮想化技術に関する研究および開発 仮想化技術に関する各種調査 仮想化技術に関連したソフトウェアの開発 仮想化技術を導入したシステムの構築 OpenStackやKubernetes、DevOps基盤の導入支援・新規機能開発 27
28. 会社概要 OpenStackへの取り組み 通信事業社でのOpenStack基盤の検討支援および構築・運用 NTTドコモ (2011年から技術評価を支援、商用利用に向けた検討・構 築・運用を実施) NTT西日本 (商用利用に向けた評価・検討の支援、プロジェクトマネー ジメント支援) 大手通信事業社 (NFV基盤についての検証・評価支援) ベアメタルOpenStackの開発 仮想環境と物理環境をOpenStackで一括管理 単一のイメージで仮想マシンと物理マシンの双方を起動可能 2013年4月リリースのGrizzlyで本体にマージ 28
29. 会社概要 OpenStack Summitでの発表実績 2014/11 OpenStack Summit Paris 2015/10 OpenStack Summit Tokyo We spoke the knowledge and tips when building and operating OpenStack Cloud on 100 Physical Servers. (Neutron HA, VXLAN performance,,,) We (NTT West, Canonical and VTJ) spoke ”Requirements for Providing Telecom Services on OpenStack-based Infrastructure”. 29
30. 会社概要 DevOpsを始めたいチームのための支援サービス DevOpsサポートサービス 開発プロジェクト 運用チーム • • • • • • • • 開発環境 GitHubリポジトリ CI/CD IaC (デプロイ環境) 運用監視 脆弱性スキャン インシデント管理 IaC (共通インフラ) 運用をまるっとお任せしたい おまかせDevOps (かんたんDevOpsに加えて) DevOps環境の運用・改善 インフラコードの保守 発生したインシデントへの対応 DevOps人材を育成したい かんたんDevOps DevOpsの環境初期構築 インフラのコード化 DevOpsプロセスの実践手順書・支 援 技術サポート 30