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
- 自動化
- アジャイル
QAプロセスへのAI活用でshared-knowledgeを始めました
はじめに こんにちは、freee振込チームでQAをしているtonchanです。 本記事では、QAプロセスにAIを活用するためにshared-knowledgeという仕組みを作った話を紹介します。 この取り組みはfreee振込チーム独自のものです。社内のAI駆動QA基盤が立ち上がる前の2025年1月頃から、独自にQA専用リポジトリを作ってAI活用を始めていました。全ての成果物をMarkdown形式で管理する方針を早い段階で採用していたため、エンジニアと同じようにAIツールにそのまま渡せるフォーマットが揃っており、社内の他チームとは独立した形で発展してきました。 最初にぶつかった壁は「AIの出力する言葉がバラつく」問題です。同じ機能なのに「申請」「依頼」「予約」と毎回違う用語が出てくる...。QAの成果物は自然言語なので、この用語のブレは品質に直結します。 2025年6月、約5ヶ月間の試行錯誤を経てshared-knowledgeを構築しました。shared-knowledgeとは、人間もAIも参照する「チームの共有知識」を一元管理する場所です。 本記事では、shared-knowledgeを導入した背景、構造、運用のコツ、得られたメリットを紹介します。 freee振込におけるQAプロセスとAIが生成する成果物 まず、freee振込チームのQAプロセスの全体像を紹介します。 要求分析: PRD（Product Requirements Document）やDD（Design Docs）を読み、開発内容を理解する テスト計画: Test Summary Reportを発行し、テスト範囲・方針・スケジュールを決定する リスク洗い出し会: 関係者を集め、仕様上の懸念点やテスト環境の制約を議論する テスト分析: PRD・DDをもとに受入基準を作成する 受入基準sync会: Engと受入基準の認識をすり合わせる テスト設計: 受入基準をもとにテストチャーターを作成する テスト準備・実行: テストデータの準備、APIテスト用runbookの生成、テスト実行 テスト完了・振り返り: テスト結果の整理と改善点の洗い出し このうち、AIコマンドで生成している成果物は以下の3つです。成果物は上流から下流へ連鎖する構造になっています。 QAプロセス 成果物 テスト分析 受入基準 テスト設計 テストチャーター テスト実行 APIテスト用runbook 本記事では、これらの成果物をAIで安定して生成するための仕組みであるshared-knowledgeを紹介します。 AI活用は「すぐに効率化」ではない 「AIツールを入れればすぐ効率化できる」わけではありません。準備とステップが必要です。 私が踏んだ3つのステップを紹介します。 ステップ1: まず個人の作業で試す 仕様調査やテスト分析など、自分で完結する作業にAIを使うところから始めました QAプロセスは影響範囲が大きいので、手元で検証が終わってからでないとチームには展開できません ステップ2: うまくいったやり方を「コマンド」にする 個人で試してうまくいく場面は増えたものの、毎回AIに同じ説明をする必要があり、品質にもバラつきがありました そこで、再現性のあるプロンプト（AIへの指示書）をファイルとして保存して、誰が実行しても同じ品質の成果物が出る状態を目指しました ステップ3: チーム全員が使えるようにする コマンド化で個人の再現性は上がりましたが、開発プロセスやタスクの進め方、個人の環境に差分があると同じコマンドでも結果が変わりました これらの差分を吸収できるレベルまで汎化して、チーム標準のワークフローに組み込んでいきました いきなりチーム全体でインパクトを出そうとしないのが大事だと思っています。「個人の成功体験」を積み重ねて広げていくのが現実的です。 AI活用のための下地作り AI活用を始める前に、成果物の形式や保守運用を根本から見直す必要がありました。個人的にはここが一番大変で、かつ一番大事なところだと感じています。 AIが読み書きしやすい形式は Markdown + Git管理 です。スプレッドシートのテストケースやWikiの仕様書を、Gitリポジトリ内のMarkdownファイルに移行しました。AIツールはテキストファイルの読み書きが得意で、バイナリやSaaSの画面上のデータはまだ苦手なことが多いですよね。 もともとGit管理を始めたのはAI活用のためではなく、「成果物のレビューをしやすくしたい」「修正差分をわかりやすくしたい」という動機からでした。QAの成果物をテキストデータとして管理する必要があったためMarkdown形式を採用し、結果的にこれがAI活用の下地になりました。 ただ、この移行には痛みが伴います。 既存ツール（スプレッドシート、Wiki、Jira等）との連携をどうするか 運用の一部が変わるとプロセス全体に影響するので、計測や管理の見直しも必要になります 例えば、スプレッドシートなら会議中に全員で同時編集できましたが、Markdownファイルとgitでは同時編集やコメントの残し方に工夫が要ります。エンジニアだけでなくBizメンバーも参加する場なので、全員が使える運用を考える必要がありました それでも、従来の形式に固執するとAI活用のボトルネックになってしまいます。チームメンバーの合意を得ることが重要で、最初は効率化の成果が出にくいです（学習コストが先行するので）。 あと、AIは万能ではないです。機械的に判定できるもの（Lint、フォーマットチェック等）はスクリプトの方が確実で安定します。AIは文脈を理解した判断が必要な場面（レビュー、分析、設計）に使う、という適材適所の使い分けが大事です。 こうして下地は整ったのですが、最初にぶつかった「用語のバラつき」問題は根本的には解決していませんでした。Markdownファイルが増えるにつれ「どのファイルが正しい情報なのか」「用語の定義はどこにあるのか」がAIにも人間にもわからなくなってきました。バラバラのファイルではなく、構造化された「チームの共有知識」として一元管理する場所が必要だと気づいたのが、shared-knowledgeの始まりです。 shared-knowledgeとは何か shared-knowledgeとは、チームの共有知識をMarkdownファイル群として一元管理する仕組みです。 第一の目的はLLM活用の品質向上ですが、それだけでなくナレッジの明文化・脱属人化・保守運用の改善も狙っています。 管理対象の例: ユビキタス言語（用語辞書）: 業務用語の定義集。カテゴリごとに整理しています QAガイドライン: 成果物の作成ルールやレビュー基準 テスト戦略: テスト方針やカバレッジの考え方 機能仕様書: 各機能の設計・仕様 技術情報: API仕様やDBスキーマなどシステムの構造情報 ディレクトリ構成は以下のとおりです: shared-knowledge/ ├── domain/ # ユビキタス言語、ドメイン固有の技術知識 ├── QA/ # QAプロセス、テスト戦略、各種ルール ├── docs/ # 機能仕様書群 └── onboarding/ # 新メンバー向けガイド shared-knowledgeはAI向けに整備したものですが、副次的に人間のオンボーディングにも効果がありました。新しいメンバーがチームに参画する際、ドメイン知識やチームの文化・ルールを体系的にinputできる資料として機能しています。「AIに教えるために整理した情報」が、そのまま人間にとってもわかりやすい資料になったのは嬉しい誤算でした。 MCPサーバーだけではダメな理由 MCP（Model Context Protocol）サーバーは便利ですが、「だけ」では解決できない問題があります。 実際にMCPでWikiやチャットの情報を取得させてみましたが、生データのまま取得されるため用語がバラバラでコンテキストも不足しており、AIの出力が安定しませんでした。 情報が散在（Wiki、チャット、スプレッドシート等）していて、どこを見ればいいかわからない 「生データ」のまま取得されるので、用語の揺れやコンテキスト不足、背景情報がない どれが最新情報なのかわからない MCPサーバーとshared-knowledgeは補完関係にあります。 MCPサーバー = 情報を「集める」手段 shared-knowledge = 情報を「整理・活用」する場所 実際の運用では、MCPで最新情報を取得してshared-knowledgeに反映・整理するという流れです。「どの情報が最も信頼できるか」は人間が明示的に定義する必要があります。 AIコマンドとの連携 shared-knowledgeが真価を発揮するのは「AIコマンド」との組み合わせです。AIコマンドとは、特定のタスクをAIに実行させるための定型的な指示のことです。Claude Codeのskills、OpenAI Codexのskills、Roo Codeのcommandなどが該当します。 AIコマンドを実行すると、AIが自動的にshared-knowledgeを参照します: ユビキタス言語 → 正しい業務用語で書く 成果物の作成ルール → 決められた形式で書く 機能仕様書 → 仕様に沿った内容を生成 テンプレート → 統一されたフォーマットで出力 前述のとおり、成果物は受入基準 → テストチャーター → APIテスト用runbookと上流から下流へ連鎖する構造になっており、各成果物は相互にリンクで参照し合います。 AIコマンドで成果物の作成が容易になると、成果物の量が増えます。すると今度は人間のレビューがボトルネックになりました。そこでレビューもAIで仕組み化しました: Lintツールで機械的なチェック + AIレビュアーで文脈理解が必要な観点を確認 AIは修正せず、レビューコメントと改善提案のみ提示します。最終判断は人間が行います 3つのメリット メリット1: AI成果物の品質向上 shared-knowledgeなしの場合、AIは一般的な知識だけで成果物を作ります。ドメイン固有の用語を間違えたり、業務フローを知らなかったりします。 shared-knowledgeありの場合、正しい用語、実際の仕様、チームの方針に沿った成果物を生成してくれます。結果として人間のレビュー負荷が大幅に減りました。 メリット2: ナレッジのメンテナンス性向上 従来はメンテできる人が限られていて（属人化）、工数に見合わず放置されがちでした。 AI活用後は、新しい仕様書が追加されたら用語辞書を自動更新、コードが変わったら技術情報を自動更新できるようになりました。変更内容はPull Requestとして提出して、人間が確認してからマージします。AIが作業し、人間が承認するという安全な運用です。 メリット3: 一次資料の明確化 多くの組織で「何が最新の正しい情報なのかわからない」問題があると思います。情報がWiki、チャット、スプレッドシートなどに散在している状況です。 shared-knowledgeで「これが一次資料」と明示的に定義できるようになりました。MCPサーバー（集める）とshared-knowledge（整理する）は補完関係にあります。 保守運用をワークさせるためには ナレッジの保守運用って、多くのチームで挫折する「永遠の課題」だと思います。 自分たちのチームでは一定ワークしています。理由は構造にあると考えています: 全ての成果物のinput（参照情報）としてshared-knowledgeを使う設計にしました shared-knowledgeが古い = AIが生成する成果物の品質が下がる 品質が下がると業務に支障が出る → 更新する自然な動機が生まれます <img src="https://cdn-ak.f.st-hatena.com/images/fotolife/Q/QA_tonchan/20260213/20260213180113.png" alt="保守運用のフィードバックループを示す図。shared-knowledgeを更新→AI成果物の品
- 生成AI
- QA
- Markdown
- Git
Coding Agent が言うことを聞かないときどうする？ - ミクロなコンテキストエンジニアリング
freee で Coding Agent 切り込み隊長をしている @him0 です。2025年は Coding Agent がコーディングの取り組み方を一新する一年でした。freee は現場に Cline を導入したところから始まり、現在(2026-02) は Claude Code が全社の標準ツールとなり落ち着いています。 Claude Code 起動時に /tutorial が紹介される Coding Agent を使いこなすという文脈で、コンテキストエンジニアリングが大事という話は散々どこでもされていると思います。2025年の年末から、2026年1月は Anthropic が Skills のフォーマット標準化の宣言を発端に、Agent Skills が話題として取り上げられるようになり、SKILL.md や AGENTS.md (CLAUDE.md) コンテキストの適切なタイミングでの投入に焦点を置いた、いわばマクロのコンテキストエンジニアリングの話題が強く扱われている様に思います。 agentskills.io SKILL.md や AGENTS.md によって Coding Agent が拡張されるのは明らかな事実である一方で、どんなコンテキストを Coding Agent に与えるべきかを理解しないままに、どんどん情報を渡していってしまうと有象無象の情報に Coding Agent は混乱してしまうことも忘れてはいけない事実です。こうなってくると出力までに時間もトークンもたくさん使う状態になったり、そもそも出力の精度が安定しないという状態が発生します。 SKILL.md や AGENTS.md にどんなことを書くべきか、LLM はそれをどの様に解釈しているか、そんなことを考える一件があったので紹介したいと思います。 問題の発端 いつも通り私は社内で AI Agent おじさんをしていると、とあるプロジェクト CLAUDE.md に GitHub の Pull Request のマイルストーンに付ける指示に Claude Code が従わないという相談を受けました。内容を確認してみると、以下の指示が書かれており、確かにマイルストーンを付ける指示が定義されている様に見えます。しかし、実行してみると PR にマイルストーンを付けてくれませんでした。 # マイルストーン ユーザーからマイルストーン番号またはマイルストーン名の指定があった場合、PRにマイルストーンを設定します： - マイルストーン番号が直接指定された場合は、その番号を使用 - マイルストーン名が指定された場合は、GitHubのAPIでマイルストーン一覧を取得して該当する番号を特定 - 指定がない場合は Untracked を設定 人間には正しく読めるのに、なぜ LLM は読めなかったのでしょうか？ 原因を探る 当事者にインタビューするのが一番素直ということで、Claude Code に相談してみました（長い部分はカットしています）。 (マイルストーンの設定に失敗したセッションの続き) ❯ .github/CLAUDE.md を読んでいるのに、なんで milestone を付けなかったか教えて欲しいです ⏺ 申し訳ありません。今から修正します。 ❯ 他のリポジトリと比べてこのリポジトリではそのミスが多発します どうしてなのか解明したいです ⏺ 良い質問です。原因を分析させてください。 質問させてください： 他のリポジトリでは、マイルストーンの指示はどこに書かれていますか？ - スキル定義自体に含まれている？ - ルートの CLAUDE.md にある？ - 別の方法？ 比較できれば、何が違うのか特定できると思います。 質問すればすっと解決できるかと思いきや、なんと Claude Code 自身もどうしてそうなったのか説明できないという回答。人間らしくない LLM らしい面白い挙動です。 ほぼ同様の指示をしているが、正しく動作するリポジトリがあったので、こちらのディレクトリを渡して、比較検討を依頼してみました。 ❯ 他のリポジトリでは同じ形式で記述されていますが、ミスらないですね ~/src/project-b を参考にしてください ⏺ 違いを発見しました。 問題点： 1. project-a は「ユーザーからの指定があった場合」という条件文から始まっている 2. 「指定がない場合は Untracked を設定」が条件分岐の一つとして埋もれている 3. 他のラベル設定（「〜を付与すること」）とフォーマットが異なる project-b は「付与すること」という命令形で、他のラベル設定と同じフォーマットなので、必須アクションとして認識しやすいです。 project-a の記述を project-b と同じフォーマットに修正すれば、改善されると思います。 差分から解釈を推測し修正内容を決めることができました。「ユーザーからの指定があった場合」が、マイルストーンのセクション全体にかかり、今回は対象外であると判断してしまい最後に書かれている、指示がなかった場合を読み飛ばしていたとのこと。 LLMは"文章"ではなく"構造化された命令集合"を読んでいる これを踏まえて修正した指示が以下です。人間から見ると微々たる違いですが、確実にマイルストーンを付けてくれる様になりました。 ## マイルストーン Pull Request 作成時、マイルストーンを付与すること - ユーザーから指定がない場合は "Untracked" を付与 - ユーザーからマイルストーン名が指定された場合は、GitHub API でマイルストーン一覧を取得して該当するものを付与 人間は Markdown を文章として流れるように読みますが、LLM は見出しや箇条書き単位で「構造化された命令集合」として解釈している可能性があります。その結果、条件付きと判断したブロックを実質的にスキップし、今回の問題につながったと考えられます。 同じテキストでも、人間と LLM では前提となる読み方が異なります。LLM の挙動を理解するうえでは、この「構造の解釈」を常に意識すべきだと学びました。 もちろん、この分析は Claude Code 自身による事後的な推測であり、内部の処理を正確に反映しているとは限りません。ただ、指示のフォーマットを修正した結果、実際に挙動が安定したことから、構造の違いが影響していたという仮説には一定の妥当性があると考えています。 まとめ Coding Agent が効率よく、再現性高く動かすためには、Agent が この一文をどの様に解釈する のかというミクロの話を正しく理解し、課題があれば、それを調整する能力が必要です。そして、本来はその基礎の先に、SKILL.md や AGENTS.md を使った、マクロなコンテキストエンジニアリングが成立するはずです。 SKILL.md は共有しやすく、最初の体験として便利さを実感しやすいものです。しかしそれが、基礎を飛ばして「よく分からないけど SKILL を追加するとうまくいく」という状態を作ってしまっている側面もります。 ときには基礎に立ち戻り、手元の SKILL.md や AGENTS.md を読んでみて（読んでもらって）理解し、必要に応じてチューニングする。そんなコンテキストのリファクタリング技術も今のうちから意識して育てておくと、今後活躍できる機会が増えるのではないかと思いました。
- 生成AI
- Claude Code