AIから最も使われやすいfreeeへ

freee 技術の日 2026のセッション資料です。

Transcript

1. AIから最も使われやすいfreeeへ 〜Headless化を⽀えるAPI量産戦略〜 髙⼭ 湧気（hamilton） 2026年10⽉3⽇
2. 常務執⾏役員 VPoE 統合flow基盤統括本部⻑ 髙山 湧気（hamilton） ワークスアプリケーションズを経て、 2017年freeeへ入社。 エンジニア、エンジニアリングマネージャー、プ ロダクトマネージャーを経て、現職へ。
3. 00 創業期からの理想
4. 創業からの⼀貫したメッセージ • 2013年10⽉、国内初の会計ソフトPublic APIを公開 ◦ 「会計ソフトのAPIなんて誰が使うのか」と⾔われた時代 ◦ そこから請求書‧⼈事労務‧プロジェクト管理などへ公開範囲を拡充 • 2026年、規模は当時からさらに拡⼤中 ◦ 公開しているPublic APIの数: 487 ◦ freeeアプリストアの掲載数: 203 • この考え⽅は、10年以上経った今も変わっていない ◦ 状況が変わっても、オープンであることに投資し続ける ◦ その姿勢が、今につながっている
5. 01 AI時代のパラダイムシフト
6. プロダクトの価値を決める変数の移動 • Before: UI時代の競争優位性 ◦ 画⾯の使いやすさ、⼊⼒補助、機能数 ◦ 「良い画⾯を作れるか」が勝負だった • After: AI時代の競争優位性 ◦ APIがなければ、AIから⾒ればその機能は「存在しない」のと同じ ◦ APIがあるから、AIはその機能を使える • なぜこれが社会的にも⼤事か ◦ 会計‧給与計算は頻繁に変わる法令順守と正確性が絶対条件。AIには代 替できない領域 ◦ AIがfreeeを正しく使いこなせることで、社会全体の⽣産性が上がる
7. 02 3,000の再利⽤可能APIへ
8. 再利⽤可能APIとは web/mobile画面 (UI) freee-mcp / public api freee製品内 AI agent 個別企業向け カスタム開発 業種特化 アプリ 再利用可能 API ─ どのクライアントからでも同じ形で呼び出せる、共通のインターフェース層 ドメイン / コアロジック（データとビジネスロジック） 1つのロジックを再利用可能 APIとして書けば、あらゆる利用先に転用できる
9. 再利⽤可能APIの量産戦略 • 再利⽤可能APIとは何か ◦ 画⾯(UI)に閉じず、AIエージェントを含むあらゆるインターフェースから 呼び出せるAPI ◦ これをとにかく増やしていく • 再利⽤可能API化は、⽬新しい概念ではない ◦ 「再利⽤可能なAPI」という考え⽅⾃体は、業界で⻑年語られてきた原則 ◦ freeeはこれを、全社規模で本気でやり切るフェーズへ • まず10倍の3,000へ ◦ 全機能を網羅する再利⽤可能API基盤を全社で構築 ◦ 社内開発効率とAIのために、爆発的に増やす
10. 03 世の中の変化とfreeeの現在地
11. 世の中はどう変わってきているか • 会計SaaS業界全体でAPI/MCP化が加速 ◦ 2026年3⽉、freee-mcpをOSS公開。1か⽉⾜らずでリモート版も追加 ◦ 同時期に他の会計SaaSも、全プランでMCPサーバー‧APIの提供を開始 • 現場から、想像以上の熱量ある反響 ◦ 税理⼠さんや個⼈開発者が次々とfreee-mcpを使った⾃動化事例を公開 ◦ ⽣産性の爆増事例や、体験の良さを指摘する声も • AI以外の⽤途においても、ヘッドレス化のニーズが急速に⾼まっている ◦ 共通のSaaSを育てる開発だけでなく、個別企業向けカスタム開発や業種特化 製品開発が増加 ◦ APIを直接組み合わせて作る開発が当たり前になりつつある
12. 05 裏側のリアル
13. 理論上はできるはず。でも実際はなかなか進まない • 7⽉に追加された新規APIの231本のうち、再利⽤可能APIは7本 ◦ 当⽉の再利⽤可能API化率3% ◦ 「想定内」のスタート • 累計では、全社API 9,870本中93本(1%) ◦ 絶対数としてはまだ⼩さい ◦ 対外的な「Public API 487本」とは別建てのカウント • 実際進めてみると、⾔語化されていなかった課題が⼀気に噴出した
14. 実際に上がってきた現場の声 • 「再利⽤可能API」とそうではないもの境界が分かりにくい ◦ 議論を重ねながらガイドラインの整理を続けている • 汎⽤性と品質の話は切り離せない ◦ どこまでの⽤途に対して想定するのか。その考慮のためにどこまで時 間を使うのか • ⼀⽅で、これはソフトウェアの設計レベルをあげる良い機会とポジティ ブに捉えているリーダーも ◦ 再利⽤可能APIを普通に作れるハイレベルな技術組織にしていきたい
15. 再利⽤可能APIを宣⾔だけで終わらせないための仕組み • 「再利⽤可能API」と名乗るには、満たすべき基準がある ◦ 全社ガイドラインで、宣⾔に必要な基準(MUST要件)を定義 ▪ 標準化された構造、命名、権限やプランなどの制限、バリデーションの 完結性、デフォルトパラメータなどのルールなど ◦ OpenAPIスキーマとして掲載して初めて「再利⽤可能」と宣⾔できる • それでも、API品質は⼀⾔では語れない ◦ 画⾯の体験‧品質と同じくらい奥が深いテーマ ◦ ガイドラインだけでは解決しない、現場ごとの判断が必要な部分がある • だからこそ、全社横断で議論する場を整備しつつある ◦ 各チームがガイドラインを⾃分たちの領域に合わせて解釈‧適⽤ ◦ レビューを⽀援する仕組みも⽤意し、みんなで作っていく体制へ
16. 06 私が⾏った意思決定
17. 全社のAPI開発状況を、全部可視化した • どのチームが何本APIを作り、どれだけ再利⽤可能かを⼀覧化 ◦ 全社のAPI開発状況を横断的に可視化する仕組みを整備 ◦ 「再利⽤可能」として宣⾔できる仕組みもあわせて整備 • 毎⽉の経営レポート会議で、⾃動的に報告される仕組みに ◦ 新規で作ったAPIの数と同じ数だけ再利⽤可能APIにする、という未達のラ インを明確な⽬標に設定 ◦ なぜできたのか、なぜできなかったのかを、数字を⾒ながら強度⾼く議論 できる場に
18. 数値⽬標だけで終わらせないために、徹底的に会話 • 出てきた課題や意⾒に、泥臭く向き合う ◦ 強度⾼い議論から出てきた声(課題、迷い、困りごと、反対意⾒など)を⼀つ ずつ拾う • #api-feedbackチャンネル ◦ Slackワークフローで要望を⾃動的にJIRAへ集約 ◦ プロダクトオーナーと利⽤側を繋ぐ場に • APIファーストオフィスアワー ◦ 毎週⽉曜15:30〜、職種を問わず気軽に相談できる場 ◦ 相談できる窓⼝があることで、現場の悩みが可視化された • 各チームのテックリードが集まる場も⽤意 ◦ ⾼い品質でAPIファーストを実現していくには何が必要かを議論 ◦ 議論の結果を、全社の⽅針として決めていく
19. 08 副次効果とエンジニア以外の関わり⽅
20. 副次効果 • APIレベルでテストをしやすくなる ◦ 画⾯からのブラックボックステストより、API単体でのテスト設計‧実 ⾏の⽅が効率が良い ◦ テスト実⾏の⾃動化を進めやすくなる • 画⾯なし開発は、AI開発との相性が良い ◦ 画⾯(UI)を作らない開発は、AIによってほぼ全⾃動で⾏える事例が出始 めている
21. PdM‧デザイナーにとっても、無関係な戦略ではない • これはエンジニアだけの戦略ではない ◦ プロダクトの企画のあり⽅そのものに関わる話 • PdM‧デザイナーに伝えていること ◦ 画⾯から考えるのをやめよう ◦ 「要求仕様(不変な業務‧事実)」の定義から始める ▪ 課題やユースケースを、画⾯ではない形でしっかり⾔語化する • それが、API-firstなものづくりを⽀える ◦ エンジニアが使い回しの効くAPIを設計できるようになる ◦ 単発の画⾯開発より、将来レバレッジの効く「再利⽤性」への投資を 選べるようになる
22. 結び • AI時代において、再利⽤可能なAPIを作ることは選択ではなく前提になる ◦ APIがなければ、AIにとってその機能は存在しないのと同じ ◦ AIでいろんな⼈が作ったアプリをfreeeのAPIと繋げられるようにするこ も世の中のためにとても⼤事 • 開発組織全体の考え⽅を変えるアプローチが必要 ◦ ⽬標設定‧可視化‧議論の場を仕組みとして整備し、⽂化として根づか せる ◦ エンジニアだけでなく、PdM‧デザイナーの動き⽅も変えていく • APIの作り⽅にこだわり、AI時代のプラットフォームへ ◦ 10年前からの「オープンにし、世の中と繋ぐ」という思想を、次のス テージへ ◦ AIに最も選ばれるプラットフォームへ、さらに進化していきます