はじめに

この記事は、エンジニアのリソース不足に悩むプロダクトマネージャーや、AIを活用して他職種との協働をスムーズにしたいエンジニア向けの記事です。結論として、Issueの運用ルールを整え、GitHub ActionsとAIを組み合わせることで、エンジニア以外でも安全に開発を回せる仕組みを実現しました。

背景

弊社には技術広報チームがあり、dip people という採用オウンドメディアを運営しています。

オウンドメディアは、記事を公開して終わりではありません。新しいコンテンツを追加するだけでなく、導線を見直したり、表示件数を調整したり、文言を変えたり、細かな改善を継続していく必要があります。

一方で、そのたびにエンジニアの工数を使っていると、事業プロダクトの開発とメディア運営の両方で開発リソースを取り合うことになります。特に、文言変更や表示調整のような小さなメンテナンスは、技術広報チーム自身が意図を定義し、GitHub上で進められる状態にしたいと考えました。

そこで、dip people の開発・メンテナンスにエンジニアの工数をできるだけ使わず、Issueを起点にAIが実装まで進める仕組みを導入しました。この記事では、その運営方法として、Issueにフラグを付けるだけで開発を進める自動処理について説明します。

Issueにフラグを付けるだけで開発が進む仕組みを作った

「AIで開発しています」と聞くと、エンジニアがAIにコードを書かせる様子を想像する人が多いかもしれません。

しかし、私たちが作りたいのはそれだけではありません。エンジニアではない人でも、やりたいことをIssue（タスクや要望を書く場所）に整理し、GitHub上でフラグを付けるだけで、実装、Pull Request（変更提案）の作成、検証、レビュー依頼まで進められる状態です。

つまり、AIを「コードを書く道具」としてだけ使うのではなく、開発工程そのものに組み込む取り組みです。

作ったもの

GitHub Issueに ai-coding-automation というラベルを付けると、GitHub Actions上でCodexが起動し、そのIssueの内容をもとに実装を行います。CodexはOpenAIのAPIを使っています。

流れはシンプルです。

GitHub Issueに「やりたいこと」を書く
Issueに ai-coding-automation ラベルを付ける
CodexがIssueを読み、必要な変更を実装する
変更内容からPull Requestが作られる
コードの書き方チェック、テスト、ビルド、画面が開くかの確認が走る
条件を満たせば自動マージ、満たさなければ人にレビューが回る
Issueには成功・失敗の結果がコメントとラベルで残る

GitHubのラベルは、ここでは「開発を開始するフラグ」として使っています。依頼者はローカル環境を立ち上げる必要も、コマンドを実行する必要もありません。Issueに何をしたいかを書き、フラグを付けるだけです。

全体の流れを図にすると、次のようになります。

大事なのは、AIに任せる前の工程を整えること

この仕組みで一番重要なのは、AIそのものではなく「Issueに何を書けば開発が進むのか」を決めておくことです。

AIは曖昧な依頼でも何かしらの答えを返してくれます。しかし、商用サービスの開発では「何か作れた」だけでは不十分です。意図した体験になっているか、既存の画面を壊していないか、検証できるか、レビューできるかまで含めて開発です。

そこで、Issueには次のような情報を書く前提にしています。

何を変えたいのか
誰のための変更なのか
完了条件は何か
触ってよい範囲、触ってほしくない範囲はどこか
表示文言やデザインの希望があるか
確認してほしい観点は何か

たとえば、次のようなIssueなら、エンジニアではなくても書けます。

## やりたいこと
採用トップページのニュース欄で、最新3件だけでなく最新5件まで見えるようにしたい。

## 背景
イベント告知が増えており、トップページで見える情報量を少し増やしたい。

## 完了条件
- トップページのニュース表示が5件になる
- PCとスマートフォンで表示崩れがない
- 既存のニュース詳細ページや一覧ページの挙動は変えない

## 注意点
デザイン全体は変えず、件数だけを変更したい。

このように「やりたいこと」と「変えてはいけないこと」を書けると、AIが実装しやすくなり、人もレビューしやすくなります。

裏側でやっていること

今回の仕組みでは、GitHub Actionsの自動処理を複数組み合わせています。

Issueに ai-coding-automation ラベルが付いたら、まず対象のIssueを選びます。ラベルが付いたそのIssueだけを処理し、成功・失敗ラベルへの付け替えでは再実行しないようにしています。これにより、同じIssueが無限に動き続けることを防いでいます。

