AIアプリのビジネスルールを平易な言葉で文書化する

なぜあいまいなルールは信頼できないアプリを生むのか

ビジネスルールは、実際の状況でアプリが何をするかを指示します。誰がリクエストを承認できるのか、合計がどう計算されるのか、通常のパターンから外れた場合に何が起きるのかを答えます。

そのルールがあいまいだと、アプリは選択をしなければなりませんが、期待した通りの道を選ぶとは限りません。

たとえば「大きな経費はマネージャーの承認が必要」というルールを考えてください。人はそれで明確だと思うかもしれませんが、開発者はそう思いません。大きいとは何ですか：$500、$5,000、それともチーム予算を超える全て？どのマネージャーですか：直属の上司、部門長、財務？2日以内に誰も応答しなければ、リクエストは保留、失効、あるいは別の人に回すのか？

だからこそ、あいまいなルールは信頼できないアプリを生みます。作り手は受け取った指示の範囲でしか一貫性を出せません。文言に推測の余地があれば、わずかに違うケースが出ると今日とは違う動作をすることがあります。

問題が最も現れやすいのは次のような領域です：

• 四捨五入、税金、割引、日付範囲などの詳細が抜けた計算
• みんなが暗黙に想定しているが文書化されていない例外
• 所有者、順序、フォールバックが明確でない承認ステップ

単純な例で問題を示せます。創業者が社内の経費アプリをKoder.aiで作り、「異常に見える出費は reimbursemment しない」とだけ書いたとします。一見合理的ですが、アプリは「異常」を判断する確実な方法を持ちません。ある従業員のタクシーは承認され、似たような別のものはフラグが立ち、理由が分かりません。

信頼できる挙動は、毎回同じように従えるルールから始まります。「大きい」「緊急」「特別扱い」といった言葉は、正確な上限、条件、アクションに置き換える必要があります。異なる二人が同じようにそのルールを適用できるなら、アプリも同じように動く可能性が高くなります。

明確なビジネスルールの例

明確なビジネスルールは一つの判断や一つのアクションに焦点を当て、プロセス全体をカバーしません。これは多くのチームが思うより重要です。承認、価格設定、例外、通知を一つのルールでカバーしようとすると、作り手はどの部分が重要かを推測しなければなりません。

良いルールは声に出して読みやすいものです。チーム外の人が内部の略語を知らなくても理解できるようにします。「ファストトラック」「標準ケース」「マネージャーの署名」といった用語は、実際に何が起きるかを正確に示す平易な言葉に置き換えてください。

ほとんどの明確なルールは次の4つの基本的な質問に答えます：

• 誰が判断またはアクションを行うのか？
• ルールはいつ適用されるのか？
• アプリ内で何が変わるのか？
• 次に何が起きるのか？

この構造がルールを実際の挙動に結びつけます。たとえば「大口注文はレビューが必要」と書く代わりに、「注文が$5,000を超える場合、出荷手配前に営業マネージャーが承認する必要がある」と書きます。一文で一つの決定と一つの結果です。

また、関連するルールは分けておくと便利です。承認ルールは単独で成り立つべきです。メール送信のルールは別、出荷停止のルールも別にしてください。そうすることで各ルールをテスト、更新、修正しやすくなります。

違いは明確です。

「プレミアム顧客は優先対応される」は曖昧です。

「顧客がプレミアムプランに加入している場合、チケット作成時にサポートリクエストを高優先度にマークする」は明確です。

後者はトリガー、条件、アプリ内の変更を明示しています。作り手に求められる信頼できる挙動を伝えます。

チャットベースのビルダーを使う場合、この種の言い回しは大きな差になります。明確なルールは法的な文言は不要です。簡単な言葉で、1回に1つのアイデア、期待される結果を1文に収めてください。

平易な言葉で計算を書く

計算は一見簡単に見えますが、作り始めると細かい点で迷います。安全な方法は、まずアプリが正確に何をするかを一文で書くことです。

良いルールはこう聞こえます：「払い戻し額は承認された距離（マイル）にマイレージ率を掛けたものとする。」これは「旅行手当を計算する」や「標準の払い戻しを適用する」よりずっと明確です。

その一文の後に、アプリが使う各入力を定義してください。作り手が推測しなくて済むように具体的に書きます。

各計算で定義すべきこと

各計算について、次を明記してください：

• 入力項目と分かりやすい名前・単位
• 各値の出所
• 四捨五入のルール
• 最小値や最大値があるか
• 値が欠落している場合の挙動

小さな詳細が結果を変えます。「最終額を小数点以下2桁で丸める」は、各行項目を先に丸める場合と異なる結果になります。上限があるなら、アプリが上限で打ち切るのか、それとも警告を出すのかも書いてください。

