働き方を変えるAXサービスを提供するSansan株式会社

こんにちは。Sansan株式会社 技術本部 Bill One Engineering Unitの市川です。日々開発業務を行いながら、アーキテクチャ改善やAI活用推進に取り組んでいます。

本題に入る前に、Sansan株式会社についてもご紹介させてください。Sansanは2007年に創業し、従業員数は2,000名以上、そのうちおよそ3割がエンジニアの会社です。「ミッション：出会いからイノベーションを生み出す」「ビジョン：ビジネスインフラになる」を掲げ、出会いをビジネスチャンスへとつなげる、AX（AI Transformation）サービスを展開しています。

本日は「AIで加速する次世代のBill Oneアーキテクチャ ― 成長の先にある軌道修正」と題して、Bill Oneのこれまでの歩みを振り返ったあと、私たちがAIエージェント時代に適応するために行った取り組みと直面した課題、その乗り越え方をご紹介します。最後に、Bill Oneが目指すAIネイティブなアーキテクチャについてもご説明いたします。

T2D3を超える速度で成長を続けてきた「Bill One」

Bill Oneは経理DXから全社の働き方を変えるサービスです。請求書受領、経費精算、債権管理など、証憑が関係する業務プロセス全体をカバーしており、経理部門だけでなく組織全体の生産性を向上させるプラットフォームとして成長してきました。

リリースからわずか5年で非常に高い成長を遂げており、年間の経常収益は2.37億円から109.62億円に達し、SaaSの成長指標であるT2D3を超えるスピードで拡大しています。プロダクト成長に伴い組織も拡大しており、2021年に1チーム5名でスタートしたところから、現在は27チームにまで増加しています。

Bill Oneを支える主要な技術スタックもご紹介します。フロントエンドはReactとTypeScriptのSPA、BFFにはExpressを採用しています。バックエンドは主にKotlin、一部ではGoも採用しています。データベースはPostgreSQL、インフラはGoogle Cloudをベースに構築しています。

技術選定のポイントは、静的型付言語を選択することで保守しやすくすること、それからクラウドサービスのマネージドサービスを活用して運用の負荷を下げることにあります。この技術基盤が次に紹介するアーキテクチャ設計の前提となっています。

こちらが現在のBill Oneのアーキテクチャ概要図です。フロントエンドのSPAアセットを配信しつつ、APIゲートウェイを担うフロントエンドBFF、そしてその後ろにマイクロサービスアーキテクチャを採用した多数のバックエンドサービスを抱えています。このアーキテクチャが、Bill Oneの成長と変化に強い構造を支えています。

Bill Oneのソフトウェアアーキテクチャの根幹にあるマイクロサービスについては、各サービスを疎結合、高凝集に保つことで、チームごとの自律性と柔軟性を最大限に生かすことを目指しています。

「業務ドメインごとのマイクロサービス分割」「サービスごとのデータベース分離」「非同期通信を基本としたサービス間連携」「各チームの独自性と全体の統一感の両立」という4つの方針により、プロダクト・組織の成長とともにマイクロサービスも拡大し、現在では主要なマイクロサービス数が16、細かいものも含めると30ほどのサービス数となりました。

AIエージェント時代に適応するために行った2つの軌道修正

いくつもの課題を乗り越えながら、プロダクトも組織も順調に拡大してきたBill Oneが、次に迎えたのが「AIエージェント時代への適用」という新たなテーマです。人とAIがどのように協働し、どうすればより創造的で持続的な開発ができるのか。ここからは、AIエージェント時代における私たちの適用の軌跡と、そこにあった課題についてお話していきます。

2025年＝AIエージェント元年におけるAI活用の歩み

2025年はAIエージェント元年と言われています。AIが自律的にタスクを実行するエージェントとして振る舞えるようになり、私たちの開発現場にも非常に大きな影響を与えています。AIが実装タスクの一部を担うだけでなく、開発プロセス全体に参加し始めている。まさに2025年という年は、人とAIの共同スタイルが大きく変わる転換点だったと感じています。

