DevinとClaude Code ActionsでAI駆動開発を実践しよう

目次

• • 導入
  • 結論ファースト
  • 開発用AIエージェントの現状整理
  • 作成したワークフローの解説
    • Devinにレビューさせる
    • Claude Code Actionsに実装させる
    • Claude Code Actionsにレビューさせる
  • Devinとは
  • Devinの設定
  • Claude Code Actionsとは
  • Claude Code Actionsの設定
  • Devin vs Claude Code Actions
  • タスクの実行と評価
    • タスク1
    • タスク2
    • その他のタスク
    • よかった点
    • 課題
  • 考察
    • 実装上のメリット
    • レビューに関するメリット
    • 興味深い現象
    • コスト
  • 今後の展望

導入

こんにちは。グループ研究開発本部 次世代システム研究室のH.Oです。
今回は、私の所属するプロジェクトに、開発用AIエージェントを導入し、運用を開始した事例について紹介します。昨今のトレンドであるAIエージェントツールの目覚ましい発展は、Webアプリケーション開発に携わるエンジニアの業務や未来を大きく変えようとしています。一般的な言説として、AIエージェントが進化していったらやがて人間のエンジニアは不要になる、という意見が聞かれますが、私はAIエージェントを使いこなせるエンジニアが残っていくのだ、と考えています。AIエージェントを使いこなせる次世代のエンジニアとなるためにはまず何をすべきなのでしょうか。

その答えはAI駆動開発であると考えます。AI駆動開発とはソフトウェア開発の様々な工程にAI技術を活用し、コーディングだけでなく開発プロセス全体を最適化する手法です。

このような背景から、私の所属するプロジェクトでも、開発手法をAI駆動開発に切り替える試みを開始しました。今回は、その第一歩として実装とレビューの工程に対して、行った施作についてご紹介します。

結論ファースト

・これからのエンジニアはAI駆動開発！
・まずは、開発とレビューについて切り替えを始めました。DevinとClaude Code Actionsを両方導入し、それぞれに実装とレビューをさせています。

作成した開発フローがこちらです。

開発用AIエージェントの現状整理

一口に開発用AIエージェントを使おうといっても、実際に調べてみると非常に多くのツールがあり、検討が難しくなっているのが現状です。今回私はDevinとClaude Code Actionsというツールを選択しました。まず初めになぜこの選択に至ったのかという背景を説明します。

まず、開発用AIエージェントは大きく次の三つに分けられます。

1. IDE型
2. CLI型
3. 自律型

IDE型の代表例はCursorで、他にはCline、Roo CodeやWindsurfなどがあります。いずれも統合開発環境内で動作するAIエージェントです。VS Codeをフォークしているものが多いです。CLI型はClaude Codeなどが代表でコマンドラインインターフェースに基づくAIエージェントです。自律型はDevinが代表格ですが、直接的な人間の介入なしに独立して動作する完全にタスクを任せてしまうことのできるAIエージェントです。まずはこの三つのタイプのうちどれを使うかを考えます。

結論、私は自律型を選択すべきと考えています。

自律型のAIエージェントは自然言語の指示文をもとにして、タスク分解、実装、テストを自動的に行う唯一のツールです。また、独自の仮想環境を持っていることが多く、shell commandを実行したり、build、testを実行させたりできるなど、他のツールと比べてできることが広がります。

一方でCLI型、IDE型は自律型と異なり、基本的に「作業をするのは人間だ」という前提があります。CursorやClaude Code、Codexなどのツールは、基本的に人間の作業を高速化することに役立つ側面が強いです。そのため、私は自律型AIエージェントのアウトプットに対して仕上げをする時などに補助的に使用していて、サブのツールとして位置付けています。

（※実際にはCursorのAgent Modeなど、IDE型ツールの中に一部自律的な機能が含まれていたりする例もあり、きれいに3つに分類できるというわけではありません。ただしここでは実用上の便宜に配慮して、結論に影響を与えないレベルの細かい議論を端折るために単純化して説明しています。）

したがって、いかに自律型AIエージェントに上手に仕事をさせるかというところにポイント集中すべきと考えます。

次に自律型AIエージェントのうちどれを使うか、を比較して選んでいきます。Devinは最も色々な作業を任せられるポテンシャルがあります。Github repositoryでコードを管理している全てのプロジェクトで導入可能です。Claude Code Actionsは後ほど説明しますように、コード実装の能力が高いモデルであるClaude 4シリーズを使うことができる、実質的に自立型AIエージェントの特徴を持っているツールです。こちらもgithubで完結する機能になっています。その他のツールにはv0やJulesなど色々あるのですが、それぞれのツールで技術的制約、回数制限等がある関係で、プロジェクトには導入できないと判断しました。

以上の検討を経た結果、天秤AIではDevinとClaude Code Actionsを使っていくことにしました。

作成したワークフローの解説

今回作成したのは以下の3つのworkflowです。

1. Devinにレビューをさせるワークフロー
2. Claude Code Actionsに実装させるワークフロー
3. Claude Code Actionsにレビューをさせるワークフロー

Devinにレビューさせる

