返金業務の抜けを見つける四つの図とArchifyの使いどころ

問い合わせ窓口を設計するとき、購入者、AI窓口、注文データベース、担当者を一枚につなげれば、全体の構成は見えます。ところが、返金額を誰が承認するのか、氏名や住所をどこで伏せるのか、案件がなぜ止まっているのかは、部品同士の接続だけでは判断できません。

Archifyは、文章やリポジトリの内容をAIエージェントへ渡し、構成図や業務の流れを表す図へ整理するエージェントスキルです。図ごとに入力データの形式が分かれているため、「何がつながるか」「誰が担当するか」「どの情報が動くか」「いま何の状態か」を別々に検討できます。

今回は同じ返金業務を、構成図、ワークフロー、データフロー、ライフサイクルの4種類の模式図に描き分けました。4枚は編集部の作図で、Archify本体の生成物とは区別しています。その結果、高額返金の承認者、個人情報を伏せる位置、顧客待ちと社内承認待ちの違いが、一枚の構成図より明確になりました。

2026年9月5日、以前の作図用データをArchify v2.16.0へ渡すと、4種類すべてが配置検査で止まりました。ワークフローでは隣り合う箱が12px重なり、構成図では承認へ向かう線が別の箱を横切っていました。後半に載せる4枚は、編集部が別の描画処理で作った模式図です。その入力をArchifyへ渡せば同じ図が完成する、という見本には使えません。

そこで「一万円超の返金を承認して回答する」一経路に絞り、受付、注文照合、金額判断、返金承認、処理記録、回答受取の6個の箱で作り直しました。版2の入力形式で通常の品質検査を通し、公式プログラムから操作できるHTMLを生成できました。元の4枚すべてを修復したわけではなく、情報不足や対象外の分岐を省いた小さな試作です。

ブラウザで「返金承認」を押すと、責任者の説明と、前にある「金額判断」、後ろにある「処理記録」が開きました。線を眺めるだけでなく、一つの承認地点から前後を確かめられます。動いたのは図の表示と探索であり、返金の実行や業務規則の正しさを検証したものではありません。

最初に試すなら、担当者へ説明したい一経路だけを生成し、必要な日本語が箱に収まるか、線が別の箱を横切らないかを確かめます。そこから例外を一つずつ加える方が、エラーが出たときに直す場所を絞れます。

図の種類による違いを比べるには、扱う業務の条件をそろえる必要があります。そこで、生活雑貨を販売する架空の通販会社「灯台商店」を置き、一件の返金依頼が届いてから回答するまでを共通の題材にしました。実在する会社の業務や顧客情報を使わず、4枚すべてを同じ事実から作るための設定です。

Archifyの作図手引きは、最初の図を8〜12個程度の主要要素と一つの主経路に絞るよう勧めています。今回も一枚へすべてを詰め込まず、同じ要件を4つの問いへ分けました。

構成図が答えるのは、窓口を構成する部品と、その接続です。購入者から回答までを主経路に置き、注文データベース、商品と規約のデータベース、担当者画面、返金承認、監査記録を枝として配置しました。

この図で確認できるのは、氏名や住所を扱う範囲です。購入者が送った内容は、個人情報を伏せる処理を通ってから振り分けへ進みます。例外案件だけを担当者へ渡し、1万円を超える返金は責任者の承認へ回す境界も見えます。

一方、構成図の線は接続を示すだけです。返金条件から外れた場合に誰が説明するのか、情報不足ならどこへ戻すのかまでは読み取れません。担当と判断の順番は、次のワークフローへ分けます。

ワークフローでは、購入者、AI窓口、担当者、責任者を担当別の帯に分けました。どの条件で仕事が次の担当へ移るのかを、左から右へ追えます。

AI窓口が担うのは、依頼の受付、注文照合、返金条件の確認までです。情報が足りなければ購入者へ追加情報を求め、規約外の案件は担当者へ渡します。担当者が返金額と例外理由を確認し、1万円を超える場合だけ責任者へ承認を求める流れです。

構成図では一本だった「AIから人への引き継ぎ」が、ここでは情報不足、規約外、高額返金という三つの分岐に変わりました。業務を自動化するときは、人へ渡すという方針だけでなく、渡す条件と次の担当を決める必要があります。

