こんにちは、Schooでエンジニアリングマネージャーをしているタキザワです。

ChatGPTやClaude Codeなどのプロダクトも深化しており、
今や、AIを活用した開発はそこまで珍しいものでもなくなってきました。

今、Schoo開発組織では、いかにAIエージェントと共創するかという課題に向き合っています。
そこで、この記事では、Schooの所属メンバーが最近取り組んでくれたことを、私の視点から紹介したいと思います。

今回の取り組みでは、主に下記のツールについて触れています。

Gemini Gem
Repomix
Code Rabbit
GitHub Copilot

事例1. 実装仕様の質問に答えてくれるAIエージェント（Gemini Gemの活用）

まずは、夕食後にお子さんとゲームするのが日課という @schoo_tetone さん（以下、てっとん）の取り組みを紹介します。

課題: ソースコードを読み解くのに時間がかかる

プロダクトに関する詳細仕様を把握したい場合には、ソースコードを読み解くのが最も正確な理解になります。
しかし、10年以上開発運用してきたサービスにおいては、これがなかなか容易なことではなく、どうしても時間がかかってしまいます。

DeepWikiやGoogle Code Wikiのようなことができれば良いのですが、実現には時間とお金がかかるので、今Schooで使えるソリューションで上手く工夫できないものかと考えました。

解決方法: Gemini Gemを活用する

Schooでは全社員がGoogle Geminiを活用できる環境になっています。

てっとんは、ソースコードの情報を知識として有するGemini Gemを作成するというアプローチでこの課題を解決してくれました。

Geminiを利用することで、非エンジニア職（例えばプロダクト企画職）の方も利用しやすい仕組みになっています。

工夫: Repomixを活用

Gemini Gemには知識としてリポジトリと連携できる機能があります。
しかし、リポジトリ連携したGemを他の人に共有するのはアクセス権管理の手間がかかる という困難が立ちはだかりました。😢

この困難に対して、リポジトリをファイル化し、それを知識として使うというアプローチをとりました。
具体的には、リポジトリの内容をAIとの親和性が高いファイルに統合するソリューションの一つに
Repomixがあり、今回はこれを使ってみました。

自動化まではしていないので、更新性の高いリポジトリには運用面での課題がありつつも、
どちらかと言えば、最近手を入れていない部分の実装仕様を確認したいことが多いので、そこまで問題にはならなさそうです。

良かったこと

将来的にはGoogle Code Wikiなどの活用も視野に入りますが、
今のところは少ない労力と費用で欲しいものが作れたので良かったと思います。

また、非エンジニア職の方が、わざわざエンジニアにイチから教えてもらわなくとも、
これで大まかな情報を把握して、知りたいことの解像度を高めた上で、
エンジニアとコミュニケーションを取れるようになったことも、課題解決の面で一役買っていそうです。

事例2. 良い感じにコードレビューをしてくれるAI（Code Rabbit）

次は、最近、体重の変化が気になっているという @junichi_fukushima_schoo さん（以下、ふくさん）の取り組みを紹介します。

課題: コードレビューに時間がかかりすぎて開発体験とシステム品質が低下...

AIの活用で、Schooでも圧倒的なスピードで実装ができるようになりました。
すると、今度はコードレビューがボトルネックとなり、全体プロセスとしてはそこまで速くなっていない、という状況に直面するようになりました。
無理に速くしようとするとコードレビューが雑になり、システム品質が下がってしまいます。

レビュアーは「レビューが多くて大変」、レビュイーは「レビューで止まるのでマージできない」という苦しい状況になっていました。

解決方法: Code Rabbitを使ってみる

ふくさんは、「システム品質、レビュアー、レビュイーの三方良しの世界」を志向し、
その理想に近づくべく、Code Rabbitの導入を提案してくれました。

ソリューションの効果的な活用にあたり、特に下記の点に注力しました。

エージェントが正しく動ける環境を作ること
きちんとメンバーに啓蒙していくこと

工夫: エージェントが正しく動けるように情報を集約する

