for Startups Tech Blog

フォースタ社員のエンジニアたちが思い思いのことを書き綴ります。

【GitHub Actions】actions/ai-inferenceを活用して痒いところを自動化しよう

目次

はじめに

こんにちは、フォースタートアップス株式会社エンジニアの野尻(@jsotakebmx)です。ヒューマンキャピタル支援システム(社内プロダクト)の開発を担当しています。

早速ですが、みなさんはGitHub ActionsでAIを活用できていますか?

「CI/CDにAIを組み込みたいけど、APIキーの管理やコスト計算、場合によっては稟議も必要で...」と二の足を踏んでいる方も多いのではないでしょうか。かく言う私もその一人でした。

この記事では、GitHub CopilotユーザーならAPIキー管理不要・追加契約不要でサクッと使えるactions/ai-inferenceを活用して、日々の開発業務の「ちょっと面倒な作業」から解放される術を紹介します。

actions/ai-inferenceとは?

actions/ai-inferenceは、GitHub公式が提供するGitHub ActionsでGitHub Modelsを手軽に呼び出すためのアクションです。

github.com

GitHub Models上の多様なモデル(GPT-5-mini, DeepSeek-v3, Phi-4など)のAPIを内部的に叩く形でテキスト生成や要約、コード解析などをCI/CDパイプラインの一部として実行することができます。

詳細は後述いたしますが、以下の様にactions/ai-inference@v1を呼び出すだけで簡単にGitHub Modelsをworkflow内で使うことができます。

name: 'AI inference'
on: workflow_dispatch

jobs:
  inference:
    permissions:
      models: read
    runs-on: ubuntu-latest
    steps:
      - name: Test Local Action
        id: inference
        uses: actions/ai-inference@v1
        with:
          prompt: 'Hello!'

      - name: Print Output
        id: output
        run: echo "${{ steps.inference.outputs.response }}"

公式引用

また、利用可能なモデルのカタログは以下で検索できますので興味ある方は見ていただけると色々試せて面白いと思います。

github.com

なぜactions/ai-inferenceなのか?

Claude Code GitHub ActionsGemini CLI GitHub Actionsもあるじゃん?」と思われるかもしれません。

確かにこれらは非常に強力なのですが、組織(人)によっては導入までの「社内調整コスト」に大きな差があると個人的には考えています。

他のAI Actionsとの比較

項目 actions/ai-inference Claude / Gemini
認証 GITHUB_TOKEN でOK API キー管理など
契約 GitHub 契約内で利用可能 ベンダーごとの契約・決済登録が必要
用途 日々の運用自動化(要約・分類) ガッツリ機能開発・コード修正

特に「認証」と「契約」の壁は無視できません。

Claude Codeには無料割り当てがなく、利用には契約や課金が必須ですし、Gemini CLIにはGoogle AI Studioの無料枠はありますが、コードがAIの学習に用いられてしまうため、組織で活用する場合は無料枠を使う選択肢は実質ないと思います。

一方GitHub Modelsは、各GitHubアカウントごとに無料枠(ただしレート制限あり)が割り当てられており、コードが無断で学習に用いられることはありません。

「PRの要約や社内リリースノートを自動化したいだけなのに、予算を決めて、稟議を通してSecretsキーを発行して...」というのは、正直気が滅入りますよね。私は滅入ります。

そんな同志たちにこそ是非おすすめです。

docs.github.com

実践:リリースノート自動生成ワークフロー

では、実際に「痒いところ」を自動化してみましょう。

解決したい「痒いところ」

私のチームでは、PRをマージした後にSlackで「これリリースしました」と報告する運用があるのですが、変更内容をまとめて書くのが地味にめんどくさい瞬間があります。

文化的に(チームへの)リリース報告では詳細の報告も特段していないので、変更内容が知りたければIssueやPRまで個々で見に行く必要があります。

チーム内のリリース報告の様子

そこで、「mainブランチにマージされたら、GitHub ModelsがPRの内容を要約して、Slackにリリースノートを投稿する」ワークフローを作ってみました。

権限設定(最重要)

このアクションを使うには、permissionsブロックでmodels: readを許可する必要があります。これがないと動きません。

jobs:
  summarize-release:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      models: read # <--- これがAI呼び出しに必要!

AIアクションの呼び出し

PRの取得方法に関しては本題から逸れるので詳細省きますが、ghコマンドやGraphQLを駆使してPRのコミットメッセージやタイトルを取得します。

# 一部抜粋
PR_NUMBER="${{ github.event.pull_request.number }}"

# PRの基本情報とコミット情報のみを取得(コメント、レビュー、差分は除外)
gh pr view $PR_NUMBER --json title,body,number,author,url,commits,baseRefName,headRefName > pr-info.json

