生成AI開発トレンド研修
静岡会場

GitHub Copilot Businessは月額19ドル/ユーザーです。Cursorは月額20ドル、Claude Codeは従量課金でAnthropicのAPI利用料に準じます（月額20ドル前後のProプランもあります）。32名でCopilot Businessを導入する場合、月額約10万円になります。

ROI測定の具体的な指標として有効なもの

• PR作成からマージまでのリードタイム変化
• 1スプリントあたりの消化ストーリーポイント変化
• ボイラープレートコードの記述時間削減率
• 開発者の主観的満足度（月次アンケート）

Shopifyの事例では開発速度25〜40%向上が報告されています。ただしROIは「測定を始めた時点の生産性」に大きく依存しますので、導入前にベースラインを取っておくことが前提です。

段階導入をおすすめします。理由は3つあります。

• Rulesファイルの整備に時間がかかります。初期のRulesが未成熟な状態で全員に渡すと「使えない」という第一印象が定着しやすくなります
• パイロットチームで「このプロンプトは効く」「この場面は人力が速い」という知見を蓄積してから横展開したほうが定着率が高まります
• ライセンスコストを段階的に承認できるため、社内稟議を通しやすくなります

具体的には、まず3〜5名の推進チームで2〜4週間のパイロットを実施し、社内向けのガイドラインとFAQを整備します。その後、チーム単位で段階展開するのが手堅い進め方です。

CI/CDとの統合には段階があります。

レベル1（すぐできる）: 開発者のローカル環境にCopilot / Cursorを入れるだけです。CI/CDの変更は不要で、これだけでもコード生成・テスト記述の効率が上がります。

レベル2（PRレビュー自動化）: GitHub ActionsにCopilot PRレビューを組み込みます。PRが作成されるとAIがコード品質・セキュリティをチェックし、コメントをつけます。人間のレビュー前にフィルタリングできます。

レベル3（Issue→実装の自動化）: Copilot Coding Agentを使い、Issueが作成されたら自動で実装ブランチを生成します。人間は最終承認だけ行います。現時点ではまだ限定的なシナリオ向きです。

レベル1からで十分です。既存パイプラインを壊すリスクはゼロですので、明日からでも始められます。

Business/Enterprise契約であれば使われません。GitHub Copilot Businessは「ユーザーのコードをモデルの学習に使用しない」と利用規約で明記しています。Cursorも同様にBusiness以上のプランで学習除外を保証しています。Anthropic（Claude）のAPIも、利用規約上ユーザーの入出力をモデルの学習に利用しないと明記しています。

個人プラン（Copilot Individual等）は注意が必要で、テレメトリデータが学習に使われる可能性があります。法人利用であればBusiness契約を前提にしてください。

通信事業者として顧客情報を扱うコードを書く場面があるなら、プロキシ経由でのAPI呼び出し（送信内容のログ取得）や、機密ファイルの自動除外設定（.copilotignore等）を併用されることをおすすめします。

AI生成コードに脆弱性が含まれる頻度は、人間が書くコードと大きく変わらないという調査があります。ただし「AIが書いたから大丈夫」と過信するリスクのほうが深刻です。

現実的な対策として有効な3つ

• SAST（静的解析）ツールをCI/CDに組み込みます。Snyk、SonarQube、GitHub Advanced Securityなどがあり、AI生成か否かにかかわらず全コードを自動スキャンできます
• AI生成コードは必ずレビューを経てからマージする運用ルールを設けます。最低1名、できれば2名以上のレビュー必須化が望ましいです
• Rulesファイルにセキュリティ要件を明記します。「SQLは必ずパラメータ化クエリを使う」「ユーザー入力はZodでバリデーションする」等を記載してください

OWASP LLM Top 10にAI固有のセキュリティリスクがまとまっていますので、セキュリティチームとの共有をおすすめします。

多層防御の考え方で設計することをおすすめします。

• .copilotignore / .cursorignore: .envファイル、credentials系、秘密鍵などをAIのコンテキストから除外する設定ファイルです。.gitignoreと同じ書式で記述できます
• プロキシ層でのフィルタリング: 社内プロキシでAI APIへの通信を中継し、送信内容にAPIキーやパスワードパターンが含まれていないかチェックします。大規模導入時に有効です
• 開発者教育: 「何をプロンプトに貼り付けるか」は最終的に開発者の判断です。「顧客データをそのままプロンプトに貼らない」「ダミーデータに置き換えてから質問する」を基本ルールとして徹底してください

AWSのKiroはVPC内での利用に対応しており、通信がAWS内で完結します。クラウドインフラを運用される事業者にとっては有力な選択肢です。

現時点では法的にグレーな領域が残っています。ただし実務上の対応は明確にできます。

