AIコーディング時代だからこそ、BEAM分析と状態遷移図が大活躍する
CueCodes

AIコーディング時代だからこそ、BEAM分析と状態遷移図が大活躍する

はい、どうもこんにちは佐藤です！

最近 「Claude に任せたら 1 日でアプリができた！」という投稿が毎日流れてきますよね。

AI コーディングは本当に速い。私もそれは強く実感しています。でも、速ければ速いほど、ある問題が浮かび上がってきます。

「AI に何を伝えればいいのか」という問題です。

設計書を書いて渡せばいい？　正直、設計書って分厚くなりがちで、読み込むトークンも膨大になります。しかも、AI はコンテキストが長くなるほどハルシネーションのリスクが増しますよね。

じゃあどうするのか。私が最近強く推しているのが、BEAM 分析と状態遷移図を組み合わせたアプローチです。

その理由を書いていきますね！

BEAM 分析とは何か

BEAM 分析は、業務要件を整理するためのモデリング手法です。以下の 6 つの要素でデータの流れを分析します。

  • （いつ）：そのデータはいつ動くのか
  • （どこで）：どの業務・システムで処理されるのか
  • （誰が）：誰がアクションするのか
  • （何を）：何のデータに対して操作するのか
  • （どのくらい）：量・頻度はどのくらいか
  • （どのように）：どのような操作をするのか
  • （なせ）：なぜその操作が必要なのか

これらを整理することで、「誰が・何に対して・どんな操作をするのか」が一目で把握できます。

ここで注目してほしいのが 「何をする」という動詞の部分です。「承認する」「差し戻す」「公開する」という動詞。これが、状態遷移のトリガーになるのです。

状態遷移図とは何か

状態遷移図は、データモデルがどの操作によってどのように状態変化するかを表した図です。

例えば、記事の投稿システムを考えてみましょう。

stateDiagram-v2
    [*] --> 下書き: 作成する
    下書き --> 承認待ち: 申請する
    承認待ち --> 公開: 承認する
    承認待ち --> 差し戻し: 差し戻す
    差し戻し --> 承認待ち: 再申請する
    公開 --> 非公開: 取り下げる

「下書き」「承認待ち」「公開」「差し戻し」がデータの状態。「申請する」「承認する」「差し戻す」がトリガーです。

ワークフローをシステム化するとき、この状態遷移図があるだけで、どんな実装が必要なのかが見えてきますよね。承認フロー・在庫管理・注文処理……業務システムで頻繁に登場するパターンです。

AI コーディングでのコンテキスト問題

さて、AI コーディングに戻りましょう。

AI に「注文管理システムを作って」と伝えるだけでは、当然ながら業務要件は伝わりません。かといって、100 ページの設計書を渡すのは現実的ではないのです。

コンテキストが長すぎると次のような問題が起きます。

  • トークンコストが跳ね上がる
  • AI がコンテキストを正確に追えなくなる
  • ハルシネーションのリスクが増す

では、設計書よりコンパクトで、しかしコンテキストとして十分に機能するものは何か。

ここで登場するのが状態遷移図です。状態と遷移のリストを JSON で書けば、データがどんな状態を持ち、どんな操作で変化するのかが数十行で表現できます。100 ページが数十行に圧縮されるのです。

Python の transitions ライブラリが強力な理由

Python に transitions というライブラリがあります。状態遷移を JSON や辞書で定義して、そのままプログラムとして動かせるライブラリです。

from transitions import Machine

states = ["draft", "pending", "published", "rejected"]

transitions = [
    {"trigger": "submit",   "source": "draft",     "dest": "pending"},
    {"trigger": "approve",  "source": "pending",   "dest": "published"},
    {"trigger": "reject",   "source": "pending",   "dest": "rejected"},
    {"trigger": "resubmit", "source": "rejected",  "dest": "pending"},
    {"trigger": "withdraw", "source": "published", "dest": "draft"},
]

class Article:
    pass

machine = Machine(model=Article(), states=states, transitions=transitions, initial="draft")

このコードを見るだけで、記事モデルがどんな状態を持ち、どのトリガーで遷移するのかがわかります。設計書を読む必要がありませんよね。

さらに嬉しいのが、JSON で定義できるという点です。JSON ならば、BEAM 分析の内容も一緒に持たせることができます。

{
  "states": ["draft", "pending", "published", "rejected"],
  "transitions": [
    {
      "trigger": "submit",
      "source": "draft",
      "dest": "pending",
      "who": "author",
      "when": "記事作成後",
      "why": "編集長の承認を受けるため"
    },
    {
      "trigger": "approve",
      "source": "pending",
      "dest": "published",
      "who": "editor",
      "when": "内容確認後",
      "why": "読者への公開のため"
    }
  ]
}