# ベースブランチとヘッドブランチを取得
BASE_REF=$(jq -r '.baseRefName' pr-info.json)
HEAD_REF=$(jq -r '.headRefName' pr-info.json)

# 差分の統計情報のみを取得(git diff --stat で要約)
git diff --stat origin/$BASE_REF...origin/$HEAD_REF > pr-diff-stat.txt

# PR情報を整形してファイルに保存
cat > pr-context.txt << 'EOF'

あとはとてもシンプルで、以下のようにai-inferenceのプロンプトに上記取得した内容を渡してやるだけです。

- name: Generate release notes with AI
  id: ai-inference
  uses: actions/ai-inference@v1
  model: openai/gpt-5-mini # モデルを指定
  max-tokens: 4000 # 生成するトークンの最大数

  prompt: ${{ steps.read-context.outputs.context }}  # 前段Stepで取得したPRの内容
  system-prompt-file: './path/system-prompt.txt'  # システムプロンプトのfile pathで指定できる

今回の例だとこんな感じのリリーステンプレートにしました。

渡されたPRの内容を元に、リリースノートを作成してください。
リリースノートは以下のフォーマットに従い、日本語で記述してください。

## やったこと
(30〜100文字程度で要約)

## 主なリリース内容
- (箇条書きで主な変更内容を列挙)
- (該当がなければ「なし」と記載)

## マイグレーションの有無
 (データベースマイグレーションやインフラ変更が必要な場合は詳細を記載、なければ「なし」)

## 注意点
- (デプロイ後の動作確認事項や注意すべき点を記載)
- (該当がなければ「なし」と記載)

Slack通知

あとは、適宜Slackアプリを作ってWebhookなり、chat.postMessage API(OAuthトークン)なりでSlack通知するように組めば完了です。

- name: Slack通知
  uses: slackapi/[email protected]
  with:
    payload: |
      {
        "text": "🎉 リリースされました!\n\n${{ steps.ai_summary.outputs.answer }}"
      }
  env:
    SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}

これで、mainにマージされるたびに自動でリリースノートが流れるようになりました。やったー

Slackに通知されたリリースノート

その他の活用アイデア

他にも、以下の使い方を検証中です。「こんな使い方してます」というのがあれば何卒ご教授ください🙏

  1. Issueの自動トリアージ
    • Issueが起票されたら、「バグ」か「機能要望」かをAIに判断させて自動でラベルを貼る。
  2. エラーログの自動解析
    • ビルド落ちした時に、膨大なログから原因と修正案をAIに提示させる。

まとめ

actions/ai-inferenceは、面倒な設定なしでGitHub ActionsにAIを組み込める便利なツールです。

非常にハードルは低いので、まずは「PRの要約」や「Issueの自動トリアージ」といった小さなタスクから試してみてはいかがでしょうか?「これ、GitHub Modelsにやらせてみましょう」とチームに提案して、開発体験を向上させていきましょう!

これからAWS認定資格を受ける人へSAA・DVAの勉強方法と所感まとめ

テックブログのアイキャッチ画像

目次


はじめに

こんにちは。フォースタートアップス株式会社でエンジニアをしている田畑です。

私は入社してそろそろ2年になりますが、最近はインフラ周りの業務に携わる機会が徐々に増えてきました。弊社ではAWSを利用しており、日々業務で触れるリソース以外にも、より幅広い知識を体系的に身につけたいと思い、AWS認定資格の取得に挑戦しました。

本記事では、実際にAWS認定資格(DVA・SAA)を取得した経験をもとに、試験の概要・勉強にかかった時間・準備方法・実務への活かし方などをまとめてお伝えしていきます。


AWS認定資格とは?

AWS認定資格は、Amazon Web ServicesAWS)に関する知識やスキルを客観的に証明するための公式認定資格です。大きく以下の4つの分野に分かれています。

Foundational(基礎)

  • Cloud Practitioner
  • AI Practitioner

AWS認定資格の中でも最も難易度が低く、AWSに関する用語や基本的な概念など、基礎的な知識を身につけることができます。

Associate(中級)

  • Solutions Architect
  • Developer
  • CloudOps Engineer
  • Data Engineer
  • Machine Learning Engineer

AWSの実務経験が1〜2年程度の初級エンジニア向けの資格です。実務で求められる知識や、各認定資格の観点に沿ったAWSリソースの理解を深めることができます。

Professional(上級)

  • Solutions Architect
  • DevOps Engineer
  • Generative AI Developer

AWSの実務経験が2年以上あるエンジニアを主な対象とした資格で、AWSを用いたシステム設計や運用において、実務経験に基づく高度な判断力が求められる上級者向けの認定資格です。

Specialty(専門)

  • Machine Learning
  • Advanced Networking
  • Security

