https://tech.itandi.co.jp/entry/2026/03/25/125831

はじめに

こんにちは。多種多様なメンバーが集まる、いつも賑やかなイタンジ精算管理チームです。

私たちが日々開発しているのは、その名の通り精算を管理するシステムであり、お金を扱うがゆえに、とても繊細で1ミリのズレも許されないプロダクトです。

品質を担保するのはもちろんのこと、ドメイン知識が複雑であるがゆえに、チーム内での漏れなく的確なコミュニケーションが求められます。一方で、プロダクトの価値をさらに提供していくためには、開発スピードも上げていかなければならないというジレンマを日々抱えています。

品質も落とせない、でも早く開発してリリースしたい... しかし、人間だけではこの両方を追い求めるのは限界がある...

この2つを両立させるためにこそ、 AI の出番なのでは...？

ということで、今回はイタンジ精算管理チームが話し合いと試行錯誤を重ねて辿り着いた、頼れるところは AI に全力で頑張ってもらうための、 GitHub Copilot Chat の Agent Skill という仕組みを使った「AIを活用した開発フロー」のお話をさせてください。

Agent Skillの活用概要

各 Skill は以下の構成で、SKILL.md に指示・チェックリスト・参照ドキュメントをまとめ、Copilot Chat から呼び出して使います。要件定義・実装レビュー・デリバリーの3工程それぞれに Skill を定義しています。

skill-name/
├── SKILL.md          # エージェントへの指示書（呼び出し条件・手順・出力フォーマット）
└── references/
    └── *.md          # チェックリストや参照ドキュメント

以降のセクションで各工程での事例を紹介します。

1. (要件定義・設計) プロジェクト読み合わせ

上流工程での認識のズレや考慮漏れは、後工程になるほど修正コストが指数関数的に跳ね上がります。ここでは、実装に入る前に行う「読み合わせ（キックオフ・設計レビュー）」をどう工夫しているかお話しします。

開発において最も恐ろしいのは、実装が終わってQAに入った後、あるいはリリース直後に「根本的な仕様漏れ」が発覚することですよね。私たちの精算管理チームでは、このような手戻りをなくすため、コードを書き始める前の最上流工程である「プロジェクトの読み合わせ」にこだわっています。

なぜ「読み合わせ」を重視するのか

元々、精算管理チームでは複数のプロジェクトを並行して回すため、PdMが要求をまとめ、担当者が設計してIssueを立てるという流れでした。ただ、これだと「担当者一人の脳内にしかない前提」が生まれてしまい、他のメンバーとの認識がズレたまま実装が進んでしまう……という課題がありました。

そこで現在は、PdMとエンジニアが同じ時間に集まり、ドキュメントを映しながら「同期的に」読み合わせる時間を必ず確保しています。開発の初期段階に品質担保の機能をシフトレフトさせることが狙いです。

要件チェックリストの運用

プロジェクト読み合わせの工程では、以下のような課題を抱えていました。

属人化による前提のズレ: PLが一人で要件からIssue起票まで完結させていたため、ドキュメント化されない「暗黙の了解」が共有されず、認識の乖離が起きていた。
実装中に「あ、これどうするの？」が頻発: いざコードを書き始めてから「エッジケースの仕様が決まっていない」「既存データの移行を忘れていた」と気づき、手が止まる。
Stagingでのバグ多発: テストフェーズで仕様の解釈違いが発覚し、修正コストが膨らむ。

こうした事態を防ぐため、私たちは独自の 「要件レビューチェックリスト」 を運用しています。

特に「作ってから気づく」という最悪のケースを避けるため、以下の項目を確認するようにしています。

ユースケース・要求項目の網羅性
- 前提条件や手順は本当に実装可能か？
- ⚠️ よくある漏れ: 「既存データは〜とする」という要求があるのに、データマイグレーションのIssueが漏れている。
Backend / Frontend の整合性
- FrontendのIssueに、どのBackend APIを叩くか明記されているか？
- ⚠️ よくある漏れ: 画面に出すべき項目が、APIのレスポンス定義に含まれていない。
権限・認可要件
- 操作できるロール（ユーザー種別）はどれか。API側（Policy等）と画面表示の両方で制御が設計されているか。
Issue間の整合性・依存関係
- Issue間で仕様が矛盾していないか。（例：Issue Aは「デフォルトfalse」なのに、Issue Bは「nilでフォールバック」となっている等）

「なんとなく分かった」を排除し、全員が同じ解像度で実装に入る状態をここで作ります。

AIの力を借りて「仕様の隙間」を見つけ出す

読み合わせの精度は上がりましたが、人間が目視で大量のIssueを完璧に突合し続けるのは限界があります。そこで私たちは、このチェック工程にAgent Skillを組み込みました。

開発者がMilestone配下のIssue情報をAIに渡すと、仕様の矛盾や抜け漏れを忖度なしでレビューしてくれる仕組みです。

精算管理チームでは、Milestone内にあるIssue群をAIに読み込ませるための専用プロンプト（milestone-review）を構築しました。

