AIネイティブな開発組織への変革 — アーキテクチャから組織まで、新しい形を模索した3ヶ月

author

authorDisplayName

Kentaro Ogawa

はじめに — AIネイティブな組織にむけて

こんにちは。令和トラベルでCTOを務めている小川です。

4月に公開した記事では、令和トラベルが「AIファーストカンパニー」として何を考え、どこへ向かおうとしているのかをお伝えしました。AIコード化率85%、全社員のAI利用率100%、攻める・変える・守る・支えるの4体制。あの記事は「戦略の全体像」を語るものでした。

この記事では、その先を書きます。コード化率85%という数字に到達したあとで、私たちが「AIネイティブな組織」を目指して進めてきた変革について共有したいと思います。

AIネイティブとは何か。それは、AIが特別なツールではなく、空気のように当たり前に存在することを前提として設計された組織・システム・働き方のことです。AIを後から組み込むのではなく、最初からAIと人間の協働を織り込んで構築された環境。

なぜそれを目指すのか。AIがここまで浸透した今、従来の延長線上での最適化では限界があると感じているからです。真の価値を生み出し、10X、100Xを目指すためには、AIと人間が最適に協働できる関係を根本から設計し直す必要がある。そう確信するようになりました。

この数ヶ月で具体的に進めてきたおもな変化は3つです。シニアエンジニア制度の導入と少数チーム化、Token上限を撤廃する実験、そしてAIネイティブなアーキテクチャへの段階的な変革。いずれも「AIをもっと使う」ための話ではありません。「AIが当たり前になった組織で、人間とシステム全体をどう進化させていくか」という話です。

コード化率85%は、ゴールではなく出発点だった

まず数字の整理から。前回お伝えしたとおり、AI生成コード比率はFY26下期に85%へ達しました（前四半期43%からの倍増）。本記事は、その後の話です。

この数字をどう読むか。前回の記事でも触れたとおり、コード生成比率はあくまで手段の指標です。重要なのは、それがリリース頻度とカスタマー価値にどうつながっているか。現状はこうです。

アプリリリース: 週2回ペースで安定稼働

バックエンドデプロイ: 日次（月間100超）

全社員AI利用率: 100%

ここで起きたのは、ボトルネックの移動でした。「コードを書く速度」が制約ではなくなった瞬間、次の制約が見えてきます。仕様を定義する速度、レビューで判断を下す精度、そしてAIエージェントが安全に動ける環境の整備。コードを速く書けるようになるほど、「何をどう書かせるか」を設計する人間の価値が相対的に上がっていきました。

つまり、85%という数字は「AIに任せられる領域が広がった」ことの証明であり、同時に「人間が集中すべき領域が変わった」ことのサインでもあったのです。ここから先の3つの取り組みは、すべてこの認識から生まれています。

シニアエンジニア制度と少数チーム化 — 少数精鋭化と技能伝承を両立させる

AIによってコードを書く工数が下がると、素朴には「人を減らせる」という発想になりがちです。しかし私たちが取った方向は少し違います。チームを小さく保ちながら、一人ひとりの専門性を意図的に深めるという設計です。

その仕組みのひとつがシニアエンジニア制度です。狙いは2つあります。

ひとつは、スペシャリストの育成。AIが定型的な実装を担うようになると、人間に残るのは難易度の高い設計判断や、ドメイン固有の複雑性をさばく仕事です。こうした領域は、経験の蓄積がそのまま価値になります。シニアエンジニアという役割を明確に置くことで、「深く狭く尖る」キャリアを正当に評価できるようにしました。

もうひとつは、技能伝承です。逆説的ですが、AIが普及するほど技能伝承の重要性は増します。なぜなら、AIが生成したコードの良し悪しを判断できるのは、その判断軸を持った人間だけだからです。判断軸は経験からしか生まれません。シニアエンジニアが若手と並走し、「なぜこの設計を選ぶのか」を言語化して渡していく。この流れを制度として組み込みました。

少数精鋭化と聞くと冷たく響くかもしれませんが、実態は逆です。少人数だからこそ一人あたりの裁量が大きく、AIを使い倒すことで個人の生産性が劇的に上がる。その上がった生産性を、人員削減ではなく専門性の深化に再投資する。これが私たちの考える少数精鋭化です。

評価制度との接続も進めています。前回の記事で触れた「AI活用を評価項目に組み込む」方針はそのままに、シニアエンジニアには「自分が使う」だけでなく「組織のAI活用水準を引き上げる」ことを期待しています。

Token上限撤廃の実験 — 制限を外すと何が見えるか

AIエージェントを本格的に使い始めると、必ずコストの議論が出てきます。Token（AIが処理する文章の最小単位。使用量に応じて費用が発生する）の消費が積み上がるからです。多くの組織は、ここで利用上限を設けます。

私たちは逆の実験をしました。一部のメンバーに対して、Token上限を撤廃する。

意図はコストを無視することではありません。「制限がボトルネックになっていないか」を確かめることでした。上限があると、人は無意識に行動を縮こまらせます。「ここでAIに大量のコンテキストを渡したら高くつくかも」という遠慮が、本来できたはずの試行を止めてしまう。その遠慮が組織全体でどれだけの機会損失を生んでいるのか、計測したかったのです。

実験から得られた知見は、大きく2つあります。

第一に、コストの可視化が前提条件になるということ。上限を外すなら、誰がどれだけTokenを使っているかをリアルタイムで把握できる仕組みが必須です。私たちはメンバー単位・用途単位でのToken使用量の可視化を進めました。「使うな」ではなく「見える状態で自由に使う」。この設計が、青天井の不安と過剰な萎縮の両方を防ぎます。