それまでNotionなどのナレッジ管理ツールとGitに分散していた情報を、すべてリポジトリ内（ .coderabbit.yaml や docs/ 配下など）に集約しました。

ソースコード
人間が読むためのアーキテクチャ/設計資料
AIレビューへの指示ドキュメント
AIコーディングをする時に読むドキュメント

また、AIへの指示書も併せて整備することで、精度も上げています。

良かったこと

Code Rabbitに漏れなく指摘してもらうことで、プロダクトのシステム品質を一定担保できています。また、レビュアーは些末な指摘から開放され、プロダクト品質のためのレビューに時間を割けています。レビュイーも素早くフィードバックを得てスピーディに改善対応を行えるようになりました。

開発プロセスにおいて、レビューと修正作業がスムーズに進むようになり、「システム品質、レビュアー、レビュイーの三方良しの世界」の実現に近づけている手応えを感じられています。

事例3. いい感じに作業してくれるAI（GitHub Copilot）

続いて、Schoo Swing開発の雄、 @thanhchungbtc さん（以下、Buiさん）の取り組みを紹介します。

課題: 簡単なタスクの対応はAIでやってほしい

Copilotはあくまで「補助」で、開発作業は自身で行う利用方法が多いかと思っています。

コード補完、生成
コード調査、ブレスト、ドキュメント作成等

2025年6月にVSCode Agentモードがリリースされ、簡単なツールであれば一発で作れる状況になりました。それを踏まえ、Issueの内容からプルリクエスト作成までを一貫して行わせることができるのでは、と考えました。

解決方法: GitHub Copilot Coding Agentの活用

Copilot Coding Agentを活用したタスクの作業については、既に何人もの方が取り組まれており、Qiitaでもいくつもの記事が見つかります。

なので、ここでは、Buiさんが試行錯誤を重ねた軌跡を紹介します。

Try-1: 課題管理システム(ITS)のチケットをそのままGitHub Issueに転記する

Schooでは別途、ITSを使用しているため、まずはITSのチケットの記載内容をそのまま、
GitHub Issueに転記して対応してもらいます。

結果は次のとおりでした。

バックエンド: ◎
フロントエンド: △

バックエンドはほぼ望むコードが得られたのに対し、
フロントエンドはUIズレなどが発生しており対応が必要でした。

ただ、@copilotにコメントすると対応してくれるため、
何回かやり取りすることで望むコードが得られました。

Try-2: Issueの説明を詳細にしPlanモードを活用する

次は、そのまま内容を転記するのではなく、VSCodeのPlanモードを利用して作業計画を立て、その結果をIssueに記載して対応してもらいました。

予めAIがコードベースを確認した上で作業計画を立てているため、Try-1よりコードの質が高まり、望むコードにたどり着きやすくなりました。

ただし、プロダクトがマルチレポ構成になっている関係で、
作業計画を立てる際に、それぞれのリポジトリに対し同じやり取りをする必要があり、
非効率的という課題も生まれました。

また、用語ブレが発生しており、仕様理解という面ではまだまだ改善の余地がありそうです。

Try-3: Copilotに事前に知識を渡す

マルチレポ構成の課題に対しては、VSCodeのWorkspace機能が役に立ちました。それぞれのリポジトリを同時に開くことができるため、効率的に作業ができるようになりました。

また、仕様理解の改善のため、下記の情報を .github/copilot-instructions.md に記載しました。

プロジェクトの概要
アーキテクチャ（フロントエンド/バックエンドの構成など）
コードルール
用語、機能の説明

ただ、今度はコンテキストの消費が早くなり、すぐに利用上限に達してしまうという問題に直面しました。

Try-4. 事前知識をスリムにする

2025年12月に、GitHubがSkills機能に対応しました。

.github/copilot-instructions.md には最低限の情報を記載し、特定の情報はスキルとして定義することで、コンテキストの消費を抑えることができました。

良かったこと

様々な試行錯誤を重ねつつCopilotに実装をさせてみることで、色々と便利な面が見えてきました。

Copilotが担当していないプルリクエストについても @copilot で修正を依頼させれば対応してくれる
例えば外出先など、開発環境を利用できない状況においても作業を進められる