name: milestone-review
description: MilestoneのIssue群を取得し、要求Issueから実装Issueへの展開で要求漏れ・解釈ミスがないかをレビューする。Backend/Frontend整合性・権限要件・データ仕様の明確性を系統的にチェックする。「Milestoneをレビューして」「要求と実装のマッピングを確認して」の際に使用。 (類義語: milestone, マイルストーン, 要求漏れ, Issue展開, 要求レビュー, GitHub Issue)

# Milestone要求漏れ防止レビュー

Milestoneの要求Issueから実装Issueへの展開で、要求漏れ・解釈ミスがないかをレビューします。

## レビューの目的

要求Issueから実装Issue（Backend/Frontend）への展開において、要求が漏れていないか・解釈が間違っていないかを確認します。

(以下略)

このスキルを実行すると、AIが裏側で以下のワークフローを回してくれます。

抽出と分類: Milestone内の全Issueから「要求」と「実装」を自動で分ける。
マッピング: 要求されたユースケースが、どの実装Issueで担保されているかの対応表を内部で作る。
系統的チェック: 前述のチェックリストに基づき、要求漏れや解釈の矛盾をあぶり出す。

AI活用のコツ：役割の境界線を引く

AIに丸投げするのではなく、プロンプトで 「重視すること（要求の網羅性）」 と 「重視しないこと（細かなコードレベルの実装詳細）」 を明確に分けています。これが功を奏し、AIから以下のような鋭いフィードバックが返ってくるようになりました。

【問題】 Frontend一覧の表示項目「部屋番号」が、対応するBackend API（#12345）のレスポンス定義に含まれていません。

【対象Issue】 #12345, #12346

【要求との対応】 要求Issue #12340 の画面要求項目

【重要度】 高

【推奨対応】 Backend APIのレスポンスに room_number を追加するようIssueを修正してください。

「人間の対話によるすり合わせ」と「AIによる網羅的な多角チェック」。この両輪を回すことで、上流工程の品質は劇的に向上しました。

2. (実装・レビュー) AIを使ったレビューフロー

実装フェーズに入った後も、AIの出番は続きます。コードレビューのボトルネックを解消するため、私たちがどのようにAIをワークフローに組み込んでいるかをお見せします。

レビューを「消耗戦」にしない

開発チームが大きくなるにつれて、コードレビューはじわじわと負荷を増していきました。私たちが特に感じていた課題は次の2つです。

機械的な指摘で時間が溶ける 「変数名がRubyらしくない」「1件しか作らないのに FactoryBot の create_list を使っている」といった、機械で判断できるはずの指摘を、エンジニアがわざわざ貴重な集中力を使って拾っていました。
レビュー待ちによる「コンテキスト・スイッチ」の負荷 PRを出してもレビューが返ってくるまでの「待ち」が発生し、その間に実装者が「何を考えていたか」を忘れてしまう。これが手戻りコストを増大させていました。

そこで、「機械的に判断できる一次チェックは、すべてAIに任せる」 という方針にしました。

GitHub CopilotによるAIレビュー

backend-review Skill の SKILL.md では、コメントの分類プレフィックスを定義し、レビュイーが優先順位を判断しやすくしています。

プレフィックス	意味	対象の例
`[must]`	必須修正（セキュリティ・バグ等）	N+1、未実装メソッドの呼び出し
`[recommend]`	推奨（可読性・イディオムの改善）	より良いRubyらしい書き換え
`[nits]`	軽微な指摘（スタイル、タイポ等）	変数名、スペースの微調整

特に不具合につながりやすいActiveRecord周りは、専用の参照ファイルを用意して観点を尖らせています。

例：JOINパターンのチェック

# ✅ GOOD: モデルに定義したスコープを merge で再利用しているか
scope.joins(:billing_destination).merge(BillingDestination.missing_bank_account)

# ❌ BAD: 直接条件を書き込んで一貫性を下げてないか
scope.joins(:billing_destination).where(billing_destinations: { bank_account_number: nil })

その他、AIは「メソッドが本当に定義されているか」をコードベースから確認し、未実装であれば [must] で指摘したり、N+1修正のPRであれば「クエリ回数が比例して増えないことを確認するテストコード」の追加を求めたりします。

AIと人間の「役割分担」がもたらした相乗効果

AIと人間の棲み分けを整理すると、以下のようになります。

観点	AIの役割	人間の役割
Typo・規約違反	✅ 得意（秒速で指摘）	△ 見落とすし、時間がかかる
テストの網羅性	✅ チェックリストに忠実	△ 漏れやすい
N+1・パフォーマンス	✅ パターンで見抜く	✅ 経験ベースで判断
ドメインロジック	❌ 困難	✅ 得意（本来注力すべき点）
アーキテクチャ設計	❌ 困難	✅ 得意（議論すべき点）

「規約や単純ミスはAIに任せ、人間はドメインロジックや設計の妥当性に集中する」。 この棲み分けができてから、レビューの質とスピードは格段に上がりました。

