Coding Agentの時代: ソフトウェアエンジニアの未来
社内 IT の部署であるGYOMUハックでマネージャーをやっている kumataro です。私たちの取り組みから実感している次の時代のソフトウェアエンジニア像のひとつについて書いてみました。 2025年から2026年にかけて、Coding Agent が爆発的に進化しました。Claude Code や Codex、GitHub Copilot Agent など、コードを書くだけならAIが人間よりも高速かつ正確にこなせる時代が現実のものになりつつあります。 最近は、自分で1行もコードを書いていないという話も聞くようになってきました。 そんな環境ですので「AIに仕事を奪われるのではないか」という不安を抱いているソフトウェアエンジニアの方も多いのではないでしょうか。 「コードを書くことそのもの」に強いやりがいを感じているエンジニアにとっては、大きな変化に戸惑う側面もあるかもしれません。しかし「課題を解決すること」が目的であるエンジニアにとって、AI はこれ以上ない強力な武器です。私たちはこの変化を、エンジニアという職種がより本質的な価値へと回帰するチャンスだと捉えています。 Coding Agent 時代に陥りやすい罠 私たちは社内のバックオフィスの生産性を向上させるためのエンジニアチームです。Claude Code を用い、実装の速度が増したことにより、寄せられる要望に対応できる能力も高まっています。 同時に、ここには罠が存在することにも気づきました。それは、開発速度が増したことにより、寄せられた要望に素早く対応するだけの存在に陥ってしまいやすいということです。対応は感謝されるだけに、すぐに要望を実現したい気持ちはエンジニアにとっても、とても強いものです。 しかし、この先に待ち受けているのは、部門、業務ごとに個別最適化された処理やデータの乱立です。一見、業務は最適化されているように見えますが、全体的な視点では業務の重複による一貫性のなさや、データの散在が起こり、連携が困難な状況が急速に拡大するのが目に見えています。 実際に freee のバックオフィス内でも、従業員数の予測値について、労務と社内IT、財務の間でそれぞれの課題感から別々に算出している事例がありました。このような組織横断的な不整合の解決は個別の部署の業務改善では実現できません。 こうした「部分最適の罠」を回避し、AI を真の武器として活かすためには、単なる「対応力」を超えた、より戦略的なアプローチが不可欠です。そこで私たちが今改めて立ち返ったのが BPR と FDE というふたつのキーワードです。 道を切り開くふたつのキーワード、BPR と FDE BPR（Business Process Re-engineering）: 既存の業務プロセスをそのままシステム化するのではなく、プロセスそのものを根本から再設計すること。 FDE（Forward Deployed Engineer）: 本社のオフィスで仕様調整を待つのではなく、現場に入り込み、業務を観察し、課題を発見し、動くものを作って解決する「前線配備エンジニア」。 FDE は米国 Palantir 社などが先駆けて導入し有名になったポジションですが、これが「今の時代」に特にもてはやされているのには、明確な技術的・ビジネス的な背景があります。 freee でも社内のバックオフィスでは、ドッグフーディング的に自社プロダクトを利用しています。そういった環境での業務改善において、パッケージ化された SaaS をそのまま導入するだけでは解決できない企業固有の複雑な課題は残るのが現実です。 SaaS のデータと社内独自のデータの統合: 業務活動ではデータ分析の要求は常にあります。しかし、SaaS 内のデータと SaaS 外のデータを統合して扱うのは簡単なことではありません。また同じ元データのはずのものが部署毎の処理の中で異なる数字になって出てくることもあります。 スピード感: フィードバックは SaaS プロダクトに届けることができます。しかし、開発優先度の問題や SaaS としての全体最適化の中で、対応スピードは思うように上がりません。 個別最適化: SaaS という性質上、個社別の環境に最適化するわけには行かないため、個別の事情にピッタリマッチする改善はできないのが現実です。 こういった課題に対して、FDE は現場で活動している強みで、自ら解決策を提示し、導入、運用まで進めることができる役割となっています。 私たちのチームは社内における FDE として、業務をハックするエンジニアチームです。私たちが取り組んでいるのは、まさにこの FDE の動きを通じた BPR の実践です。 ミッションとバリュー では、ふたつのキーワードと陥りやすい罠を避けるために、どのようなマインドセットを持って業務に取り組めば良いと考えているのか紹介してみます。 私たちのミッションは「テクノロジーと対話を通じて、バックオフィスの生産性を最大化し、全従業員がより創造的な業務に集中できる環境を創り出す」ことです。このミッションを実現するために、以下の4つのバリューを大切にしています。 Why First（なぜ？から始める） 私たちは、表面的な要望の奥にある本質的な課題を探求することを常に最優先します。依頼された解決策をそのまま実装するのではなく「その業務はそもそも必要なのか？」「理想の状態は何か？」という問いから始めます。必要であれば「開発しない（業務自体をなくす）」という選択すら積極的に行います。 Be a Partner（最高のパートナーであれ） 私たちは、依頼者を「お客様」ではなく「課題解決のパートナー」と捉え、共に考え、共に成功を目指します。依頼者と対話し、業務のAs-Is/To-Beを描きながら、現場の泥臭い課題を共に解きほぐしていきます。 Impact Driven（インパクトで動く） 私たちは、取り組むべき改善を、そのインパクト（効果）の大きさによって判断します。 Go Simple（シンプルを追求する） 私たちは、複雑な問題を、誰もが使い続けられるシンプルで持続可能な解決策へと導きます。 私たちが目指すシステム全体像 こういった理想を実現するため、現場の課題に寄り添いながら、同時にそれを支える強固な技術基盤も並行して構築しています。現在、私たちが構築しているシステム全体のイメージ図を共有します。 開発中の基盤の全体像 Cadiz: OneLogin × AWS Cognito × Cerbosを組み合わせ、行・列レベルの認可制御を一元化した社内アプリ開発基盤。社内業務で用いる社員のセンシティブなデータも適切に守る。 Service Data Pipeline: AWS EKS 上で構築した自前のデータ連携基盤。複数の SaaS やデータソース間を柔軟に連携。 データ分析基盤: Google Cloud（BigQuery）/ Looker Cloud Core / Looker Studio Pro で構築したバックオフィスデータマネジメントを支えるデータ活用基盤。局所最適化された自動化でデータの分断が起こらないように一元化。 これらは単なるツールではなく、バックオフィスという複雑な領域を、他社にも誇れる「ショーケース」に変えるための重要なパーツです。これらの技術選定の裏側や、なぜその構成を選んだのかというトレードオフについても、また別の機会に詳しく共有していきたいと考えています。 まだまだ道半ば ここまで「FDE 的な動き」や「強固な基盤」について書いてきましたが、正直に言えば私たちはまだ、目的を成し遂げるための努力が必要な「発展途上」の段階です。 バックオフィスの現場には、未解決の複雑な業務フローや、解決すべきレガシーな仕組みが山ほど残っています。しかし、だからこそ面白い。 完成されたシステムを保守するのではなく、業務の現場に深く入り込み、技術の力で泥臭い課題を一つずつ解きほぐし、組織のあり方そのものを変えていく。この「変化のプロセス」こそが、私たちがエンジニアリングを通じて体験できる最大の醍醐味です。 これらの状況は、程度の差こそあれ、どのような会社にも存在するものではないでしょうか。 Coding Agent が強力になる中で、これからのエンジニアに必要なスキルセットは現場の深い理解（ドメイン知識）と、それを技術で最適化するアーキテクチャ設計能力の掛け合わせではないか、というのをひとつの答えとして提示してみました。 最後に GYOMUハックは、AIを武器に変え、バックオフィスの「前線」で挑戦を続ける仲間を募集しています。 「技術を使って組織を強くしたい」「コードを書く以上に、本質的な課題解決をしたい」と考えているエンジニアの方、ぜひ私たちと一緒にバックオフィスの新しいあり方を創りませんか？ hire.wantedly.com
- 生成AI
- アーキテクチャ
- AWS
- Google Cloud
要求から体験への変換を、AIが検証する時代のデザインシステム
はじめに 現在freeeでAIフィジビリティ検証基盤のPdMをしています。Jです。もともとはフロントエンドエンジニア、デザインエンジニア、プロダクトデザイナーとキャリアを渡り歩いてきました。 どの職種にいても感じていたのは、要求が画面になり体験になるまでの変換のたびにロスが発生する、という問題です。デザイナーがFigmaで描いた画面をエンジニアが実装すると、見た目のズレで差し戻しが入る。デザインシステムのコンポーネントが標準化されても、画面全体の組み立て方（どのパターンを使い、要素をどう配置し、状態遷移をどう設計するか）は各チームの解釈に委ねられていた。コンポーネントが揃っていても、組み合わせ方の解釈が食い違えば「意図と違う」は起き続けます。 2023年頃には、この断絶の橋渡し役として「デザインエンジニア」が業界で注目されましたが、橋渡しを人に求める限りスケールしません。この変換を、人ではなく仕組みで担保する必要がありました。しかし当時、その仕組みは存在しなかった。AIコーディングエージェントの登場が、このパラダイムを変えることになります。 この記事では、freeeのデザインシステムの変遷と、この変換の検証をAIが担うに至るまでの過程を整理します。 要求、UI設計、実装、体験 要求が画面になり、ユーザーの体験になるまでには、3つの変換を経て4つの層を通ります。 要求: 機能要求やユースケース。何を実現するか、誰がどう使うか。 UI設計: 要求を画面構成に落とし込む。どの画面パターンを使い、どの要素をどう配置するか。 実装（この記事ではフロントエンド実装に焦点を当てる）: 状態管理や異常系を考慮し、UI設計をコードに具現化する。 体験: 実装されたUIを通してユーザーに届くもの。操作感、情報の見通し、業務の流れやすさ。 デザインシステムはUI設計と実装に使われる制約を定義します。freeeでは、その制約を通して届けたい体験を「デザインプリンシプル」として定義しています。 デザインプリンシプルとは、プロダクトの見た目や使い勝手を設計する際の「判断基準」となる基本方針（原則）のことです。プロダクト全体の体験に一貫性を持たせつつ、素早く質の高いデザイン判断を行うための土台として機能します。 プリンシプルは、UI設計の判断基準であると同時に、実装されたUIを通して届く体験の質を測る基準でもあります。 フィジビリティ検証とは、今の要求をデザインシステムの制約を通してUI設計・実装したとき、どのような体験になるかを確認すること。制約の中で設計・実装できるかだけでなく、その結果がプリンシプルの目指す体験に到達できるかまでを含みます。 ここまでの前段：freeeのデザインシステムが辿ってきた2つの試行 freeeのデザインシステムがどのような試行を経てきたかを整理します。 freeeがこれまで辿ってきた2つの試行。部品レベルの標準化から画面パターンレベルの標準化へと、制約の粒度が拡張されてきた。 第1の試行：UIの部品を標準化する（vibes） freeeでは2018年からデザインシステム「vibes」を開発・運用してきました。ボタン、テキストフィールド、テーブルといったAtomsやMoleculesレベルのコンポーネントを共通化し、アクセシビリティを含む品質を標準化しました。 vibesの導入で、部品レベルの見た目と品質は統一されました。しかし、規模が拡大し開発チームが増えていく中で、制約の粒度が足りないことが見えてきました。個々のコンポーネントは揃っていても、要求からUI設計への変換は各チームの裁量に委ねられていました。同じような要求に対しても、アプリケーションによってUI設計が異なり、実装もバラバラになり、ユーザーに届く体験が一貫しなくなっていました。 部品の制約だけでは、要求→UI設計→実装→体験の一貫性は保てませんでした。 第2の試行：プリンシプルを画面パターンに翻訳する（標準UI） 個々の部品ではなく、要求をUI設計に変換するパターンそのものを標準化する。これが第2の試行の答えでした。 freeeではまず、UIを通して届けるべき体験を「デザインプリンシプル」として策定しました。そしてこのプリンシプルを体現する画面パターンとして、高機能UIライブラリ「標準UI」の開発を進めました。この取り組みについては「デザインシステムを拡張し、プロダクト開発の共通基盤を目指す」で詳しく紹介しています。 標準UIは、vibesのコンポーネントを内部的に使用しつつ、業務システムで基本となる3つのパターン（一覧・詳細・作成/編集）を、少数のコンポーネントを組み合わせるだけで作成できるようにしました。UI設計だけでなく、状態管理やAPI連携、エラーハンドリングといった実装ロジックも標準化の対象とし、プリンシプルが目指す体験をUI設計と実装の両面から担保できる状態を目指しました。 この試行の本質は、プリンシプル（目指す体験）を、画面パターン（UI設計と実装の制約）に翻訳したことです。 制約は成熟した。使いこなすためのハードルが残った 第2の試行で制約は成熟し、今も成長を続けています。標準UIの画面パターンのおかげで、要求→UI設計→実装の変換における組み合わせ方のばらつきは大幅に減りました。しかし、2つのハードルが残っていました。 制約を作るハードル 画面パターンレベルの制約を作るには、具象から抽象を描き出せるシニアデザイナーの知識と、エンジニアリングとデザインの両方を持つUIエンジニアの力が必要です。 制約を使いこなすハードル 制約を利用する側にも、コンポーネント仕様の理解、インターフェースの把握、画面パターンの使い分け判断という学習コストが伴いました。そして最も大きな問題は、「この要求を、この制約でUI設計・実装したとき、プリンシプルが目指す体験に到達できるか」の判断が専門家にしかできなかったことです。Figmaでは制約の外でも何でも描けるからこそ、この検証が後回しになっていました。 これらのハードルは、標準UIの成果を否定するものではありません。標準UIがなければ、組み合わせ方の標準化自体が存在しなかった。しかし、標準化された制約を使いこなし、要求から体験までの変換を検証する仕組みは、まだありませんでした。 cutterの構築：制約をAIに渡すだけでは解決しない では、制約をAIに渡せば解決するのか。答えはNoでした。 freeeではこの問題を解決するために、デザインシステムの制約をAIのコンテキストとして活用する検証パイプライン「cutter」を構築しました（noteの「AIで速く作るほど遅くなる──手戻りを生む「変換コスト」を潰す、基盤化の話」で紹介しています）。このcutterの画面設計エージェントが1枚の画面を設計するとき、実際に参照しているものを並べてみると、コンポーネント仕様だけでは足りない理由がわかります。 コンポーネントの仕様: UIの部品として何が存在し、どんなインターフェースを持つか 画面パターン別の設計ガイドライン: 一覧・詳細・ウィザードそれぞれの構成ルール UIの要素別ガイドライン: ボタン配置、フォームバリデーション、モーダルの原則、ライティングルール、誤操作防止など デザインプリンシプル: 「業務フロー動線に沿った画面分割」「反復操作の効率」「情報の一覧性」など13のプリンシプル 実現可否の判定基準: 機能・レイアウト・視覚表現・インタラクションの4観点での評価 階層構造のルール: Container → Area → Segment → Block → ElementというUIの入れ子の文法 これらが整備されていない状態でAIにUIを作らせると、何が起きるか。これは人のチーム開発で起きていた問題と同じ構造です。1人の熟練者なら暗黙知でカバーできても、複数人で開発すると解釈がずれる。AIエージェントも同じで、明示的なルールがなければ各画面で判断がばらつき、スロップ（意図しないばらつき・劣化）を生みます。 設計ガイドラインがなければ、一覧画面と詳細画面の構成ルールの違いを知らず、すべて同じ構造で組み立てる。要素別ガイドラインがなければ、削除ボタンを確認なしで配置したり、バリデーションメッセージの表示位置が画面ごとに異なったりする。プリンシプルがなければ、「動くが使いにくい」UIが生成される。実現可否の判定基準がなければ、制約を無視して自由に組み立ててしまう。階層構造のルールがなければ、レイアウトが破綻する。 人のチーム開発では、これをレビューやペアプログラミングで防いできました。AIの場合は、これらのルールをコンテキストとして渡すことで防ぎます。解決の手段は違いますが、問題の構造は同じです。 つまり、コンポーネント仕様は6つの要素のひとつにすぎません。要求をUI設計に変換する判断基準（ガイドライン）、UIを通して届ける体験の基準（プリンシプル）、変換の実現可否を判定する仕組み。これらすべてをAIのコンテキストとして整備し、さらにFigmaを介さずコードベースで要求からUI設計・実装・体験の検証までを一気通貫で行う。これがcutterの発想です。 cutterを支える4つの要素とAIオーケストレーション デザインシステムの制約をAIがフィジビリティ検証に使えるようにするために、4つの要素を整備しました。 体験の判断基準をテキスト化する: プリンシプルやコンポーネントの使い分けルールを、AIがスキルとして参照できるMarkdownに変換する。Claude Codeのskillsのように、AIエージェントが設計判断の場面で必要なナレッジを呼び出せる形式にします。 制約の範囲をAIリーダブルにする: 各コンポーネントの仕様をAIリーダブルなドキュメントに整理する。人向けのStorybookやデザインファイルではなく、AIエージェントが機械的に参照・判定できるテキスト形式にすることがポイントです。 変換プロセスを標準化する: PRDのフォーマットと画面設計の記法（UFML、slideの「図じゃなく言語で描く - Common Ground for Design AI Operations」で紹介しています）を定義し、AIエージェントのワークフローに組み込みます。UFMLはユースケースの完遂に必要な画面要素・遷移・アクションを宣言的に記述する中間言語です。 品質評価の仕組みを組み込む: 各ユースケースが必要な要素を満たしているか、複数のユースケースが干渉し合わないか、仕様に曖昧さが残っていないか。こうした品質チェックをパイプラインに組み込み、変換精度を構造的に担保します。 11のエージェントによるオーケストレーション これらの要素は、渡すだけでは機能しません。要求→UI設計→実装→体験の変換は一度に行えるほど単純ではなく、デザイナーやエンジニアが日常的に行っている設計・実装・検証のオペレーションを丁寧に分解し、各工程を専門のAIエージェントに委ね、中間成果物を次の工程に受け渡していく。このオーケストレーションが品質の鍵です。 cutterでは、中央のオーケストレーターが11の専門エージェントを協調させて検証を実行します。 <img src="https://cdn-ak.f.st-hatena.com/images/fotolife/n/neejack72/20260421/20260421164247.png" alt="上部にオーケストレーター、下に4つのフェーズが縦に並ぶ構成図。PHASE 1「要求の構造化」にエージェント1 (プロジェクトセットアップ) と2 (プランニング)、PHASE 2「UI設計の検証」にエージェント3 (プロトタイプ準備) と4 (画面間連携の構築)、PHASE 3「画面単位の並列処理」にエージェント5 (UI設計)・6 (カスタム要素構築、条件付き並列)・7 (画面実装)・8 (画面エラー解決)・9 (レイアウト検証)・10 (UIレビュー) の5段階パイプライン、PHASE 4「全体検証」にエージェント11 (全体エラ&#x
- デザインシステム
- 生成AI
- React
PHPカンファレンス小田原 2026に参加してきました！
こんにちは！フリーナンスのエンジニアをやっているthe よしだです！ 今回は2026年4月11日(土)におだわら市民交流センター UMECOで開催された「PHPカンファレンス小田原 2026」に参加してきました！ RubyKaigi が開催地を毎年変えるスタイルなのに対し、PHPカンファレンスは地域コミュニティが主体となって開催されるという違いがあり、その多様性が面白い部分です。 私自身、地方開催のカンファレンスは今回が初参加なのですが、「小田原は首都圏から日帰りで参加でき、地方カンファレンスの良さを味わえる」と聞き、早速参加することにしました。 今回はその中で特に印象に残ったトークを紹介していきたいと思います！ 特に印象に残ったトーク Webアプリケーションエンジニアにも知ってほしい オブザーバビリティ の本質 speakerdeck.com オブザーバビリティの概念の丁寧な説明から始まり、初学者だけでなく学び直しの方にも最適な内容でした。 また、AIが普及してきた今だからこそ、オブザーバビリティを意識することの大切さを説いており、チーム全体で取り組む重要性にも触れていました。 当たり前ではありますが、「ツールを導入することが目的ではなく、考え方を進化させることが必要」の部分には、ハッとさせられることも多く、とても実りの多い内容でした。 PHPと旅するOSI 7階層 第二章 docs.google.com PHP で IPルーターを作った話でした。 中でもチューニングの部分が非常に面白く、何をしたらどのくらい速度が上がったのか紹介されています。 同日の別のトークではPHPでMP3プレイヤーを作成した方の話もあるくらいでして、PHPerのPHP愛を感じるトーク達です。 デシリアライゼーションを理解する speakerdeck.com デシリアライゼーションに起因する脆弱性の話から、PHPのデシリアライゼーションについて、脆弱性のデモとかなり丁寧にデシリアライゼーションを理解できるトークでした。 特にデモで紹介されたTODOアプリの脆弱性は、分かりやすく、理解の助けになりました。 脆弱性を起こさないための方法や、デシリアライゼーションとの付き合い方をまとめており、学びの多いトークでした。 ドメインエキスパートだったのでDDD+Claude Codeでチート開発します〜 speakerdeck.com ライトノベルの「なろう系」を彷彿とさせるコミカルな演出で始まりましたが、内容は非常に実践的でAIにおけるゼロイチ開発のリアルを生々しく語っていました。 また、まとめとして「ユーザーに向き合って着実に作る」というメッセージを明確に出しており、面白さだけでない熱い話を聞くことができました。 Past, Present, Future: The PHPUnit Story phpunit.expert PHPUnit の作者である Sebastian Bergmann がオンラインで登壇してくれました。 PHPUnitのこれまでを振り返る濃密な時間であり、PHPUnitの恩恵を受けた私たちにとって胸が熱い話が沢山聞けました。 このような方々の尽力のお陰で今のPHPは存在していると再認識させられる、そんな時間でした。 最後に 初めて小田原に降り立ち、カンファレンスに参加しましたが、カンファレンスの満足度も非常に高く、また参加したいと思っています！ それだけでなく、小田原には観光でも行ってみたいと思いました！ ぜひ、小田原おすすめの観光スポットがあれば教えてください！
- PHP
- オブザーバビリティ
- セキュリティ
- DDD
- 生成AI
AI Agentに関する試行錯誤を共有する社内LTイベントを開催しました！
こんにちは！freee請求書の開発エンジニアをしているkochanです。 近年、AI Agentの進歩が目覚ましく、AI Agentを使って開発生産性を向上させた事例や、AI Agentを組み込んだ機能提供の事例が続々と登場しています。 しかし、いざ実務に投入しようとすると、プロンプトの微調整に追われたり、期待通りの挙動にならず頭を抱えたりと、理想と現実のギャップにぶつかることも少なくありません。 今回は、そんな現場の泥臭い試行錯誤を組織で共有するために開催した、社内LTイベントの様子を紹介します。 LT会の様子 開催の背景 組織全体でClaude Codeを利用した開発が推進されていたり、AI Agentを利用した機能提供が進んでいます。その中で、Claude Codeによる生産性向上やAI Agent機能開発の知見が、各チームや個人に閉じてしまっているという課題が出てきました。 AI Agentを業務に適用するにはまだまだ試行錯誤が必要です。特定のタスクに適用するために格闘したプロセスをオープンに共有し、「不確実性を楽しみながら乗りこなせるエンジニア」を増やしたいと思い、今回のイベントを企画しました。 社内でAI Agentを用いた機能開発をしている方やClaude Codeを使った開発生産性向上のための仕組み作りに取り組んでいる方々にお声がけし、9人の方に発表してもらいました。 セッション紹介 全9セッションの中から、特に印象的だった2つの発表をピックアップして紹介します。 Rails UpgradeをAI Skillで仕組み化した話 登壇者：nuresen 内容の要約 nuresenさんは、Rails 7系から8.1への一気通貫したアップデートを、Claude CodeのSkillsを活用して仕組み化した事例を共有してくれました。 初めは1つのセッションでUpgrade作業を実施しようとしましたが、コンテキストの肥大化による精度低下の問題があることや、途中で人間による細かい介入がしづらいといった課題が見つかりました。 そこでUpgrade作業を、調査、依存関係解決、失敗の分析、修正、設定更新の５つのステップに分割し、それぞれに対応したSkillを定義。各ステップの成果物をMarkdownとして出力し、それを次のステップの入力にする設計にすることで、コンテキストの肥大化による精度低下を回避。人間が各チェックポイントで意思決定できる仕組みを構築しました。 詳細はfreee Developers Hubにも投稿されているので、気になる方はぜひこちらの記事も見てください！ developers.freee.co.jp nuresenさんの発表の様子 現場の反応 「ベテランの暗黙知がSkill化されて、誰でも簡単にRails Upgradeできる状態になったのすごい」「巨大なタスクをステップごとに分割するアプローチは、他の業務自動化にも展開したい」と、実用性の高さを評価する声が多かったです。 まほう経費精算プロジェクト 登壇者：momoji 内容の要約 まほう経費精算の開発に関わったエンジニアのmomojiさんからは、サービス提供に至るまでの、泥臭い試行錯誤の記録が共有されました。 まほう経費精算とはAIエージェントが過去の傾向から申請内容を推測することで、誰でも迷わず正確な申請ができる機能です。 corp.freee.co.jp 開発当初はのチャットUIで何でも解決できるという構想でしたが、ユーザーの入力負担が多く、利用してもらえないという失敗談からスタート。そこからターゲットを大量の領収書が発生する訪問ワーカーに絞り込み、まずは利用してもらってフィードバックを得ることを目指しました。フィードバックと改善を回す中でAIの推測が正しいか確認することに特化した専用UIへと方向転換した経緯が語られました。 まほう経費精算のUIの試行錯誤 現場の反応 「まずはN=1でもいいから使い倒してもらい、フィードバックを回す姿勢を見習いたい。」「AI Agentという不確実な対象だからこそ、これまで以上にアジャイル開発の重要性が上がっている。」といった、反応がありました。 振り返りと今後 AI Agentの進化スピードは凄まじく、今日得た正解が明日には古くなっているかもしれません。だからこそ、組織全体で知見をオープンにし、互いの失敗と成功を共有して資産にしていく文化が重要だと思います。 これからも定期的にこうした知見共有の場を設け、freee全体でAI Agentという荒波を楽しみながら、開発生産性とプロダクト価値の向上に挑み続けていこうと思います！
- 生成AI
- 自動化
- アジャイル