以前のAIは、人間の入力や指示に対して自動的に応答するツールでした。IDEの補完機能やコードサジェストなど、私たちがコードを書くことを助けてくれる存在、いわばアシスタントでした。しかし、今のAIはエージェントに進化しました。人間がゴールや制約条件を提示すると、AI自ら情報を収集・判断し、タスク完了に向けて自律的に行動します。

つまり、AIはただコードを生成するツールから、開発タスクを共に進めるパートナーへと役割を大きく変化させたのです。私たち開発者は、この新しいパートナーとどのように協働するかを真剣に考えるフェーズに来ています。

AIコーディングエージェントの登場により、最初に広まったのがバイブコーディングと呼ばれるスタイルでした。仕様や設計が曖昧なまま、AIに雰囲気で指示を出す開発スタイルです。モックアップを素早く作る、アイデアを動く形にして検証するといった用途では便利でしたが、部分最適に陥りやすいという課題があり、中長期的に整合性や保守性を保つことは困難です。大規模なプロダクト開発下においては、バイブコーディングは成り立ちません。

そこで昨今注目されているのが、エージェンティックコーディングです。開発者が明確な目的と制約を提示し、AIがその達成に向けて計画・実行・検証を自律的に繰り返すスタイルです。人間が上位レベルでの意図設計や品質判断を行うことで、継続的な開発が可能となります。

Bill Oneでも、このエージェンティックコーディングを前提とした開発プロセスへの移行を始めています。

Bill OneのAI活用について振り返ると、2024年末頃からClineの利用を開始しました。画像にはトライアル施策と書いておりますが、これはAIツールを触って慣れてもらうことを目的にしていたからです。開発メンバーがAIコーディングツールの特性を理解し、日常の開発フローの中でどのように活用できるかを試す段階でした。

続いて、2025年初頭にはAIエージェントツールの先駆け的サービスであるDevinの利用も始めました。AIが人の手を離れ、自律的にタスク遂行する場面を実際に体験し、一定規模のタスクであればAIエージェントに手放しで依頼できるという肌感覚をつかみました。

そして、2025年2月末頃からCursorやClaude Code、4月からCodexといった定額課金タイプのツールを本格的に導入しています。これらはAIエージェンティックコーディングを実現する代表的なものであり、チームがAIエージェントと並走しながら開発できる環境を整えています。

ここでお伝えしたいのは、これらはあくまでもツールの導入の話に過ぎないということです。真に重要なのは、これらのAIツールを活かすために、開発プロセスやアーキテクチャそのものをどう変えていくかというところです。

生産性が2倍に！Bill Oneが実践するAI駆動開発プロセスとは

変革の内容についてお話していきます。1つ目は、開発プロセスへのAI適用です。Bill OneがAIを活用していく中で、まず変化させる必要があったのが開発プロセスそのものでした。これまでは人間が設計、実装、レビューを一貫して担っていたプロセスに、AIが常時参加することで、私たちはAIを使うだけでなく、AIと共に開発を進めるという前提に合わせてプロセスを再設計する必要が出てきました。ここではその変化の中核をなす考え方や、実際にどのようにAIを組み込んでいったのかについてお話していきます。

Bill Oneでは、AI実用研究の第一人者であるペンシルベニア大学のイーサン・モリック教授が提唱するAIと協働するための4つの原則「常にAIを参加させる」「人間参加型にする」「AIを人間のように扱う」「AIの進化を前提とする」をAI活用の基盤・基礎として位置付け、AIとともに成果を高め合う共同知能を実践しようとしています。

もう1つ、AIを開発ライフサイクル全体に適用する考え方として、AWS社が提唱するAI Driven Development Lifecycle（AI-DLC）も参考にしています。AI-DLCの中心となる考え方は次の2点です。

1つ目は「AIが実行し人間が監視する」です。AIが体系的な作業計画を策定し、人間はビジネス文脈を踏まえて最終判断を下す。人間の知識とAIの効率性を掛け合わせることで、最適な意思決定が実現されます。

2つ目は「ダイナミックなチームコラボレーション」です。AIがルーティンタスクを自動的に処理することで、チームはリアルタイムな課題解決や創造的な意思決定に集中できます。これにより、エンジニア個々人が孤立して作業する状態から、AIも含めた協働的なチーム開発へと転換し、イノベーションを加速させることができます。