次に、CodexがIssueのタイトルと本文を読み、実装に必要な差分を作ります。このとき、Codexには書き込み権限を持たせていません。AIが直接ブランチを作ったり、pushしたり、Pull Requestを作ったりするのではなく、AIは差分を作るところまでを担当します。

作られた差分は一度パッチとして保存し、別のクリーンな処理で適用します。その処理がブランチを作成し、コミットし、stg 向けのPull Requestを作ります。

この権限分離はかなり重要です。AIに全部の権限を渡すのではなく、AIが担当する範囲と、GitHub Actionsが担当する範囲を分けることで、運用しやすくしています。

成功・失敗もIssueに戻す

ラベルを付けたあと、利用者がActionsのログを読みに行かないと結果が分からない状態では、エンジニア以外には使いづらい仕組みになります。

そこで、結果はIssueに戻すようにしています。

Pull Requestを作れた場合は、ai-coding-automation-done ラベルを付け、IssueにPRリンクをコメントする
差分がなかった場合や失敗した場合は、ai-coding-automation-failed ラベルを付け、理由とCodexの最終メッセージをコメントする
再実行したい場合は、もう一度 ai-coding-automation ラベルを付け直す

これにより、Issueを見るだけで「AIに依頼した結果どうなったか」が分かります。

自動で進めるが、無条件ではマージしない

AIがPull Requestを作ったあとも、そのまま無条件に本番相当の流れへ進めるわけではありません。

Pull Requestに対して、コードの書き方チェック、テスト、ビルド、画面が開くかの確認を実行します。さらに、Codexによる構造化レビューも行い、Issueの内容を満たしているか、重大な指摘がないかを確認します。

自動マージできるのは、あらかじめ人レビュー必須としているファイルを触っておらず、テストやビルドが通り、構造化レビューでも問題がない場合だけです。.github/、scripts/、package.json、設定ファイル、環境変数まわりのような変更は、人が見るべき領域として扱います。

つまり、「AIだから全部通す」のではなく、「AIが進めてもよい範囲を決めて、その範囲だけ自動化する」設計です。

技術広報にとって何が変わるか

この仕組みがあると、技術広報の役割は「エンジニアに口頭でお願いすること」から「Issueでやりたいことを定義すること」に変わります。

Issueに残すことで、背景、目的、完了条件、判断理由がGitHub上に集まります。AIも人も同じIssueを見て作業できます。あとから「なぜこの変更をしたのか」も追いやすくなります。

また、エンジニアにとっても、すべての依頼を最初から手で実装する必要がなくなります。AIが最初の差分を作り、機械チェックを通し、必要な場合だけ人がレビューする形に近づきます。

商用サービスでもAI前提の開発へ

私たちは、商用サービスの開発でもAIを使った開発にかなり振り切り、実装の進め方そのものをAI前提に変え始めています。

もちろん、商用サービスでは安全性、品質、説明責任が必要です。だからこそ、ただAIに作らせるのではなく、Issueの書き方、ラベル運用、権限分離、テスト、レビューゲート、失敗時の戻し方まで含めて工程として設計する必要があります。

今回の「Issueにフラグを付けるだけで開発が進む」仕組みは、その第一歩です。

今後は、さらに細かい仕組みを導入していきたいと考えています。たとえば、Issueの種類ごとにAIの担当範囲を変える、デザイン確認を別のチェックとして分ける、文言変更・UI変更・データ取得変更などで承認フローを変える、といった形です。

最終的には、商用サービスでも「Issueでやりたいことを定義すれば、AIが実装し、検証し、必要なレビューへ回し、リリース可能な状態まで持っていく」開発に近づけていきたいです。

まとめ

AI開発で大切なのは、AIに何を頼むかだけではありません。

誰が、どこに、どの粒度で依頼を書き、どの条件なら自動で進め、どこから人が見るのか。その工程を整えることで、エンジニアではない人でもGitHub上で開発を前に進められます。

Issueにやりたいことを書く。フラグを付ける。AIが実装する。Pull Requestと検証結果を見て判断する。

この流れを当たり前にできれば、開発はもっと開かれたものになります。AIを使った開発は、エンジニアだけの生産性改善ではなく、プロダクトに関わる人全員が開発に参加しやすくなる仕組みだと考えています。