はじめに

はじめまして、株式会社AzitのCTOの十亀です。 2025年は一年を通して、「生成AIと組織として、そして一人の開発者としてどう付きあうか」というテーマが、ずっと頭のどこかにありつづけた年でした。
本記事では、2025年をふりかえりながら、株式会社Azitとして生成AIとどのように向きあってきたのかを整理し、現時点での考えを共有します。

積極的に実験をする

生成AIを取り巻くエコシステムは変化の周期が異例に短く、モデル性能やツールチェーンの最適構成が、数か月単位で刷新される環境です。 そのため、ひとつのプレイヤーに絞って利用したり、逆に「勝者が決まるまで待つ」というスタンスを取ってしまうと、実際にモデルをどう活用すべきかという知見を得ること自体が難しい領域であると感じました。
そこで弊社では、生成AIに関しては次のような方針で進めています。

• 入力データの取り扱い範囲や外部送信の有無、ログの扱い等のセキュリティ基準を設ける
• 併せて、ツールの運営企業等の信頼性や情報管理ポリシー等の安全面で必要最低限のチェックをおこなう
• 一方で、ROIの事前の厳密な議論をしすぎない
• 会社として確保したバジェット内で、複数のツールを併用しながら試す

この方針を取ることで、新しいモデルやツールがリリースされた際にも、予算内であればすばやく導入してトライできるようにしています。
また、利用頻度が下がったツールについても、「一度やめたからといって、また戻せないわけではない」
という前提で、いったん利用停止し、必要に応じて再検討する運用をおこなっています。 結果として、生成AIを特別視しすぎることなく、「小さく試し、合わなければ戻る」という実験のリズムを保ち続けることができました。

生成AIの成長と変わる関係性

投資対効果がまだ厳しかった年初

年初の社内チャットをふりかえってみると、当時の生成AIとの距離感がよく表れています。 生成AIをつかってコーディングや実装にトライするものの、既存の前提を無視した修正が返ってきたり、発生したエラーにたいして適切な修正判断ができず、誤った修正対応を行き来するループに入ってしまったりする場面が少なくありませんでした。
人間側が状況を整理し、指示の粒度を調整しなければ、機能そのものが完成しない。 当時は、そのようなケースが多く、生成AIに実装をそのまま任せることの難しさを強く感じていました。
モデル側にも、コンテキスト制限や一般的なコーディング知識の不足といった制約があり、要件や方針をまとめて渡して実装を任せるよりも、CursorやCopilotといったエディタ補完を中心に進める方が、結果としてリターンが大きいと感じる時期でした。
一方で、単に補完ツールとして使うだけではなく、実験として、AIに渡す要件の抽象度を変えながら、

• どのくらいの粒度で指示を出すと、期待しているコードが出てくるのか
• どの抽象度で破綻しやすいのか

を日々探っていました。
今のモデルと比較すると、当時はプロンプトの文章としての精緻さが、出力の品質に及ぼす影響が現在と比べるとそれほど大きくありませんでした。 そのため、誤字脱字や走り書きに近い指示を投げても、一定のアウトプットが返ってくる、という感覚もありました。 ただし、その気楽さがそのまま「実装を任せられる」ことを意味するわけではなく、当時の実感は次の通りでした。

• モデル側はまだ「コーディングを完全に代替する」段階には来ていない

そのため当時は、自分の使い方を Agentic Typing と呼び、意思決定をAIにほとんど委ねず、「文字列フィールド xxx を追加してください」といった、タイピングを省略する用途で使っていました。 実装のコントロールの主体は、ほぼエンジニア自身が握っている状態だったと思います。

モデルの進化とともに、AIに実施させる領域を段階的に広げる

しかし、新しいモデルがリリースされるにつれて、この境目は徐々に変わっていきました。 こちらが担っていた領域の一部をAI側に寄せても、品質や速度が大きく崩れない。むしろ、その方が安定する。そう感じる場面が増えてきました。
2025年12月現在、私自身は Agentic Coding と呼ばれる手法を中心に開発をおこなっており、自分の手で直接コードを書いていることは、以前よりもかなり少なくなっています。
具体的には、

• AIに既存のコードベースの調査を依頼する
• 別のプレーンテキストエディタなどで設計方針や要件を整理する
• 整理した内容をプロンプトとしてAIに渡す
• テストや型検査といったガードレールを通しながら実装を収束させる

といった流れで、ほぼ満足のいくコードが得られるようになりました。
（このブログを書いている現在も、エディタ上で機能の実装がAIによって進んでいるのを見まもっています。）
また、巷で Vibe Coding と呼ばれるような、より多くの領域をAIに委ねる手法についても、用途を限定して取り入れています。 たとえば「アイデアの発散」という場面では、実現したいUIの要件を伝えたうえで、複数のパターンを同時に実装させ、短時間で比較検討するといった使い方をしています。

生成AIが開発の中心になっても変わらないもの

このように、AIに実施させる領域を段階的に広げていきながらも、人間がコーディングの中心だった頃から変わらない、むしろいっそう重要になったことがあります。
それは、

• 暗黙の前提や隠れた依存がすくないコードであること
• 一部分だけを切りとって読んでも、挙動や意図が把握しやすい疎結合かつ明瞭なコードであること
• 静的解析や静的型検査、自動テストなどによって、自動的に検証できる領域を継続的に増やしていくこと