Bill Oneでは、このAI-DLCの思想を自社の開発プロセスに取り入れ、InceptionフェーズからConstructionフェーズに当たる領域で、AI駆動開発プロセスを実践して組織に展開しています。

具体的には、要件定義、設計、計画、実装、結合テストといった開発の一連の流れにおいて、AIを常時参加者として組み込んでいます。各ステップにおいてコンテキストを整理してAIに入力し、それから人間がAIのアウトプットを精査・補正して再入力していく。AIと人間が交互に改善を重ね、成果物を成熟させるライフサイクルを一連のプロセスで回していきます。

ここで重要なのは情報とコンテキストの整理・型化です。AIを活かすためには、プロダクト要件やプロダクトの意図を構造化し、AIが理解できる形に整える必要があります。また、組織展開する上ではプロセスの型化も欠かせません。Bill Oneでは、AI駆動開発のためのコマンドを整備し、組織展開に活用しています。

この開発スタイルは一見ウォーターフォール開発に見えるかもしれません。ただ、実際にはドキュメントをインクリメンタルに更新しながら、必要に応じて上流プロセスへの逆伝搬も行います。AI活用によって設計書や仕様書の更新・維持が容易になったため、チームの思考をドキュメントに書き起こしながら、アジャイルに開発を進められるようになったのです。

このAI駆動開発プロセスを実際に取り入れているチームでは、いくつかの成果が現れ始めています。例えば、四半期あたりの機能開発の生産性が2倍に向上したチームがあるほか、あるプロジェクトでは開発期間が4.5ヶ月から2ヶ月に短縮された例もあります。

これらはあくまでも好例ではありますが、チームがAI活用に積極的であったからこそ得られた結果です。全てのチームに同じ成果が出るわけではなく、現場では課題や摩擦もまだ多く存在しています。

それでも確実に言えるのは、AIを前提としたプロセスを導入することで、人間の思考の精度やスピード、そしてチーム全体の開発速度が加速しているということです。

こうしたAI駆動開発プロセスを導入していくなかで、Bill Oneのマイクロサービスアーキテクチャとの高い親和性も実感しています。その理由は大きく2つあります。1つ目が「適正なコンテキストサイズ」。各マイクロサービスが独立しているため、AIエージェントが使うコンテキストを明確かつ理解しやすい範囲に維持できています。

2つ目が「明確なオーナーシップ」です。各チームが自分たちのサービスに責任を持ち、自律的に改善を進められます。これにより、AI活用に必要なルールやガードレールをチーム単位で整備・進化させていくことができます。

この構造がBill OneのAI駆動開発を支える大きな強みとなっています。マイクロサービスアーキテクチャによる分割と自律性が、結果的にAI活用における柔軟性とスピードを高めてくれているのです。

AI活用の効果を最大化したマイクロフロントエンド化

ここからは2つ目の軌道修正、マイクロフロントエンド化について触れていきます。AI駆動開発プロセスを進めていく中で、障壁として立ちはだかったものの1つがフロントエンド開発でした。AIを活用しやすくするためのアーキテクチャ転換について、その背景と狙いをお話しします。

マイクロフロントエンドとは、2016年にThoughtworks社が提唱した概念で、バックエンドにおけるマイクロサービスの概念をフロントエンドに適用したアーキテクチャスタイルです。ざっくり言えば、フロントエンド版のマイクロサービスですね。巨大なモノリシックフロントエンドを、独立して開発・デプロイ可能なビジネス機能単位の小さなアプリケーション群として分割します。

その目的は主に「チームが自律的に開発・運用できるようにする」「独立したデプロイで迅速なリリースを可能にする」「機能開発単位で安全に刷新・改善を進められるようにする」の3つです。

Bill Oneのフロントエンド課題を少し整理します。バックエンドはマイクロサービスアーキテクチャとして整備されてきましたが、フロントエンドは長らくモノリシックなReact SPA構成になっていました。請求書受領、経費精算、債権管理、全ての領域を扱うため、ページコンポーネントの数は200を超える規模に拡大しています。

