Slide 1

Slide 1 text

CIで使うClaude 2026/7/10 岩田 智哉

Slide 2

Slide 2 text

2 自己紹介 ● 2018年5月 入社 ○ サーバーレス開発部 ● 2025年1月〜 オフショア案件のアーキテクト ○ コードを書かなくなる ● 2026年4月 ● CCA-F受験 ● 2026年6月 ● なんやかんや色々あった後にようやくCCA-F合格 ● 部署 ○ リテールアプリ共創部 ● 名前 ○ 岩田 智哉 ● 好きなAWSサービス ○ Lambda ● 趣味 ● ブレイクダンス ● 前十字靭帯再建手術リハビリ中

Slide 3

Slide 3 text

質問 Claude Code どう使ってますか?! 3

Slide 4

Slide 4 text

Claude Code = インタラクティブに利用するもの?? 4

Slide 5

Slide 5 text

claude –p / claude --print ⚫ 非インタラクティブモードでClaude Codeを実行 ⚫ 引数で与えられたプロンプトを処理して結果を出力 ⚫ 非インタラクティブなので自動実行と相性が良い 5

Slide 6

Slide 6 text

--json-schemaオプション ⚫ 出力に対して期待するJSONスキーマを定義 ⚫ 構造化した出力が得られる 6

Slide 7

Slide 7 text

--json-schemaオプションの裏側を少し覗いてみる 7 role type content assistant thinking The user just said hello. I'll greet them briefly. assistant text Hello! How can I help you today? user text [structured-output-enforce] You MUST call the StructuredOutput tool to complete this request. Call this tool now. assistant thinking The user is asking me to call the StructuredOutput tool. Let me look at the tool's parameters to understand what's required. The StructuredOutput tool requires: greeting, hoge, fuga (all strings). me call it with some reasonable values. assistant tool_use { "type": "tool_use", "id": "toolu_bdrk_01N38mBnHMjc4qW8ZuBq2kW8", "name": "StructuredOutput", "input": { "greeting": "hello", "hoge": "hoge", "fuga": "fuga" } }

Slide 8

Slide 8 text

CI環境でClaudeを利用してみる 8

Slide 9

Slide 9 text

Claude Code Action 9 ⚫ Claude Agent SDKを利用したGitHub Actionsのアクション実装 ⚫ GitHub Actions上でclaude –pを実行するのと同じ感覚で利用可能 https://github.com/anthropics/claude-code-action

Slide 10

Slide 10 text

GitHub Actionsのワークフローサンプル 10 https://github.com/anthropics/claude-code-action/blob/main/docs/solutions.md

Slide 11

Slide 11 text

CI環境でClaudeを利用する時のお悩みポイント 11 ⚫ キーの管理をどうするか? ⚫ そもそもAPIキーが発行可能か? ⚫ 費用負担はどうするか?

Slide 12

Slide 12 text

Claude Code(Action)は複数クラウドプロバイダーに対応 12 ⚫ Anthropic APIの直接呼び出し ⚫ OIDC連携 ⚫ Amazon Bedrock ⚫ Google Vertex AI ⚫ Microsoft Foundry

Slide 13

Slide 13 text

Bedrock経由でClaudeモデルを利用するには ⚫ anthropics/claude-code-actionの use_bedrockをtrueに設定 ⚫ ※BedrockのAPIを呼び出すために AWSのクレデンシャルが必要にな るので、これは別途設定しておく ⚫ 事前にBedrock側でClaudeのモデ ルアクセスを有効化しておく 13

Slide 14

Slide 14 text

GitHub ActionsからAWSの一時クレデンシャルを取得するには ⚫ AWS側でIAMロールを作成し、必要 な権限や信頼ポリシーを設定 ⚫ aws-actions/configure-aws- credentialsで一時クレデンシャル を取得 14

Slide 15

Slide 15 text

(任意)Bedrock経由でClaudeモデルを利用するには ⚫ Bedrock側でアプリケーション推論 プロファイルを作成しておく ⚫ ANTHROPIC_DEFAULT_... 系の環 境変数でアプリケーション推論プロ ファイルのARNを指定 ⚫ コストやモデルの使用状況が追跡可 能に 15

Slide 16

Slide 16 text

Vertex AI経由でClaudeモデルを利用するには ⚫ anthropics/claude-code-actionの use_vertexをtrueに設定 ⚫ 同様に以下の環境変数を設定 ⚫ ANTHROPIC_VERTEX_PROJECT_ID ⚫ CLOUD_ML_REGION 16

Slide 17

Slide 17 text

GitHub ActionsからGoogle Cloudの一時クレデンシャルを取得するには ⚫ Google Cloud側でWorkload Identityプール等のリソースを作成 し、GitHub ActionsからのOIDC連 携を許可 ⚫ google-github-actions/authで一時 クレデンシャルを取得 17

Slide 18

Slide 18 text

クラウドプロバイダー経由でClaudeモデルを利用するメリット 18 ⚫ クラウドプロバイダーとの契約があればClaudeモデルが利用可能 ⚫ プロジェクトの予算として利用しやすい ⚫ 既存の権限管理との統合(IAMなど)