といった点です。
これらは、人間が複数人で開発をおこなうチーム開発においても、新しいメンバーを迎えいれたり、久しぶりにコードを読む場面でも一貫して重要でした。
さらに、生成AIによるコード生成が開発の中心になっていく場合には、これらの重要性は増していきます。 統計的に予測を繰りかえすモデルの性質上、コードベース内の書き方のブレがすくなく、変更の影響範囲を予測しやすい構造であることが求められます。
仮に予測が誤ったとしても、自動的に誤りが検知されるようなガードレール（型検査・静的解析・テスト・CI）を整備しておくことで、生成AI自身がフィードバックループをまわし、適切な実装に収束しやすくなります。
初期のコーディングエージェントは、こういった「人間が詰みあげてきた、数学や工学、ソフトウェア資産に裏打ちされたツール」を十分に活用できず、車輪の再発明のようにAIがゼロから考える挙動が目立っていました。 一方で、近年のコーディングに特化したエージェントは、周辺環境にあるツールを前提として取り込み、その環境に適応する能力を持つようになってきています。
もともと私たちのチームには、テストカバレッジを高く保つ文化や、疎結合なアーキテクチャを意識する文化があります。 Railsにおいても RuboCop や RBS を積極的に活用し、それらのチェックが落ちるPRはマージしない、といった運用を続けてきました。
コーディングの中心が生成AIへと移っていくとしても、こうした文化は引き続き大切にしていきたいと考えています。

生成AIと学び、生成AIと作る

生成AIによって、コーディングという作業そのものは、今後さらに自動化が進んでいくと思います。 その結果、人間が直接コードを書く機会は、これまで以上に減っていくかもしれません。
一方で、その変化が進んだとしても、「自分が何を理解していて、何を理解していないのか」という境界を曖昧なままにすることは、適切ではないと感じています。 生成AIが書いたコードをそのまま受け入れるだけでは、実装の是非を判断したり、問題が起きたときに適切にガイドしたりすることができません。
ここで重要なのは、「すべてを自分で書くこと」ではなく、「どのような理解を持ったうえで任せているのか」を把握していることだと思います。 生成AIに実装を任せること自体は問題ではありませんが、その結果として出てきたコードについて、

• なぜこの実装になっているのか
• どの前提に依存しているのか
• どの選択肢を捨て、何を選んでいるのか

を説明できない状態は、健全とは言えません。
私自身は、判断において「何を選んだのか」も重要ですが、それと同等、あるいはそれ以上に、「なぜ他の選択肢を選ばなかったのか」を説明できることが重要だと考えています。 そのためには、「他にはどのような選択肢があり得たのか」というストックを、常に自分自身の中に蓄えておく必要があります。
私自身は、生成AIを前提とした開発においても、「理解そのものを手放さない」ことが重要だと感じています。 ただし、それは従来と同じ学び方をそのまま続ける、という意味ではありません。
むしろ、生成AIを前提とすることで、理解するためのアプローチ自体を加速させることができると感じています。
たとえば、NotebookLMのようなツールを使うことで、論文や仕様書といった一次情報を、要点を保ったまま素早く把握できるようになりました。 全文を精読する前に構造を掴んだり、特定の前提や主張だけを抜き出して確認したりと、「読む」ことにかかる認知コストを大きく下げられています。
また、PLaMo翻訳のような翻訳技術によって、英語で書かれた最新の書籍や論文、技術記事を、ほとんどストレスなく読めるようになった点も大きいです。 言語の壁が下がったことで、「後で時間を取って読む」のではなく、「必要になった瞬間に読む」という選択を取りやすくなりました。
事実、私自身も、時系列予測やヒューリスティックな経路最適化アルゴリズムに関するサーベイや論文の読解、あるいは邦訳前の書籍や最新の技術記事をいち早く読むといった場面で、これらのツールを活用してきました。 実装と調査を行き来しながら、前提や選択肢を整理したうえでコードに戻る、という往復を、ほとんどストレスなく行えるようになったと感じています。
このように、生成AIと一緒に作りながら、同時に学ぶというサイクルを回せるかどうかが、これからの開発において重要になっていくと考えています。 最終的な判断や責任は人間が持ち続ける。その前提を保ったまま、生成AIを理解の補助としても活用していく。
生成AIによって「書く」ことのコストは下がっていきますが、「理解し、判断し、レビューする」ことの価値が下がるわけではありません。 むしろ、生成AIを前提とした開発では、その部分の重要性は、これまで以上に高まっていくように思います。

まとめ

2025年は、生成AIを「便利な補助ツール」として扱う段階から、「開発プロセスの中心に置き、前提条件を整えた上で任せる」段階へと、距離感が大きく変わった一年でした。 モデルやツールの更新サイクルは速く、正解が固定されない領域だからこそ、私たちはROIを机上で固めすぎず、一定の基準を設けたうえで小さく試し、合わなければやめ、必要であれば戻る、という実験のリズムを重視してきました。
一方で、AIに任せられる領域が広がるほど、コードベース側の前提が問われます。暗黙の依存が少なく、局所的に読んでも意図と挙動が追える構造、そして静的解析・型検査・自動テストといった「機械で検証できる領域」を増やしていくこと。 これは人間中心の開発でも重要でしたが、AI中心の開発では、実装を安全に収束させるためのガードレールとして、より決定的な意味を持つようになりました。
来年も、生成AIそのものの進化は続きます。 だからこそ私たちは、特定のツールや手法に過度に依存するのではなく、「どんな環境でも品質を担保できる開発の型」と「変化に追従する運用」をセットで磨き続けます。 生成AIに過度に依存せず、ソフトウェア工学の積み上げの上に置かれた強力な道具として、安全に、そして着実にチームの生産性と品質に接続していく。2026年は、その精度をもう一段上げる一年にしたいと考えています。