その結果として、いくつかの課題が顕在化してきています。1つ目が「リリースプロセスの硬直化」です。単一アプリケーションとしてフロントエンドをリリースする必要があり、チーム数や機能数の増加に対して、リリースの頻度・速度が追従できなくなってきています。この影響はこの5年で徐々に広がり、無視できないレベルになっております。

2つ目が「コンテキストの肥大化」。AIの作業範囲がコードベース全体となってしまうことで、単一の巨大なコンテキストを扱う必要が出てきます。AIが解析・理解できる範囲を適切に絞り込むことが難しく、この状態は人間にとっても認知負荷が高いため、プロダクト開発の障壁となっています。

最後が「あいまいなオーナーシップ」です。単一のコードベースであるため、チーム毎の責任範囲が曖昧になりがちです。結果として、フロントエンドの技術的改善やAI活用がチーム単位で進めづらくなっています。こうしたアーキテクチャ上の課題が、AIを前提とする開発の大きなボトルネックになっていたのです。

そこで、これらの課題を解決し、AIをより活かしやすい構造を目指して、マイクロフロントエンド化を進めることとなりました。

マイクロフロントエンド化で期待するのは「リリースの分散・独立化」「領域ごとのオーナーシップ醸成」「自律的なAI活用を推進するための足場づくり」の3つです。これらの効果を短期的に最大化することを意識しつつ、次のような方針を採用しています。

まず、分割方式は業務領域に沿った垂直分割を採用しています。Bill Oneが扱う多様な業務領域、例えば経理業務、経費精算、請求書発行など、それぞれに画面構成が大きく分かれているため、各領域ごとにフロントエンドのアプリケーション分割を進めているところです。

分割後の各アプリケーションは、それぞれ独立したSPAとして提供しています。ユーザーからは単一のBill Oneプロダクトとして利用できるよう、ロードバランサでパスベースの振り分けを行う構造をとっています。将来的には、クライアントサイドでのアプリケーション統合も視野に入れています。

現在はこの分割対応を段階的に進めており、この分割対応によって、既にいくつかの効果が出てきています。

まず、独立したリリースプロセスを確立できました。他チームの作業を待たずにデプロイできるようになり、チーム毎の開発速度とリリース頻度を最適化できるようになりました。

次にコンテキストの適正化です。アプリケーションが分割されたことで、AIが扱うコード範囲も明確になり、AIによるコード生成や理解の精度が向上する傾向が見られています。

そして何より、明確なオーナーシップが生まれました。各チームがフロントからバックエンドまでをEnd-to-Endで所有できるようになり、AI活用を含む技術選定、改善プロセスを自律的に推進できるようになりました。

AI時代のマイクロサービスでうまくいった疎結合、自律性の考え方をフロントエンドにも拡張できた形です。結果として、AIのメリットをより最大化できるアーキテクチャへと近づいています。

AI増幅効果を味方につけるための三大要素

ここからは、AI活用が当たり前となった今、どのようなアーキテクチャが求められているのか、AIネイティブなアーキテクチャとは何なのかを考えていきます。

DORAの2025年最新のレポートでも強調される通り、AIは高パフォーマンス組織の強みを拡大するだけでなく、同時に組織の機能不全をも拡大します。この1年間、AI活用を進める中で、私たちはそれを強く実感しました。

Bill Oneの現場で感じている増幅効果を見てみましょう。

まずはプラスの増幅です。ソフトウェア面では、ベストプラクティスや実装パターンの大規模展開が進み、AIレビューによってコード品質と一貫性が向上しました。開発プロセス・組織の面では、設計精度や要件整理の精度が向上し、開発のフィードバックループが短縮されました。AI駆動開発の導入により、チームの思考サイクルも加速しました。

一方で、マイナスの増幅も見られております。ソフトウェア面では、非推奨コードやアンチパターンの複製拡散が散見されるようになりました。その他、AIによる複雑な実装による保守性の低下も一定見られています。開発プロセス・組織面では、AIの成果物が大量生成されることで、レビュー時間の増加やレビュー疲れの発生が見られています。

このように、AIは組織の能力をそのまま拡大する増幅機のような存在です。だからこそ、AIのポテンシャルをプラスの方向に働かせるための環境が重要になります。

AIの増幅効果をプラスに最大化するために、私は「ソフトウェア」「開発プロセス」「開発組織」という3つの軸をセットで捉えています。

