みなさん、こんにちは。スタメンCTOのtakuya (GH: @tnir X: @tn961ir, @takuya_stmn) です。社内ではたくちゃんと呼ばれています。こちらはスタメンnoteリレー2025 23日目の記事です。tnirアドベントカレンダー 23日目も兼ねています。

2025年は、まさに「AIに始まりAIに終わった一年」でした。 冬から始まったAIエージェントの導入、全社展開、そして数多の失敗と成功。この激動の一年を振り返りながら、「AIで開発はどう変わったのか」、そして「AI時代のCTOは何を見るべきなのか」について、現時点での私の結論をお話しします。

❄️冬: エージェント導入の夜明け

2024年以前のAIツールを継続的に使いつつ、年末に発表されたGoogle Agentspace（現Gemini Enterprise）の利用検討開始、1月にはCursor, Devinの利用を開始するところから始まりました。

2月にはagent modeが出たことから慌ててOpenAI o3-miniとGitHub Copilot (agent mode) の記事を書きました。AIエージェントによる開発を進めていく中で課題と感じていたのがコードレビューでしたので、Geminiがベースのファウンデーションモデルとして利用されているGoogle Code Assist Enterpriseを導入したのが3月でした。

🌸春: 試行錯誤と「コンテキスト」の壁

4月は未経験エンジニアをCTO室直下で育成するプロジェクトを開始したり、RubyKaigi 2025 (松山) やGoogle Cloud Next 2025 (ラスベガス)、TSKaigi 2025 (東京) への参加もあり、GW明けの5月もRubyKaigiアフターイベント（複数）やVPoE Summitなどもあり、激動の中、あっという間に夏が来ていました。

ちょうどその頃Claude Codeが出てきてその性能は高いものだと認識したのですが、CLIは全社で幅広く使うのは難しい点と途中の思考回路がpull requestに記載されずコードレビューに含まれない問題に遭遇していました。

その流れを受けたことやGitHub Copilot Enterpriseで先行して利用可能になっていたGitHub Copilotのcoding agentに関して利用する方法を模索し始めました。

また時を同じくして、オブザーバビリティ製品SentryからSeer by Sentryが出たので、試用したのもこの頃でした。
よいチャレンジではあるものの、コンテキストが少なく、明後日の方向へ行く実装もあり、修正方針のレビューに課題を感じたのもこの時期でした。

🌻梅雨・夏: コーディングエージェントの全社展開

7月から8月にかけてはGitHub Copilot coding agentの全社利用への準備を仕込みつつ、久しぶりに登壇2件をしました。

この登壇のあと、日本マイクロソフトの社員の方からも「coding agent 17並列の方ですか？」と声をかけられるなど新規性の高い取り組みに関して認知が広まったと実感できたタイミングでした。

その後、GitHub Copilot coding agentについて10-12月ごろまで継続的に使用していますが、AIと自動化を駆使することで最大で30-40並列を投げていました。
30並列くらいでリクエストするとエラーとなることが分かったので、20並列くらいに留めておくほうがCopilotインフラ側や我々人間レビュワーの双方によいのではないかという知見が溜まりました。

利用モデル、ガバナンス、エビデンスを残す形でいろいろやってくれるようです

🍂秋〜初冬: AIコーディング組織の完成、そして…

上記のような発表とその後の議論をしたのち、夏以降は「coding agent」に全力を投じていました。
ちょうどスタメンでは東京本社を立ち上げてから21ヶ月目になったところで、東京の従業員数が名古屋のそれを上回り、エンジニア・プロダクトの人数も東京のほうが名古屋を上回るようになりました（名実ともに東京と名古屋のスタートアップとなったのは、「東京エンジニア第一号」としては感慨深かったです）。（誤解のないよう補足しますが、名古屋でのエンジニア採用を止めたという意味ではありません）

10月にはサンフランシスコでGitHub Universe 2025が開催されましたが、そこでもgithub/githubの最大の開発者はCopilotであると発表されていました。