特定の分野に関する専門的な知識と実務レベルでの深い理解が求められる、専門特化型の認定資格です。クラウド未経験〜初級であれば、多くの人はCloud Practitioner(CLF)またはSolutions Architect Associate(SAA)から始めるケースが多いです。

参考:AWS 認定


なぜAWS認定を受けようと思ったか

今回、私が取得したAWS認定資格は以下の2つです。

AWS Certified Solutions Architect – Associate(SAA)

可用性や冗長化といった観点から、システム全体の設計を理解していることが求められる資格です。

AWS Certified Developer – Associate(DVA

AWS SDKやLambda、API Gatewayなどを用いた、アプリケーション開発者視点でのAWS利用に関する理解が求められる資格です。

AWS認定資格を取得しようと思ったきっかけは、実務で日常的に触れているAWSリソースが、全体の中ではごく一部に限られており、これまで使ったことのないリソースについても幅広く理解したいと感じたことでした。

普段の業務では、S3やLambdaなど、アプリケーションと連携して利用されるサービスに触れる機会が多くあります。例えば、アプリケーションからS3にファイルをアップロードし、そのイベントをトリガーにLambdaを実行するといった構成で利用しています。一方で、ネットワーク設計やセキュリティ周りのサービスについては、実務で直接触れる機会が少なく、体系的に学ぶ必要性を感じていました。

その中でも、今回取得した2つの資格は、日々の業務に直結する実践的な内容を体系的に学べると考え受験しました。DVAでは普段利用しているLambdaやS3についてより深く理解すること、SAAではシステム全体のアーキテクチャを俯瞰して捉えられるようになることを期待していました。


勉強方法

まずは、対象資格の参考書を一通り読みました。その後は、Udemyで購入した模擬試験問題集を中心に、繰り返し問題を解く学習方法を取りました。参考書については、すべてを暗記しようとするのではなく、全体像を把握する目的でさらっと読み進め、理解が浅かった部分や重要そうなポイントを、問題演習を通じて復習するようにしていました。

Udemyの問題集では、回答後に各選択肢で登場するAWSサービスの概要が図解付きで解説されており、単なる正誤確認にとどまらず、サービス理解を深めるのに役立ったと感じています。

また、より深く理解したいテーマについては、AWS Black Belt Online Seminar を活用しました。これはAWS Japanが提供している公式の技術解説セミナーシリーズで、サービスの背景や設計思想まで含めてキャッチアップできるため、知識の補完として非常に有用でした。

個人的な感覚としては、参考書だけでの合格はやや厳しい印象です。参考書の巻末に付属している模擬問題は、内容理解の確認という位置づけで難易度も比較的易しく、実際の試験レベルを想定すると、問題演習量が不足しがちだと感じました。とはいえ、参考書のみで合格している方の声も多く見かけるため、学習の進め方次第では十分対応可能だと思います。当たり前ですが、自分に合った学習スタイルを見つけることが重要だと感じました。

使用した教材

Udemy
参考書

※ 本記事で掲載している参考リンクは、すべてアフィリエイトリンクではなく、純粋な情報共有を目的としたものです。


実際にかかった時間

DVA

  • 勉強期間:2週間
  • 平日:通勤中に30分
  • 休日:3〜4時間

合計:23時間程度

SAA

  • 勉強期間:1週間
  • 平日:通勤中に30分、業務時間後に30分〜1時間程度
  • 休日:5〜6時間

合計:15時間程度

今回の受験では、先にDVAを取得し、その直後にSAAを受験しました。直前まで学習していたDVAの知識をそのままSAAの試験でも活かすことができたため、結果としてSAAはDVAよりも少ない学習時間で合格することができました。

一方で、試験の難易度自体はSAAの方が高いと感じました。DVAAWSリソースの使い方や特徴を理解していれば対応できる問題が多いのに対し、SAAではそれに加えて、要件に応じてどのようにアーキテクチャを構成するかといった設計観点が求められます。

そのため、もし受験順序が逆であった場合、SAAの取得にはより多くの学習時間が必要だっただろうと感じています。


試験会場(オンライン・オフライン)

AWS認定試験は、指定されたテストセンターで受験する方法と、自宅やワークスペースなどからオンラインで受験する方法の2通りがあります。

私は、DVAはテストセンターで、SAAは自宅からオンラインで受験しました。オンライン受験の場合、試験開始前に身分証明書のアップロードやネットワーク環境のチェックなど、事前準備が必要になりますが、移動時間や交通費がかからない点を考えると、個人的にはオンライン受験の方がメリットが大きいと感じました。

一方で、オンライン受験では、手の届く範囲に物を置かないことや、試験中に第三者が部屋に入らないことなど、受験環境に関するルールが厳しく定められています。そのため、事前に受験環境を整えておくことには注意が必要です。


実務に活かせるか?

私の場合は前述のとおり実務でLambdaとS3を利用していますが、学習を通じて「なぜLambdaを使うのか」という設計上の背景をより深く理解できるようになりました。S3イベントをトリガーとしてLambdaが起動する構成についても、単に動作を知っているだけでなく、その仕組みがどのようなユースケースに適しているのかを意識できるようになり、全体の解像度が上がった実感があります。

一方で、実務で使用する機会の少ないAWSリソースについては、時間の経過とともに知識が薄れていくのも事実だと思います。そのため、資格取得そのものが直接すべての実務に直結するというよりは、AWSに関する知識を体系的に整理したり、普段触れないサービスにも目を向けるきっかけとしての側面が大きいと思いました。


まとめ

今回は、AWS認定資格についてまとめてきました。インフラ領域に普段あまり触れない方であっても、クラウドに関する知識は持っておいて損はないと思います。

資格取得は、学習を継続するための良いモチベーションになりますし、AWSを体系的に学ぶための入口としても適していると思います。これからAWS認定資格の受験を検討している方にとって、本記事が少しでも参考になれば幸いです。

AWS Terraform MCP Server使ってみた

記事タイトル

目次

  1. はじめに
  2. AWS Terraform MCP Serverとは
  3. 機能
  4. 事前準備
  5. 導入方法
  6. 使ってみた
  7. コードの生成
  8. 終わりに

1. はじめに

こんにちは。フォースタートアップス株式会社でエンジニアをしている田畑です。 最近Terraformを使うことが増えてきたのですが、同じタイミングでMCPサーバーも注目されているのを見かけました。 せっかくなので両方触ってみたいなと思って調べていたら「Terraform MCP」というのを発見しました。

今回はその中でも AWS Terraform MCP Server を実際に試してみたので、感想や導入の流れをまとめてみます。 Terraformに興味がある方や、AWS Terraform MCPが気になっていた方にとって、少しでも参考になれば嬉しいです。

2. AWS Terraform MCP Serverとは

AWS Terraform MCP Serverとは、AWS向けTerraformのベストプラクティスに沿ったコード生成や静的解析を行ってくれるMCPサーバーです。これにより、安全性と信頼性を意識したTerraformコードを簡単に書けるようになります。

参考:AWS Terraform MCP Server

3. 機能

Terraformのベストプラクティス
  • Terraformの設定について、AWSが推奨する最適な設計方法を確認したり、安全性や規制順守の観点から注意すべきポイントを把握することができます。

AWSアーキテクチャを構成する際の、セキュリティやコンプライアンスの推奨事項を考慮したベストプラクティスに則った設計であるかをチェックするのに役に立ちます。

参考:AWS上でアプリケーションを構築するためのTerraformの具体的なアドバイス(ベストプラクティス)を使用

セキュリティファースト開発ワークフロー
  • 生成したTerraformコードに対して、自動で静的解析を行い、脆弱性やセキュリティリスクを検出

こちらはAWS Terraform MCPの機能を使用する上で、常に適用される仕組みです。 そのため、AWS Terraform MCP Serverを使えば、どのワークフローでコードを生成しても安全性が担保され、安心してインフラ構築を進められます。

checkov統合

checkovは、Terraformなどで書かれたインフラの設計図(コード)にセキュリティ上の問題や設定ミスがないかを自動でチェックしてくれる静的解析ツールです。

ここでいう「統合」とは、AWS Terraform MCP Serverの機能としてcheckovを組み込み、MCPを通じて直接セキュリティチェックを実行できるようになっていることを指します。これにより、わざわざ別途checkovをセットアップすることなく、Terraformコードの安全性をすぐに確認できるようになります。

  • 脆弱性のある設定を自動で検出
  • 具体的な修正方法も提示

参考:checkov

Terraformレジストリモジュール分析
  • 入力変数、出力変数、README コンテンツを抽出
  • モジュールの使用方法と構成オプション、モジュール構造と依存関係を分析

こちらを使えば、モジュールの使い方や構成オプションを一目で把握できます。事前調査の手間が省けて、導入やレビューがスムーズになります。

その他の機能

  • AWS プロバイダードキュメント
  • AWS-IA GenAI モジュール
  • Terraform ワークフロー実行
  • Terragrunt ワークフロー実行

4. 事前準備

導入するにあたり、以下が必要になります。
以下は公式ドキュメントからの引用です。

-AstralまたはGitHub READMEからuvをインストール
- uv python install 3.10Pythonをインストール
- ワークフロー実行用にTerraform CLIをインストール
- セキュリティスキャン用にCheckovをインストール

(出典:AWS Labs Terraform MCP Server ドキュメント

参考までに、私の環境は以下のとおりです。

  • uv 0.8.19
  • Python 3.13
  • terraform 1.13.3
  • checkov 3.2.471

5. 導入方法

VS Codeの場合、公式ドキュメントのInstallationページにある「Install on VS Code」をクリックすることで、簡単に導入できます。 VSCodeにMCPをインストールする方法 参考:Installation

VS Codeに手動で導入する場合は、macOSでは ~/Library/Application Support/Code/User/mcp.json ファイルに以下を記述します。

{
  "servers": {
    "awslabs.terraform-mcp-server": {
      "command": "uvx",
      "args": ["awslabs.terraform-mcp-server@latest"],
      "env": {
        "FASTMCP_LOG_LEVEL": "ERROR"
      },
      "disabled": false,
      "autoApprove": []
    }
  }
}

Visual Studio CodeにおけるMCPの設定方法としては、Dockerコンテナを利用する方法や、.vscode/mcp.jsonに設定する方法などがあります。

参考:Add an MCP server

6. 使ってみた

検証環境

checkov統合

始めに、checkov統合の機能を試してみたいと思います。 改めてcheckovとは、クラウドの設定ミスや脆弱性をビルド時に検出し、インフラストラクチャコード、コンテナイメージ、オープンソースパッケージの問題を事前に防ぐオープンソースの静的解析ツールです。

checkovに定義されたルール(例: CKV_AWS_53)に照らし合わせてスキャンすることで、コンプライアンスのチェックや脆弱性の検出を行うことができます。

S3バケットを作成するサンプルコードに対して検証しました。

resource "aws_s3_bucket" "sample_bucket" {
  bucket = "sample-bucket"
}

# パブリックアクセスブロックなし
# バケット暗号化なし
resource "aws_s3_bucket_public_access_block" "sample_bucket_public_access_block" {
  bucket = aws_s3_bucket.sample_bucket.id
  block_public_acls       = false
  block_public_policy     = false
  ignore_public_acls      = false
  restrict_public_buckets = false
}

AWS Terraform MCP Serverを用いて、checkovスキャンを行ってください。」 出力結果

出力結果に、S3バケットでパブリックACLのブロックが有効になっていることを確認してください。とある通り、想定していたパブリックアクセスブロックや暗号化が設定されていないことを指摘してくれました。

次にEC2のセキュリティグループを作成するサンプルコードに対して検証しました。

# EC2インスタンス - セキュリティグループの問題
resource "aws_security_group" "vulnerable_sg" {
  name_prefix = "vulnerable-sg"
  description = "Vulnerable security group for testing"

  # 全てのIPからSSHアクセス許可
  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  # 全てのIPからHTTPアクセス許可
  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  # 全てのポートへのアウトバウンド許可
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

AWS Terraform MCP Serverを用いて、checkovスキャンを行ってください。」 出力結果 こちらも、想定していたセキュリティリスクを指摘してくれました。 セキュリティグループがEC2インスタンスに関連付けられていないことや、descriptionがないことまでも検出してくれています。

こちらの機能を使ってみた所感としては、特にTerraformを始めたばかりの方におすすめだと感じました。
私自身もTerraformを使い始めた頃、S3のパブリックアクセスを無効にする重要性が理解できなかったり、EC2のセキュリティグループの設定が不十分だったりして、脆弱性のあるアーキテクチャを組んでしまった経験があります。
そのような場合でも、コミットごとやリソース作成後にCheckovスキャンを行うことで、セキュリティを意識した開発が実践できるようになると思います。

Terraformレジストリモジュール分析

次に、Terraformレジストリモジュール分析の機能を使ってみたいと思います。 この機能では、利用したいモジュールのURLや識別子を指定するだけで、その使い方や必要な設定(入出力変数)、内部構造までを瞬時に分析してくれます。

「Terraform レジストリからS3モジュールの使い方を教えてください」

出力結果 出力結果 出力結果

コードを出力する前に、内部ではセキュリティやベストプラクティスに沿った回答をするようなワークフローがあるみたいですね。

ステップ1: Terraform開発ワークフローの確認
.
.
ステップ2: AWSベストプラクティスの確認
.
.
ステップ3: モジュールの基本構造

基本的な使用方法、入力変数や参考ソースなどセキュリティの観点やベストプラクティスに沿った雛形コードを生成してくれるため、モジュール利用の最初の一歩として非常に便利だと感じました。

また、プロジェクトに導入したり、モジュール戦略に移行する際も、この機能を使えばモジュールの使い方が分からなくてもスムーズに開発を進められると思いました。雛形コードや入力例を参考にしながら実装できるので、効率よくベストプラクティスに沿った開発ができます。

7. コードの生成

最後に、コードの生成を任せると、どこまでやってくれるのか気になったので試してみました。

AWS Terraform MCPを使用し、S3バケットを作成してください」 出力結果

シンプルに、s3バケットのみを提案してくれました。関連する設定やセキュリティを意識したコードを提案してくれると思っていたので、正直物足りなさを感じました。

またここで使われているawscc は、AWS Cloud Control APIを利用する公式のTerraform プロバイダーで、最新のリソース定義に対応しています。 そのため今回の例では、awscc_s3_bucketを使った最新の書き方でS3 バケットを生成してくれていました。 ただ、こちらは比較的新しいプロバイダーのようで、まだ未対応のリソースも多く、現時点では使いこなすのが難しい印象でした。

参考:

AWS Terraform MCPを使用せず、S3バケットを作成してください」 出力結果 こちらはバージョニングやパブリックアクセス設定など柔軟に提案してくれました。 AWS Terraform MCPを使った場合も、これくらい包括的なコードを提案してほしかった、というのが正直な感想です。

8. 終わりに

いかがでしたでしょうか。

使ってみた所感としては、コミット前やプッシュ前に静的解析やベストプラクティスを確認し、コードやアーキテクチャをブラッシュアップする用途で特に力を発揮するのではと感じました。

コード生成の機能については、一度に必要なコードを全て揃えてくれるというよりは、ドキュメントを参照しながら、まずは最小限のリソースを提案してくれるという印象でした。そのため開発速度の向上というよりも、信頼性のあるコードを生成するための補助ツールとして活用するのが効果的だと思います。

【AI駆動開発】GitHub Copilotだけでやり切るAgentic(Vibe)Coding

目次

はじめに

こんにちは。フォースタートアップス株式会社エンジニアの野尻(@jsotakebmx)です。ヒューマンキャピタル支援システム(社内プロダクト)の開発を担当しています。

現在、AIツールが全く利用されていない開発組織はほぼ無いと言っていいほど、AIはエンジニアにとって身近な存在になりました。しかし、導入されているAIツールは以下の様に組織によって様々ですよね。

  • AI先進企業DevinClaude Codeのような最新のAIエージェントや、複数のAIチャットツールを自由に使いこなしている。GitHub Copilot Enterpriseが導入されている。
  • AI導入企業ChatGPTGeminiなど、特定のAIチャットとGitHub Copilot Business(もしくはEnterprise)が導入されている。
  • AI導入中企業::申請ベースで最低限のAIチャットツールとGitHub Copilot Businessが利用できる。
  • AI未導入企業:全くAIツールが導入されていない。

バズるテックブログやSNSの投稿を見ているとほとんどの組織がAI先進企業であるように錯覚しますが、実際のところは多くの組織がAI導入企業に当てはまり、あくまで体感ですがGitHub Copilotが標準的なツールとして導入されているのではないでしょうか。

最新のDevinやClaude Codeのような新興AIエージェントの(進化の早いAI界隈ではDevinなど新興ではないのかもしれないですがw)活用事例を目にするたびに、こう感じているエンジニアも少なくないはずです。

「すごいな… でも、うちの会社では高度なAIエージェントは使えないし、自分には関係ないか…」

いや、諦めるのはまだ早いかもしれません!

未だGitHub Copilotのイメージは「高機能なコード補完ツール」で止まっている人もいるのではないでしょうか。しかし実際にはGitHub Copilotのポテンシャルはもっと先にあります。

この記事では、多くの開発現場で再利用可能なGitHub Copilotを最大限に活用し、自律的なAIエージェントのように振る舞わせる「AI駆動開発」の実践方法についてご紹介します。

AI駆動開発の3つのレベル

まず前提としてAIによるコーディングスタイルは、大きく3つのレベルに分類できます。

  1. コーディングサポート
    • コードの補完や簡単なスニペット生成など、最も基本的なスタイル。
  2. Vibe Coding
    • 「いい感じにやっといて」といった抽象的な指示に対してAIがコーディングを進める。人間は細かいフィードバックを与えながらゴールを目指すスタイル。
  3. Agentic Coding
    • ゴールを伝えることで、AIが自律的にタスクを分解・計画し一つずつ実装を進めていくスタイル。

Vibe CodingAgentic Codingの違いや詳細な説明については、arXiv論文の「Vibe Coding vs. Agentic Coding: Fundamentals and Practical Implications of Agentic AI」を一度読んでみることをお勧めします

arxiv.org

多くのテックブログやSNSではClaude CodeやGemini CliなどがAgentic Codingの代表例として紹介されています。そのため、「GitHub Copilotでは物足りない」と相対的に感じてしまっている方も多いのではないでしょうか。

しかし、私は「GitHub Copilotでも工夫次第でAgentic Codingに近い開発体験が可能」だと考えています。

GitHub Copilotを"最強のAgent"にする4つの工夫

GitHub Copilotを単なる補完ツールから開発エージェントへと昇格させるためには、いくつかの重要な機能を使いこなす必要があります。

3つのモードを意識的に使い分ける

Copilotには大きく3つのモードがあります。これらを状況に応じて使い分けることが全ての基本です。

モード 機能 主な用途
💬 Ask AIチャット 既存コードのロジック解明、仕様に関する壁打ち、アイデア出し
📝 Edit 選択範囲内のコード編集 機能追加、修正、リファクタリング、テストコード生成
🤖 Agent 自律的な開発エージェント 新機能開発複数ファイルにまたがる大規模なリファクタリング

特にAgentモードは、Copilotが自律的に思考し、複数のファイルにまたがる変更を行う際にはメインで利用することになります。

instructionsを分割・活用する

プロジェクトのコーディング規約やアーキテクチャといった"お作法"をCopilotに教えるためのファイルが.github/copilot-instructions.mdです。

重要なのは、ドメインごとにファイルを分割して適用範囲を限定することです。これにより、コンテキストに応じたより正確な指示が可能になります。

記述例: (.github/instructions/backend.instructions.md)

---
# この指示はバックエンド関連のファイルにのみ適用する
applyTo: "src/backend/**/*.ts, src/trpc/**/*.ts" 
---
# バックエンドアーキテクチャ・実装ガイド

## 概要
当プロジェクトのバックエンドは三層アーキテクチャを採用しています。
Presentation層、Application層、Infrastructure層の責務を厳密に守ってください。

## 実装ルール
- 新しいエンドポイントを追加する際は、必ずXXXのルールに従うこと。
- ...
etc...

promptで定型作業を効率化する

テストコードのテンプレート生成や、Pull Requestに記載するE2Eテスト項目のリストアップなど、繰り返し行う指示はカスタムプロンプトとして登録しましょう。

/.github/prompts/* ディレクトリに .prompt.md 形式でファイルを作成し、チャットでスラッシュコマンドで入力することで登録したプロンプトを簡単に呼び出せます。

例えば、テストコードの生成において、ただ「テストを書いて」と依頼するだけでは品質にばらつきが出がちになってしまうので、以下のようなプロンプトファイルを作成しています。

ファイルパス例:/.github/prompts/unit-test.prompt.md

# Testing Rules

## 基本要件

- **テストフレームワーク**: Vitest + React Testing Library
- **言語**: TypeScript
- **テストケース命名**: 日本語
- **import文**: vitestのメソッド(test, expect等)は不要

## テストパターン

以下のテストケースを含めてください:

- **正常ケース**: 期待される動作の検証
- **異常ケース**: エラーハンドリングの検証
- **エッジケース**: 境界値・極端な入力の検証
- **UI動作**: 表示・非表示、ユーザーインタラクション
- **非同期処理**: ローディング、APIレスポンス

## ベストプラクティス

- Testing Libraryのメソッド優先(`getByRole`等)
- 外部依存はモック化
- `fireEvent`でのイベントテスト
- `beforeEach`/`afterEach`で共通処理をまとめる

## テストファイル配置
- src/components/Button/index.tsx
- src/tests/components/Button/index.test.tsx

後はチャット内で「このコンポーネントのテストコードを作成してください」のような通常のプロンプトの先頭に /unit-test とスラッシュコマンドを入力するだけで、チームで一貫した品質のテストコードを生成することが可能になります。

ナレッジの自己蓄積と育成

AIは一度の対話で教えたことを永続的に覚えてはくれません。そのため、私のチームでは対話を通じて得られた学びをGitHub Copilot自身に記録させるために、copilot-instructions.mdに以下のようなルールを記述しています。

## ナレッジの記録
- セッションを通じて学んだことは、「.agent-doc/knowledge」配下のマークダウンファイルに記録してください。
- 記録は重要なステップであるため、私たちの確認を待たずにあなたの判断で記録してください。
- 「何をしたか」よりも「なぜそう判断したか(思考のプロセス)」を最も重要視して書いてください。
- 私たちからの指示と、あなた自身の行動の差分から、今後の開発で気をつけるべき点を記録してください。

このプロセスを各セッションごとに繰り返すことでプロジェクト固有の知識を蓄積することが実用的なエージェントへ成長させるための鍵となります。

ただ都度ナレッジ化させるわけですので、内容が重複したり情報が古くなったりがよくあります。定期的に整備しましょう。 場合によってはpromptファイルへ昇格させるのもかなり有効な手段だと思います。

旧システム移行プロジェクトでの実践例

私が所属しているチームでは、Rails + Vue.js on AWS(ECS)で構築された社内システムをNext.js on Salesforceへ移行しています。

この移行における最大の壁は主に以下の2点です。

  1. データ構造の根本的な変化
    • RDB (MySQL) からSalesforceオブジェクトへの変更に伴い、データ構造や型、リレーションの考え方が大きく異なります。また、SQLとSOQLの差分も吸収しなくてはなりません。
  2. 複雑な既存ロジックの把握
    • 移行元のRailsアプリケーションの各APIの実装にはテキストベースの設計書はほとんど存在しておらず、またbefore_actionafter_saveといったコールバックが複雑に実装されていることで、APIリクエストの裏側で何が起きているのかコードを追うだけでは実装の詳細を把握するのが非常に困難でした。

このような複雑な移行タスクは、まさにClaude Codeのような高度なAIエージェントが得意とする領域かもしれませんが、彼らはまだ私たちのチームには参画していません。とはいえGitHub Copilotという古株の強力な味方がいるので工夫して現代の働き方をトレースしてあげましょう。

人間が司令塔となる擬似Agentic Coding

Agentic Codingの核心は、目的(ゴール)を達成するために、AIが自律的にタスクを分解し順序立てて実行していく点にあります。

この「タスクを分解する」というAIエージェントにおいて最も重要なプロセスを人間が肩代わりします。そして、分解された個別のタスクの実行をCopilotに任せることで、擬似的なAgentic Codingを実現します。

今回の目的は、「Railsで実装された〇〇 APIをNext.jsへ完全に移行する」ことです。 以下でそのために実行した具体的なステップを紹介します。

Step 1: Askモードで既存APIを設計書化する

Askモードを使い、対象のRails APIに関連するコードを全てコンテキストとして与え、「登録APIの一連の処理を仕様書としてまとめてください。データフローや条件などについても詳しく説明してください。Markdownファイルに書き出してください」の様に指示します。これにより、複雑なコールバックを含めたロジックをドキュメント化させます。もちろん、生成された内容が正しいかは人間が厳密に精査しましょう。(当該APIで再度同じ作業をしなくて良いように生成したAPI設計書もGitで管理できるとベストですね)

Step 2: Agentモードで設計と実装のタスクを実行させる

仕様が明確になったところでやっとこさAgentモードの出番です。Copilotの出力品質は、当然私たちが与えるコンテキストの質に大きく左右されます。

この品質をもう一歩進めるのにADR (Architecture Decision Records)も有効です。所属チームでは重要な技術的決定事項を記録したADRGitHub Discussionsで管理しており、GitHub MCPリポジトリ内のこれらの議論を参照させています。(このADR活用法については、以前執筆したこちらのテックブログで詳しく紹介していますので、ぜひご覧ください。)

tech.forstartups.com

単純な型情報の比較だけでは不十分です。ドメインとの関連性、Salesforceへの移管となった技術的背景、MySQLSalesforceオブジェクトのN:N関連の表現方法など、豊富なコンテキストを事前に与えることが重要になります。

そのために「Salesforceのデータモデルに関するADRを参照し、その決定背景を考慮した上でスキーマの差分を分析してください」といった形で指示することでCopilotはコードや型定義だけでなく、「なぜそうなったのか」という設計思想まで理解した上で、精度の高い分析レポートを作成してくれます。この分析結果は、後の工程で何度も参照するため、ナレッジとして蓄積しておきましょう。

  • Next.js用のAPI設計書を作成させる

Step1で生成したRailsAPI仕様と、先ほど分析したスキーマ差分をインプットとして、「これらの情報に基づき、Next.js用のAPI設計書をマークダウンで作成してください」の様に指示します。生成された設計書に対しては、人間がレビューとフィードバックを繰り返し、完成度を高めていきます。

  • Agentモードで設計と実装のタスクを実行させる

後は、最終的にFIXした設計書をもとに「この設計書と関連するADRの規約に従って、APIの実装とテストコードを作成してください」と指示するだけです。ここでも必ず生成されたコードに対して人間がフィードバックを行い品質は担保しましょう。

成果と考察

この一連のプロセスを経て実装した「+300, -160」行ほどの変更量のAPIを特に不具合なくリリースすることができました。

「いや、そのプロセスを一々やるのが手間だからClaude Code使ってるんやが...」という声が聞こえてきそうです。しかしよくよく考えるとたとえClaude Codeを使ったとしても、生成されたタスクリストや設計書、そして最終的なコードをレビューなしで承認する(auto approve)ことはほとんど無いのではないでしょうか。

結局のところ、各タスクの節目で人間がレビューし、次のステップに進む許可を出すという本質的なプロセスは、どのツールを使っても変わらないのです。

GitHub Copilotを使って紹介したプロセスを踏むことで、その「節目」を人間が意図的に作り出し、ADRのようなアーキテクチャ情報を与えてAIを正しく導くことができます。 それにより高度(トレンド)なAIエージェントを使って高品質な成果を得ることができると考えています。

ちなみに先月はここ半年で一番Copilotを駆使したつもりでしたが、プレミアムリクエスト70~80%くらいの消費で収まっていました。 みなさん超えた人いますか?いたらどんな使い方したら超えたのか何卒教えていただけますと幸いです🙏