簡単な業務について、コードを書くよりも、情報整理や指示、レビューなどに役割をシフトさせられています。

事例4. 運用保守をAIに任せて見えてきた「エンジニアとしての土台知識」の重要性

最後は、スポーツ観戦やサウナ、ドライブが好きな25年新卒入社の @takumi_hashimoto さん（以下、はっしー）が取り組みの中で見えてきた学びについての紹介です。

課題: 保守運用にかかるコストを減らしたい

現状では保守運用にも一定の時間を割いていますが、機能開発との時間のバランスが少し悪くなっており、理想としてはもっと機能開発に時間を使いたいところです。

はっしーはエラー通知チェック、バグ改修、機能実装などの運用保守業務を行う中で、AI活用によってこのコストが減るのではないかと考え、問題提起してくれました。具体的には、問題箇所の特定、設計、実装、テストという一連のフローのうち、いくつかのプロセスをAIに担わせることで工数を削減し、より価値のある開発に集中できる状態を目指せるのでは、と考えてくれました。

しかし、はっしーとの対話を重ねる中で、保守運用に時間がかかっている要因がはっしーの中にもあることが見えてきました。

解決方法: GemとCursorを活用して素早く「あたり」をつけ、Cursorで計画を立てる

何かの保守作業が必要となったときに、事例1でも紹介した、てっとんが作ってくれたGemを活用して「あたり」をつけ、CursorのPlanモードを用いて、設計からテストケース作成、実装までを一気に進めるフローを試しました。

気づき: AIの作業を評価するための基礎知識が足りていなかった

この取り組みを通して以下の壁にぶつかりました。

AIが提案したA案とB案のどちらが良いのかが判断できない
AIが生成したコードに一貫性がなく、レビュアーによるレビュー指摘が減らせていない
- 既存のコードと違う実装になっている
- すでにあるメソッドを使っていない
- etc...
同じプロンプトでもアウトプットが毎回異なる
AIが生成したテストケースの文言が、プロダクト独自の用語と乖離していることに気づけない

AIにタスクを任せれば任せるほど、そのアウトプットを正しく評価するための『エンジニアとしての土台知識』が、より一層問われることに気づきました。

これから: AI時代において今後の新人のためにできることをやる

取り組みを通して、運用保守の効率化から、エンジニアとしての土台知識の重要性に課題感がシフトしていきました。

新卒エンジニアがいつでも参照できる「Schooの設計思想」をAIに学習させ、判断基準を揃えたり、プロダクト独自の名称やロジックをドキュメントとして管理し、AIが参照できるようにすることに取り組んでみようと考えています。

おわりに

いかがだったでしょうか。SchooではAIも積極的に学び、取り入れ、業務で効果的な利活用ができるよう、日々研究しています。

特に事例4は若手エンジニアの取り組みの紹介でしたが、私はこの事例から若手エンジニアの能力評価や育成の優先度をアップデートする必要性を感じました。
いままでは、いかに若手自身が高速・高品質なソフトウェア製作をできるようになるか、というスケールアップを狙い新人育成方針を組み立てていましたが、今後はいかに手段を使って高速・高品質なソフトウェア製作をさせるようにできるか、というスケールアウトも狙いに持った方針を変えていくことが必要なのではないかと考えています。

最後に、このような取り組みの原動力となっている、Schooのフィロソフィーを引用し紹介します。

Laboratory #105

「Laboratory（ラボラトリー） #105」とは、まだ世の中にない価値を生み出し続ける研究所であるべきという、Schooの根幹の精神を表現しています。「105」は、創業時に事務所を構えていたマンションの部屋番号。どれだけ企業の規模が大きくなっても、創業当初の想いを忘れずにチームで実験し続けるという意思を表しています。 私たちは、まだ世の中にない価値をつくり続ける「研究所」として、他社・他者の模倣をよしとせず、“Schooだからこそ”の価値を発明し続けていきます。

本稿が皆さんの今後のAI活用のヒントとなれば幸いです。

Schooでは一緒に働く仲間を募集しています！