はじめに Jumpstart your project with Copilot とは 利用方法 使ってみた リポジトリの作成 動作確認 Dev Containers の起動 GitHub への接続 pnpm のインストール AWS CLI と AWS CDK TypeScript Biome の利用 動作確認結果 まとめ はじめに こんにちは。アプリケーションサービス本部 ディベロップメントサービス3課の北出です。 今回は新しく始まるプロジェクト用の GitHub リポジトリを作るときに、GitHub Copilot の 「Jumpstart your project with Copilo…

はじめに こんにちは！デリッシュキッチンで主にバックエンドの開発を担当している秋山です。 最近GitHub公式ブログで発表された GitHub Agentic Workflows というツールを知り、使い心地が気になったので試してみました。本記事では、CI/CDパイプラインにAIエージェントを組み込んで、テスト失敗時の原因調査からIssue作成までを自動化するワークフローを試しに構築した体験を紹介します。 目次 はじめに GitHub Agentic Workflowsとは 今回試してみたこと セットアップ 実際に作ったもの テスト対象のGoコード GitHub Agentic Workflowsを使ったワークフロー定義 コンパイル 結果 GitHub Agentic Workflowsのセキュリティ設計 Safe Outputs 脅威検出（Threat Detection） 豊富なデザインパターン まとめ ご参考 GitHub Agentic Workflowsとは GitHub Agentic Workflows は、ワークフローを自然言語で定義し、コーディングエージェントに実行させる仕組みです。従来のGitHub ActionsではYAMLでワークフローを記述していましたが、GitHub Agentic Workflowsでは マークダウン形式 で自然言語を使ってワークフローを定義できます。定義したマークダウンは gh aw compile コマンドでGitHub Actions用のYAMLにコンパイルされ、GitHub Actions上で実行されます。 主な特徴は以下の通りです。 マークダウンベースのワークフロー定義 : YAMLの代わりにマークダウンで自動化を記述。直感的で柔軟 選択可能なAIエンジン : GitHub Copilot、Claude、OpenAI Codexなど、使用するコーディングエージェントをワークフローごとに選択可能 セキュリティ重視の設計 : デフォルトで読み取り専用権限。書き込み操作には明示的な許可が必要。さらに脅威検出による自動セキュリティ分析も実行される ※Agentic Workflowsは2026年2月現在 テクニカルプレビュー段階 にあり、今後大きな変更が入る可能性があります。 今回試してみたこと GitHub Agentic Workflowsを使って、 CI上の自動テスト失敗時に原因を調査し、Issueを作成してくれるワークフロー を構築しました。Claude Codeに手伝ってもらいつつ、初回ワークフロー実行まで約30分で完了しました。 セットアップ まずは拡張機能をインストールし、initで初期設定を行います。 # Agentic Workflows拡張機能のインストール gh extension install github/gh-aw # Agentic Workflowsのワークフローの初期化 gh aw init 実際に作ったもの テスト対象のGoコード まず、検証のために 意図的にデータレースのリスクがあるGoコード を用意しました。 // cache.go package main type Cache struct { data map [ string ] int } func NewCache() *Cache { return &Cache{data: make ( map [ string ] int )} } func (c *Cache) Set(key string , val int ) { c.data[key] = val } func (c *Cache) Get(key string ) int { return c.data[key] } // Increment increments the value for key by 1. func (c *Cache) Increment(key string ) { c.data[key]++ } sync.Mutex を使わず map[string]int に直接アクセスしているため、並行アクセス時にデータレースが発生します。 また、テストでは100個のgoroutineから同時にIncrementを呼び出します。 // cache_test.go func TestCacheConcurrentIncrement(t *testing.T) { c := NewCache() c.Set( "counter" , 0 ) var wg sync.WaitGroup const workers = 100 for i := 0 ; i < workers; i++ { wg.Add( 1 ) go func () { defer wg.Done() c.Increment( "counter" ) }() } wg.Wait() got := c.Get( "counter" ) if got != workers { t.Errorf( "expected counter=%d, got %d (lost %d increments due to race)" , workers, got, workers-got) } } 自動テストワークフロー（ test.yml ）の定義です。 # .github/workflows/test.yml name : Tests on : push : branches : [ "**" ] pull_request : jobs : test : runs-on : ubuntu-latest steps : - uses : actions/checkout@v4 - uses : actions/setup-go@v5 with : go-version : "1.23" - name : Run tests (race detector + repeat) run : go test -v -race -count=5 -timeout 120s ./... GitHub Agentic Workflowsを使ったワークフロー定義 続いてGitHub Agentic Workflowsを使ったワークフローの定義です。 定義は マークダウン で書きます。 Front Matterでワークフローの細かい設定ができます（engineなどの部分です）。 メインの内容に、自然言語でワークフローの定義をしています。今回は英語で書いてますが、日本語でも問題ないと思います。 --- engine: copilot on: workflow_run: workflows: ["Tests"] types: [completed] branches: - main permissions: contents: read actions: read safe-outputs: create-issue: ~ --- # CI Doctor Automatically investigate failures in the "Tests" workflow and create a GitHub Issue with a diagnostic report. ## Instructions When triggered, check if the "Tests" workflow run that just completed has a conclusion of `failure`. If it succeeded, do nothing. For failed runs: 1. **Fetch the workflow run logs** for the failed "Tests" run using the GitHub Actions API. 2. **Classify the failure type** by scanning the logs: - `DATA RACE` → **Race condition** - `too long` or `took too long` → **Time-dependent flakiness** - `panic:` → **Panic / crash** - `FAIL` with a specific test name → **Assertion failure** 3. **Identify the affected tests** by extracting lines matching: - `--- FAIL: TestXxx` - `FAIL\tgithub.com/...` 4. **Extract the root cause evidence** — copy the relevant log lines verbatim as a code block. 5. **Create a GitHub Issue** with the following structure: **Title**: `CI Failure: <TestName> — <failure type>` **Body**: - Summary - Failed Test(s) - Failure Type - Log Evidence - Root Cause Analysis - Suggested Fix Add labels: `bug`, `flaky-test`. Front Matterの設定について補足します。 engine: copilot でAIエンジンを指定。Copilot以外にもClaudeやCodexを選択でき、使用するモデルの指定も可能（ エンジン設定リファレンス ） workflow_run トリガーでTestsワークフローの完了を監視 permissions で contents: read と actions: read のみに権限を限定 safe-outputs に create-issue を設定し、Issue作成のみを許可。それ以外の書き込み操作は行えない コンパイル GitHub Agentic Workflowsのワークフロー（ .md ）は、 gh aw compile コマンドで .lock.yml にコンパイルされます。 gh aw compile 検証ではci-doctorという名前でワークフローを作っていたので、 .github/workflows/ci-doctor.lock.yml が生成されました。このYAMLファイルが実際にGitHub Actionsで実行されるワークフローのようです。 これでワークフローの準備は完了です。 結果 Testsワークフローが失敗すると、定義したワークフローが自動的に起動しました。 GitHub Agentic Workflowsで定義したワークフロー また、以下のようなIssueが作成されました。 自動作成されたissue bug と flaky-test ラベルも自動で付与されています。 また、問題の説明や具体的な修正案まで提示してくれました。 今回は簡単な例でしたが、より複雑なケースでどうなるのかは今後確認していきたいです。 GitHub Agentic Workflowsのセキュリティ設計 AIエージェントにCI/CDパイプライン上で作業させるとなると、気になるのがセキュリティです。GitHub Agentic Workflowsはこの点について手厚い設計がされています。 Safe Outputs GitHub Agentic Workflowsのワークフローは デフォルトで読み取り専用権限 で実行されます。書き込み操作（Issue作成、PR作成など）を行うには safe-outputs で明示的に許可する必要があります。 safe-outputs : create-issue : ~ # Issue作成を許可 create-pull-request : ~ # PR作成を許可 ワークフローごとに許可する操作を限定できるため、「このワークフローはIssue作成だけ」「このワークフローはPR作成まで」といった細かい権限管理が可能です。 脅威検出（Threat Detection） safe outputsが設定されている場合、GitHub Agentic Workflowsは自動的に 脅威検出 を実行します。これはエージェントの出力が実際にGitHubに書き込まれる前に、セキュリティ分析を行う追加のレイヤーです。デフォルトでは有効になっています。 検出フローは以下の順序で動作します。 エージェントジョブ （読み取り専用権限で実行） 脅威検出ジョブ （エージェント出力のセキュリティ分析） Safe Outputsジョブ （安全確認後に書き込み権限で実行） プロンプトインジェクション、シークレットの漏洩、悪意のある変更を検出します。 脅威が検出された場合、ワークフローは失敗し、safe outputsジョブはブロックされます。 詳細は 脅威検出リファレンス を参照してください。 豊富なデザインパターン GitHub Agentic Workflowsのリファレンスには具体的なデザインパターン/使用例がいくつも載っています。 その中で僕が気になったのは MultiRepoOpsパターン という、複数リポジトリを横断した自動化パターンです。 例えば、PRD（プロダクト要求仕様書）を別リポジトリで管理しているケースでは、PRDの変更に連動して開発リポ側にIssueを作成したり、実装状況をPRDリポ側にフィードバックしたりといった連携ができるようになるのではないかと思いました。 まとめ GitHub Agentic Workflowsを使って、ワークフローを作成しました。 リファレンスには今回紹介した他にも細かい設定やユースケースが書かれています。 気になった方はぜひ 公式ドキュメント を見て、試してみてください。 ご参考 GitHub Agentic Workflowsを発表 - リポジトリの自動化を実現 - GitHubブログ Blog | GitHub Agentic Workflows About Workflows | GitHub Agentic Workflows GitHub - github/gh-aw: GitHub Agentic Workflows

