こんにちは！LayerXでモバイルエンジニアをやっているたまねぎです！
最近は朝9:30頃にランチを食べる習慣がついてしまい、この記事を書いた日はとんかつ弁当を9:30に食べ終えました！おいしかったです！！！

先日、チームメンバーのyoheiさんが書いたブログで「AI First」な働き方を発信しました。 AIと共に進化するエンジニアへ：モバイルアプリチームが目指す「AI First」と「越狂」な働き方 - LayerX エンジニアブログ

今回の記事では、それも踏まえてチームで定期的に開催しているテックイベントについて、ご紹介いたします。

オープニング

早速ですがAI Firstを実践して、このブログの予告PVとテーマソングをAIに作ってもらいました。
まずはこちらをご覧ください。

オープニングテーマ

それでは満を持して本編に入っていきたいと思います！！

No Coding, AI Code Day

No Coding, AI Code Day とは

“人間はコードを書かず、AI だけがコーディングしていい日”

「AI が書くほうが速くて正確」という未来を前提に、丸１日チーム全員が Cursor / Devin / Cline / Roo Code など、AIツールに“Full Bet”する実験イベントです。

ゴールは 「AIの活用に関する知見を貯めて共有すること」。

公式ソングもあります。 <a href="https://suno.com/song/22c139c4-2980-4bce-86ae-a279a8d0821b">Listen on Suno</a>

上記内容で、実際にチームメンバー全員でHappy Vibe Codingしてみました。

やってみて分かったこと

以下のように、規模によってAIの活躍度合いが変わりました。

規模	AI だけで完結？	メモ
小規模（ツール、スクリプト、小さなバグ修正）	◎ 完全自動でOK	人間はレビューに徹するだけで十分
中規模（重ためのバグ修正、小さめの機能開発）	○ 7割AI＋3割人	仕様の解釈や意思決定は人間がやる方が効率的
大規模（大きめの機能開発やリファクタリング）	△ 人間主導が無難	AIと設計を入念に実施し、タスクを細かく分割していくことでアウトプットの精度は上げられる

あくまで2025/04時点での評価のため、数か月後には全く別の結果かもしれませんが、人間が介在するポイントはどこなのかを見極める指針がこの取り組みで見えるようになったかなと思います。

その上で、実際の成果物以外にも「AI活用」という観点での学びもありました。

“AI が暇しない”タスク設計が重要
- MTG やランチ中のデッド時間を活用することでアウトプット量を増やせる
- Cursor / Cline / Roo Code は１レーン集中型＝速くて正確だが並列には向かない
- Devin はフルリモート実行できるので同時並行がラク
環境分離の工夫もできる
- AI 専用 workspace をディレクトリごと分けたり、 git worktree などを活用して、AIも人間も手が空かないようにするといったことは可能
- 一方コンテキストスイッチのコストが増加したり、マシンスペックが求められるトレードオフがある
ツールごとの特性を理解し使い分ける必要がある
- Devin：明確な指示出しが必要で、Devin自身に考えさせることは最小化させた方がいい（Knowledgeが溜まるとまた変わってくるかもしれない）
- Cline/RooCode：AIと設計を議論して明確にする→実装を開始するの流れでアウトプットが良くなる
- Cursor：何でも屋として、開発に閉じないAIエディタとしても活用できる

AIを開発フローに組み込む

また、AIの活用は「コーディング」だけでは勿体無く、レビューやナレッジ整理なども任せられる力を十分持っていることも確かめられました。
開発フローの中で、コーディング以外の AI活用ができたポイントを 2 つ紹介します。

1. PR 作成＆コードレビューの全自動化

1つ目は人間が行っていた作業をAIに行ってもらうというアプローチです。 PR作成とコードレビューをAIに任せることが可能になっています。

利用ツール: Cursor（Cline / Roo Code でも可）
実行方法: チャットに create pr と打つだけ
裏側のフロー（CursorRule で定義）
1. PR Descriptionを自動生成
  - タイトル／目的／やったこと／やらなかったこと／QA 観点
2. AI コードレビュー（ローカルで即フィードバック）
3. 関連ドキュメントの修正提案

プロンプト

# ワークフローの発動条件

ChatでPullRequestの作成or更新を依頼されたとき

# やること

以下の手順を順番に実施すること。
その際、いずれかのステップで中断条件に合致した場合は後続のステップを中止すること

~~ 省略 ~~ 

## 3. Pull Requestの作成

1. 変更内容の把握
  - 現在のブランチとリモートのdevelopブランチの差分をチェックして、どのような変更が入ったかをキャッチアップしてください
  - `git diff origin/<ターゲットのブランチ名> | cat`