まず、Devinによる自動レビューについて説明します。
このワークフローは、PRが作成・更新されたタイミングで実行されます。
最初にGithub Action RunnerからGitHubのAPIを叩いて、「このPRでどのファイルが変更されたか」を取得します。次に、取得したPR fileとあらかじめ設定したレビュープロンプトをinputとして、Devin APIを叩き、Devinにレビューさせます。最後にレビューコメントを投稿するときには、GitHubの gh api コマンドを使って、Github APIを叩き返すことで対象のコード行にピンポイントでコメントを付けるよう指示しています。

Claude Code Actionsに実装させる

こちらは、Issue／PR コメントや Issue 本文に @claude が書かれるとそれをトリガーとしてワークフローが起動します。Actions Runnerの中には、Anthropic公式がリリースしている claude-code-actionsというSDKがいて、これがClaude Sonnet-4 モデル呼び出して、Issueやコメントの内容に基づいてコードの解析・実行、コード修正、Issue コメント返信などを自動で行います。

Claude Code Actionsにレビューさせる

最後にClaudeに自動的にレビューさせるワーフクローです。こちらは先ほどの実装用のワークフローとは違ってPRを作成、pushしたのをトリガーとします。それ以外はほぼ同じ設定をしています。

Devinとは

Devinとは、米国のAIスタートアップCognitionが開発した自律型AIソフトウェアエンジニアです。コーディングをサポートしてくれるだけでなく、バグの修正から実装に至るまで、開発プロセス全体をエンドツーエンドで自律的に処理する能力を持っていて、プロンプトを入力するだけで、完全に実装タスクをお任せできるようなツールになっています。

Devinの設定

はじめに、使用するgithub上の各repositoryをDevinと連携します。その後、基本的なbuild, test用コマンドを設定していきます。（公式Documentに設定の仕方が記載されています。）次にDevinのKnowledgeという機能を使います。こちらは、Devinがタスクを行う際に参照することができる情報をテキストベースで記述し、貯めることができる機能です。ここにローカル環境構築用のコマンドや手順、各レポジトリの概要とコーディング規則、セッションを立ち上げる際に必ずしてほしい挙動などをあらかじめ記載して登録しました。そして、普段ローカルで行っている環境構築をDevinが自分でできるか確認をして基本的な準備が終わります。

今回、独自に工夫した点として、セッションスタート時のルールでDevinが自動的にPRを作成しないように指示しています。DevinはデフォルトではPRを自動的に作成してくれます。しかしこの機能を使うと自動レビューのワークフローを起動するときに問題が生じます。実はgithub側の仕様が原因となってDevinが自動的にPRを作成したことをトリガーとして、自動レビューのworkflowを実行させることができません。（これはworkflowが無限に連鎖して実行されることを防ぐための仕様と考えられます。）そのため、DevinがPRを作るときにはレビューのワークフローが動作しないという問題がありました。人間がPRを作成するという手間はかかるのですが、自動的にレビューが動くメリットを優先してあえてPRを作成させないようにしました。

次にDevin API keyを取得して、githubのsecretに登録します。
最後にworkflowのyml fileを作成します。workflowの内容は、Devinの開発元であるCognition AIのBlogで公開されているものを使いました。この自動レビューworkflowはDevinの開発にも使用されているようです。今回は開発チームのメンバーがレビューコメントを読みやすいよう、プロンプトに、レビューコメントを日本語・英語・ベトナム語の3カ国語で書くように記述を追加しました。

Cognition AIのBlog記事

YAML fileの記載内容はこちら↓

name: Automated PR Review By Devin

on:
  pull_request:
    types: [opened, synchronize, reopened]

permissions:
  contents: read
  pull-requests: write
  issues: read