平易な言葉でのルール例：

「旅行の払い戻し額は承認済みのマイル数 × $0.67 とする。最終額は小数点以下2桁に丸める。1回あたりの最大払い戻し額は$300とする。承認済みマイルが空欄の場合、金額は計算しない。申請を未完了としてマークし、ユーザーにマイル数を入力するよう求める。」

その後に実際の数値を使った1〜2の具体例を加えてください。例は抽象的な式よりも欠点を早く露呈します。

例1：「承認済みマイルが120の場合、払い戻しは120 × $0.67 = $80.40。これは$300の上限未満なので、最終額は$80.40です。」

例2：「承認済みマイルが500の場合、払い戻しは500 × $0.67 = $335.00。最大が$300なので、最終額は$300.00です。」

この書き方はレビューしやすく、作り手がアプリの動作に変換しやすくなります。

例外を混乱なく書く

多くのアプリがつまずくのはメインルールではなくエッジケースです。

通常の流れは単純でも、実際の業務には締め切り後の返金、VIP顧客、書類の欠落、個別承認などが含まれます。例外が抜けていると、アプリは勝手に穴を埋めようとし、それが一貫性のない結果につながります。

例外を書く簡単な方法は、短いif-thenルールを使うことです。各ルールは一つの条件と一つの結果に集中させてください。

• 経費が$100未満なら自動承認する。
• 経費が$100未満だが提出が30日後であれば手動レビューに回す。
• 従業員が役員チームに所属する場合、$100の上限を無視して財務に回す。
• 財務管理者が請求を緊急とマークした場合、手動オーバーライドが適用され請求はキューの先頭に移る。

この形式は隠れたロジックを可視化します。重複や矛盾もバグになる前に見つけやすくなります。

同じくらい重要なのは、二つのルールが衝突したときにどちらが優先されるかを書いておくことです。顧客が割引条件に合致していても、休日期間のブラックアウトに該当することがあります。優先度を平易に書いてください：「休日期間のブラックアウトルールが顧客割引ルールと矛盾する場合、ブラックアウトルールが優先される。」

上限や日付、ユーザー種別、場所、アカウント状況、手動オーバーライドは結果を変えます。「遅延提出は承認が必要」と書く代わりに、「イベント発生日から14暦日を超えて提出された場合はマネージャー承認が必要」と書いてください。

また、各例外でアプリがユーザーに何を表示するかも明記してください。良いルールは判断で終わらず、次に表示するメッセージも定義します。たとえば「14日後に提出されました。マネージャー承認が必要です」や「財務管理者による手動オーバーライドが適用されました」のように書きます。

このように例外を記述すれば、珍しいケースも通常のテスト可能な挙動になります。

承認ロジックを段階的に記述する

承認ロジックはあいまいなポリシーではなく決定の連続として書くと最も機能します。各ステップは次の5つに答えるべきです：誰が行うか、何がレビューのトリガーか、どんな制限があるか、どれくらいの時間があるか、そして判断後のステータスは何か。

まず役割を明記してください。チーム名ではなく役職を明らかにします。「財務が大口申請をレビューする」と書く代わりに、「財務マネージャーは$5,000を超える申請を承認、却下、差し戻しできる」と書きます。これで推測の余地が減り、作りやすくなります。

次に各ステップのトリガーを定義します。トリガーは金額、部門、リスクレベル、リクエスト種別、あるいはこれらの組み合わせで決まります。

例：

• 申請が$500未満ならチームリードがレビューする。
• 申請が$500〜$5,000なら、チームリード承認後に部門マネージャーがレビューする。
• 申請が$5,000を超える場合は、部門マネージャー承認後に財務がレビューする。
• 申請がハイリスクとマークされている場合、最終承認前にコンプライアンスがレビューする。

しきい値は境界を正確に書いてください。「大きい」「機密」と言わずに「$5,000を超える」「営業部からの」「リスクスコア8以上」と書きます。複数のしきい値が同時に適用され得る場合、どちらが優先されるかも書いてください。例：「ハイリスクは金額が低くても必ずコンプライアンスに回る。」

タイムアウトルールも必要です。誰も応答しなければリクエストが無期限に放置されるべきではありません。48時間や3営業日などの期限を決め、承認者の上司へエスカレーションするか、バックアップ承認者へ割り当てるか、自動でキャンセルするかを指定してください。

最後に、各判断後のステータスを定義します。ラベルは短く一貫性を保ちます：