第二に、上限を外しても暴走的なコスト増は起きなかったということ。むしろ、自由に使える環境では、メンバーは「どの場面でAIに投資する価値があるか」を自分で判断するようになりました。費用対効果の感覚が、制限ではなく当事者意識から育っていく。これは予想していなかった発見でした。

もちろん全員に無条件で開放しているわけではありません。可能性探索のフェーズとして、見極めながら範囲を広げています。

ここで重要なのが、一部チームから新しい動き方を試すというアプローチです。全社一斉に変えるのではなく、まずは一部のチームが極端に尖った実験をする。あえて個別最適化されることも臆さない。従来なら嫌われがちだった属人性も、AI時代には一つの武器として許容する。個人の専門性とAIの組み合わせで生まれる独特な価値を、むしろ積極的に育てていく。

その上で、うまくいった実験を全社最適の文脈に乗せて展開する。個別最適と全社最適の両方を追うという、一見矛盾するようなコンセプトですが、AI時代にはこの矛盾を解く必要があると考えています。

「制限ありき」で考えるのをやめ、「何のために制限するのか」を問い直す。その問い直し自体が、AI時代の組織運営に必要なマインドセットだと感じています。

AIネイティブなアーキテクチャ再設計 — すべてを作り直す覚悟

技術的にいま最も大きく動いているのが、AIネイティブを前提としたアーキテクチャとコンポーネントの再設計です。

この取り組みを技術的に支えているのが、AIエージェントの実行環境設計です。代表的なものだとハーネスエンジニアリングがあります。そして、この領域でもシニアエンジニアが技術的なリーダーシップを発揮し、組織全体を牽引してくれています。私たちが向き合っているのは、「AIが当たり前の世界で、システム全体をどう設計し直せば、人間とAIの協働が最大化されるのか」という根本的な問いです。

この数ヶ月で具体的に進めているのは、以下の4つの軸です。

API・アプリのリアーキテクチャ検討

バックエンドAPIの設計から根本的に見直しています。AIエージェントが自然に理解し、操作できるAPI設計とは何か。従来の設計思想を問い直し、「AIが読みやすい形」への最適化を進めています。同時に、アプリ側のデータフローも、AIが途中で介入しやすい形に再構成する。これは単なる技術的な改修ではなく、「誰が何を判断し、どの部分をAIに委ねるか」という責任分界の再設計でもあります。具体的な技術的アプローチについては、また別の機会に詳しくお伝えできればと思います。

フロントエンド・アプリのコンポーネント再設計

UIコンポーネントも同様です。従来のコンポーネント設計は「人間の操作」を前提としていますが、AIエージェントが動的にUIを構成したり、カスタマーの意図を汲み取って画面を変更したりする世界では、コンポーネントの粒度や責任範囲が変わります。デザイナーと密に協業しながら、「AIが理解しやすく、かつ人間にとって自然なインタラクション」を実現するコンポーネント体系を構築しています。

ハーネスエンジニアリング

Martin Fowler のサイトでも近年取り上げられている、AIエージェント周辺環境の設計です。同じモデルでも、ハーネスの設計次第で性能が大きく変わることが研究で示されています。型情報の整備、コンテキストの構造化、ツールと権限の設計、検証ループの自動化。これらを通じて「AIが読めるコード」「AIが動ける環境」を整備しています。

バリューストリーム最適化

アイデアから本番リリースまでの全工程を、AIとの協働を前提に再設計する。従来は「企画→設計→実装→テスト→リリース」という直線的な流れでしたが、AIが各工程で積極的に関与することで、フィードバックループが短くなり、工程間の境界も曖昧になります。デザイナー・エンジニア・プロダクトマネージャーの役割分担も、この変化に合わせて進化させています。

例えば、エンジニアの役割が大きく変わっています。従来の実装だけでなく、リサーチも行うようになり、PMと一緒にAI活用のためのスキルを作るところから整えることもある。デザイナーと協業してデザインシステムの整備を進め、簡単なものであればエンジニアがデザイン修正を行ってデザイナーにレビューをしてもらってリリースをする。こうした動きを行うことで、従来とは比べられないスピードで機能開発を行っています。

おわりに — AIという武器をどう使いこなすか

AIコード化率85%。AI生成コード比率の高さ。リリース頻度の向上。これらの数字は、私たちが歩いてきた距離を示してくれます。

ただ、数字が高いこと自体は目的ではありません。AIがこれほどまでに浸透すると、働き方そのもの、エンジニアリングのあり方そのものが変わってしまいます。コードを書く技術、設計する技術、チームをつくる技術。これまで積み重ねてきた知見の多くが、根本から問い直される時代です。

けれど、あくまで人間が主体です。AIは強力な武器ですが、その武器をどう使うかを決めるのは人間です。どのような価値を生み出すために、どのような問題を解くために、この武器を使うのか。その判断軸を持つのは人間であり、その判断軸を磨き続けるのも人間です。

シニアエンジニア制度で専門性に投資し、Token上限の実験で制約の意味を問い直し、AIネイティブなアーキテクチャで環境そのものを資産にする。個別最適と全社最適を両立させ、属人性を武器にしながら組織の力も高める。これらはすべて、「AIという強力な武器をどう使ってアップデートしていくか」という大きな問いかけに向き合った結果です。

この問いかけに、正解はありません。私たちも手探りです。サイクルタイムは、すでに高い水準からさらなる向上を目指していますが、いま面白いのは速度そのものよりも、組織の形が変わっていく感覚のほうです。85%に到達した数ヶ月前には想像していなかった働き方が、いまの当たり前になっている。その次の当たり前を、私たちはまた手探りでつくっていきます。

AIに問いかけられているのは、私たち人間自身のアップデートなのかもしれません。