jobs:
  devin-review-pr:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Get PR files
        id: pr-files
        run: |
          FILES=$(curl -s -H "Authorization: token ${{ secrets.GITHUB_TOKEN }}" \
            "https://api.github.com/repos/${{ github.repository }}/pulls/${{ github.event.pull_request.number }}/files" | \
            jq -r '[.[].filename] | @json')
          if [ -z "$FILES" ] || [ "$FILES" = "null" ] || [ "$FILES" = "[]" ]; then
            echo "Error: Failed to fetch or parse PR files."
            exit 1
          fi
          echo "files=$FILES" >> $GITHUB_OUTPUT
      - name: Create Devin Review Session
        id: devin-review
        env:
          DEVIN_API_KEY: ${{ secrets.DEVIN_API_KEY }}
          FILES_TO_REVIEW: ${{ steps.pr-files.outputs.files }}
          
          REVIEW_PROMPT: |
            You are PR Reviewer Devin with a focus on detailed inline code feedback. Your tasks:
            1. Clone the repository ${{ github.repository }} locally.
            2. Next, set up a pre-push Git hook that prevents any pushes from a user with the username "Devin AI" OR an email containing "devin-ai-integration" as a substring. Activate the hook.
            3. View the diffs of the changed files for PR #${{ github.event.pull_request.number }} in repository ${{ github.repository }}.
            4. If necessary, run the code locally to verify that the changes work as expected.
            5. Read the PR discussion to see what previous comments and suggestions have been made.
            6. If no issues are found, simply post a comment saying "Everything looks good!" and stop here. Your work is done.
            7. Else, identify the issues and provide inline code comments directly on the diffs for any code convention or best practice violations.
            8. Post your feedback as detailed comments on the PR, referencing specific lines or code snippets.
            Rules and Guidelines:
            1. NEVER make any commits or pushes to the repository - you are ONLY allowed to review code and leave comments
            2. Do not make more than three total comments on the PR.
            3. Use inline feedback where possible with specific line references
            4. Include code snippets in markdown format when discussing issues
            5. Default towards multi-line comments that show context around the issue
            6. Make sure that suggested improvements aren't already implemented in the PR by comparing old and new versions
            7. Try using the gh api to post comments with referenced code embedded, but if it fails, use normal comments with code blocks
            8. Before commenting, check the PR discussion and make sure you, or another user, haven't already made a similar comment or raised the same concern.
            9. Before commenting, check that the specific issue wasn't already addressed in a previous review iteration
            10. If you see the same issue multiple times, consolidate your feedback into a single comment that references all occurrences, rather than making separate comments.
            11. Refer back to these rules and guidelines before you make comments.
            12. Never ask for user confirmation. Never wait for user messages.
            13. Write review comments in English, Japanese, and Vietnamese.

            How to post comments with code embedded:
                1. Create JSON file for each comment you want to post.
                Example 1: 
                    {
                        "body": "Security Issue: Hardcoded API key. Recommendation: Use environment variables",
                        "commit_id": "954...12312",
                        "path": "file.py",
                        "line": 11,
                        "side": "RIGHT"
                }
                Example 2:
                {
                "body": "Multiple issues found:\n1. Hardcoded API key should be in environment variables\n2. Inconsistent class naming (userAccount vs Product)\n3. Inconsistent parameter casing (Password vs username)\n4. Missing docstrings and type hints\n5. Inconsistent spacing around operators",
                "commit_id": "323......87686",
                "path": "code.py",
                "start_line": 11,
                "start_side": "RIGHT",
                "line": 25,
                "side": "RIGHT"
                }
                body: The text of the review comment. Include markdown code blocks for snippets
                commit_id: SHA of the commit you're reviewing. Not using the latest commit SHA may render your comment outdated if a subsequent commit modifies the line you specify as the position.
                path: Relative file path in repo
                line (integer): Specifies the exact line in the pull request's diff view to which your comment should attach. Required unless using subject_type:file. The line of the blob in the pull request diff that the comment applies to. For a multi-line comment, the last line of the range that your comment applies to.
                side: In a split diff view, the side of the diff that the pull request's changes appear on. Can be LEFT or RIGHT. Use LEFT for deletions that appear in red. Use RIGHT for additions that appear in green or unchanged lines that appear in white and are shown for context. For a multi-line comment, side represents whether the last line of the comment range is a deletion or addition.
                subject_type: The level at which the comment is targeted. Either "line" or "file". Use "line" for inline comments. Use "file" for file-level comments.
                start_line (integer): Required when using multi-line comments unless using in_reply_to. The start_line is the first line in the pull request diff that your multi-line comment applies to.
                start_side: Required when using multi-line comments unless using in_reply_to. The start_side is the starting side of the diff that the comment applies to. Can be LEFT or RIGHT. 
                A pull request diff may not match the original file's absolute line numbering. That is, if the PR contains additions or deletions before the line you’re commenting on, the line indices shown in the “Files changed” tab can shift from the original file’s line numbers.
                For example: In the pre-PR state, line 231 might refer to a completely different section of code than line 231 in the post-PR diff (because code added or removed above it shifts everything down or up).
                Therefore, you must use the line numbers as shown in the PR diff rather than the original file's line numbers.
                If you have issues, visit the docs: https://docs.github.com/en/rest/pulls/comments?apiVersion=2022-11-28#create-a-review-comment-for-a-pull-request
                2. Use gh api command.
                            gh api \\
                --method POST \\
                -H "Accept: application/vnd.github+json" \\
                /repos/owner/repo/pulls/4/comments \\
                --input comment.json
                
                owner: the account owner of the repository. The name is not case sensitive.
                repo: The name of the repository without the .git extension. The name is not case sensitive.
                pull number: The number of the pull request.
                
            Changed files to review:
            ${{ steps.pr-files.outputs.files }}
        run: |
          # Convert multiline string to JSON-safe format
          ESCAPED_PROMPT=$(echo "$REVIEW_PROMPT" | jq -Rs .)
          RESPONSE=$(curl -s -X POST \
            -H "Authorization: Bearer $DEVIN_API_KEY" \
            -H "Content-Type: application/json" \
            -d "{\"prompt\": $ESCAPED_PROMPT}" \
            "https://api.devin.ai/v1/sessions")
          # Check for errors in the response
          ERROR_MSG=$(echo "$RESPONSE" | jq -r '.detail')
          if [ "$ERROR_MSG" != "null" ]; then
            echo "Error creating Devin session: $ERROR_MSG"
            exit 1
          fi
          SESSION_ID=$(echo "$RESPONSE" | jq -r '.session_id')
          SESSION_URL=$(echo "$RESPONSE" | jq -r '.url')
          if [ -z "$SESSION_ID" ] || [ -z "$SESSION_URL" ]; then
            echo "Error: Devin session details are missing from the response."
            exit 1
          fi
          echo "session-id=$SESSION_ID" >> $GITHUB_OUTPUT
          echo "session-url=$SESSION_URL" >> $GITHUB_OUTPUT
          echo "Devin session created successfully: $RESPONSE"

Claude Code Actionsとは