また、SKILL.md 自体が「チームの資産」としてコードベースに残るため、新メンバーのオンボーディング資料としても非常に優秀な役割を果たしてくれています。

3. (デリバリー) Change Logの自動化と運用

実装がマージされたら、いよいよデリバリーです。私たちのチームでは、社内wikiを通じて、CSやセールスといった「エンジニア以外のメンバー」にも伝わるリリースノートを公開しています。

記憶に頼らない Change Log 運用

1週間スパンでリリースを回していると、直前に「何を変更したか」をすべて思い出すのは至難の業です。そこで私たちは、「記憶が新鮮なうちに、PR単位でchangelogを書く」 という運用を徹底しています。

changelogは changelogs/{Issue番号}.yml として保存。カテゴリは 機能追加・仕様変更・不具合修正 の3つです。

仕様変更:
  - |
    オーナー宛請求書に印字済みのテナント請求を削除できるようにしました。
    （中略）印字エントリを同時に削除するよう変更したため、削除が可能になりました。

「リリースノート生成」の自動化

「changelogを書いて」と一言伝えるだけで、AIが git diff から変更を読み取り、YAMLを自動生成します。エンジニアは内容の微調整だけで済みます。

git diff main で差分を取得
ブランチ名からIssue番号を特定（例: feature/#12345 → 12345）
changelogs/{Issue番号}.yml を生成

changelogがmainにマージされたら、リリースタグを切り、リリースノートの作成に移ります。以前はフォーマットに沿った書き換え作業に時間がかかっていましたが、generating-release-notes というAgent Skillを作って運用するようにしました。

入力するのはマイルストーン番号とリリースタグのURLだけです。Skillは以下を自動で行います。

ステップ	処理内容
Step 1	マイルストーンから「要求」ラベルのIssueを取得し、背景・完了条件を読み取る
Step 2	GitHub Releasesのchangelogを取得
Step 3	要求Issueとchangelogエントリを突き合わせ、対応する実装PRを特定
Step 4	フォーマットに沿ってリリースノートを生成
Step 5	変更内容に登場する専門用語の解説テーブルを自動生成

Skillの内部にはチェックリスト（フォーマット通りか、丁寧語が統一されているかなど）も組み込まれており、生成品質を一定に保てます。

運用してわかったメリットと今後の課題

Skill化してから実感した具体的なメリットは以下の通りです。

フォーマットに合わせた書き換え作業が減り、誤字脱字などの基本的なミスが発生しない
書く人によってフォーマットや粒度のばらつきがでない
リポジトリの内容から読み取って、専門用語の解説テーブルを自動生成してくれる

一方で、どの機能が変わったかを伝えるためにスクリーンショットを多く使っており、その取得はまだ手動作業です。今後は自動化できるとよいと考えています。

おわりに

人間がAIを上手く使い、ユーザーに価値を届けるためにできることを最大限考えながら、品質とスピードの向上を目指して私たちが磨きをかけている「AIを活用した開発フロー」いかがでしたでしょうか？

まだまだ改善すべき点はありますが、このプロセスにさらに磨きをかけ、より良いプロダクトへと育てていけるよう、これからもチームで頑張っていきたい思います。

最後に、チームのみんなからの一言です！

Jully：

changelogのセクションを書いた南です。
日々開発プロセスの改善のアイデアがでて、一人ひとりがAIを使った改善を進めています。
今回その雰囲気が少しでも伝わっていたら嬉しいです。

のぶ：

全体の校正を担当した加藤です。
今回ご紹介した事例以外にも、GitHub Actionsを活用して、
PRマージ時にレビューコメントを自動抽出して既存のSKILLファイルを更新（追記・編集）するという「プロセスの自己進化」を実践しています。
精算管理チームの最近の合言葉は「それ、AIで一撃では？」です。

ぬーま：

AIを使ったレビューフローを担当した沼崎です。ここ数ヶ月でAIの進化に驚きが隠せません。
今まで課題となっていたところAIによって改善することができ業務の効率が格段に上がりました。
今後AIはもっと進化し人間は目の前の仕事に注力できるようになることをとても期待しています。

かず：

最後までお読みいただき、ありがとうございました！
昨今、業界全体でAI活用というキーワードが飛び交い、焦りを感じることもあるかもしれません。
しかし、私たちが本当に大事にすべきなのは、AIを導入すること自体ではなく、
エンジニアが真に価値のある業務に集中できる環境を作ることだと考えています。
本記事が、日々の開発プロセスやAIの実務導入に悩む皆さまにとって、少しでも現状を打破するヒントになれば幸いです。

ななみん：

「はじめに」と「おわりに」を担当した田中です。
最初はGeminiで文章を生成してみたのですが、やはりAI感が出てしまい魂が宿らない文章になってしまいました。
が、文章の校正・校閲はAIにお願いして見やすい文章になったと思っています。
人間が得意なところとAIが得意なところをそれぞれ活かして使い分けながら、これからも開発プロセスをより良くしていきたいです。

最後までお読みいただき、本当にありがとうございます！！！