freee 技術の日 2026に参加してきました。

自社開発企業の技術だけでなく、そこで働くエンジニアや開発文化を知りたくて参加しました。

実際に参加してみると、大規模リファクタリング、AIエージェント、ブラウザ動作確認の自動化、API、データ基盤など、かなり幅広い話を聞くことができました。

それぞれ違うテーマの発表でしたが、聞いているうちに自分の中では一つの考え方につながっていきました。

「人間やAIが正しく判断してくれることに頼るのではなく、間違えることを前提に仕組みを作る」

という考え方です。

「全部分かってから変更する」を前提にしない

特に印象に残ったのが、

「ETCカード提供の裏側ー大規模リファクタリングを支えた戦略と戦術」

というセッションでした。

ここで出てきた、

「すべて把握することを諦める」

という言葉がかなり印象に残っています。

最初に聞いたときは少し意外でした。

大規模な変更ほど、影響範囲を全部調べて、理解してから変更するものだと思っていたからです。

でも、「分からないまま変更していい」という話ではありませんでした。

すべてを人間が把握できることを、安全性の前提にしない。

その代わり、新旧の処理を並行して動かして結果を比較したり、問題が起きたときに旧バージョンへ戻れるようにしたりする。

つまり、

「絶対に間違えないようにする」のではなく、「間違えても戻れるようにする」。

という考え方でした。

これは自分にとってかなり新しい視点でした。

AIでも同じ話が出てきた

ポスターセッションでは、AIエージェントについて研究されている方とも話すことができました。

そこで聞いた話も、自分の中では大規模リファクタリングの話と少し似ていました。

LLMは、本当は判断できていなくても、それらしい回答を生成できてしまいます。

例えばAIに、

「この処理は問題ありませんか？」

と聞けば、何らかの答えは返ってきます。

でも、それが本当に保証された「OK」なのかは別の話です。

そこで、Leanなどの形式的・数学的に検証できる仕組みと組み合わせて、保証できる場合だけ結果を返す。

保証できないなら、無理にAIへ判断させずエラーにする。

という考え方について聞きました。

※この部分はポスターセッションで直接聞いた内容を、自分なりに理解して整理したものです。

ここでも、

AIを100%正しくする

という方向ではありません。

AIは間違える可能性がある。

それなら、

間違った判断を、そのままシステム上の「OK」にできないようにする。

という考え方です。

大規模リファクタリングでは、

「人間が全部理解できる」ことを前提にしない。

AIエージェントでは、

「AIが必ず正しく判断する」ことを前提にしない。

扱っているものは違いますが、自分の中ではかなり近い話に見えました。

AIに仕事をさせるための「道具」を作る

AIを使ったブラウザ動作確認の自動化についての発表も面白かったです。

ここでは、freeeのサービス群を操作できるCLI「inoC」が紹介されていました。

AIに大量のHTMLや画面情報を最初から全部渡すのではなく、CLIを通して必要な情報を必要なタイミングで取得できるようにする。

情報をたくさん与えてAIに頑張って理解してもらうのではなく、

AIが仕事をしやすいインターフェースをシステム側に作る。

という考え方です。

この取り組みでは、従来2週間程度かかっていた動作確認を2日程度まで短縮できたという話もありました。

AI活用というと、モデルをもっと賢くするとか、プロンプトを工夫するとか、そういう方向に目が向きがちです。

でも今回の話を聞いて、

AIそのものだけではなく、AIが扱いやすい環境を周りに作ることも設計なんだ

と感じました。

APIの話でも「境界」が出てきた

「AIから最も使われやすいfreeeへ――Headless化を支えるAPI量産戦略」という発表も印象に残りました。

AIエージェントなどからfreeeの機能を利用してもらうためには、人間向けの画面からしか使えない機能ではなく、外部から利用できるAPIとして機能を提供する必要があります。

ただ、APIをたくさん作ればいいわけでもありません。

細かくしすぎれば、利用する側が大量のAPIを組み合わせる必要があります。

逆に、一つの画面やユースケースに特化しすぎれば、他から再利用しづらくなります。

結局、

どこで責務を切るのか。

という設計の問題が残ります。

AIがコードを書いてくれるようになっても、こういう境界を決める仕事までなくなるわけではないんだと思いました。

実装が速くなるほど、設計が重要になるのかもしれない

一日いろいろな発表を聞いて、自分の中ではこんなふうにつながりました。

既存コードを全部理解できなくてもいい。

AIが必ず正解しなくてもいい。

ただし、

変更を分割する
比較できるようにする
観測できるようにする
保証できないなら止める
問題があれば戻れるようにする
AIや人間が扱いやすいインターフェースを作る

こういった仕組みをシステム側に作っておく。

最近はAIによって「どう速く実装するか」に目が向きがちですが、実装速度が上がるほど、

どこまでを任せるのか。

どこで止めるのか。

何をシステムとして保証するのか。

という設計が、むしろ重要になるのかもしれません。

freee 技術の日 2026で、一番持ち帰りたいと思ったのはこの考え方でした。

個々の技術については、もう少し整理しながら別の記事でも書いていこうと思います。