Claude Code Actionsがどのようなツールであるかを一言で表すと、Claude Code IN Github Actionsと言えます。Claude Code自体はCLI型のツールですが、これをGithub Actionsの中で実行させることができる機能があります。プロンプトを送信して、Github Actionsを回し、その中でClaude Codeを実行させてコード生成などができることになるので、実質的に自律型AIエージェントと同じ能力を備えたツールになるのです。PRや課題で@claudeとメンションするだけで、簡単にIssueの実装、Bug修正、レビューをすることができます。また、Claude Code Actionsではコーディングに強いClaude 4 seriesのモデルを使えます。コードベースの読み込み方式はPromptに基づいて関連するfileをその都度grepで検索するこということをやっていて、GithubのRepositoryを連携してコードベース全体を読み込むdevinとは対照的なアプローチになっています。
Claude Code Actionsはgithub actions外へのアクセスがdefaultではできません。そのため、Web検索機能など、github actionsの外部の環境にアクセスするためには、workflowの中でmcpを設定する必要ががあります。また、Defaultではいかなるシェルコマンドも実行することができません。BashやNPMなど、実行させたいコマンドがある場合は全てworkflowに記載しておく必要があります。基本的にClaude Codeはこのようにアクセスを厳しく管理することで強固なセキュリティを担保しているツールです。

Claude Code Actionsの設定

今回はこちらの手動でのセットアップという方法をとっています。
GithubにClaude GitHubアプリをインストールしてリポジトリに追加します。
また、プロジェクトルートにCLAUDE.mdというファイルをおくと、DevinのKnowledgeのような役割を果たし、実装の際に参照されるコンテキストを置けます。ここにプロジェクトの概要・ルール等を記載します。
続いて、Github Actionsのworkflowを記載します。モデルはdefaultにClaude Opus 4に設定されていますが、コストを鑑みて、今回はClaude Sonnet 4を使用します。今回、actionsの処理中にコマンドが実行できるようbash, grep, npmツールの使用を許可しました。また、公式が推奨している、思考の整理をするためのsequentialThinkingというMCPと、最新の技術ドキュメントが読み込めるcontext7というMCPを設定しました。詳細は公式の発表しているexample directoryを参考にしました。

YAML fileの記載内容はこちら↓

name: Claude Assistant

permissions:
  contents: write
  pull-requests: write
  issues: write
  id-token: write  

on:
  issue_comment:
    types: [created]
  pull_request_review_comment:
    types: [created]
  issues:
    types: [opened, assigned]

jobs:
  claude-assistant:
    if: |
      (github.event_name == 'issue_comment' && contains(github.event.comment.body, '@claude')) ||
      (github.event_name == 'pull_request_review_comment' && contains(github.event.comment.body, '@claude')) ||
      (github.event_name == 'issues' && contains(github.event.issue.body, '@claude'))
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Generate GitHub App token
        id: app-token
        uses: actions/create-github-app-token@v2
        with:
          app-id: ${{ secrets.APP_ID }}
          private-key: ${{ secrets.APP_PRIVATE_KEY }}

      - name: Authenticate to Google Cloud
        id: auth
        uses: google-github-actions/auth@v2
        with:
          workload_identity_provider: ${{ secrets.GCP_WORKLOAD_IDENTITY_PROVIDER }}
          service_account: ${{ secrets.GCP_SERVICE_ACCOUNT }}
      
      - uses: anthropics/claude-code-action@beta
        with:
          trigger_phrase: "@claude"
          timeout_minutes: "60"
          github_token: ${{ steps.app-token.outputs.token }}
          use_vertex: "true"
          model: 'claude-sonnet-4@20250514'
          mcp_config: |
            {
              "mcpServers": {
                "sequential-thinking": {
                  "command": "npx",
                  "args": [
                    "-y",
                    "@modelcontextprotocol/server-sequential-thinking"
                  ]
                },
                "Context7": {
                  "command": "npx",
                  "args": ["-y", "@upstash/context7-mcp"]
                }
              }
            }
          allowed_tools: "mcp__sequential-thinking__sequentialthinking,mcp__context7__resolve_library_id,mcp__context7__get_library_docs,Bash(npm:*),Read,View,GlobTool,GrepTool,BatchTool"
        env:
          ANTHROPIC_VERTEX_PROJECT_ID: ${{ steps.auth.outputs.project_id }}
          CLOUD_ML_REGION: us-east5

最後にレビュー用のworkflowです。こちらは実装用のworkflowと比べて、トリガーがPRの作成、pushであること、workflowにレビュー用のシステムプロンプトを書いていることが異なります。Claude 公式が出しているレビュー用のプロンプトは短く完結なものになっていますが、今回は条件を揃えるためにDevinと同じものを使いました。

YAML fileの記載内容はこちら↓