GitHub Copilotには「パブリックコードに一致する提案をブロックする」フィルタ機能があります。Business契約ではこのフィルタがデフォルトで有効です。これにより、OSSライセンスに抵触する可能性のあるコード片が提案されるリスクを軽減できます。

社内ポリシーとして定めておくべきことは、AI生成コードも既存のコードレビュープロセスを通すこと、ライセンス検知ツール（FOSSA、Snyk License Compliance等）でOSS混入チェックを自動化すること、の2点です。AIが書こうが人間が書こうが、マージ前に検査する体制があれば運用できます。

チームの状況で答えが変わります。判断基準を3つ示します。

VSCode + Copilotが合うケース: 既にVSCodeが標準IDEとして定着している、拡張機能資産が多い、エンタープライズ契約（GitHub Enterprise）がある場合です。最も無難で、既存環境を壊しません。

Cursorが合うケース: 新規プロジェクトが多い、フロントエンド中心の開発、Composerによる複数ファイル一括編集を頻繁に行いたい場合です。ただしVSCodeの最新アップデートが遅れて反映される点にはご注意ください。

Kiroが合うケース: AWSを主要クラウドとして利用している、セキュリティ要件が厳しくVPC内でAIを利用したい、IAMベースのアクセス管理と紐付けたい場合です。

迷われるならVSCode+Copilotから始めるのが低リスクです。後からCursorやKiroに移行する際もVSCode互換のため移行コストは低く抑えられます。

CLIツールが真価を発揮する場面はIDE上の開発とは異なります。

• サーバー上の作業: SSH先にIDEを持ち込めない場面でもCLIなら使えます。本番障害の緊急対応やログ解析にも有効です
• 大規模リファクタリング: リポジトリ全体を対象にした一括変更はCLIのほうが扱いやすいです。Claude CodeはGit操作も自然言語で行えます
• 自動化パイプライン: スクリプトからAIを呼び出す場合はCLI一択です。CIの中でテスト生成やドキュメント更新を自動化する用途に適しています
• 並列開発: Git Worktreeと組み合わせ、複数のCLIセッションを同時に走らせて別々の機能を並列実装できます

IDE統合型は「日常のコーディング」に、CLIは「自動化と大規模作業」に向いています。両方を状況で使い分けるのが理想です。

MCP（Model Context Protocol）は、AIに「外部の情報源を直接読み書きさせる」ための通信規格です。たとえば以下のようなことが実現できます。

• AIがSlackの特定チャンネルを読んで、議論内容をコードに反映します
• AIがJIRAのチケットを読んで、そのまま実装に着手します
• AIが社内ドキュメント（Confluence等）を参照して、コーディング規約に準拠したコードを生成します
• AIがデータベースのスキーマを直接確認して、正確なクエリを生成します

導入ハードルは「MCPサーバーの設定」が必要な分だけ、Copilotを入れるより一段高くなります。ただしJSON設定ファイルを数行書くだけで済むケースも多いです。公式のMCPサーバーリストには数百のコネクタがあり、GitHub、Slack、PostgreSQL、Notion等の主要サービスは対応済みです。

通信事業者の現場では、ネットワーク監視ツールや障害チケットシステムとAIを繋げるMCPサーバーを自作する、という応用も考えられます。

初期作成に30分〜1時間、その後は月1回のレビューで15分程度です。コーディング規約ドキュメントの維持と同じ感覚でお考えください。

放置すると、プロジェクトの実態とRulesが乖離し、AIが古いパターンでコードを生成するようになります。たとえばライブラリのバージョンアップで非推奨になったAPIをAIが使い続ける、といった事態が起こります。

運用のコツは、コードレビューで「AIがまた同じミスをした」と気づいたタイミングでRulesに追記することです。事後的に育てていくのが現実的で、最初から完璧なRulesを書く必要はありません。Rulesファイルはリポジトリにコミットしてバージョン管理しますので、変更履歴も追えます。

効果はあります。むしろレガシーコードベースのほうが恩恵を感じやすい場面があります。

• コード理解の補助: ドキュメントがない古いコードを「この関数は何をしている?」とAIに聞けます。リバースエンジニアリングの速度が段違いに上がります
• テスト追加: テストがないレガシーコードにユニットテストを自動生成します。「既存の動作を壊さない」ためのセーフティネットを素早く構築できます
• 段階的リファクタリング: 「この関数をTypeScriptに書き換えて」「このクラスを小さな関数に分割して」といった指示でリファクタリングを支援してくれます

ただしレガシーコードの「暗黙のビジネスルール」はAIが読み取れないことがあります。ドメイン知識を持つ人間がレビューする体制は必須です。

「動く」と「品質が高い」は別の話です。バイブコーディングで一発生成したコードをそのまま本番に入れることはおすすめしません。

品質担保の仕組み