• 承認済み：リクエストは次に進むか完了する。
• 却下：リクエストはクローズされ、それ以上のアクションは行われない。
• 差し戻し：申請者が編集して再提出する必要がある。
• エスカレーション：リクエストがバックアップまたは上位承認者に移る。

このように承認ロジックを記述すれば、作り手の推測が減りワークフローの信頼性が大きく向上します。

再利用できるシンプルなルールテンプレート

一貫した挙動が欲しいなら、すべてのルールに同じ形を与えてください。書き方が混在すると結果も混在します。

短くて分かりやすい形式が多くのケースで機能します：トリガー、条件、アクション、結果。書くのが速く、後で他の人がレビューしやすい順序です。

1ルール＝1ユニットを使う

各ルールは独立した行、カード、ブロックに書いてください。複数のアイデアを1段落に詰め込まないでください。価格、承認、例外を同時に扱うとテストが難しく誤読が起きやすくなります。

実用的なテンプレートは次の通りです：

Trigger: When [event happens]
Conditions: If [facts must be true]
Action: Then [the app does this]
Result: So [expected outcome]
Assumption: [anything not yet confirmed]
Example: [short sample input and output]

すべてのフィールドが毎回必要なわけではありません。しかし順序を揃えておくと人がルールを素早く理解できます。

例：

Trigger: When an employee submits an expense claim
Conditions: If the total is over $500 and no receipt is attached
Action: Then send the claim back for correction
Result: So incomplete claims are not forwarded to a manager
Assumption: Receipt is required for all claims above $500
Example: A $620 taxi claim without a receipt is returned to the employee

例はルールの下に置き、ルールの中に混ぜ込まないでください。例はルールの挙動を示すだけです。

前提は「Assumption」や「要確認」と明確に表示してください。小さな注記が未解決の問いをビルド前に見つけやすくします。

また、言葉遣いを一貫させると良いです。トリガーは常に「When」から始め、条件は「If」、アクションは「Then」で始めるなど小さなパターンが混乱を減らします。

簡単なテストも効果的です：このルールを誰かがテストできるか、誰かが誤読できるかを確認してください。テストできない、あるいは誤読されるなら文言をさらに明確にしてください。

例：経費承認アプリ

従業員の経費アプリはテストケースとして適しています。方針がなじみ深く、エッジケースがすぐに出るためです。従業員は食事、タクシー、ホテル、小口の接待費などを申請しますが、それぞれ上限、例外、承認ステップがあります。こういうプロセスこそ平易な言葉が重要です。

サンプルポリシー

食費のルールはこう書きます：通常の勤務日における食事は1日あたり最大$40まで申請できる。アプリは同じ日の食事領収書を合計して日ごとの上限と比較し、個々の領収書ごとではなく日別合計で判定する。

火曜日に朝食$12、昼食$22を申請した場合、合計は$34で上限内なので通ります。同じ日に$15の夕食が追加されると合計は$49となり、アプリは上限超過としてフラグを立てます。

例外を追加します。出張扱いまたは顧客との会食であれば、日ごとの食事上限は$75に引き上がります。その例外は従業員が「出張日 = Yes」または「顧客会食 = Yes」を選び、顧客名や出張目的の簡単なメモを付けたときのみ適用されます。

この方が「特別な場合は許可されることがある」といったあいまいな文言より信頼できます。例外が明確な条件に結び付けられているからです。

承認ステップ

承認ロジックも同様に平易で構いません：

• $100未満の請求は従業員のマネージャーが承認する。
• $100〜$500の請求はマネージャー承認の後に財務承認が必要。
• $500超の請求はマネージャー、財務、部門長の順に承認が必要。
• 「travel」とマークされた請求は金額が$100未満でも財務レビューが必要。

いくつかの簡単なケースでルールをテストします。通常勤務日の$36の食事請求は領収書が添付されていれば承認されるはずです。出張日に$60の食事請求は、出張がマークされメモが埋まっていれば合格します。通常日で$60の食事請求は却下または差し戻しになります。$650のホテル請求は3段階すべての承認ステップを通過します。

目標はこれです：現実のケースでテストしても毎回同じ結果が出ること。

悪い結果につながる一般的な間違い

文章が人間には明確に見えても作り手を混乱させることがあります。多くの場合、文書があいまい、複数のアイデアが混在している、あるいは行間で不整合があると起きます。

よくある間違いの一つは、いくつものルールを一つの長い段落に詰め込むことです。例：「マネージャーが旅行を承認するが、合計が高い場合は財務が領収書を確認し、緊急はレビューをスキップできる。」一見効率的ですが複数の判断を隠してしまいます。価格、承認、例外は分けて書きましょう。