name: Claude Auto Review

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  auto-review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
      id-token: write
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4
        with:
          repository: ${{ github.event.pull_request.head.repo.full_name }}
          ref: ${{ github.event.pull_request.head.ref }}
          token: ${{ secrets.GITHUB_TOKEN }}
          fetch-depth: 1

      - name: Generate GitHub App token
        id: app-token
        uses: actions/create-github-app-token@v2
        with:
          app-id: ${{ secrets.APP_ID }}
          private-key: ${{ secrets.APP_PRIVATE_KEY }}

      - name: Authenticate to Google Cloud
        id: auth
        uses: google-github-actions/auth@v2
        with:
          workload_identity_provider: ${{ secrets.GCP_WORKLOAD_IDENTITY_PROVIDER }}
          service_account: ${{ secrets.GCP_SERVICE_ACCOUNT }}

      - name: Automatic PR Review
        uses: anthropics/claude-code-action@beta
        with:
          timeout_minutes: "60"
          github_token: ${{ steps.app-token.outputs.token }}
          use_vertex: "true"
          model: 'claude-sonnet-4@20250514'
          direct_prompt: |
            You are PR Reviewer Devin with a focus on detailed inline code feedback. Your tasks:
            1. Clone the repository ${{ github.repository }} locally.
            2. Next, set up a pre-push Git hook that prevents any pushes from a user with the username "Devin AI" OR an email containing "devin-ai-integration" as a substring. Activate the hook.
            3. View the diffs of the changed files for PR #${{ github.event.pull_request.number }} in repository ${{ github.repository }}.
            4. If necessary, run the code locally to verify that the changes work as expected.
            5. Read the PR discussion to see what previous comments and suggestions have been made.
            6. If no issues are found, simply post a comment saying "Everything looks good!" and stop here. Your work is done.
            7. Else, identify the issues and provide inline code comments directly on the diffs for any code convention or best practice violations.
            8. Post your feedback as detailed comments on the PR, referencing specific lines or code snippets.
            Rules and Guidelines:
            1. NEVER make any commits or pushes to the repository - you are ONLY allowed to review code and leave comments
            2. Do not make more than three total comments on the PR.
            3. Use inline feedback where possible with specific line references
            4. Include code snippets in markdown format when discussing issues
            5. Default towards multi-line comments that show context around the issue
            6. Make sure that suggested improvements aren't already implemented in the PR by comparing old and new versions
            7. Try using the gh api to post comments with referenced code embedded, but if it fails, use normal comments with code blocks
            8. Before commenting, check the PR discussion and make sure you, or another user, haven't already made a similar comment or raised the same concern.
            9. Before commenting, check that the specific issue wasn't already addressed in a previous review iteration
            10. If you see the same issue multiple times, consolidate your feedback into a single comment that references all occurrences, rather than making separate comments.
            11. Refer back to these rules and guidelines before you make comments.
            12. Never ask for user confirmation. Never wait for user messages.
            13. Write review comments in English, Japanese, and Vietnamese.

            How to post comments with code embedded:
                1. Create JSON file for each comment you want to post.
                Example 1: 
                    {
                        "body": "Security Issue: Hardcoded API key. Recommendation: Use environment variables",
                        "commit_id": "954...12312",
                        "path": "file.py",
                        "line": 11,
                        "side": "RIGHT"
                }
                Example 2:
                {
                "body": "Multiple issues found:\n1. Hardcoded API key should be in environment variables\n2. Inconsistent class naming (userAccount vs Product)\n3. Inconsistent parameter casing (Password vs username)\n4. Missing docstrings and type hints\n5. Inconsistent spacing around operators",
                "commit_id": "323......87686",
                "path": "code.py",
                "start_line": 11,
                "start_side": "RIGHT",
                "line": 25,
                "side": "RIGHT"
                }
                body: The text of the review comment. Include markdown code blocks for snippets
                commit_id: SHA of the commit you're reviewing. Not using the latest commit SHA may render your comment outdated if a subsequent commit modifies the line you specify as the position.
                path: Relative file path in repo
                line (integer): Specifies the exact line in the pull request's diff view to which your comment should attach. Required unless using subject_type:file. The line of the blob in the pull request diff that the comment applies to. For a multi-line comment, the last line of the range that your comment applies to.
                side: In a split diff view, the side of the diff that the pull request's changes appear on. Can be LEFT or RIGHT. Use LEFT for deletions that appear in red. Use RIGHT for additions that appear in green or unchanged lines that appear in white and are shown for context. For a multi-line comment, side represents whether the last line of the comment range is a deletion or addition.
                subject_type: The level at which the comment is targeted. Either "line" or "file". Use "line" for inline comments. Use "file" for file-level comments.
                start_line (integer): Required when using multi-line comments unless using in_reply_to. The start_line is the first line in the pull request diff that your multi-line comment applies to.
                start_side: Required when using multi-line comments unless using in_reply_to. The start_side is the starting side of the diff that the comment applies to. Can be LEFT or RIGHT. 
                A pull request diff may not match the original file's absolute line numbering. That is, if the PR contains additions or deletions before the line you’re commenting on, the line indices shown in the “Files changed” tab can shift from the original file’s line numbers.
                For example: In the pre-PR state, line 231 might refer to a completely different section of code than line 231 in the post-PR diff (because code added or removed above it shifts everything down or up).
                Therefore, you must use the line numbers as shown in the PR diff rather than the original file's line numbers.
                If you have issues, visit the docs: https://docs.github.com/en/rest/pulls/comments?apiVersion=2022-11-28#create-a-review-comment-for-a-pull-request
                2. Use gh api command.
                            gh api \\
                --method POST \\
                -H "Accept: application/vnd.github+json" \\
                /repos/owner/repo/pulls/4/comments \\
                --input comment.json
                
                owner: the account owner of the repository. The name is not case sensitive.
                repo: The name of the repository without the .git extension. The name is not case sensitive.
                pull number: The number of the pull request.
        env:
          ANTHROPIC_VERTEX_PROJECT_ID: ${{ steps.auth.outputs.project_id }}
          CLOUD_ML_REGION: us-east5