Slide 19

Slide 19 text

CIにClaudeを組み込むと 何ができる?? 19

Slide 20

Slide 20 text

CI × Claudeのユースケース 20 ⚫ コードレビュー ※これが一番使われていると思う ⚫ Issueのトリアージ、ラベル付け ⚫ ドキュメントとソースコードの乖離をチェック ⚫ コミット履歴から進捗や作業負荷を分析 ⚫ AIエージェント向けのスキルを評価

Slide 21

Slide 21 text

CI × Claude 利用例① 21

Slide 22

Slide 22 text

Claude Code ActionでPJの進捗レポートを生成する例 22 「GitHub Actions ✕ Claude CodeのスキルでGitHub Projectsからプロジェクトの進捗状況を取得・分析してSlackに通知してみた」 https://dev.classmethod.jp/articles/auto-report-gh-project-progress-via-clouade-code/

Slide 23

Slide 23 text

Claude Code Action利用時の注意点 ⚫ --max-turnsを指定する ⚫ 指定したターン数を超えると強制終了 ⚫ コストの爆発を未然防止 ⚫ --json-schemaを指定して応答を JSON形式にする ⚫ 実行結果がstructured_outputに格納 される ⚫ 単一のテキストが必要な場合でも、結 果を後続stepで使用したいならJSON 形式必須 23

Slide 24

Slide 24 text

CI × Claude 利用例② 24

Slide 25

Slide 25 text

Claude Code Actionでドキュメントとソースコードの乖離をチェックする例 25 https://github.com/classmethod/icasu-cdk-serverless-api-sample/ 公開されているリポジトリをfork、Claude Code Actionでチェックしてみた

Slide 26

Slide 26 text

Claude Code Actionでドキュメントとソースコードの乖離をチェックした結果① 26 # 深刻度 対象ドキュメント(file:line) 実装の実態(file:line) 乖離の内容 推奨対応 1High docs/system-design/rest-api.yml:168-172 (companiesPostRequestBody.required: ["companyName"]) packages/server/src/lambda/handlers/api- gateway/rest-api/companies-post.ts:13 (zodスキーマ は name フィールドのみ) OASのrequiredに"companyName"と書いてあるが propertiesキーは"name"。存在しないフィールド名を requiredに指定している OASのcompaniesPostRequestBody.requiredを ["name"]に修正 2High docs/system-design/rest-api.yml:186 (companiesPostResponseBody.required: ["id","createdAt","companyName"]) packages/server/src/lambda/domains/services/schem as.ts:3-8 (Company型のキーはid/createdAt/name) / packages/e2e/rest-api/test-cases/companies- post.ts:62 (nameで検証) POSTレスポンスのOASスキーマがcompanyNameを requiredに含むが、実際のレスポンスフィールドは name OASのcompaniesPostResponseBodyのpropertiesを id/createdAt/nameに修正し、requiredを ["id","createdAt","name"]に修正 3High docs/system-design/rest-api.yml:150-163 (companiesGetResponseBody.properties: companyId, companyName) / 189-203 (companiesIdGetResponseBody同 様) packages/server/src/lambda/domains/services/schem as.ts:3-8 (フィールド名はid, name) / packages/e2e/rest-api/test-cases/companies- get.ts:31-48 (id/nameフィールドを使用) GET /companies および GET /companies/{id} のOASス キーマがcompanyId/companyNameだが、実装は id/name OASのcompaniesGetResponseBodyと companiesIdGetResponseBodyのpropertiesをid/name に合わせて修正 4High packages/iac/README.md:3-13 ("IacStack"、"Amazon SQS queue subscribed to an Amazon SNS topic"と記載) packages/iac/lib/main-stack.ts:14 (スタック名は MainStack。SQS/SNSの直接構築なし) IaCパッケージのREADMEがCDK初期テンプレートのまま で、本プロジェクトの実態(Lambda+API GW+DynamoDB+Cognito+WAF等)と完全に乖離 packages/iac/README.mdをプロジェクト実態に合わせ て書き直す 5Med README.md:36 (.github/workflows/cicd.yml参照) / README.md:136 (.github/workflows/manual-deploy-to- development.yml参照) リポジトリに.github/workflows/ディレクトリが存在し ない GitHub ActionsワークフローファイルをREADMEで参照 しているが、対応するファイルが存在しない .github/workflows/が意図的に非公開なら注釈を追加。 公開する場合はファイルを追加 6Med packages/server/README.md:10 (ユースケース層パ ス: ./src/lambda/domain/usecases/) packages/server/src/lambda/配下の実際のパス: domains/services/ (domain→domains、usecasesディ レクトリは存在しない) ドキュメント記載パスが実際のディレクトリ構造と異な る packages/server/README.mdのパス表記を実際のディ レクトリ構造に合わせて修正 7Med docs/system-design/rest-api.yml:101,108 (パスパラメータ名を {companyId}と定義) packages/server/src/lambda/handlers/api- gateway/rest-api/router.ts:40,55 (/companies/:idと ルーティング) / companies-id-get.ts:12, companies-id- delete.ts:12 (id フィールドで受け取る) OASでは{companyId}だが、Express routerは:idとして 受け取りhandlerもidとして参照している OASのパスパラメータ名companyIdと実装のパラメータ 名idを統一する 8Med README.md:46 (システム設計書にバケット仕様書を列挙) packages/iac/lib/配下にS3バケットの構築コードは存在 しない S3バケット仕様書が設計書一覧に掲載されているが対応 する実装が存在しない READMEの設計書一覧からバケット仕様書を削除するか、 T.B.D であることを明記 9Low README.md:30, docs/user-guide/README.md:30 (Serverless ExpressリンクURL: github.com/CodeGenieApp/serverless- express) packages/server/package.json:14 (npmパッケージ名: @codegenie/serverless-express) リンク先URLのGitHubオーナー(CodeGenieApp)とnpm パッケージ名(@codegenie)のケーシングが異なる(同一 プロジェクトの可能性大だが要確認) URLとnpmパッケージ名の整合性を確認し、正しいURL に修正