2. Pull Request Titleの作成
  - 変更内容を踏まえて内容を端的に表すタイトルを作成してください
3. Pull Request Descriptionの作成
  - @pull-request-desciption.mdc のルールを用いて、変更差分を踏まえた内容を作成し、以降のコマンドの入力に使ってください
4. Pull Requestの作成
  - 下記のコマンドを実行してPullRequestを作成してください

gh pr create 
  --title "<2で作成したTitle>"
  --body $'<3で作成したDescription（マークダウン形式を壊さないこと）>'
  --assignee "@me"
  --repo LayerX/Repository
  --head <現在のブランチ名>
  --draft

  - もし、すでにPullRequestが作成済みだった場合はTitleとDescriptionの更新のみを行なってください
  - 更新する場合は以下のコマンドを実行してください

gh pr edit <PR番号>
  --title "<2で作成したTitle>"
  --body $'<3で作成したDescription（マークダウン形式を壊さないこと）>'

5. 作成したPull RequestのURLを提示
  - 開発者が確認しやすいよう、作成したPullRequestを確認できるWebページのURLを提示してください
  - この時、1クリックで対象のページに飛べる形で表示してください

## 4. コードレビューの実施

1. 作成したPullRequestに対してコードレビューを実施してください
  - コードレビューの具体的な手順については @code-review-workflow.mdc の内容を徹底してください
  - レビュー結果はPull Requestに直接コメントする必要はありません
  - Chatのコンソール上に結果をフィードバックしてください

~~ 省略 ~~

実行イメージ（一部省略）

AIによるレビューは、Copilot Code ReviewのようにGitHub上にコメントを書かせるというアプローチもありますが、エディタ上でのレビューには以下のようなメリットがあります。

手元で即時にフィードバックされる
フィードバック内容をそのままAIに修正させられる
チャットで対話しながらコメント内容を深掘りしていける

これにより、“AI に指摘させる → その場で AI 自身に直してもらう” サイクルで、ノンストップで対応を進めることが可能となりました。
一方、レビュー内容やQA観点はまだまだ改善の余地がある状態なので、今後もTryできそうな改善ポイントがまだまだありそうです。

2. ルール & ドキュメントの自動アップデート

2つ目は、人間同士の議論をAIが解釈して自動でナレッジ生成をさせるアプローチです。

これまでは人間同士の会話情報は意識的にドキュメント化しないと、ナレッジとして抜け落ちてしまう課題がありました。
これをコードレビューの面で改善する手段として、PRマージをフックにして、GitHub上でのレビューコメントから自動でルールを生成する仕組みを動かしています。

これにより、 “議論 → 知見化 → リポジトリへ蓄積” が自動で実行されるようになり、ナレッジが チームの資産 として残りつづけるようになりました。
結果的に、共通認識の言語化ができ、AIへのインプットも増やすことが可能になっています。

プロンプト

name: Devin Cursor Rules Review

on:
  pull_request:
    types: [closed]
    branches: [develop, 'release/*']
    paths:
      - '**.dart'