Devin vs Claude Code Actions

ここまでの振り返りとして、DevinとClaude Code Actionsという二つのツールを比較したいと思います。特に、Devinではできるが、Claude Code Actionsではできないことがいくつかあります。特に重要な挙動の違いとして、Claude Code ActionsはPRを自動的に作成することができません。作業ブランチを切って実装が完了すると、コメントにCREATE PRというリンクが出現しますこれを人間が踏むことによってPRを作成させる、という仕組みになっています。また、Claude Code Actionsはrepositoryに保存するactions用のyml fileを見て動かすものなので、clientとserverのスキーマを合わせるといった複数のrepositoryを連携させた実装はできません。

＜指示出し、ブランチ管理＞

＜実装とレビュー＞

DevinはClaude Code Actionsよりも柔軟にブランチ管理や開発をさせることができる一方で、レビューはClaude Code Actionsの方が簡単にやらせることができます。このように両方のツールで一長一短の特徴があることがわかります。これだけではどちらを使うのがより良いのか、が判断できないため、ひとまず両方で開発・レビューができるようにし、パフォーマンスを比較してみようと考えました。

タスクの実行と評価

今回は、次の3種類のタスクを検証しました。

1. OpenAIの新APIへ対応するための書き換え
2. 新しいAIモデルの追加
3. その他のタスク（おまけ）

それぞれ、定量・定性両面で評価しました。

タスク1　〜OpenAIのAPIをchat completion APIからResponses APIに書き換える〜

タスク1はOpenAIのAPIを旧版のchat completion apiから新版のresponses apiに書き換えるというタスクです。こちらは、最近リリースされたモデルを天秤AIに追加しようとした時、当該モデルがresponses APIにしか対応していないことがわかり、急遽書き換えが必要になったという経緯で発生したタスクです。このタスクのポイントは外部のDocumentを読みにいき、既存の実装と、responses APIの実装を比較して、parameterの設定を書き直す必要があることです。Devinへ与えた初期プロンプトとClaude Code ActionsのIssueに記載した内容は全く同じにしています。

