こんにちは、LIFULLの渡邉です。シニアエンジニア兼エンジニアマネージャー（EM）として、普段はLIFULL HOME'Sの流通領域のエンジニアチームにてマネジメントを担当しています。日々チームの開発生産性やDeveloper Experience（DX）の向上に取り組んでいます。 今回は、長年スプレッドシートで管理されてきた「開発チェックシート」を、GitHubリポジトリ + GitHub Sub Issues + GitHub Actionsで再構築した話をお伝えします。スプレッドシートで管理している運用ドキュメントをGitHubに移行するひとつのサンプルケースとして紹介させていただきます。 課題の背景と目的 開発チェックシートとは スプレッドシート運用の限界 具体的なアプローチ 設計方針：既存のフローを壊さない 技術選定 エンジニアが実際にやること Markdownで管理する意味 AI時代の開発プロセスとの融合 MarkdownのAI親和性 各プロセスへの導入 MCP化による情報アクセスの容易化 直面した壁と乗り越え方 合意形成と移行の進め方 GitHub Sub Issuesの制約 成果と今後の展望 得られた成果 今後の展望 まとめ 課題の背景と目的 開発チェックシートとは LIFULL HOME'Sの開発では、以下のようなプロセスで開発が進行します。 実装 → 実装レビュー → テスト仕様書作成 → テスト仕様書レビュー → テスト この実装前、もしくは実装後に「開発チェックシート」を複製してチェックする工程があります。過去に発生した障害やバグを事前に検知するためのもので、組織の学びが蓄積されたナレッジそのものです。 スプレッドシート運用の限界 従来はGoogleスプレッドシートでマスタを管理し、開発案件ごとに複製 → チェック → レビューという流れで運用していました。この運用自体は機能していましたが、いくつかの課題が顕在化していました。 マスタ情報の所在があいまい : 「最新版はどれ？」とスプレッドシートを探す手間が発生する AI活用との親和性が低い : スプレッドシートのデータ構造はLLMに読ませるには不向き 開発プロセスとの統合が困難 : チェックシートの確認が開発フローから切り離された「別作業」になりがち 本質的な課題は、チェックシートの情報が開発のコンテキストから分離していることでした。 具体的なアプローチ 設計方針：既存のフローを壊さない 重要だったのは、「スプレッドシートを複製 → チェック → レビュー」という既存の運用フローを崩さないことです。運用が定着しているプロセスを無理に変えると、チームの認知負荷が上がり、結果的に誰も使わなくなります。 そこで、以下の方針で設計しました。 既存の「複製 → チェック → レビュー」のフローはそのまま維持する ツールとフォーマットだけを、よりエンジニアリングに適した形へ置き換える 技術選定 従来 新 役割 スプレッドシート（マスタ） GitHubリポジトリのMarkdownファイル（mainブランチ） チェック項目の原本管理 スプレッドシートの複製 Issue Templateからepic issueを作成 案件ごとのチェックシート作成 各シートに記入 epic issueでのチェックをトリガにsub-issueが自動生成 詳細チェック項目の展開 手動チェック＆レビュー 各sub-issue上でのチェック＆レビュー チェック・承認フロー ─ GitHub Actions 自動化・AI連携 スプレッドシートの「複製」に相当するのが、Issue Templateからのepic issue作成です。epic issueで該当する項目にチェックを入れると、GitHub Actionsがそれをトリガに詳細なチェックリストを持つsub-issueを自動生成します。開発者は生成されたsub-issue上で一つ一つチェックを進めていく流れです。 エンジニアが実際にやること 全体の流れを図にすると以下のようになります。 sequenceDiagram participant 開発者 participant GitHub participant レビュアー 開発者->>GitHub: Issue Templateからテンプレート選択 開発者->>GitHub: 施策情報入力＆該当項目にチェック GitHub-->>GitHub: sub-issue自動生成 開発者->>GitHub: 各sub-issueのチェックリストを埋める 開発者->>GitHub: 必要に応じてコメント記載 開発者->>レビュアー: レビュー依頼 レビュアー->>GitHub: epic issue・各sub-issueを確認 レビュアー->>GitHub: 親issueにレビューOKコメント レビュアー->>GitHub: 親issueをclose GitHub-->>GitHub: 全sub-issue自動close 具体的な手順は以下の通りです。 1. 新規チェックシートの作成 リポジトリの「New Issue」から対象のテンプレートを選択 施策名・実装者・対象リポジトリを入力 該当するチェック項目にチェックを入れてIssueを作成 チェックした項目に対応するsub-issueがGitHub Actionsにより自動生成されます。 2. チェックの実施 自動生成された各sub-issueのチェックリストを確認し、該当/非該当をチェック 必要に応じてコメント欄に対応内容や対応不要の理由を記載 3. レビュー & 完了 レビュアーが各sub-issueと親issue（epic）の内容を確認 問題なければ親issueにレビューOKのコメントを記載 親issueをclose → 全sub-issueが自動でcloseされる スプレッドシート時代の「複製 → チェック → レビュー」という流れがそのまま「Issue作成 → チェック → レビュー&close」に置き換わっている点がポイントです。 Markdownで管理する意味 チェック項目をMarkdown形式でリポジトリに格納したことで、以下の利点が生まれました。 Single Source of Truth : mainブランチが常に最新のマスタ。探す必要がない 変更履歴の追跡 : Git履歴で「いつ、なぜ、誰が」項目を追加・修正したかが明確 Pull Requestによる更新プロセス : チェック項目自体の追加・変更もレビューを経て反映される AI時代の開発プロセスとの融合 今回の移行で最も大きなインパクトがあったのは、AI活用との親和性の向上です。 MarkdownのAI親和性 スプレッドシートのデータをLLMに読ませる場合、セル構造の解釈やフォーマットの揺れに精度が左右されます。一方、Markdownは構造化テキストとして最もLLMが正確に理解できるフォーマットのひとつです。 この特性を活かし、開発プロセスの随所にチェックシートの知見を組み込めるようになりました。 各プロセスへの導入 [実装] → [実装レビュー] → [テスト仕様書作成] → [テスト仕様書レビュー] → [テスト] ↑ ↑ ↑ ↑ AI支援 AI支援 AI支援 AI支援 (チェック項目を (チェック項目を (チェック項目を (チェック項目を プロンプトに含む) レビュー基準に含む) 仕様に反映) 確認基準に含む) 具体的には以下のようなことが可能になりました。 実装時 : チェックリストの情報をプロンプトに含めることで、AIが「そもそも既知の障害パターンを回避する実装」を提案してくれる レビュー時 : レビュアー（人・AI問わず）がチェック項目を基準として参照できる GitHub ActionsによるAI自動レビュー : PR作成時に自動でチェック項目との整合性を検証 従来は「実装が終わってからチェックシートで確認」という事後確認型でしたが、開発プロセス全体に予防的にチェックの知見を浸透させることが可能になりました。手戻りが減り、生産性を最大化する方向に大きく前進したと感じています。 MCP化による情報アクセスの容易化 さらに、チェックシートの情報をMCP（Model Context Protocol）サーバとして提供することで、開発者がAIアシスタントを通じて自然言語でチェック項目を参照できる環境を整備しました。「この実装でセキュリティ面において気を付けることある？」と聞けば、関連するチェック項目が返ってくるイメージです。 直面した壁と乗り越え方 合意形成と移行の進め方 移行にあたっては、事前にエンジニアチャンネルで構想を共有し、関係各所との合意形成を行いました。肯定的な意見が多く集まり、スムーズに推進できました。 実際の移行では、以下を心がけました。 移行期間中は旧スプレッドシートも並行稼働 「まず1案件だけ新フローで試す」スモールスタート メンバーからのフィードバックを即座にマスタへ反映し、「自分たちが育てているチェックリスト」という当事者意識を醸成 GitHub Sub Issuesの制約 GitHub Sub Issuesはまだ比較的新しい機能であり、いくつかの制約もありました。UIの表示やフィルタリングなど、スプレッドシートの一覧性には及ばない部分もあります。ここはGitHub Actionsによる自動生成テンプレートで補い、手作業を最小限にとどめる工夫をしています。 成果と今後の展望 得られた成果 マスタ情報の一元化 : 「最新版どこ？」がなくなった AI活用による予防的チェック : チェックシート確認前に多くの問題が解消されるようになった 開発プロセス全体への浸透 : 特定のタイミングだけでなく、各工程でチェック知見が活用されている 自動レビューとの統合 : GitHub ActionsによるAIレビューにチェック項目を組込み属人化を排除 チェックシートの形を変えただけで、開発プロセスの質が全体的に底上げされるといった手応えを感じています。 今後の展望 チェック項目が「過去の障害やバグの記録」である以上、継続的に更新されていくものです。GitHubリポジトリで管理することで、障害対応のポストモーテムからそのままPRでチェック項目に追加する、というフローも自然に回り始めています。 技術的にはシンプルな構成ですが、「スプレッドシートで十分動いているもの」をあえてエンジニアリングの文脈に持ち込みました。AI時代の開発プロセスに自然に統合できる形に進化させられた事例として共有させていただきます。 組織の中で「なんとなくスプレッドシートで管理しているもの」があれば、Markdownでリポジトリ管理することを検討してみてください。AI活用という文脈で、想像以上の恩恵があるかもしれません。 まとめ 「スプレッドシートで運用しているものをGitHubに移す」という、一見するとシンプルな取り組みですが、その先に見えた景色は想像以上のものでした。 本質的な課題は、チェックシートの情報が開発のコンテキストから分離していたことでした。それをエンジニアリングの文脈に統合したことで、以下のような変化が生まれています。 AIが開発プロセス全体でチェック知見を活用できる状態 手戻りの削減による、技術者が創造的な仕事に集中できる環境 PRベースの更新フローによる、チーム全員がナレッジを育てている当事者意識 これらは、単なるツール移行では得られない、本質的な価値だと考えています。 「スプレッドシートで十分動いている」と思っているものこそ、変化の余地があるかもしれません。既存の運用フローを壊さずに、ツールとフォーマットだけを変えるアプローチであれば、チームへの負荷を最小限に抑えながら大きな恩恵を得られる可能性があります。 今後もチェック項目を継続的に育てながら、開発プロセスのさらなる改善につなげていければと思います。 最後に、LIFULLではともに挑戦し成長していける仲間を募集しています。よろしければこちらのページもご覧ください。 https://hrmos.co/pages/LIFULL/jobs/010 https://hrmos.co/pages/LIFULL/jobs/010-9998