AIがコンテキストを理解し、自律的にコードを生成検証できる構造。これはマイクロサービスやマイクロフロントエンドのことを指します。

それから、AIが開発ライフサイクルの全行程に常駐し、人間は意図設計と品質判断に集中できるワークフロー。これはBill Oneで実践するAI駆動開発、AI-DLCのことを指します。

それから、人がAIの能力を引き出し、AIが組織の学習を加速させる共同知能文化。この3つが連動して初めてAIの増幅効果はプラスに働きます。

ツール導入や開発プロセスの一部を最適化するのではなく、ソフトウェア、プロセス、組織を一体として進化させることが鍵となるのです。

AIネイティブなソフトウェアアーキテクチャを目指す上で、Bill Oneが重視する品質特性は変わりません。保守性、テスト容易性、疎結合性、これらの特性を重視することで、AIによるマイナス増幅を抑制し、かつAIへの迅速なフィードバックを実現して、AIが働きやすい環境を整えていきます。

その上で、これらの特性ごとに適応度関数を設けて定点観測することが重要だと考えています。具体的には、コードの複雑度やテストの実行時間、サービス間の依存を可視化するといったものです。それらの指標を定期的に分析し、随時軌道修正をかけていく必要があります。

分析や軌道修正についても、今後AIを活用することで適用のスピードを上げられると考えています。

前述の通り、Bill OneではAIの常時参加を前提としたAI駆動開発型のプロセス変革を進めています。2025/11時点での導入状況としては、全体の4分の1ほどのチームへ導入を始めた段階であり、今後拡大を予定しています。

適用プロセス自体の範囲拡大も必要となります。現時点では、エンジニアが中心に行動している部分に限ってAI適用を進めています。これからはPdMやデザイナー、QA領域まで含めたAIネイティブ化を進めていく必要があります。

開発プロセスについても定点観測が重要となります。ソフトウェアデリバリーパフォーマンスはもちろんのこと、AI活用に伴う認知負荷の増大など、新たな観点で開発者体験の変化も計測・改善していく必要があります。

AIネイティブな開発組織の実現には、AIを作業の代替手段ではなく、共に学ぶパートナーとして扱うことが求められます。人とAIの対話を通じて、組織全体の学習速度と創造性を高める共同知能文化の確立が必要です。

これを可能にするのが、全員がリーダーシップを発揮する挑戦型組織です。AI活用という正解のない問いに対し、メンバーそれぞれが現場でAI活用を実践し、ソフトウェアやプロセス、チームを継続的に進化させる。挑戦を通じて新たな価値とイノベーションを生み出す組織こそが、AIの持つプラスの増幅効果を最大限に引き出すことができるのです。Bill Oneは、このような挑戦型組織への変革を進めています。

AI時代であっても、磨き続けるべきアーキテクチャは変わらない

まとめます。AIネイティブ化に必要なのは、ソフトウェア、開発プロセス、開発組織の3つに向き合い、地道に改善を続けること。AIは増幅器であり、これらの基盤が整っていれば成果を増幅し、整っていなければ課題を増幅します。

何か特別なことをする必要はありません。AIが登場する前から大切とされてきた原則を、AI時代に合わせて捉え直せばよいのです。これら3つのアーキテクチャを磨き続けることが、結果としてAIのプラスの増幅効果を最大化します。Bill Oneはこのアーキテクチャを磨き続けながら、AIネイティブなプロダクト開発組織へと進化していきます。

最後に、Bill Oneでは現在エンジニアアーキテクト職を募集しています。急成長の中で生まれる複雑な課題をAIと共に解きほぐし、次の爆発的な成長フェーズを一緒に築いていきたいと考えています。AIを活かして組織とプロダクトを進化させたい、AIネイティブな開発を自分の手で実践したい、そんな思いをお持ちの方は、ぜひご応募ください。

本日は、ご清聴いただきありがとうございました。

アーカイブ動画・発表資料

イベント本編は、アーカイブ動画を公開しています。また、当日の発表資料も掲載しています。あわせてご覧ください。

▼動画・資料はこちら
アーキテクチャConference 2025

※動画の視聴にはFindyへのログインが必要です。