BEAM 分析の「誰が・いつ・どうして」を、状態遷移の定義にそのまま埋め込める。これが強力なのです。

プログラムにコンテキストを持たせる

従来の RESTful API の設計を振り返ってみましょう。

GET    /articles/{id}     → 記事取得
PUT    /articles/{id}     → 記事更新
PATCH  /articles/{id}     → 記事部分更新
DELETE /articles/{id}     → 記事削除

データベースのリソースをそのまま取得・更新する API です。シンプルで作りやすい。でも、「誰がどのタイミングでどんな操作をしていいのか」というコンテキストは API の外にあります。

フロントエンドのコードが承認ボタンを出すかどうかを判断して、人間が「このステータスなら次にこのボタンを押す」という知識を持って操作する。業務のコンテキストが人間とフロントエンドに吸収されていた構造です。

状態遷移を持たせると、API の設計が変わります。

GET  /articles/{id}/triggers   → 今の状態で実行できるアクション一覧を返す
POST /articles/{id}/submit     → 申請する
POST /articles/{id}/approve    → 承認する
POST /articles/{id}/reject     → 差し戻す

バックエンドが「今この記事はどの状態で、誰がどの操作をできるのか」を知っています。AI エージェントが /triggers を叩けば、次に何をすべきかがわかるのです。

AI との相性が抜群な理由

ここが核心です。

AI エージェントが業務システムを操作するとき、「次に何をすべきか」を判断するためのコンテキストが必要です。状態遷移を持つ API なら、AI はトリガーの一覧を取得するだけで、今何ができるかを理解できます。

graph LR
    A[AI エージェント] -->|GET /triggers| B[バックエンド API]
    B -->|submit, withdraw が実行可能| A
    A -->|POST /submit を実行| B
    B -->|状態遷移を実行・結果を返す| A
    style A fill:#fce4ec,stroke:#ad1457
    style B fill:#e3f2fd,stroke:#1565c0

AI に業務の全仕様を伝える必要はありません。「今何ができるか」だけを渡せば、AI は適切に判断して操作できます。コンテキストが短く・正確になるのです。

さらに、「実行できるトリガーと、そのトリガーに必要なパラメータ」をバックエンドが返してあげれば、データのやり取りに強い AI はそれだけで動けます。AI がプログラムの制御を握るのではなく、バックエンドが制御を持ちながら AI を活かす設計。これが堅牢さと柔軟さを両立させます。

テストコードとの相性も抜群

状態遷移図があると、テストケースが自然に導けるのもメリットです。

  • 「下書き状態で approve を呼んだら失敗するか」
  • 「承認待ち状態で approve を呼んだら公開状態になるか」
  • 「公開済み記事に submit を呼んだら何が起きるか」

状態 × トリガーの組み合わせが、そのままテストケースになるのです。

def test_submit_from_draft():
    article = Article()
    article.submit()
    assert article.state == "pending"

def test_approve_not_allowed_from_draft():
    article = Article()
    with pytest.raises(MachineError):
        article.approve()

「どのトリガーがどの状態変化を起こすのか」が明確なので、テストのカバレッジも自然と上がります。これまでは実装のコード量が増えすぎるため、なかなか整備できませんでしたよね。でも、AI がコードを書いてくれる時代なら、このアプローチが一気に現実的になります。

コードを書くコストが下がれば、設計の質を上げることに注力できる。AI コーディングの恩恵を最大限に受けられる構造が、状態遷移ベースの設計なのです。

まとめ

というわけで、AI コーディング時代だからこそ、BEAM 分析と状態遷移図が大活躍するよ！って話でした！

あ。正確には、状態遷移をプログラムに持たせることで、AI へのコンテキスト通知とバックエンドの制御が両立できるって感じですねっ。

設計書を読み込ませるより、JSON の状態遷移図を渡す方がトークンは少なく、コンテキストは豊かになります。しかも、その定義がそのままプログラムとして動き、テストの根拠にもなる。この一石三鳥の設計が、AI 時代のシステム開発を大きく加速させるのです。

弊社では、IT コンサルとして BEAM を用いたデータのモデリング・業務分析・システム化の要件定義を行っています。「うちの業務をどう整理すればいいかわからない」という方、ぜひ相談してくださいね！

この記事をシェアする

Xでシェア LINEでシェア