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

- 媒体: 知能圏（CHINOUKEN）
- 公開日: 2026-08-29
- カテゴリー: エージェント・ソフトウェア
- タグ: Archify、エージェントスキル、業務フロー、作図
- 想定読了時間: 約11分
- 調査基準日: 2026年8月31日
- 出典: 8件（末尾の「参照リンク」に番号順で記載）
- ページ: https://www.chinouken.com/articles/archify-interactive-architecture
- このMarkdown: https://www.chinouken.com/articles/archify-interactive-architecture.md
- 利用条件: 引用する場合は出典として「知能圏（chinouken.com）」と該当ページのURLを明記してください。本文の再配布は行わず、要約や引用の範囲で使ってください。

返金窓口の設計では、担当、個人情報、待機理由を別の図へ分けると、確認する論点を絞れます。編集部の四つの模式図に加え、Archifyで高額返金の一経路を実際に生成しました。元データが配置検査で止まった理由と、ブラウザで承認の前後をたどれた範囲を紹介します。

![架空の返金業務を構成図、ワークフロー、データフロー、ライフサイクルの四つに描き分けた概念図](https://www.chinouken.com/images/articles/archify-interactive-architecture/hero.png)

*同じ返金業務でも、図ごとに接続、担当、情報、状態という別の問いを確認します。*

## 一枚の構成図では三つの抜けが残った

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

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

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

## 高額返金の一経路を実際に生成した

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

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

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

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

![Archifyで実際に生成した図の返金承認を選択し、金額判断と処理記録との接続を開いた画面](https://www.chinouken.com/images/articles/archify-interactive-architecture/figure-official-approval-focus.png)

*公式プログラムで生成した小さな試作の実画面です。返金承認を選ぶと、前後の接続が表示されました。*

## 架空の返金業務で図の使い分けを確かめる

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

| 場面 | 灯台商店のルール |
|---|---|
| 受付 | 購入者が注文番号と相談内容を送る |
| 個人情報 | 氏名と住所はAIへ渡す前に伏せる |
| 自動調査 | AI窓口が注文状況と返品規約を調べる |
| 例外 | 規約外の案件は担当者へ引き継ぐ |
| 高額返金 | 1万円を超える返金は責任者が承認する |
| 記録 | AIと人の判断を監査記録へ残す |

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

## 構成図で個人情報を扱う境界を見る

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


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

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

![架空の通販会社のAI問い合わせ窓口を、購入者、受付、個人情報保護、振り分け、回答、人の承認、データベースに分けた構成図](https://www.chinouken.com/images/articles/archify-interactive-architecture/figure-lighthouse-architecture.png)

*返金対応の主経路、個人情報を扱う範囲、人が判断する場所を一枚で確認します。*

## ワークフローで返金の担当と承認を見る

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


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

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

![返金依頼を購入者、AI窓口、担当者、責任者の担当別に分け、情報不足、対象外、高額返金の分岐を示した業務フロー図](https://www.chinouken.com/images/articles/archify-interactive-architecture/figure-refund-workflow.png)

*返金業務を担当別に配置し、自動化の終点と承認者を示します。*

## データフローで個人情報の通り道を見る

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


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

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

![問い合わせ本文と添付写真が個人情報の伏せ字処理とファイル検査を通り、注文データベース、商品と規約のデータベース、購入者への回答、担当者の確認へ流れるデータフロー図](https://www.chinouken.com/images/articles/archify-interactive-architecture/figure-customer-dataflow.png)

*線へデータ名を付けると、生の個人情報がどこまで届き、何を購入者へ返すかを確認できます。*

## ライフサイクルで待機と再調査を分ける

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


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

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

![問い合わせ案件が受付済みから解決済みへ進み、購入者の回答待ち、承認待ち、再調査、取下げ、期限切れへ分岐する状態遷移図](https://www.chinouken.com/images/articles/archify-interactive-architecture/figure-ticket-lifecycle.png)

*顧客待ち、社内承認待ち、再調査、終了を別の状態にすると、案件が止まる理由を区別できます。*

## 四つの図が答える問い

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

| 図 | 答える問い | 今回見つけた抜け | この図だけでは分からないこと |
|---|---|---|---|
| 構成図 | 何がつながり、境界はどこか | 個人情報を扱う範囲 | 作業の順番と承認条件 |
| ワークフロー | 誰がどの順で担当するか | 高額返金の承認者 | 生の情報が届く範囲 |
| データフロー | 何の情報がどこを通るか | 個人情報を伏せる位置 | 案件の現在の状態 |
| ライフサイクル | 何をきっかけに状態が変わるか | 顧客待ちと社内待ちの違い | 部品同士の接続 |

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

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

| 読者へ答えたいこと | 選ぶ図 |
|---|---|
| 部品、接続、保護する範囲 | 構成図 |
| 担当、承認、例外の流れ | ワークフロー |
| 呼び出しと応答の順番 | シーケンス図 |
| 情報の発生源、加工、保存先 | データフロー |
| 待機、再試行、完了条件 | ライフサイクル |

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

```bash
npx skills add tt-a1i/archify -g
```

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

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

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

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

## 参照リンク

1. [tt-a1i: Archify README](https://github.com/tt-a1i/archify/blob/main/README.md)
2. [tt-a1i: Archify Skill](https://github.com/tt-a1i/archify/blob/main/archify/SKILL.md)
3. [tt-a1i: Archify JSON IR Schemas](https://github.com/tt-a1i/archify/blob/main/archify/schemas/README.md)
4. [tt-a1i: Authoring Cookbook](https://github.com/tt-a1i/archify/blob/main/docs/authoring-cookbook.md)
5. [tt-a1i: MIT License](https://github.com/tt-a1i/archify/blob/main/LICENSE)
6. [tt-a1i: Release v2.16.0](https://github.com/tt-a1i/archify/releases/tag/v2.16.0)
7. [Microsoft Learn: ビジネス プロセス フローの概要](https://learn.microsoft.com/ja-jp/power-automate/business-process-flows-overview)
8. [IPA: 形式手法適用調査 調査報告書](https://www.ipa.go.jp/archive/digital/iot-en-ci/keishikisyuho/hjuojm000000m6wx-att/000026829.pdf)

2026年8月31日時点の公式資料を確認しています。仕様は更新される可能性があります。

---

© 知能圏 https://www.chinouken.com/articles/archify-interactive-architecture