我々の組織内の11月の計測においても、（merged PRsの数で）最大の開発者がCopilotとなり、2025年はAIコーディング組織にするという目標は最低限達成されたのではないかと自認しています。
もちろんPR数だけで開発の価値は測れませんが、実装スピードの指標や人間が働けない土日夜間にも実装できる強みはあり、我々の組織における「エンジニア」の役割は「プロダクト要求情報からのアーキテクチャの設計・レビューと品質管理」にシフトが進んだと理解しています。

一方で寒い冬はまだこれからだと思うので、全力でAIと対話していきます。

一年を振り返り: AIで「事業の生産性」は上がったのか？

以上を振り返り12月を通じて感じたこととしては、AIというソリューション（特にファウンデーションモデルの飛躍的なレベルアップとプロンプトのエコシステムの発展）は個人の生活と企業の経済活動を大きく変えるものであったということです。

一年を通じてAIによるコーディング変革に取り組んできましたが、ふと立ち止まって考えたことがあります。これを経営視点に立って眺めると「我々の開発組織は、事業に対してどれだけ貢献できているのだろうか？」ということです。

上場企業としては、最終的に株価（時価総額）を向上させることが求められます。営業やデリバリー（TUNAGではカスタマーサクセス）であれば「The Model」のような明確なKPIがありますが、エンジニアリングには同等の「経営と直結する共通言語」がまだ足りていないと感じました。

昔からチャレンジしている論文・プロダクト・ツールはあるのでしょうが、確かにミクロな開発タスクはスピードが10倍あるいはそれ以上になったのでしょうが、プロダクトのidea to production (ItoP; アイデアをプロダクションに) では10倍にはなっていません。
むしろAIの使い方を間違えることにより、事業上の生産性が2倍あるいは1.5倍になったとは言えない状況です。局所的には事業上の生産性は1.0倍を下回っている可能性もあるのではないかと思っています。

では、どうすれば「AIの速度」を「事業の成長」に変換できるのか？

答えは「計測」にあると考えています。感覚値ではなく、データで生産性と品質を可視化すること。それが2026年に向けた私たちの次なる挑戦です。

計測が大事

人と組織には計測が必要

組織の下部組織や組織で働く人の健康状態を測るにはパルスサーベイが有効的だと言われています。私が開発運用しているTUNAGではパルスサーベイや通常のサーベイが可能です。
それを通じて組織と人の関係性を客観的に評価できると言えます。

ソフトウェアには計測が必要

数年前に私がジョインしたタイミングでは特に計測等はしていなかったようですが、その後Code Climate Quality, SonarQubeを活用して計測をするようにしました。

昨年からCode ClimateがQualityをdiscontinuedとし、創業CEOがQltyを立ち上げたため、TUNAGで利用するソフトウェア品質SaaSをQltyに載せ替えました。

当初はややUI的に遅いこともありましたが、2010年代から続くCode Climate Qualityとは異なり、Qltyではフロントエンドの再実装が行われたこともあるのでしょうか。

UI表示速度が高速化されたり、ドリルダウンができる箇所が増えたため、チームやサブプロダクトごとの分析がとてもしやすくなりました。
Qltyを使っていない開発組織があれば、ぜひ試してもらいたいです。

SaaSプロダクトにも計測が必要

私はSaaSのプロダクト（55機能以上あるオールインワンプロダクト）のCTOをしております。BtoBtoE SaaS、年間契約（含む複数年契約）であることがあることから、プロダクトの指標を定めることが極めて難しく、プロダクトカテゴリーごとに存在する競合他社の用いる指標を参考にしながら指標を定めていました。

ただ、その数値指標がプロダクトの継続・新規開発・廃止などの意思決定に使われる状況には至っていません。

AI時代にはデータドリブン経営が必要

我々TUNAGにおいてはデータ基盤が整っているとは言いがたく、データ基盤を企画・構築・運用する専任者が必要と考えています。

まだ専任ポジションの職務記述書 (job description) としてオープンできているわけではありませんが、少しでもご興味ございましたら、X @takuya_stmn へダイレクトメッセージをいただければと思います。

関連ポジションもありますので、以下からご自身にあったポジションを見つけていただければと思います。私たちと一緒にAIを使って事業をレバレッジしていきましょう。

スタメンでは、新卒・中途問わず、スタメンを一緒に盛り上げてくれる方を募集中です🔥

もし興味を持っていただけたらぜひカジュアル面談からお話しましょう！！