関連ニュース 出展の目的 会場の印象 アプトポッドブースの展示 ベンチ計測データ統合基盤 データ駆動型開発基盤 オペレーション・データ基盤 intdashの特徴 来場者の反応 会場で気になった技術トレンド SDV デジタルツイン まとめ こんにちは、アプトポッドの門脇です。 2026年5月27日（水）〜5月29日（金）にパシフィコ横浜 ノースで開催された「人とくるまのテクノロジー展2026 YOKOHAMA」に出展しました。 今回、アプトポッドは 「開発現場のデータを統合、SDV時代の自動車開発をまるごとデータで繋ぐ！」 をテーマに、産業向けIoTミドルウェア intdash を中心とした、自動車開発・製造現場におけるデータ活用の取り組みをご紹介しました。 アプトポッドブースの様子 関連ニュース 人とくるまのテクノロジー展2026 YOKOHAMA出展のお知らせ 出展の目的 自動車業界では、SDV（Software Defined Vehicle）化の進展により、車両開発・評価・製造の各プロセスで扱うデータがますます多様化・大容量化しています。 実車、ベンチ、シミュレータ、製造設備、搬送機など、さまざまな場所で発生するデータをどのように収集し、統合し、活用していくかは、今後の開発スピードや品質向上において重要なテーマです。 今回の展示では、こうした課題に対して、intdashを活用したデータ基盤のあり方を、以下の3つのソリューション軸でご紹介しました。 ベンチ計測データ統合基盤 データ駆動型開発基盤 オペレーション・データ基盤 会場の印象 会場では、SDV、AI、データ活用、シミュレーション、製造DXなど、自動車開発の変化を感じる展示が多く見られました。 特に印象的だったのは、個別の車両性能や部品技術だけでなく、開発プロセス全体をどう変えていくか、取得したデータをどう活用していくか、という視点の展示が増えていた点です。 アプトポッドブースの展示 アプトポッドブースでは、intdashを中心に、自動車開発・製造現場におけるデータ統合・活用のユースケースをご紹介しました。 今回のブースでは、ベンチ計測データ統合基盤、データ駆動型開発基盤、オペレーション・データ基盤の3つの展示テーマを用意しました。 中でも、実際の計測機器を使ってデータ収集・可視化の流れを確認できる ベンチ計測データ統合基盤 には、多くの方に足を止めていただきました。 ベンチ計測データ統合基盤 ベンチ試験や評価環境では、複数メーカーの計測機器や解析ツールが使われることが多く、データ形式や管理方法が分散してサイロ化しやすいという課題があります。 今回の展示では、ASAM規格に準拠した計測データの同期収集と統合管理を軸に、複数の計測機器から得られるデータをメーカーを問わず統合し、既存の管理システムや解析ワークフローへ接続する流れをご紹介しました。 計測データをリアルタイムに可視化するデモ 単にデータを取得するだけでなく、取得後の管理、検索、再利用、解析自動化までを見据えた基盤として、intdashの活用可能性を感じていただける展示になったと思います。 複数の計測機器・センサーを接続したデモ構成 データ駆動型開発基盤 SDV時代の車両開発では、実車試験、ベンチ試験、シミュレーション、AI、モデルベース開発などを組み合わせながら、開発サイクルを回していくことが重要になります。 展示では、ASAM標準、生成AI、シミュレーターを組み合わせたデータ駆動型の車両開発プロセスについてご紹介しました。 計測から検証、モデリングまでを一気通貫で支援するデータ基盤として、intdashがどのように活用できるかをお伝えしました。 オペレーション・データ基盤 製造・生産・現場オペレーションの領域では、フレキシブル生産、無人化、デジタルツイン、Physical AI、ROS、フィールドバスなど、さまざまな技術が実運用に近づいています。 一方で、現場には既存設備、搬送機、センサー、カメラ、PLCなどが混在しており、データが分断されやすいという課題があります。 Physical AI、ROS、フィールドバスなどを紹介したオペレーション・データ基盤の展示 今回の展示では、intdashを活用して搬送機やOT設備、各種センサー・フィールドバスのデータを柔軟につなぎ、オペレーション全体を可視化・最適化していくアプローチをご紹介しました。 また、自動運転むけ遠隔監視のデモでは、車両や周辺状況を複数のカメラ映像・データと合わせて確認できる構成をご紹介しました。 自動運転むけ遠隔監視デモの画面 intdashの特徴 intdashは、さまざまなセンサー、車載機器、エッジデバイス、アプリケーションをつなぎ、リアルタイムなデータ収集・可視化・保存・活用を支援する産業向けIoTミドルウェアです。 今回の展示でも、複数デバイス・複数拠点のデータ統合、時刻同期されたデータの収集・管理、遠隔監視、API連携などをご紹介しました。 展示していたエッジデバイスや周辺機器 自動車開発や製造現場では、CAN、センサー、カメラ、設備、搬送機、シミュレータなど、多様なデータが発生します。 intdashは、それらのデータを横断的につなぎ、現場の課題解決や開発プロセスの改善につなげるための基盤として活用できます。 来場者の反応 ブースでは、車両開発、実験・評価、品質管理、研究開発など、さまざまな立場の方にお立ち寄りいただきました。 特に反応が大きかったのは、ベンチ計測データ統合基盤の展示です。実際の計測機器を使ったデモ構成だったこともあり、計測データの収集・同期・可視化・再利用といったテーマについて、具体的な利用シーンをイメージしていただきやすかったように感じます。 会話の中では、「データが分散している」「形式が揃わない」「取得したデータを十分に活用しきれていない」といった課題が多く残っていることも感じました。 会場で気になった技術トレンド 今回の展示会で個人的に気になったのは、 SDV と デジタルツイン です。 SDV 会場では、SDV時代の開発効率を高めるためのソリューションが多く展示されていました。 データ管理、シミュレーション、評価、解析、ソフトウェア開発環境などを一体で扱う開発プラットフォームとして提案している展示もあり、開発プロセス全体を支える基盤として構成されている点が興味深かったです。 車両機能がソフトウェア中心になるほど、実車、ベンチ、シミュレータ、仮想化環境、AIなどのデータをどのようにつなぎ、開発サイクルを効率化するかが重要になると感じました。 デジタルツイン デジタルツインの領域では、車両挙動や走行環境を再現するシミュレータに加えて、人の感覚や印象を評価するための展示も見られました。 特に印象的だったのは、感性工学に特化したドライビングシミュレータです。走行性能や制御だけでなく、乗り心地、操作感、安心感、違和感といった人の感覚に近い領域を評価しようとしている点が興味深いと感じました。 デジタルツインを活用するうえでも、現実世界のデータを正しく収集し、シミュレーションや解析環境に接続することが重要だと感じました。 まとめ 今回の人とくるまのテクノロジー展2026 YOKOHAMAでは、SDV時代の自動車開発において、データを「取る」「見る」だけでなく、「つなぐ」「活用する」ことの重要性を改めて感じました。 アプトポッドブースでご紹介した3つのソリューション軸は、以下の動画でもご覧いただけます。 www.youtube.com www.youtube.com www.youtube.com 自動車開発・製造の現場では、今後も扱うデータの種類や量が増え続けていきます。アプトポッドは、intdashを通じて、自動車開発、ベンチ計測、製造現場、搬送機・搬送ロボット、デジタルツインなど、さまざまな領域のデータ活用を支援していきます。 ブースにお立ち寄りいただいた皆さま、誠にありがとうございました。

