はじめに
こんにちは、Lighthouse Studioでエンジニアをやっている きっちゃん です。
私の所属する Lighthouse Studio の開発チームでは、今年の4月からAIエージェントを活用して開発を効率化するために、「AI夕会」と題した定例を毎日行い、チーム全体で取り組みを進めてきました。 しかし、実際にチームで本格的な活用を始めてみると、すぐにひとつの現実にぶつかりました。
「今の開発プロセスのままAIを入れても、うまく使いこなせないのではないか」
この記事では、AI活用を目指した結果として、むしろ泥臭く業務改善に向き合うことになった半年間の試行錯誤をまとめます。
AIエージェントは「銀の弾丸」ではなかった
私たちはさまざまな AI エージェントを試していく中で、自律型 AI エージェントである Devin を導入しました。まずは試験的に、あらゆる開発タスクを Devin に依頼してみました。
Devin は文句も言わず、次々と PR（Pull Request）を作成してくれます。
「これで溜まっていたライターからの開発依頼を一気に消化できる」
そう期待したのも束の間、すぐに課題に直面しました。
「PRは出ているのに、マージまで辿り着けない」のです。
Devin は自律的に PR の作成まで進めてくれますが、仕様の考慮漏れや、人間側で修正を加える必要があるケースも多々あります。そのため、最終的には人間がレビューを行わなければなりません。
しかし、私たち人間はすでに自分自身のプロジェクトや MTG、優先度の高いタスクで手一杯でした。その結果、次のようなことが起きました。
- Devin のレビューをする時間が物理的に確保できず、PR が溜まっていく
- 無理にレビューしようとすると、人間が進めるべき「優先度の高いタスク」が圧迫される
- 優先度が低いタスクの PR ばかりが積み上がり、1ヶ月以上放置されるものも出てくる
AI が高速にボールを投げ続けた結果、受け手である人間のキャパシティが飽和し、チーム全体のフロー効率はむしろ悪化しました。
この経験から、私たちは「今のプロセスのまま AI という強力なエンジンを積んでも、事故を起こすだけだ」と痛感しました。
「AI夕会」で業務フローの課題に向き合う
「ツールを入れるだけでは解決しない。自分たちのフローを見直さないと」
そう気づいた私たちは、4月から毎日実施していた「AI夕会」の目的を変えました。
当初は「Devin の活用法の議論」や「各 AI エージェントの比較」といった、どちらかというとツールの使い方の議論が中心でした。それをやめ、次第に次のようなテーマを話す場へとシフトさせていきました。
- そもそも、普段の業務フローで辛いのはどこか？
- なぜ開発が詰まるのか？
議論を深めるために、Figma（FigJam）上に開発フロー全体を書き出し、チーム全員で「どこが辛いか」を付箋で貼り出していきました
そこで浮かび上がってきたのは、AI 以前の問題である、私たちの「開発プロセスの基礎的な課題」でした。
- 工数の見積もりが甘く、スケジュール通りにタスクが消化できていない
- タスク着手時の優先度認識と、レビュワーの認識にズレがある
- CI/CD が遅く、待ち時間が長い
こうした「当たり前の課題」をひとつずつ解消していくことこそが、結果的に AI 活用の近道なのだと捉え、泥臭い改善に向き合うことにしました。
「当たり前」をちゃんとやる
議論を通じて見えてきた課題は多岐にわたりますが、ここでは私たちが実際に取り組んだ改善の一例を紹介します。
1. レビューリソースの確保と調整
まずは、Devin 導入で最初にパンクした「レビュー体制」の立て直しです。
可視化してみると、メンバーそれぞれが抱えるプロジェクトや MTG が多く、レビュー依頼が来ても「物理的に見られない」状況が多発していることがわかりました。
そこで、毎朝のリソース確認を徹底するようにしました。
- 「今日は MTG が多くてレビューは無理」と正直に宣言する
- Slack で即座に「今は見られない」とアラートを上げる
- 空いている人にボールを回す
こうしたコミュニケーション量を増やす運用を通じて、レビューが滞留し続ける状況を緩和していきました。
2. 見積もりと実績の乖離を埋める
レビューだけでなく、スプリント運営自体の甘さも見えてきました。
スケジュールの遅延が頻発している原因を探るため、私たちは初めて自分たちの「消化速度の実測値」に向き合いました。
これまで、曖昧な基準でタスクの見積もりを行ってしまっていました。そこで、
- MTG などを除いた純粋な稼働時間
- 実際に消化できたタスク量
を数週間計測しました。
その結果、突きつけられた事実は、私たちが 1 時間あたりに消化できるタスク量は、想定していた量の半分しかなかった、というものでした。
私たちは、自分たちの実力の倍の速度で走る計画を立てていたことになります。これでは、AI を使おうが使うまいが、計画が破綻するのは当たり前です。
この事実を受け入れ、実測値をベースに計画を立てるように修正したことで、無理のないスプリント計画を意識できるようになりました。
3. 情報の整地（Asana to GitHub）
タスク管理を Asana から GitHub Issues / Projects へ移行しました。
これまでは、
- 要件は Asana
- コードは GitHub
と情報が分散しており、AI に指示を出す際にコンテキストを渡すのが手間でした。
そこで、GitHub Issue に情報を集約し、Markdown で記述する運用に切り替えました。これにより、LLM にとっての「読みやすさ」 が格段に向上します。
- GitHub Copilot や Claude Code などの AI ツールが、Issue のリンクひとつで背景から実装方針までを読み取れる
- GitHub 上で「この Issue やっておいて」「このレビューの指摘をもとに修正して」と指示するだけで、的確な実装が返ってくるケースが増えた
人間にとっての見やすさだけでなく、AI にとっての読みやすさを整備することが、エージェント活用に大きく寄与していると感じています。
整地された土地で、AIは「戦力」になる
こうした泥臭い改善（地ならし）を徹底し、情報を GitHub に集約したことで、ようやく AI を適切に活用できる土壌が整ってきました。
現在、私たちは AI ツールの特性に合わせて、次のように適材適所で使い分けています。
- Claude Code
- 日常的なコーディングで、エンジニアが「手足」として使う
- コーディング以外でも、ドキュメントや Issue / PR の作成などを強力に補助してくれる
- GitHub Copilot / Claude
- GitHub 上からタスクを依頼したり、レビューを依頼したりするなど、エンジニアの指示に応じて非同期的に働いてくれる
- Devin
- 環境構築が必要なタスクや、一連の自律的な試行錯誤が必要なタスク
- Devin Search による強力なコード調査（新卒やインターン生へ教えるコストも大幅に抑えられます）
- 「定型業務の自動化」や、非エンジニアがクラウド上のプレビュー環境をもとに指示を出せるプラットフォームとして活用
こうした日常的な活用に加え、よりフローそのものを変える取り組みにも手をつけています。
定型業務フローの刷新
これまでは、社内のライターからツール改修などの要望を Asana で受け、エンジニアがトリアージし、実装・リリースするというフローでした。
このうち、手順が明確な定型タスクについては、Devin に一任するフローへと移行しました。
- ライターが専用フォームに要望を入力する
- その内容を API 経由で Devin に依頼する
- Devin がコードを修正し、PR を作成する
このとき、Devin への指示プロンプトには、
- 明確な実装手順
- 修正すべきファイルパス
- 禁止事項
といった情報をテンプレートとして埋め込むことで、実装のブレを防いでいます。
エンジニアは、手元でブランチを切り替えたりエディタを開いたりする細々とした面倒な作業と、それに伴う脳のコンテキストスイッチから解放され、「上がってきた PR をレビューしてマージするだけ」でリリースができるようになりました。
ビジネス職からDevinへ直接依頼
さらに一部のプロジェクトでは、ビジネス職のメンバーが直接 Devin に修正依頼を出せる仕組みも試験運用しています。
エンジニアを介さずとも、整備したテンプレートに要望を入力してもらえれば、Devin が実装を行い、プレビュー環境まで用意してくれます。 ビジネス側のメンバーは、そのプレビューを見ながら要件を詰め、理想の挙動になるまで Devin とやりとりを完結できます。
もちろん、「エンジニア以外がコードを触る」ことにはリスクが伴います。そこで、このフローには明確なガードレールを設けています。
- 壊れても本体には影響しない範囲に絞る
システム全体に関わるような改修は対象外です。「記事内の特定の記法で呼び出されるツール」のように、そこが壊れても他へ影響が広がらない独立した機能だけを任せています。 - 「使わない」という回避策を用意しておく
万が一リリース後に不具合が見つかっても、その記法を使わなければシステムへの影響が出ない状態を担保しています。 - 最後はエンジニアがレビューしてマージする
ビジネス側で「思った通りの動きになった」と確認できたら、最後にエンジニアがコードレビューします。実装の試行錯誤は任せますが、コードの安全性や品質の最終責任はエンジニアが持ちます。
これにより、安全性を確保しながら、エンジニアのリソースを割かずにプロダクトの改善サイクルを回し続けることが可能になりつつあります。エンジニアの人数が開発のボトルネックにならないための、重要な挑戦だと感じています。
さいごに
この半年間を振り返って思うのは、「AIツールの導入効果そのものよりも、それを受け入れるためにチームが変わったことのほうが価値があった」ということです。
以前の Lighthouse Studio 開発チームは、それぞれのタスクをこなす「個」の力が中心のスタイルでした。 しかし、AI ツールを入れたことでプロセスに負荷がかかり、私たちは初めて、
- チームとしてどう動くべきか
- どこが非効率なのか
- もっとこうしよう
といったことを、毎日のように議論するようになりました。
AI ツール自体の進化も大きいですが、それ以上に、
「どういう課題を解決するために使うのか」をチームで話し合い、自分たちの手でプロセスを改善していく
この「チームのスタンスの変化」こそが、AI 導入がもたらした一番の成果であり、開発組織を強くした要因だと感じています。
AI は「銀の弾丸」ではありませんでした。 しかし、AI の圧倒的な生産力は、本来なら長い時間をかけて顕在化するはずだった「開発プロセスの構造的な課題」を短期間で浮き彫りにしてくれました。
そのおかげで、私たちは早急に課題に向き合うことができたのだと思います。