こんにちは！プロダクトエンジニアのkazzhiraです。 私たちのチームでは、2025年の夏ごろから「AI活用による開発生産性の向上」に取り組んできました。しかし、当初の取り組みは抽象的なガードレールの提示や個々人の実践にとどまり、チームとして大きな成果には結びつきませんでした。 その後、SDD（仕様駆動開発）というアプローチに出会い、オープンソースの cc-sdd フレームワークをベースに試行錯誤を重ねてきました。 本記事では、AI開発標準の策定に失敗した経験から何を学び、どのように仕様駆動開発に辿り着いたのか、そして、実践を通じて得た成果と学びをご紹介します。 チームのAI導入でうまくいかなかった話 AI活用の個人最適化 当初、チームでは Cursor、Claude Code、Devin、GitHub Copilot、Gemini などの AI ツールを個々人の判断で利用できる状態でした。 しかし、AI活用の状況は個々人に閉じており、チームとしてのナレッジ共有や標準化は進んでいませんでした。 AI開発標準策定の失敗 そこで「AI開発標準」の策定を試みました。情報を収集したうえで、Planモードで実装計画を立て、途中でレビューを挟む開発スタイルを言語化しました。しかし、結果的にこの取り組みは失敗に終わりました。 資料の説明が抽象的で、チームが具体的に動きようがなかった 開発手法の共通項を抜き出しただけのガードレールに過ぎなかった 実際の開発プロセスに落とし込めず、絵に描いた餅になった 参考： 当時の考えを振り返った記事 なぜSDDをやろうと思ったのか 理想の開発体験の議論 チームで理想の開発体験・開発生産性の課題を話し合った結果、以下の課題が明確になりました。 リファインメント（仕様を決める会議）で議論が発散して収束に時間がかかる AIは顧客課題、ユーザーストーリーを知らず、要件の精度が高くない AIの出力が微妙で、整理されたコンテキストが足りない SDDとの出会い これらの課題を解決する方法として、 SDD（仕様駆動開発） に辿り着きました。 SDDの本質は、 仕様書を「単なるドキュメント」ではなく、AI と人間の両方が参照する SSoT（Single Source of Truth）として機能させる ことです。 定性面 AIがユーザーストーリー、背景、受け入れ条件から精度の良い仕様書を生成する →「AIは顧客課題、ユーザーストーリーを知らず、要件の精度が高くない」の解決 構造化された要件定義書・設計書・開発ルールで一貫したコンテキストを提供する →「AIの出力が微妙で、整理されたコンテキストが足りない」の解決 定量面 価値提供速度の向上 これらの効果を期待し、投機的に取り組んでみることを決めました。 ちなみに、「リファインメントで議論が発散して収束に時間がかかる」は当時Notion AIでの解決も試しました。しかし本題から外れるため、本記事では割愛します。 SDDの実践と工夫 cc-sddフレームワークの採用 SDD を実践するにあたり、私たちはオープンソースの cc-sdd （Spec-Driven Development フレームワーク）を採用しました。 深い理由はなく、筆者が各所で目にして実験的に入れていた背景があります。 チーム固有の課題 cc-sdd の基本的なアプローチを導入した上で、私たちのチームは以下の課題に直面しました。 複数のリポジトリを AI が横断的に操作できない チーム固有のタスク分割・実行ルールがなく、AI の出力がチームの開発フローに合わない Rails 固有の設計パターンが AI に伝わらない プロダクトのドメイン知識が AI に渡っていない 私たち独自のソリューション これらの課題に対し、私たちは以下の解決策を構築しました。 1. マルチリポジトリ横断ワークスペース Cursorによる開発を前提に、code-workspaceを生成して複数リポジトリを統合的に扱う仕組みを実装しました。 【my-team.code-workspace】 { " folders ": [ { " name ": " my-team ", " path ": " . " } , { " name ": " backend ", " path ": " ~/workspace/backend-repository " } , { " name ": " frontend ", " path ": " ~/workspace/frontend-repository " } , ... ] } これにより以下のメリットが得られました。 AI エージェント（Cursor / Claude Code 等）がリポジトリを横断して操作可能 仕様書リポジトリ（my-team）とコードベースを統合管理 私たちの最初の実装では、my-team・backend・frontendをセットで管理しました。 今はもう少し増えています。 2. タスク生成・実行ルールの整備 チーム固有のタスク生成・実行ルールを定義しました。 ルール種別 内容 タスク分割ポリシー "デプロイ可能な最小粒度" にタスク分割 Commit・Push・PRのルール 例示することで、意図した生成に誘導する。例えば "commitには変更理由とリファレンスを必ず含める"、"PRテンプレートに従う" など。 タスク実行順序の定義 Swaggerを定義してからfrontendとbackendの作業に移行する。 3. カスタムステアリングドキュメント Rails 固有の設計パターンやプロダクトのドメイン知識をステアリングドキュメントとして整備しました。 Controller Patterns（ before_action の濫用禁止、個別でエラーハンドリング不要など） プロダクト固有の名称、用語、ユースケース リポジトリ構造のサマリ 採用している技術の詳細 例として「プロダクト固有の名称、用語、ユースケース」を定義した例を示します。 # Product Overview タイミーアプリのAPIサーバー、クライアント向けWebアプリケーションのAPIサーバー、 ワーカー向けモバイルアプリケーション、社内管理ツールを提供するプラットフォーム。 ## Core Capabilities 1. **ワーカー・クライアント管理**: ワーカーとクライアント企業のアカウント管理、認証、プロフィール管理 2. **求人・マッチング**: 求人作成、公開、ワーカーとのマッチング機能 3. **勤怠・給与管理**: 出勤管理、給与計算、支払い処理 4. **コミュニケーション**: チャット機能、レビュー・フィードバック機能 5. **管理機能**: 社内管理ツール、各種レポート・分析機能 ## Target Use Cases - **クライアント企業**: 求人作成・管理、ワーカー管理、勤怠確認、給与支払い - **ワーカー**: 求人検索・応募、勤怠管理、給与確認 - **社内管理者**: システム管理、データ分析、各種レポート生成 ## Value Proposition - ワーカーとクライアント企業を効率的にマッチングするプラットフォーム - 勤怠管理から給与計算まで一貫した業務フローを提供 4. カスタムコマンド cc-sddのコマンド体系以外で、チームで必要な成果物を保管するためのコマンドを用意しました。内容は長いため省略します。 QAチェックリストの自動生成「spec-qa-checklist」 Playwright MCPによるQA自動実行「playwright-mcp-qa」 最終的なファイルツリーを示します。 my-team/ ├── my-team.code-workspace # マルチリポジトリ統合ワークスペース定義（独自作成） ├── repos.yml # 対象リポジトリ一覧（独自作成） ├── repos.template.yml # ↑のテンプレート（独自作成） ├── docs/ # プロジェクト横断ドキュメント │ ├── scripts/ │ ├── setup.sh # 初期セットアップ（独自作成） │ ├── setup-workspace.sh # ワークスペース構成生成（独自作成） │ └── sync-*.sh # リポジトリ・設定の同期（独自作成） │ ├── .cursor/ │ └── commands/ # カスタムコマンド（独自作成） │ ├── spec-qa-checklist.md # QAチェックリスト生成 │ └── kiro/ # Kiro Spec-Driven コマンド群 │ └── .kiro/ ├── steering/ # アーキテクチャ制約 │ ├── product.md # プロダクト原則 │ ├── tech.md # 技術標準 │ └── structure.md # コード構造パターン ├── settings/ │ ├── rules/ # 設計・実行ルール（独自） │ │ ├── tasks-generation.md # タスク生成（プレフィクス規約・分割順序）（独自作成） │ │ └── task-execution-policy.md # 実行ポリシー（環境・Git・コミット規約）（独自作成） │ └── templates/ │ ├── specs/ # 仕様テンプレート │ └── steering/ # ステアリングテンプレート └── specs/{feature}/ # 機能単位で生成 ├── requirements.md # 要件 ├── design.md # 設計 ├── tasks.md # タスク └── e2e-qa-checklist.md # QA（独自作成） 評価 ポジティブな評価 cc-sddの短期間の導入で最も価値を感じたのは、実装速度の向上ではなく、 開発プロセスの質の向上 でした。 暗黙知の形式知化 — これまで個人の頭の中にあった仕様判断が、requirements / design / task の3つの成果物を通して言語化・共有された 手戻りの減少 — 仕様書によってコンテキストが整理されたことで、AIの出力品質が安定し、実装後の手戻りが体感として減った 合意形成の質の向上 — 仕様を厳格に言語化するプロセスが、チーム内の認識齟齬を早期に解消した モブワークとの親和性 — 構造化された仕様書が共通言語として機能し、スプリント初期の設計作業を効率的に進めることができた ネガティブな評価 一方で、チームで改善すべき課題も挙がっています。 モノにもよるが、仕様書を作る工程で同期的に1日〜1.5日の時間を使う 仕様書を精査する工程の疲労感 実装スピードとデプロイ頻度は、以前と同等か、微増している感覚 シンプルに練度不足 リファインメントが引き続きボトルネック。実装が効率化しても、要求の供給が追いつかなければ全体のスループットは上がらない 中間生成物のレビューがリファインメントに次ぐボトルネック。AIが高速に生成するアウトプットに対し、人間のレビューが追いつかない etc. データで見る事実：cc-sdd導入でデプロイ頻度は向上しなかった 前提として、開発者が3名のスクラムチームです。 【デプロイ頻度の移動平均推移】 デプロイ頻度の移動平均推移 開発生産性を測るFour Keysの1つの指標であるデプロイ頻度に着目しました。 cc-sdd導入前後でデプロイ頻度が向上していないことを観測 AIを本格導入してきた過去6ヶ月で見るとデプロイ頻度は増加傾向 先ほどのネガティブな評価の「実装スピードとデプロイ頻度は、以前と同等か、微増している感覚」とも一致しています。 ここで、他の視点も入れてみます。 【デプロイ頻度と変更リードタイムの移動平均推移】 デプロイ頻度と変更リードタイムの移動平均推移 【平均レビュープルリク数とレビューからアプルーブまでの平均時間の移動平均推移】 平均レビュープルリク数とレビューからアプルーブまでの平均時間の移動平均推移 【マージ済みプルリク数のアクティビティの推移】 マージ済みプルリク数のアクティビティの推移 これらの結果から、cc-sddによる開発について3つの事実が分かりました。 変更リードタイムは以前の開発繁忙期の時と同程度の推移 ※sddに関連するドキュメント更新のアクティビティは計測対象外です レビュー時間は以前よりも下がっている 瞬間風速的にはPR作成数が過去半年で最多を記録した cc-sddによって、設計からレビューの効率化には成功しているが、デプロイまでの流れを阻害しているボトルネックが別に存在すると読み取れます。 これまでの経緯を含めて考察すると、それはリファインメントによる要件の供給速度だということがわかります。 今後の取り組み ここまでの取り組みでは事実としてデプロイ頻度が上がりませんでした。 ネガティブな評価であがった課題を “のびしろ” と捉え、インパクトの大きい課題をコツコツ解消していく予定です。 直近では、AI-DLCのアプローチとスクラム開発と組み合わせ、リファインメントを改善する方針で以下の取り組みを進めています。 AIを要求・デザインフェーズにも適用し、仕様策定のボトルネックを解消する 仮説の壁打ち プロトタイプ作成を回す AIがアクセス可能なSSoTの範囲拡充（ビジネスコンテキスト、ユーザーリサーチ等） 価値提供のフィードバックループを短縮し、次の要求定義に繋げる まとめ cc-sddの導入で仕様の認識齟齬が早期に解消され、意図した仕様どおりの実装に到達しやすくなりました。 しかし世間で語られるようなAIによる劇的な生産性向上には至っていません。 仕様策定フェーズのボトルネックやレビュー負荷など、AIを適用できる余地は多く残されています。 私たちのチームでは、思考をAI Drivenに変化させ、要求定義から価値提供までの全体フローを、改めてAI前提で組み直す必要があることが見えてきました。 この記事を書いている時点でも新たな取り組みで急速に進化していることを実感しています。 私自身も置いていかれないように、チームに貢献できるように成果を出し続けようと思います。 引き続きこの領域に挑戦していきます。 タイミーには、こうした挑戦と学び、そして発信を歓迎する文化があります。 ともに挑戦し成長していきたい方、興味があればぜひ1度お話ししましょう！ プロダクト採用サイトTOP カジュアル面談申込はこちら