jobs:
  create-devin-session:
    if: github.event.pull_request.merged == true
    runs-on: ubuntu-latest
    steps:
      - name: Create Devin Session
        env:
          DEVIN_API_SERVICE_KEY: ${{ secrets.DEVIN_API_SERVICE_KEY }}
          PR_URL: ${{ github.event.pull_request.html_url }}
          PR_NUMBER: ${{ github.event.pull_request.number }}
          PR_AUTHOR: ${{ github.event.pull_request.user.login }}
          REPO_NAME: ${{ github.repository }}
          REPO_OWNER: ${{ github.repository_owner }}
        run: |
          curl --request POST \
            --url https://api.devin.ai/v1/sessions \
            --header "Authorization: Bearer $DEVIN_API_SERVICE_KEY" \
            --header 'Content-Type: application/json' \
            --data @- << EOF
            {
              "prompt": "以下のタスクを実行してください：\n
              1. リポジトリ ${REPO_NAME} の最近マージされたPR（${PR_URL}）の内容とレビューコメントを分析し、Cursorルール（.cursor/rules/*.mdcファイル）に取り込むべき知見やパターンを特定してください。\n
                 - ${PR_URL} 以外のPRの内容は考慮しないこと。\n
                 - この時、コードのコンテキストも考慮し、特に再利用可能なパターン、一般的な問題、またはCursorルールのドキュメントに追加する価値のあるベストプラクティスの抽出に焦点を当ててください。\n
                 - 汎用性のないルールは必要ありません\n
                 - コメントにmust, wantがついているものは優先的に取り込むべきもので、imoやnitsはコンテキストに応じて取り込むべきか判断してください。\n
                 - ルールへの記載について、元となったPRの言及などは必要ありません。\n
              2. Cursorルールを更新すべき領域が見つかった場合：\n
                 - ${REPO_NAME} の \`develop\`ブランチに対して、\`devin/cursor-rules-update-pr-${PR_NUMBER}\`という名前の新しいブランチを作成\n
                 - .cursor/rulesディレクトリの関連する.mdcファイルに必要な変更を加える\n
                 - 「PR #${PR_NUMBER} の知見に基づくCursorルールの更新」というタイトルでPRをOpenする\n
                   - それ以外の余計な情報は記載しないこと\n
                 - PRのDescriptionには、元となったPRのURL、特定したパターンとそれらをCursorルールに追加すべき理由を説明してください\n
                 - PRのレビュワーには、元のPRの作成者（${PR_AUTHOR}）をアサインしてください。\n
                 - 特に修正の必要がない場合はPRを作成せず、セッションを終了してください。",
              "idempotent": true,
              "max_acu_limit": 3,
              "tags": ["cursor-rules-update", "automated"]
            }
          EOF

実行イメージ

以上が、No Coding, AI Code Dayの振り返りです。

Hack Day

次にHack Dayをご紹介させてください。

Hack Day とは

“好奇心 50 ％、ユーザー要望 50 ％。”

普段はユーザーの要望ベースの開発が大前提。

Hack Day だけは 技術ドリブン／やりたいことドリブン を強めに振りつつ、「本当に使われるのか？」 についても最低限押さえながらアイデアを爆速で形にするチーム内ハッカソンです。

開催初期は「やりたいこと」に強くウェイトを置いていたのですが、私たちのチームは「ユーザーの課題を解決したい」ということを最重要ミッションとしているため、ハッカソンではありながら「ちゃんと使われる機能も目指す」という方針を立てたイベントとなっています。

進め方

事前準備：開催前に PdM も交えて「どんな課題を誰に届けたいか」を議論
価値検証フローの軽量化：Factデータの調査や要望確認を事前に実施 → Hack中の方針ブレを防止
“Hack” と “リリース” の両立：「技術・アイデアの自由度」と「ユースケース検証」のバランスを取る

上記の流れで進めることで、以下のような効果を得ることが出始めてきました。

普段の開発では手を出しづらい領域への挑戦が可能
“おもしろい” だけで終わらず、リリースや今後の開発のベースとなるプロトタイプをアウトプットできる

また、Hack Day 2ではAI開発ツールのフル活用もしたので、より高速にアイディアを実現できるようになりました。
もちろん公式ソングもあります。

↓これまでの開催概要

開催	日付	テーマ	主な実装内容
#1	2025.01	申請の承認体験を最高にする	Widgetを活用したやることリストの提示 LiveActivityを活用した承認リマインダーレシートと入力フォームの比較UI探索（横画面対応・画像ピン留め）連続承認の体験探索
#2	2025.04	AIを活用して、申請の作成体験を最高にする	カメラ周りの大幅機能改善レシート自動抽出写真ファイル×端末データの自動突合 LLMによる申請の自動作成

このイベントは、AIを単に開発のツールとして使うだけでなく、AIを組み込んだサービス改善に取り組めているという点で、より踏み込んだアクションに繋げられています。
最悪リリースまではいかなくてもその過程で得られた学びなども大きく、今後は機能開発だけでなく「業務改善」というテーマで開催してみるのも面白いかなと考えています。

まとめ

最後にこれらの活動を通して得られた所感のまとめになります。

AIの活用は開発の一部ではなく“全体”へ
- No Coding, AI Code Day でAIによる開発はすぐに主流になることを実感
- PR 作成・レビュー・ドキュメント更新までも　委譲できることがわかった
エンジニアの役割は “AI の舵取り” へシフト
- 文脈を与え、意思決定し、AI を並列に走らせることがメイン
- Hack Dayで人間はより「意思決定」や「クリエイティブ」に集中できることを実感
- ref. AIと共に進化するエンジニアへ：モバイルアプリチームが目指す「AI First」と「越狂」な働き方 - LayerX エンジニアブログ
ナレッジは “流さず・溜めて・育てる”
- 文書化されたデータの価値がより高まっていく
- ドキュメントをAIに渡す → AIが強化される → AI自身がドキュメントを強化する、の改善ループを繰り返すことで開発がドライブしていく
- これにより学びが開発フローに溶け込み、すぐにチームの武器にすることができる