Slide 27

Slide 27 text

Claude Code Actionでドキュメントとソースコードの乖離をチェックした結果② 27 観点別サマリー: • 観点1(APIの実体 vs rest-api.yml): 複数の重大な乖離あり。POST requestBodyのrequired誤記、POST/GETレ スポンスのフィールド名不一致(companyId/companyName vs id/name)、パスパラメータ名不一致 ({companyId} vs :id)。 • 観点2(AWS構成 vs system-design): 構成図はSVGのため直接検証不可。CDKスタックに存在する GitHubActionsOidcConstructはシステム設計書READMEに記載なし(要確認)。 • 観点3(セットアップ/コマンド手順): 一致・問題なし。npm ci, test-unit, test-snapshot, deploy:dev, test-e2e- api:devはすべてpackage.jsonのscriptsに存在。 • 観点4(前提条件): Node.jsバージョン制約をpackage.jsonのenginesフィールドや.nvmrcで明示していないが、 CDK実装がNODEJS_20_Xを指定。ドキュメントにNode 20要件の明記を推奨。 • 観点5(ドキュメントにあって実装にないもの): packages/iac/README.mdがCDKテンプレートのままで実態と 完全乖離。S3バケット仕様書が設計書一覧に挙げられているが実装なし。 総評: OASドキュメント(rest-api.yml)と実装の間にフィールド名の命名不一致(id/name vs companyId/companyName)およびrequired配列の誤記(companyName vs name)という複数のHigh指摘があり、 APIクライアント開発者に誤った実装を誘発するリスクが高い。packages/iac/README.mdはCDK初期テンプレー トのまま放置されており、iacパッケージの説明として完全に無効化されている。.github/workflows/の非存在・ S3仕様書のゴースト記載など、T.B.D状態のままドキュメントに残留している未完成記述も整理が必要である。

Slide 28

Slide 28 text

CI × Claude 利用例③ 28

Slide 29

Slide 29 text

Agent Skill Evalでスキルを評価する例 29 ⚫ AWS DevOps Agentのサンプルスキル評価に利用されているツール ⚫ LINTなどの決定論的なチェックに加え、実際にLLMを利用した評価も可能 ⚫ スキルがトリガーされるか? ⚫ スキルの実行結果に特定の文字列が含まれるか? ⚫ スキルの実行結果の妥当性をLLMが評価 https://github.com/aws-samples/sample-agent-skill-eval

Slide 30

Slide 30 text

Agent Skill Evalの仕組み ⚫ subprocessでclaude –pを呼び出し てスキルを実行 ⚫ 実行結果をevals.jsonで定義された 期待値と比較して評価 30 https://github.com/aws-samples/sample-agent-skill-eval/blob/main/skill_eval/agent_runner.py https://github.com/aws-samples/sample-agent-skill-eval/blob/main/examples/data-analysis/evals/evals.json

Slide 31

Slide 31 text

Agent Skill Evalの実行結果サンプル ⚫ LLMは利用せずにPythonで機械的 なチェックを実施 ⚫ 実際にClaude Codeを実行してスキ ルの実行結果を評価 31

Slide 32

Slide 32 text

スキルを評価する手法についてもAgent Skillsで定義されている 32 https://agentskills.io/skill-creation/evaluating-skills

Slide 33

Slide 33 text

/skill-creator にもevalの機能が! 33 https://claude.com/blog/improving-skill-creator-test-measure-and-refine-agent-skills

Slide 34

Slide 34 text

/skill-creatorでスキルのベンチマークを実行した結果 34

Slide 35

Slide 35 text

/skill-creatorに同梱されているスクリプトで評価を実行可能 35

Slide 36

Slide 36 text

まとめ 36 ⚫ インタラクティブな利用だけがClaudeのユースケースではない ⚫ 非インタラクティブに利用することでCIでもClaudeが活用可能 ⚫ Claudeに自動実行させたいタスクがあればCIにClaudeを組み込む ことを検討してみよう

Slide 37

Slide 37 text

No content