もう一つの問題はあいまいな語です。「通常」「大きい」「緊急」「最近」といった言葉は定義がなければ意味をなさない。もし「大きい経費」が$2,000以上を指すならそう明記してください。もし「緊急」が24時間以内を意味するなら、その条件を書いてください。

データ欠落も大きな原因です。チームは普通は成功する流れだけを書き、情報が不完全な場合にどうするかを忘れがちです。金額がない、部門がない、領収書がない場合に何が起きるかをルールに書いてください。

最も問題を起こすミスは通常次のとおりです：

• 複数のルールを1段落に詰め込む
• サイズ、時間、優先度について未定義の語を使う
• エラーケースや欠損フィールドを忘れる
• 最終承認者を不明確にする
• 同じものに対して別の名前を途中で使う

最終決定権は多くのチームが思うより重要です。マネージャーと財務レビュアーが対立したとき、誰が最終決定を下すのか。誰も最終ステップを所有していないとアプリは停滞したり作業がぐるぐる回ったりします。

用語の変更も静かなバグを生みます。「request」と書いておきながら途中で「submission」や「ticket」と呼ぶと、読者はそれらが別物だと誤解するかもしれません。用語は一貫して使ってください。

これはチャットベースのビルダーで特に重要です。平易な言葉で書けば挙動が明確になり、形式張る必要はありません。具体的で一貫し、完全な記述を心がけてください。

構築前のクイックチェックリスト

要件を画面やフロー、プロンプトに変える前に最終チェックを行ってください。ここでの短い確認が後の奇妙な動作を防ぎます。

各ルールはテスト可能であること。各ルールは明確な結果（はい/いいえ、承認/却下、手数料適用/不適用）で終わるべきです。二人が同じ文を読んで異なる答えを出すなら、そのルールは書き直しが必要です。

すべての計算を明記してください。入力項目、式、計算が行われるタイミング、四捨五入、通貨、日付の扱い、値が欠落またはゼロの場合の挙動を記してください。

例外は分けて書きます。まずデフォルトルールを書き、次に例外を独立して追加してください。主要な支出上限を請負業者や緊急購入、事前承認の特殊ケースの中に紛れ込ませないでください。

承認経路をマッピングしてください。各しきい値について誰が承認し次に何が起きるかを明記します。境界も正確に：「$500より上」か「$500以上」かをはっきりさせます。

その後、新しいメンバーのテストを行ってください。ルールを初めて見る人に説明してもらい、返ってくる説明に追加の文脈が必要かを確認します。補足が必要ならまだあいまいです。

小さな例で重要性が分かります。「マネージャーは大きな経費を承認する」は$500が大きいかどうか問われるまで曖昧です。「マネージャーは$500を超える経費を承認する。ディレクターは$2,000を超える経費を承認する。$500以下は自動承認」と書けば誤解の余地がずっと小さくなります。

ルールを実働アプリに変える

ルールが明確になったら、日常的にプロセスを使う人たちとレビューしてください。マネージャー、コーディネーター、財務担当、承認者はドキュメントに入りきらなかった小さな詳細に気づくことが多いです。そうした詳細がアプリの使い勝手を左右します。

ルールドキュメントは作成時の草案ではなく作業手順として扱ってください。何が起きるか、誰が決めるか、例外は何か、情報が欠落したときにアプリがどうするかを説明するものにします。

本格構築の前に最近の実際のシナリオをいくつか試してください。きれいなケースと混乱したケースの両方を使います：通るべき標準的なリクエスト、情報が欠けたリクエスト、手動レビューが必要な例外、支出上限や承認しきい値をまたぐケースなど。

この段階でギャップが見つかります。紙の上では明確でも、実際のリクエストが想定パターンに合わないとルールが破綻することがあります。

それらのシナリオが成立したらビルダーに移します。Koder.aiのようなチャットベースのプラットフォームを使う場合、明確なルールセットがあれば構築はずっと速くなります。というのもその時点ではフローやアクションが定義済みで、都度判断する必要がなくなるからです。

ローンチ後もドキュメントを真の情報源（source of truth）として維持してください。ポリシーが変わったとき、承認者が増えたとき、上限が更新されたときはまずドキュメントを更新し、その後アプリを更新してください。そうすれば将来の修正が簡単になり、異なる人が異なるやり方を記憶しているリスクを下げられます。

小さな習慣が役立ちます：プロセスが変わったときにだけでなく、定期的にルールを見直すこと。小さな更新は早めに行えば大変さが少なく、後で混乱を直すよりずっと楽です。

ドキュメントが最新であれば、アプリはテストや改善がしやすく、時間とともに信頼できるものになります。