await openai.chat.completion.create(...

await openai.responses.create(...

Claude Code Actionsを使用するにあたっては、commentを以下のように記載して実行しました。

定量評価

まず定量評価ですが、大きく差が出たのは実装時間です。Devinの実装に時間がかかってしまったのは、lint errorを直すのにDevinが苦戦を強いられていたため、それから同時に別のsessionが走っていたためと考えられます。その結果コストも高くつきました。Claude Code は非常に実装の時間が短く、そして安いことがわかります。

定性評価

続いて定性評価です。コードのクオリティは同程度でした。Devinはプロンプトで指定した外部のドキュメント以外の関連したページも見に行っている点が優秀な動きでした。今回のタスクでは、parameterの構造を書き換えた結果、新たにリファクタリングをした方が良いと判断したため、マージはできませんでした。そういった次の課題を見つけることはまだAIには難しいようです。

タスク2　〜新しいモデルを追加する〜

タスク2は天秤AIに新しいモデルを追加する、というタスクです。こちらは新しいモデルを各社がリリースするたびに頻発するタスクです。複数のrepositoryにまたがる実装を必要とし、変更範囲が広いです。特にmigration fileの作成、GraphQLのスキーマ更新がどのくらいできるのかが、重要な項目です。

Devinにはこちらの初期プロンプトを渡しました。

docker-compose exec metis-server sh
yarn generate-migrations src/migrations/add_gemini_flash_lite�```
After the file src/migrations/add_gemini_flash_lite is generated, open it and remove all code unrelated to adding AIConversationModel from both the up() and down() functions.
Once done, exit the container.


2. **Update ChatModel Enum**  
  - Add the same value to the `ChatModel` enum in #file:../../src/modules/ai_conversations/presenters/resolvers/ai_conversation.issue_execution_token.resolver.ts

3. **Map to API Service**  
  - Update the new `AIConversationModel` in its corresponding API service in #file:../../src/modules/ai_conversations/usecases/services/ai_conversations.chat.service.ts

4. **Update dailyChatTokenLimits**
  - In #file:../../src/modules/common/constants/daily_chat_token_limits.ts , update the `DailyModelGroupToAIModel`, `DailyAIModelToCostGroup` and `DailyExecutionCostByModel`.

5. **Update function call**
  - In #file:../../src/modules/common/function_call/generate_tool_definitions.ts , update `isModelOpenAI`, `isModelGemini`, `isModelAnthropic`, `isModelDeepSeek`, `isModelPerplexity`, and `isModelPlamo` functions to include the new model.
  
### Module-Specific Updates
#### `gemini`
1. **Update GeminiChatCompletionModel**  
  - In #file:../../src/modules/common/gemini/gemini.service.interface.ts , ask for the key and value of `GeminiChatCompletionModel` and append the new item to this constant.

2. **Update Gemini Service**
  - In #file:../../src/modules/common/gemini/gemini.service.ts , update new model to `getChatModel`. In `getChatModelLocation`, if new model is preview model, return the experimentalLocaltion else return localtion.

3. **Update Gemini Chat API Service**
  - In #file:../../src/modules/ai_conversations/infrastructures/gemini_chat_api.service.ts perform the following updates as a single task:
    1. **Model Mapping**: Map the new `AIConversationModel` value to `GeminiChatCompletionModel` in `getModel()`.
    2. **Model Name**: In `getModelName()`, ask for the value to return (explain that this field is used for saving the model name to the statistics table in the database).
    3. **Token Limit**: Return `100000` by default for the new `AIConversationModel` in `getInputTokenCountLimit()`.


#### Other Modules
- Don't do anything! No updates are required for other modules at this time.

### Notes
- Ensure all updates maintain consistency across files.
- Verify that the new `AIConversationModel` integrates seamlessly with the existing architecture.
- If additional clarification is needed, ask for specific details during the update process.


Oshiete-AI/metis-client 
# Add New Chat Model Prompt

This prompt is used when new chat models are added to the server side. Your goal is to ensure all related files are updated correctly.

---

## Steps to Follow

### 1. Fetch Latest Models
- Use the following command to fetch the latest models from the server side:
  ```bash
  yarn codegen

```typescript

    Gemini20FlashLite: {

	title: “[表示名] (Google)”

	description: [description]

	precision: [precision]

	credit: [credit]

	speed: [speed]

	alertTitle: undefined,

	alertDescription: undefined

	links: undefined

	isWebSearchSupported: [isWebSearchSupported]

     }

```

```typescript

    Gemin20FlashLite: ’[表示名] （消費: [個人:クレジット]）’ 

```

{text: [表示名], canWebSearch: [isWebSearchSupported]}

Claude Code Actionsにおいて、Issueに記載した内容はDevinのプロンプトと同じものですが、ClientとServerに分かれているので、分けて登録しています。

Claude Code ActionsのIssueにコメントした文章はこちらです。

定量評価

このタスクでは、Devinの中でDocker containerを立てる必要があります。それを完了させることができず、ハマってしまったことが原因でした。私がインストラクションを与えることで環境構築に成功しました。この時も別のsessionが走っていたためと考えられます。その結果コストも高くつきました。
相変わらず、Claude Code は非常に実装の時間が短く、そして安いことがわかります。

定性評価

続いて定性評価です。こちらのタスクではあべこべの結果が出ました。DevinはGrpahQLスキーマの更新に成功していましたが、migration fileは生成できず、Claude はその逆で、結果的に片方のレポジトリの手直しが必要でした。完全に引き分けです。

タスク3　〜その他のタスク〜

ここまで2つの大きなタスク以外にも、他に様々な種類のタスクをやらせてみました。
・1fileで収まったり数行程度など軽微なUIの修正
・バックエンドの1function単位のバグ修正やAPIの修正
などは双方とも問題ないできで、そのままマージすることも多いものでした。一方でCSSの修正については問題がありました。デザイナーの意図、既存の管理規則を無視したアウトプットが多く、逆に修正コストが上がってしまうという問題がありました。

よかった点

小さいタスクやプロンプトを作り込んだルーティンのタスクははマージ可能なクオリティが出るので、AIエージェントに今後も投げていけそうということがわかりました。
レビューについては、いくつかのケースにを除いて内容が的外れなレビューはそれほどありませんでした。特にバグはタイポなどの指摘は正確で、3ヶ国語のレビューが安定してできるという点で、手戻りが減り、レビューの回数や時間が確実に減ったと言えます。

課題

実装面では、Devinを複数人で同時に使うと遅くなることがあったり、エラーでハマったりすると人がテコ入れをしなければならないというケースが発生しました。
レビューでは、Devinがレビューする時に外部情報を読み取ってくれないので、その結果的外れなReviewをしてくるということが起きました。また、今回の差分以外のところで問題を解消しているケースなどで、実装の大まかな意図を理解してくれない場合があって、的外れなReviewが出てしまうことが起きました。

考察

ここまで両者のツールを比較してきましたが、長所・短所は概ね共通していて、Claudeは単一レポジトリの実装限定だが安定して速く、安い。Devinは複数レポジトリの連携などに強みがあり、難しめのタスクもできる、という特徴があって、正直甲乙つけ難いという印象でした。そこで、しばらく両方を回してみて考えたのですが、最終的にどちらかを選択するのではなく、両方残すのが良いだろうと判断しました。両方残すというのは一番コストがかかるものの、あえて両方を使うことで、最終的にマージするか判断する人間にとって大きなメリットがあることがわかったためです。人間にとってのメリットには実装面とレビュー面の2つがあります。

実装面のメリット

改めて、今回導入したワークフローはこちらですが、

一番左の開発者のところに、実際にTaskがどこからどのように開発者に流れていくのかを付け加えたイメージ図が次の図になります。

Taskの色分けは、このタスクがどこから来たものかを表します。また、人間の実装フローを下部に追加しています。この図は実際の開発チームの状況を反映したものになっています。タスクの入り口は、事業部からの要望、代表からの緊急の指令、デザイナーからの修正依頼、外部のステークホルダからの要望、チームないで発見した課題と少なくとも5種類の入口があります。また、各タスクの性質も、すぐにできる修正から、新しく設計が必要なものまで複数あります。さらにこれらの期限が絡んできますので、それも考慮して優先順位をつけることは簡単ではないです。

一方で、人間が実装するにあたり、複雑な問題に取り掛かるとき人は一つのタスクに集中する必要があります。そのため、小さな差し込み対応が入るだけで生産性が落ちるという課題がありました。しかしこのフローを回し始めたことで、小さな差し込み対応、簡単に治せそうなタスク、ルーティンのタスクをAI Agentにまず流すようにすることができました。例えば
・単一レポジトリに収まる、特定箇所のバグ修正であればClaude
・複数レポジトリに渡るものであればDevin
といったようにタスクを振り分け、緊急性、タスクの複雑性に合わせて使い分けてAIエージェントツールを並行稼働させることで、同じ時間で取り掛かれるタスクが増えることがわかりました。これらのタスクの一つ一つが小さくても、小さいタスクでのAIのアウトプットは修正がほとんど必要なく、そのままマージ可能な場合も少なくないなので、同じ時間で捌けるタスクの量は明らかに増加しました。

レビューに関するメリット

続いて、レビューの観点でのメリットを説明します。同じコードを二つのエージェントがレビューすると、その結果を見て、こちらのマトリックスように問題点を分類することができます。

このように、DevinとClaude Code Actionsが両方レビューすることによって、必然的に人間が把握すべきレビューの観点が三つに分類されることがわかります。また、それによって次のように優先順位をつけることができます。

1. 双方が同じ問題を指摘する -> バグの可能性が高く確認すべき事項として最優先
2. 双方の意見が割れる -> 次に確認すべき事項
3. 双方がapproveする -> 大丈夫そう or 人間が最終チェック

もちろんAI側の判断が間違っているという可能性があるものの、このように複数のフローでレビューすることで、人間がレビューするにあたって必要な観点が洗い出され、結果的に優先順位をつけてくれるという効果があります。
1つのAIレビューだけを使っているとハルシネーションを疑って、一定程度しか信用できなくなってしまう心理的な障壁がありますが、二つのAIエージェントを使うことによって幾分、信頼度が高まります。また、タイポやバグなどの小さいミスについては正確にレビューされるので、人同士の手戻りが減ります。これらの効果が合わさって、レビューの速度をさらに向上させることができました。

興味深い発見

さらに、実際にレビューを見ている中で2つのエージェントが補い合い、協力し合っているように見える面白い現象を発見しました。こちらが一例です。

このコメントの趣旨は、Claude code がレビューして問題を指摘してくれていたので、devinからはいうことはありません。というものです。こういった現象は現在、毎回発生するわけではないですが、過去の議論を読むようにPromptで指定していることから、あるエージェントが他のエージェントが作ったコメントを読み込んで、それが出力に反映されると、結果として両者が協力し合っているのと同じ状況が発生するのです。二つのエージェントが無関係に動作するのではなく、マルチエージェントの共同作業のように振る舞ってくれるということがわかります。これは将来的にレビューのクオリティをより一層上げることができるきっかけになるのではないかと考えています。

コスト

最後にこのフローを構築し、運用するにあたってひと月あたりどのくらいのコストがかかるのかを計算しました。結果は下記の通りとなります。

Devin
・82780円/月 （280ACU）
Claude Code Actions
・Anthropicのモデル：　8000円~10000円/月
・Github Actions：1110分稼働　実質無料
※開発者は全員、Teams Planに加入（6380円/月）月3000分が無料

今後の展望

最後に私の考えるAI駆動開発の今後の展望について考えます。二つの方向性があります。
一つは今回実装した開発とレビューのワークフローに磨きをかける方向です。
・外部ドキュメントを読ませてreviewをさせる
・実装の意図に反していたり、プロジェクト特有の理由で取り決めている事柄などを認識させる
といった対策で的外れなレビューや、繰り返し同じレビューをすることを防ぎ、コストを削っていく必要があります。
もう一つは、開発とレビューよりも上位の工程でAI駆動開発を導入することです。例えば、現在はタスクが出来上がった場合、いちいちそこからプロンプトを書き起こしています。これは面倒な作業です。タスクを作成して、AIが理解できるような仕方の命令文を自動的に生成できると非常に楽になります。最終的には事業部側と揉んだ仕様書を適切に管理し、そこからタスクを作成して、命令文を自動生成、さらにDevinとClaude Code Actionsに投げて実装させる、というフローを回せるようになると、一気に自動化が促進します。この状態になれば、人間が注力すべきは間違いのない仕様書を作成することになるため、AI駆動開発はやがて仕様書駆動開発に進化していくと考えられます。また、もう一つの経路として、エラーを検知した時に自動的にタスク化、命令文生成、実装開始というフローを自動化することも重要だと考えています。

参考資料

・Claude Code Actions 公式ドキュメント
https://docs.anthropic.com/ja/docs/claude-code/github-actions

・Claude Code Actions 公式レポジトリ
https://github.com/anthropics/claude-code-action/tree/main/examples

・Devin 公式ドキュメント
https://docs.devin.ai/get-started/devin-intro

・Devinの自動レビュー
https://cognition.ai/blog/devin-101-automatic-pr-reviews-with-the-devin-api#conclusion

・GITHUB TOKENの仕様
https://docs.github.com/ja/actions/writing-workflows/choosing-when-your-workflow-runs/triggering-a-workflow#triggering-a-workflow-from-a-workflow

最後に

グループ研究開発本部 次世代システム研究室では、最新のテクノロジーを調査・検証しながらインターネット上の高度なアプリケーション開発を行うエンジニア・アーキテクトを募集しています。募集職種一覧 からご応募をお待ちしています。