こんにちは、Merpay の Payment Core チームと Payment Solution チームで Engineering Manager (EM) をやっている komatsu です。普段は決済基盤や決済体験の開発をするチームを見ていたり、最近は PCP Foundation というチームを発足して Individual Contributor (IC) として基盤の整備や AI 周りのツールの導入も行っています。 この記事は Merpay & Mercoin Tech Openness Month 2026 の 4 日目の記事です。 この記事では、私たちの Payment Platform が「決済」と「会計」のあいだに置いている共通言語 MoneyFlow と、それを支えるために開発したツール群 mfgen (MoneyFlow Generator; /ˌemefˈdʒen/) について紹介します。一見すると別物に見える「システムとしての決済基盤」と「上場企業として厳密さが求められる会計」ですが、実際には深く結びついています。私たちは、その複雑な関係を整理し、経理・PdM・エンジニアといった異なる立場の人々が共通の理解を持てるよう、MoneyFlow という共通言語を整備してきました。この一年ほどで MoneyFlow は徐々に組織へ浸透し、現在では同じフォーマットで記述し、同じフォーマットでレビューする開発プロセスが少しずつ定着しつつあります。本記事では、その取り組みの背景と、それを支える mfgen の仕組みについて深掘りしていきます。 決済プラットフォームと会計のつながり メルカリグループの Payment Platform は、メルカリのマーケットプレイス (Consumer to Consumer; CtoC) だけでなく、メルカリShops やメルペイ、メルコイン、メルカリモバイル、メルカリAds、グローバルアプリなど、「お金が動くすべてのプロダクト」の土台となり、決済にまつわる汎用的な機能を提供しています。決済そのものについての記事は多く上がっているので、興味があれば メルカリのグローバル展開を支えるPayment Platformの進化 や Payment に関するその他の記事 もあわせてご一読ください。 また、Payment Platform チームが掲げる理念の一つに「会計も含めた決済ソリューション」というものがあります。決済の一回一回は、お客さまや Payment Platform の利用者 (つまりプロダクトのマイクロサービス) から見れば「支払いが完了した」という体験です。しかし会社や経理から見れば、それは会計上の仕訳として正しく記録しなければならない事象でもあります。そこで Payment Platform は、外向きの決済 API を提供するだけでなく、その裏側で「お金がどう動き、どの勘定にどう記録されるか」までを引き受け、記帳や会計レポートの発行を通した社内向けの統合的な決済ソリューションとして存在しています。これによってプロダクトはビジネスロジックの開発に集中し、会計にまつわる大半の連携を Payment Platform に委ねることができます [^1]。 たとえば、メルカリのシンプルな購入ひとつを取っても、段階ごとにお金が動き、それぞれに対応する会計上の記録が発生します。お客さまが支払う場面では、残高を使う場合は購入者の資金移動口座からエスクロー決済の預かり金へと振り替え、メルペイのクレジットを使う場合はあと払い債権を計上し、他社クレジットカードを使う場合は PSP (Payment Service Provider) に対する未収入金として処理します。そして取引が完了して売上が立つ段階では、預かり金を取り崩し、出品者の資金移動口座と手数料収入へと振り分けます。 これはまだ単純な例ですが、実際には、コンビニ決済のような非同期な決済手段、キャンセルや返金、資金移動口座の開設有無、クーポン等による値引き、為替が絡む決済——こうした条件の組み合わせやタイミングの違いが絡み合い、仕訳はもっと複雑になります。特に、ひとつの API 呼び出しが複数の勘定に影響することもあれば、逆に、会計上はひとつの動きが複数の API にまたがることもある、という点も複雑性を増す要因となっています。この「ズレ」があるために、エンジニアと経理が直接話しても認識が噛み合わず、議論が長引くということが頻繁に起きていました。エンジニアが「決済 API のフロー」として見ているものを、経理は「仕訳」として見ており、同じ事象を、まったく異なる言語で眺めているからです。 MoneyFlow という共通言語 このすれ違いの根本にあるのは、Payment Platform のエンジニアと経理のあいだに横たわるドメイン的な距離です。両者は使う言葉からして異なり、エンジニアが API やエンドポイントで語るのに対し、経理は勘定科目や仕訳で語ります。前提とする知識も、システムの内部構造と会計基準というように噛み合いません。そのうえ、API と勘定科目が必ずしも 1:1 で対応しないため、片方の言葉をそのまま翻訳しても意味が通じないことがままあります。 この距離を埋めるために、Payment Platform で直近約一年にわたって運用しているのが MoneyFlow です。これはシステム上のお金の動きを表現するためのフロー図であり、同時に、エンジニア・経理・Product Manager (PdM) の理解を揃えるための共通言語でもあります。MoneyFlow は主に三つの要素で構成します。一つ目の Actor は取引の主体（誰が価値を出し、誰が受け取るのか）で、User (購入者や出品者)や Partner (加盟店さま等取引の相手方。社外事業者に限らず、会社として Mercari / Merpay / Mercoin もシステム上は Partner) が該当します。二つ目の Account は各 Actor が持つ勘定 (ledger) で、 USER_FUNDS や PARTNER_SALES 、 USER_DEBT 、 PARTNER_CLEARING_SALES などがあります。三つ目の Flow はおおむね 1 回の API 呼び出しに相当するお金の移動を表し、Source (from) と Target (to) を持つことで、その決済でお金がどこからどこへ動くのかを示します。さらに各 Flow は、勘定科目に対応する accounting code を持ちます。 こうした図として表現することで、エンジニアは価値交換を行う API を記述でき、経理は Flow を中心とした会計観点でのお金の動きを把握できます。図の Actors section は Actor の一覧とそれぞれが持つ Account (ledger) を表現し、MoneyFlow section は商流ごと・API ごとのお金の動きを表現します。 この一年ほどをかけて、MoneyFlow は徐々に組織に浸透してきました。現在では、経理・PdM・エンジニアが同じフォーマットで書き、同じフォーマットでレビューする、といった開発の工程が少しずつスタンダードになりつつあります。著者自身もプロジェクトや開発の最初のフェーズでこれを行うことで、ステークホルダーと認識を合わせやすくなったと実感しており、Design Doc に並ぶ重要なドキュメントだと感じています。さらに、エンジニアリングと会計の両面を表現する概念を持ったことで、エンジニアは会計のドメインを、経理はエンジニアのドメインを理解しやすくなりました。エンジニアが勘定科目について経理に相談したり、経理が API 名を使って商流を表現したりと、お互いの歩み寄りがかなり加速したと感じています。 mfgen CLI — DSL による MoneyFlow の標準化 組織への浸透が進む一方で、MoneyFlow は最初からフォーマットが決まっていたわけではありません。初期は Draw.io (Diagrams.net) で手描きしていました。これはこれで描けるのですが、いくつかの課題がありました。まず、書き方が人によって異なり、解像度や粒度が書き手に依存するため、図にばらつきが出ます。次に、そもそもどう書けばよいか分からない人がほとんどで、書ける人が限られていました。書ける人がいないプロジェクトでは、会計観点の考慮漏れを見落とすこともありました。さらに、Draw.io は XML で表現できるものの human-friendly な宣言的記法が存在せず、同じフォーマットで安定して描画することや AI agent との親和性に欠けていました。 そこでまず取り組んだのが、MoneyFlow を YAML の DSL として定義することでした。そして、その YAML から Draw.io (および PNG 画像) を生成する CLI ツール mfgen を開発しました。YAML は次のようなイメージです。 name: Example Payment Flow actors: - id: user name: User type: USER - id: partner name: Partner type: PARTNER accounts: - id: user_funds owner: user account_type: USER_FUNDS currency: JPY - id: partner_sales owner: partner account_type: PARTNER_SALES currency: JPY flows: - id: MF1 name: Payment api: Payment.CreateCharge currency: JPY accounting_code: xyz from: - id: user_funds amount: 1000 to: - id: partner_sales amount: 1000 描画のクライアントとしては依然として Draw.io を使っているため、CLI の実装の中身はかなり地味なものです。YAML をパースし、描画に必要な座標を計算し、Draw.io の XML を組み立てる——レイアウトのための座標計算や XML 生成を、ひとつずつ実装した形になります。この段階では、validation を強めに設けて一貫性を高めることと、AI agent による生成を簡単にすることを目的としました。具体的には、次のチェックを行います。 必須フィールドを検証する ID の重複を検出する 参照整合性を確認する (actors の owner、flow の from / to などが実在するか) セマンティクスを検証する ( from の合計と to の合計が一致するか、 PARTNER_DEBT / USER_DEBT に debt_type があるか、など) さらに、GitHub Actions で YAML を自動変換して Draw.io 形式および画像でアップロードする CI を組みました。これによってレビューや共有、過去の MoneyFlow の管理が簡単になり、MoneyFlow が蓄積されることで次の MoneyFlow 作成時の AI による精度も向上していきました。 mfgen Web — リアルタイム共同編集の実現 DSL 化によって標準化は大きく進みましたが、mfgen CLI にも残された課題がありました。変換が YAML → Draw.io の片方向であるため、図を見ながら直接編集して保存する、という使い方ができません。ミーティング中に Draw.io を直接編集したりコメントを付けたりすると、それを YAML に取り込むコストが発生します。そして、Draw.io の表現力そのものが上限になる場面もありました。 そこで開発したのが mfgen Web です。これは社内にホストしている Web ツールで、「Draw.io のような同時編集」と「YAML による宣言的な定義」の両方を実現します。具体的には、三つの編集方法を備えています。Canvas 上で直接描く方法では、Draw.io のようにノードを配置してつなぎます。MoneyFlow に特化した編集機能では、Actor / Account / Flow といったドメイン概念をそのまま編集できます。そして YAML を直接記述する方法では、エディタで宣言的に書けます。 これらはすべて双方向に同期します。YAML を更新すれば図に即座に反映され、図をドラッグすれば YAML にも反映されます。さらに、複数人が同じ MoneyFlow をリアルタイムで共同編集でき、メンバーが作成した MoneyFlow はカタログとして蓄積されていくため、チームのドキュメンテーションとしても活用できる形になりました。 この手の内製ツールは Vibe Coding でおおよそ作れてしまう時代ですが、技術的なポイントを簡単に紹介します。 サーバは役割の異なる 2 つに分かれています。 api サーバ (Hono) が SPA の配信と REST API を担い、 collab サーバ (Hocuspocus) が WebSocket での同時編集を担います。設計上のポイントは次のとおりです。 Single Source of Truth として Y.Doc (Conflict-free Replicated Data Type; CRDT) を採用する。サーバが権威ある Y.Doc を保持して各クライアントと同期し、YAML はサーバ側で Y.Doc から投影して生成する派生物とすることで、クライアントが直接書き込むことはありません。これにより、YAML を入力とする CLI 版 mfgen とのデータ互換性を保っています。 「追記ログ + スナップショット」方式で永続化する。編集は append-only な update ログに追記し、2-10 秒程度の debounce で Y.Doc 全体のスナップショットと生成した YAML を Postgres に書き込み、古い update を圧縮 (compaction) します。 Canvas 上の座標を YAML から除外する。位置情報を YAML から外すことで、既存 CLI と等価なデータに保っています。 Origin タグ (5 種) で編集の出どころを区別する。「UI 操作」「YAML 編集」「ドラッグ操作」「他クライアントからの更新」「初期同期」をタグで見分け、双方向同期で起こりがちな無限ループを防ぎつつ、Undo の対象も制御しています。 Redis (Memorystore) の pub/sub で collab サーバ間のメッセージを fan-out する ( @hocuspocus/extension-redis )。複数レプリカ運用に備えた仕組みで、単一レプリカであれば Redis なしでも動作します。 技術スタックは TypeScript / Bun に統一しています。フロントエンドは React + Vite + @xyflow/react + CodeMirror + Yjs、サーバは Hono + Hocuspocus + Drizzle ORM、データストアは Postgres と Memorystore Redis という構成です。これらを専用の Google Cloud プロジェクト上で、api / collab それぞれ独立したサービスとして運用しています。 mfgen Web はまだ開発したばかりで活用事例はありませんが、Web 版になったことで、MoneyFlow はより実践的なツールになると感じています。今後さらに開発を続け、エディタ内に Claude Code SDK などで AI を搭載したり、経理によるレビュー後にシステムへ登録するところまで E2E で自動化できるようになれば、会計がプロダクト開発のブロッカーにならず、基盤として素早いサポートができるようになると信じています。 まとめ この記事では、Payment Platform が「会計も含めた決済ソリューション」であること、そしてエンジニアと経理のあいだを繋ぐ共通言語 MoneyFlow と、それを実践的に運用するための mfgen について紹介しました。MoneyFlow を共通の出発点に置いたことで、これまで噛み合わなかったエンジニアと経理の議論は、同じ図を指しながら進められるようになりました。考慮漏れが減り、お互いがお互いのドメインに歩み寄る——そうした定性的な変化が、この直近多く見られるようになったと感じています。 著者自身、会計はまだ勉強中の身ですが、システムと結びつけて考えるとかなり理解しやすくなる、というのが正直な実感です。そして、こうした内製ツールは AI の力を借りて本当に手軽に作れる時代になりました。私が所属する PCP Foundation チームでは、今後もこうした組織横断のツール開発とメンテナンスを通じて、チームの垣根を越えた生産性の向上につなげていきたいと思っています。 [^1]: 決済 API を利用するタイミングと会計連携のタイミングが異なる場合はプロダクトが直接行っているが、この深掘りと進化はまた別の機会に。 次の記事は hokao さんの「会計システムにおける訂正機能の設計と実装」です。引き続きお楽しみください。