• 生成後にLinter / Formatterを必ず通します（ESLint、Prettier等）
• Rulesファイルに品質基準を書いておきます。「any型禁止」「関数50行以内」「エラーはthrowする」等を記載してください
• AI自身にテストコードも生成させます。テストが通らなければリジェクトしてください
• 人間によるコードレビューは省略しないでください

バイブコーディングの本質は「最初の80%を高速に生成し、残り20%を人間が仕上げる」ことです。全自動化ではなく、初速を上げる手段としてお使いください。

明確に苦手な領域があります。

• 社内独自のビジネスロジック: 学習データに存在しない自社固有の計算ロジックや業務フローは、AIの推測が外れやすいです
• 最新のAPI・ライブラリ: 学習データのカットオフ以降にリリースされたAPIの正確な使い方は把握していません。ハルシネーション（存在しないAPIを自信満々に使う）が起きやすくなります
• パフォーマンスチューニング: 「動くコード」は書けますが、本番負荷を考慮した最適化には人間の知識が必要です
• 暗号処理・セキュリティの実装: 暗号アルゴリズムの選択やセキュリティ設計は、専門家のレビューなしにAI任せにすべきではありません

逆に、CRUD処理、テスト生成、ドキュメント作成、定型的なUI実装は得意中の得意です。苦手な領域と得意な領域を見極めて使い分けることが、実務適用の鍵になります。

使える場面はあります。ただし適用範囲を選ぶ必要があります。

効果が出やすい領域

• Ansible / Terraform等のIaCコード生成です。定型的なインフラ構成定義はAIが得意です
• ネットワーク設定テンプレートの生成です。CiscoのACLやルーティング設定のひな型作成に使えます
• 監視スクリプトの作成です。Zabbix / Prometheus用のアラートルール生成に活用できます
• 障害対応手順書の自動生成です。ログから状況を要約し、対応手順のドラフトを作成します

慎重にすべき領域

• 本番ネットワーク機器への直接設定投入です。AIの出力を検証なしに流し込むのは危険です
• 機器固有のファームウェアバグの回避策です。ベンダー固有の知見はAIが持っていないことが多いです

「生成→人間がレビュー→適用」のフローを守れば、インフラ領域でもAIは有効な補助ツールになります。

この懸念はもっともで、多くの企業で議論されています。対策として効果が報告されているものをご紹介します。

• 「AIなしタイム」の設定: 週に数時間、AI補助なしで開発する時間を確保します。アルゴリズムの理解やデバッグ力を養う時間として位置づけてください
• AIの出力を説明させる: 「このコードが何をしているか説明して」とジュニアに問います。コピペしただけなら説明できないため、理解度のチェックになります
• レビューでの「なぜ」の追求: AIが生成したコードであっても、PRレビューでは「なぜこの実装にしたか」を説明させます。設計判断の力は説明を求められることで育ちます
• 障害対応への参加: 本番障害の対応はAIに任せられません。ジュニアを対応チームに入れることで、生のトラブルシューティング力が身につきます

AIは「書く力」を補助しますが、「読む力」「判断する力」は人間側で鍛える必要があります。育成設計の軸をそこにシフトしていただければと思います。

トップダウンの号令だけでは定着しません。「この人に聞けばわかる」という存在をチームに1人ずつ作るのが現実的な進め方です。

チャンピオン候補の選定基準

• 新しいツールに対する好奇心が高い方（役職は問いません）
• チーム内で日常的にコミュニケーションが取れる方
• 「これ便利だよ」と自然に周囲に勧められる方

育成ステップ

• 先行してライセンスを付与し、2〜3週間自由に使ってもらいます
• 週次で「こう使ったらこうなった」を共有するミニ発表の場を設けます
• Rulesファイルの作成・メンテナンスをチャンピオンの役割として明確にします
• 社内Slack等でTips共有チャンネルを運用し、チャンピオンが投稿をリードします

半年後には、チャンピオンがいるチームといないチームで明確な生産性差が出てきます。その事実が次のチームへの横展開を後押しします。

コード量やコミット数で開発者を評価している組織は、AI導入で指標が破綻します。見直しは避けられません。

AI時代に有効な評価軸

• 判断の質: AIの提案を適切に取捨選択できているかどうかです。盲目的に受け入れていないかを確認します
• 問題定義力: 曖昧な要件をAIが処理できる粒度まで分解できるかどうかです。プロンプトの質は問題定義力そのものです
• チーム貢献: Rulesの整備、ナレッジ共有、チーム全体の生産性向上への寄与を評価します
• 品質維持: バグ発生率、障害件数、コードレビューでの指摘率を指標にします

「たくさんコードを書いた人」から「チーム全体の成果を最大化した人」に評価の重心が移ります。マネジメント層がこの転換を理解し、評価基準をアップデートすることが先決です。