データフローは、情報の発生源、加工、保存先、利用先を追う図です。問い合わせ本文と添付写真を出発点にし、個人情報を伏せる処理、ファイル検査、注文照会、回答、監査記録までを並べました。

構成図では一つの部品だった個人情報の保護が、データフローでは通過条件になります。生の本文を受け取るのは伏せ字処理までで、その先へ渡すのは氏名や住所を除いた本文だけです。添付写真も、形式と危険性を検査してから画像解析へ進めます。

購入者へ返す情報と、社内だけに残す情報も分かれます。配送状況や返品条件を回答に使う一方、監査記録と例外案件の確認内容は社内側へ残しました。線に情報名を付ければ、どのデータが境界を越えるのかを確認しやすくなります。

ライフサイクルは、問い合わせ案件が現在どの状態にあり、何をきっかけに次へ進むかを示します。受付済み、自動調査中、担当者確認中、回答準備済み、解決済みを主経路にし、購入者の回答待ち、承認待ち、再調査、取下げ、期限切れを分けました。

購入者から写真が届くのを待つ案件と、責任者の承認を待つ案件では、次に動く人も期限も違います。どちらも同じ「保留」として数えると、件数を見ても滞留の原因が分かりません。待機状態を分ければ、購入者への催促と社内承認の催促を別々に扱えます。

追加申告が届いた案件は、終了扱いにせず再調査から自動調査へ戻します。取下げと14日間応答がない場合だけを終了状態にしました。失敗や待機を描くときは、戻り先と終了条件まで決める必要があります。

4枚の違いは、同じ業務から何を残し、何を省くかにあります。図を増やすこと自体が目的ではなく、答えたい問いに合わせて箱と線の意味を変えます。

Archifyには、処理を呼び出す順番を示すシーケンス図もあります。今回は通信の順番や応答時間ではなく、担当、個人情報、滞留理由を確かめたかったため使いませんでした。利用できる種類をすべて作るのではなく、中心の問いに必要な図だけを選びます。

Archifyは、tt-a1iがGitHubでMITライセンスのもと公開しているエージェントスキルです。AIエージェントが文章やリポジトリを読み、図の種類に合ったJSON形式の入力を作ります。同梱の検証・描画プログラムが形式と配置を確認し、単体で開けるHTML、SVG、PNGなどへ書き出す仕組みです。

現在の公式資料では、構成図、ワークフロー、シーケンス図、データフロー、ライフサイクルの5種類に対応しています。ワークフローは版2の入力形式、それ以外は版1の入力形式を使い、図ごとに必要な要素が決まっています。AIが自由な一枚絵を生成する方式と違い、元のJSONを残して特定の分岐や文言を直せる点が実務向きです。

2026年9月5日の再確認では、保存していた4入力がすべて公式の配置検査に失敗しました。本文の4枚は、ローカルの別スクリプトで描いた静止SVGをPNGへ変換したものです。公式プログラムで生成できたのは、冒頭で示した6個の箱による一経路だけです。

Archifyを使い始める前に、誰へ何を説明したいのかを一文にします。図の種類は、描きたい見た目ではなく、読者へ答えたい問いから選べます。

公式の導入コマンドは次の一行です。

npx skills add tt-a1i/archify -g

最初から自社のリポジトリや顧客データを渡す必要はありません。まずは公開しても問題のない架空の業務だけを使い、図の選び方と出力を確認できます。これは入力する社内情報を減らす方法であり、Archifyや導入コマンド自体の安全性を保証するものではありません。第三者のスキルを導入する判断では、対象の版、SKILL.md、実行スクリプト、依存関係を別に確認します。

今回の返金業務をワークフローにするなら、依頼文は次の程度まで具体化します。

Archifyを使って、架空の通販会社の返金業務をワークフロー図にしてください。
購入者、AI窓口、担当者、責任者の担当を分けます。
受付、注文照合、情報不足、規約外、高額返金の承認、回答を含めます。
主要な工程は12個以内にし、入力したJSONも残してください。

「図を作って」だけでは、全体構成、担当、情報、状態のどれを優先するか決まりません。一枚目で答えたい問いを先に決めると、二枚目が必要かどうかも判断できます。