会計システムの導入や刷新でテスト工程に入ると、「何を確認すれば十分なのか」「ベンダーが実施したテストだけで本番移行してよいのか」と迷いやすくなります。 特に会計システムは、画面が問題なく動くだけでは品質を判断できません。 売上や仕入などの取引から正しい仕訳が作られ、残高や元帳、帳票まで一貫して反映されることに加え、税計算、売掛・買掛、入出金、決算、権限、周辺システムとの連携なども確認する必要があります。 さらに、新システムへ切り替える場合は、旧システムから移したマスタや残高、未消込データなどが正しいかという データ移行の確認 も欠かせません。 テスト対象が広いため、思いついた機能から確認するのではなく、 「テスト工程」「会計業務」「システム品質」 の3つの軸で整理することが大切です。 そのうえで、個々の機能だけでなく、実際の業務と同じ流れで処理を最後まで通すことで、本番稼働後に発生する問題を見つけやすくなります。 そこで今回は、 会計システムで確認したいテスト観点からテストケースの作り方、本番移行の判断基準までを実務の流れで整理しました！ 初めてテスト計画やUAT（ユーザー受入テスト）を担当する場合でも、必要な確認範囲を順番に整理できる内容です。 import haihaiInquiryFormClient from "https://form-gw.hm-f.jp/js/haihai.inquiry_form.client.js";haihaiInquiryFormClient.create({baseURL: "https://form-gw.hm-f.jp",formUUID: "927d2c4e-f06c-45b1-bd36-0240e55ccf72",}) ▼テストの種類について詳しい内容はこちら▼ 【保存版】テストの目的別タイプ一覧 会計システムのテスト全体像を押さえよう！工程ごとの目的と役割 会計システムのテストでは、すべての確認を一度に実施するのではなく、開発の進行に合わせて複数のテスト工程を設けます。 代表的なのが、単体テスト、結合テスト、システムテスト、受入テストです。 工程を分ける理由は、 見つけたい問題と確認する範囲がそれぞれ異なるため です。 個々の機能が正しいかを確認する段階もあれば、複数の機能やシステムをつないで確認する段階、実際の利用部門が業務として使えるかを判断する段階もあります。 テストレベルは、個々のコンポーネントからシステム全体まで、対象となる範囲に応じて整理されます。 会計システムでは、技術的な動作確認だけで終わらせず、最終的に 正しい会計処理を継続できる状態か まで確認することが重要です。 まず知っておきたい！会計システムのテストで確認する3つのポイント 会計システムのテストは、大きく 「仕様どおりに動くか」「会計処理として正しいか」「実際の業務で使えるか」 の3つに分けて考えると整理しやすくなります。 1つ目は、入力や登録、検索、計算などの機能が設計された仕様どおりに動作するかという確認です。 2つ目は、画面上で処理が完了しただけでなく、売上や仕入などの取引から適切な勘定科目と金額で仕訳が作られ、元帳や残高、帳票に正しく反映されるかという会計面の確認です。 3つ目は、経理担当者などが実際の業務手順に沿って操作し、日常業務や月次・年次決算を問題なく進められるかという確認です。 さらに、販売、購買、経費精算、給与、銀行などと連携している場合は、システム間でデータが正しく受け渡されるかも確認します。 性能、アクセス権限、セキュリティ、障害発生時の運用など、機能以外の品質も忘れてはいけません。 「テストを実施したか」ではなく、「本番でも会計業務を安定して続けられるか」 をゴールにすると、確認すべき内容を判断しやすくなります。 単体・結合・システム・受入テストの違いを整理しよう！ 単体テストでは、入力、登録、更新、計算など、個々のプログラムや機能が意図したとおりに動作するかを確認します。 たとえば、金額を入力すると正しい税額が計算されるか、伝票登録によって期待する仕訳が生成されるかといった確認が該当します。 結合テストでは、複数の機能やシステムをつないだ際に、データが正しく受け渡されるかを確認します。 販売管理システムの売上データが会計システムへ送られ、正しい仕訳として登録されるかといったケースが代表的です。 システムテストでは、本番に近い環境でシステム全体が要求された機能や品質を満たしているかを確認します。 最後の受入テストでは、UAT（User Acceptance Testing：ユーザー受入テスト）として、経理・財務など実際に利用する側が 業務要件を満たしており、本番で受け入れられるシステムか を判断します。 受入テストは、システムを受け入れられるかどうかの判断に焦点を当てたテストレベルです。 工程ごとの目的を決めておけば、同じ確認を何度も繰り返すのではなく、リスクに応じて効率よく品質を高められます。 誰が何を確認する？ベンダー・情報システム・経理部門の役割を決めよう！ 会計システムのテストでは、開発ベンダー、情報システム部門、経理・財務部門がそれぞれ異なる視点を持っています。 開発ベンダーは、プログラムや画面、インターフェースなど、仕様書にもとづく技術的な品質確認を中心に担当します。 情報システム部門は、周辺システムとの連携、アクセス権限、性能、運用、障害対応など、システム全体を横断して確認する役割を担います。 一方、経理・財務部門でなければ判断しにくいのが、仕訳や締め処理、消込、決算などの 業務上の妥当性 です。 そのためUATでは、実際の利用者や業務責任者が参加し、「業務として問題なく利用できるか」を確認することが重要になります。 受入テストは、テスターだけでなく、業務担当者やプロダクトオーナーなど幅広い関係者が関与するテスト領域です。 テスト開始前に、実施者、結果確認者、不具合の判断者、本番移行の承認者を決めておくと、「誰がOKを出すのか分からない」という状態を避けられます。 抜け漏れを防ごう！会計システムで必ず確認したいテスト観点 会計システムでは、一般的な業務システムのテストに加え、 数字の正確性と会計処理のつながり を重点的に確認する必要があります。 画面上では正常に登録できていても、生成された仕訳の勘定科目が違っていたり、総勘定元帳や試算表へ正しく反映されていなかったりすれば、会計システムとしては問題があります。 また、日常取引だけを確認して本番稼働すると、月末の締め処理や年度決算になって初めて不具合が発覚する可能性があります。 そのため、仕訳、税計算、売掛・買掛、入出金、決算、周辺システム連携、権限、マスタ、帳票、データ移行まで、 実際の会計業務全体からテスト観点を洗い出す ことがポイントです。 仕訳をチェック！取引から元帳・試算表まで正しくつながるか確認する 会計システムで特に重要なのが、取引から作られる仕訳が正しいかという確認です。 売上、仕入、経費、入金、出金、振替など、自社で利用する代表的な取引をテストケースとして用意します。 取引を登録したら、借方・貸方の勘定科目だけでなく、補助科目、部門、取引先、税区分、金額などが期待した内容になっているか確認します。 自動仕訳を採用している場合は、画面上の登録結果だけで終わらせず、 生成された仕訳そのものを確認すること が大切です。 さらに、仕訳帳、総勘定元帳、補助元帳、試算表などへ同じ金額が正しく反映されているかまで追跡します。 通常の登録だけではなく、取消、修正、逆仕訳なども対象にすると、本番で発生しやすい例外処理の不具合を見つけやすくなります。 テストケースには「登録できること」と書くのではなく、「どの勘定科目にいくら計上され、どの帳票へ反映されるか」という 会計上の期待結果 を設定すると、合否判断が明確になります。 税金・金額計算で事故を防ごう！消費税・端数・境界値を確認する 会計システムでは、金額計算のわずかな違いが大量の取引に影響する可能性があります。 そのため、消費税などの税計算や端数処理は、代表的な金額だけでなく複数の条件を使って確認します。 自社で扱う課税、非課税、不課税などの税区分について、それぞれ意図した計算結果になるかを確認します。 内税・外税の設定を使い分けている場合は、それぞれのケースを用意することも重要です。 また、金額を割り切れないケースでは、切り捨て、切り上げ、四捨五入などの端数処理が自社のルールどおりになっているかを確認します。 通常の値だけでなく、ゼロ、上限付近、桁数の境界などを使った 境界値のテスト も有効です。 税区分や会計設定はマスタによって制御されるケースも多いため、設定変更後に既存取引や新規取引がどのように処理されるかも確認しておくと安心です。 月次・年次決算まで通そう！日常処理だけでは見つからない問題を確認する 会計システムのテストで見落としやすいのが、月末や年度末にしか実施しない処理です。 日常的な伝票入力が問題なく動いていても、月次締めや年度締めが正常に完了しなければ、本番稼働後の決算業務に大きな影響が出ます。 そのため、月次締め、締め後の入力制御、締め解除、翌月・翌年度への繰越など、 期間管理に関する処理 を確認します。 減価償却、引当、振替、決算整理仕訳などをシステム上で実施している場合は、それらも重要なテスト対象です。 処理後には試算表や総勘定元帳、補助元帳などの残高を確認し、元となる仕訳と数字が一致しているかを確かめます。 テストケースを作る際は、日々の業務マニュアルだけでなく、年間の経理業務カレンダーも確認すると効果的です。 月次、四半期、年度末など発生頻度が低い業務まで洗い出せるため、 本番稼働後の最初の決算で初めて問題に気づくリスク を減らせます。 売掛・買掛・入出金をつなげよう！一連の業務フローで確認する 売掛金や買掛金に関する機能は、1画面ずつ確認するだけでは不十分です。 売上であれば、売上計上、売掛金の発生、請求、入金、消込、仕訳というように、 取引の開始から完了までを一つのシナリオとして確認する ことが重要です。 仕入についても、仕入計上、買掛金の発生、支払、消込までを一連の流れとして確認します。 その際は、金額がすべて一致する通常ケースだけでなく、一部入金、過入金、前受金、前払金、相殺など、自社で実際に発生する例外ケースも含めます。 特に注意したいのが、業務の途中で担当者やシステムが変わる場所です。 販売管理から会計へデータが渡る場面や、銀行データを取り込んで入金消込を行う場面などは、処理の境目で不具合が発生しやすくなります。 UATでは、個別機能を単独で触るだけでなく、 実際の担当者が普段行う順番で操作して最後まで処理を完了できるか を確認すると、実務上の問題を発見しやすくなります。 周辺システムとの連携を確認！データの欠落・重複・二重計上を防ぐ 会計システムは、販売管理、購買管理、経費精算、給与、銀行など、多くの周辺システムからデータを受け取ります。 まずは、どのシステムからどのデータが入り、会計システム上で何に変換されるのかを一覧にしておくと、連携テストの抜け漏れを防げます。 テストでは、送信元と送信先のデータ件数だけでなく、金額、勘定科目、部門、取引先、日付などの主要項目も照合します。 データが届く正常系だけではなく、通信エラー、必須項目不足、不正なコードなどによって連携に失敗した場合も確認します。 さらに重要なのが、失敗したデータを再送した際の動作です。 再送によって同じ仕訳が二重登録されないか、エラーとなったデータだけを安全に再処理できるかを確認します。 「送信できたからOK」ではなく、業務システムから会計システムへ入り、正しい仕訳や帳票になるまで追跡すること が連携テストのポイントです。 権限・マスタ・帳票も忘れずに！日常運用で困らないか確認する 会計システムでは、仕訳の正確性と同じくらい、日常運用に必要な権限やマスタ、帳票の確認も重要です。 権限テストでは、一般担当者、承認者、管理者など役割ごとに、閲覧、登録、変更、削除、承認が可能な範囲を確認します。 権限を持たない担当者が機密性の高い財務情報を閲覧できたり、承認前のデータを不正に変更できたりしないことも確かめます。 マスタについては、勘定科目、補助科目、取引先、部門、税区分など、業務で利用する主要な設定を対象とします。 新規登録だけではなく、変更、無効化、適用開始日なども確認すると実運用に近づきます。 帳票では、仕訳帳、総勘定元帳、試算表などの金額が元データと一致するかを確認します。 CSV（Comma-Separated Values：カンマ区切り形式）やExcel、PDFへ出力する場合は、 桁落ち、文字化け、項目不足、並び順の崩れ などもチェックすると、導入後の集計作業や監査対応で困りにくくなります。 データ移行は「件数＋残高」で突合！旧システムとの不一致を防ぐ 会計システムを刷新する場合、旧システムのデータを新システムへ正しく移せるかは、本番稼働を左右する重要なポイントです。 移行対象には、勘定科目や取引先などのマスタだけでなく、顧客や仕入先、未処理の取引、残高なども含まれることがあります。 まずは「何を移行し、何を移行しないのか」を明確にし、データごとに移行前後の確認方法を決めます。 確認では単純な件数比較だけではなく、勘定科目別残高、取引先別残高、未消込金額など、 会計上意味のある単位で金額を突合すること が大切です。 件数が一致していても、コード変換や金額変換が誤っている可能性があるためです。 差異が出た場合は、欠落、重複、変換ミス、移行対象外など原因を追跡できるようにします。 本番移行の直前だけで確認するのではなく、テスト移行を複数回行い、データ抽出から投入、照合、修正までの手順を固めておくと、切り替え当日のリスクを抑えやすくなります。 正常系だけでは不十分！異常系・性能・セキュリティも確認する 正常なデータだけでテストすると、実運用で起こるエラーを十分に検証できません。 必須項目を入力しなかった場合、不正な日付を指定した場合、上限を超える金額や桁数を入力した場合など、 意図的に失敗させる異常系テスト も行います。 エラーになったことだけではなく、原因と対応方法を担当者が理解できる表示になっているかも確認します。 性能面では、通常日の処理速度だけでなく、月末や決算期など大量の仕訳処理が集中する状況も想定します。 帳票出力や大量データ取込に時間がかかり、締め業務に影響しないかを確認しておくことが大切です。 セキュリティ面では、権限管理、不正アクセス対策、操作ログなど、財務情報を安全に扱うための仕組みを確認します。 機能が正常に動くことだけに集中せず、 「エラーが起きても安全か」「業務量が増えても使えるか」「必要な人だけが操作できるか」 まで確認すると、実運用に近い品質評価ができます。 実務で迷わない！会計システムのテストケース作成から本番移行までの進め方 会計システムのテストでは、確認項目を思いつくまま並べるだけでは、重要なリスクを見落とす可能性があります。 まず業務やシステムの変更点を整理し、問題が起きた場合の影響が大きい場所を優先してテストします。 そのうえで、実際の業務フローからテストシナリオを作り、具体的な入力条件と期待結果へ落とし込んでいきます。 テスト実施後は不具合の件数だけを見るのではなく、業務への影響と残っているリスクを確認し、本番へ移行できる状態かを判断します。 「テストケース作成→実施→不具合管理→移行判定」までを一つの流れとして設計すること が、テストを形式的な作業にしないポイントです。 重要業務から洗い出そう！リスクの高い範囲を優先する テストケースを作る前に、要件定義書や新旧の業務フローを確認し、どの業務やシステムが変更されるのかを整理します。 すべての機能を同じ密度でテストしようとすると、時間や人員が不足しやすくなります。 そこで、取引量が多い業務、扱う金額が大きい業務、決算への影響が大きい業務、障害時に業務停止につながる機能などから優先順位を付けます。 判断するときは、 「問題が発生した場合の影響度」と「問題が発生する可能性」 を組み合わせて考えると整理しやすくなります。 たとえば、年に一度しか利用しない機能でも、年度決算を止める可能性があるなら重要度は高くなります。 反対に、利用頻度が高くても業務への影響が限定的で簡単な回避策がある場合は、テストの優先度を調整できます。 限られた期間では「全部を同じように確認する」のではなく、 失敗したときに困る場所ほど厚くテストする という考え方が効果的です。 新しい業務フローからテストシナリオを作ろう！ テストシナリオは、画面や機能の一覧だけを見て作るのではなく、実際の業務フローから作成します。 たとえば売上関連であれば、「売上登録→請求→入金→消込→仕訳→帳票確認」のように、業務の開始から完了までを一連の流れとして設計します。 こうすることで、個々の画面は正常でも、処理をつないだときに発生する不具合を見つけやすくなります。 通常の取引だけではなく、修正、取消、一部入金、月末処理など、実際の業務で発生するパターンも加えます。 特にUATでは、仕様書に書かれた機能をなぞるだけではなく、 新システム導入後に現場が行う業務そのものを再現すること が重要です。 テストシナリオを作成したら、経理や財務など実務に詳しい担当者にも確認してもらいます。 システム担当者だけでは気づきにくい締め処理や例外業務を補えるため、本番稼働後の「このケースを確認していなかった」という事態を防ぎやすくなります。 期待結果まで書こう！判断に迷わないテストケースを作る テストケースには、少なくともテスト対象、事前条件、入力内容や操作手順、期待結果を記載します。 特に重要なのが 期待結果を具体的にすること です。 「正常に登録されること」「正しく仕訳されること」だけでは、実施者によって判断が変わる可能性があります。 たとえば売上取引であれば、「売掛金100,000円／売上100,000円の仕訳が作成される」といったように、確認すべき値を具体的にします。 ステータスが変わる処理であれば、処理後に何という状態になるのかまで書きます。 また、実行結果、実施日、実施者、証跡、不具合番号などを記録できるようにしておくと、後から結果を説明しやすくなります。 正常系だけでなく、異常系や境界値、業務シナリオを組み合わせることも大切です。 誰が実行しても同じ基準で合否を判断できる状態 にすることが、実務で使えるテストケースの基本です。 本番に近いデータと環境で受入テストを実施しよう！ UATでは、できるだけ本番の利用状況に近い条件でテストします。 勘定科目や取引先などのマスタ、実際に発生する取引パターン、利用者の権限などを本番に近づけることで、机上では見つけにくい問題を確認できます。 操作する担当者も、可能な限り実際にシステムを利用する経理・財務などの業務担当者を含めます。 確認するのは「ボタンを押せるか」ではなく、 業務開始から会計処理の完了まで支障なく進められるか です。 周辺システムがある場合は、販売や購買からデータを受け取り、仕訳や帳票へ反映されるところまで通して確認します。 データ移行を伴う場合は、移行後のデータを使ったUATや回帰テストを実施することで、移行が業務へ与える影響も確認しやすくなります。 実データを利用する際は、個人情報や機密情報の取り扱いにも注意し、必要に応じて匿名化したデータを使用します。 UATは単なる最終操作確認ではなく、 本番導入を受け入れてよいかを業務側が判断する工程 として位置付けることが大切です。 不具合を数えるだけではNG！重要度と残存リスクを管理する テストで不具合が見つかったら、件数だけで品質を判断しないことが重要です。 同じ1件でも、表示位置が少しずれる問題と、仕訳金額が誤る問題では業務への影響が大きく異なります。 そのため、不具合を重大、高、中、低などに分類し、決算不能、金額誤り、業務停止、データ破損などの影響があるものを優先して対応します。 修正が完了したら、不具合が直ったことを確認する再テストに加え、修正によって関連機能へ別の問題が発生していないかを確認する 回帰テスト も必要です。 スケジュールなどの都合で本番までに修正しない不具合がある場合は、放置するのではなく、業務への影響、発生条件、回避策を整理します。 また、「未解決の不具合」と「まだテストしていない範囲」は分けて管理します。 本番移行時にどのような問題が残っているかを明確にし、 残存リスクを関係者が理解したうえで判断できる状態 を作ることが重要です。 本番移行して大丈夫？合格基準を決めて判断しよう！ 本番移行の判断基準は、テストが終わってから考えるのではなく、できるだけテスト計画の段階で決めておきます。 たとえば、重要な業務シナリオがすべて完了していること、業務停止につながる重大な不具合が残っていないこと、データ移行後の主要残高が一致していることなどが判断材料になります。 単純に「テストケースを100％実施した」という数字だけでは十分ではありません。 重要度の低いケースを多数実行していても、決算や入出金など重要な業務を確認できていなければ、本番稼働の安全性を判断しにくいためです。 未解決の不具合や未実施のテストが残る場合は、その影響と回避策も合わせて整理します。 経理・財務、情報システム部門、ベンダーなどで結果を共有し、 重要な会計業務を本番環境で安定して続けられるか という視点で判断します。 実施結果や証跡、未確認範囲、残存リスクを残しておけば、本番移行の判断理由を社内でも説明しやすくなります。 こんなテストは要注意！失敗しやすい5つのパターンを避けよう 会計システムのテストで注意したいのが、ベンダーから提示されたテストケースだけで確認を終えてしまうケースです。 ベンダーは製品やシステムの仕様には詳しくても、企業独自の会計処理や例外的な業務まですべて把握しているとは限りません。 そのため、 自社固有の業務ルールは自社側でもテスト観点として追加すること が重要です。 また、正常な入力だけを確認し、取消、修正、エラー、境界値などを確認しないテストも注意が必要です。 個別機能だけを確認して、販売から会計、入金から消込といった業務全体を通していない場合も、本番で初めて連携上の問題が見つかる可能性があります。 経理担当者の参加が本番直前になり、UATで業務上の問題が大量に見つかるケースも避けたいところです。 さらに、「不具合が何件残っていても予定日に本番移行する」といった進め方では、テストの意味が薄れてしまいます。 自社業務の観点不足、異常系不足、業務フロー不足、現場参加の遅れ、合格基準の曖昧さ という5つを避けるだけでも、テストの実効性を高めやすくなります。 まとめ｜「業務が最後まで正しく回るか」を基準にテストしよう！ 会計システムのテストでは、画面や個別機能が動作することだけでなく、取引から仕訳、元帳、試算表、帳票まで正しくつながることを確認する必要があります。 仕訳や税計算だけでなく、売掛・買掛、入出金、月次・年次決算、システム連携、権限、マスタ、帳票、データ移行、性能やセキュリティまで含めてテスト観点を整理することが大切です。 限られた期間や人員ですべてを同じ密度で確認する必要はありません。 決算が止まる、金額を誤る、業務が停止するといった影響の大きい領域から優先し、重要な部分ほどテストを厚くします。 テストケースでは手順だけでなく、仕訳や金額、ステータスなど 具体的な期待結果 まで決めておくと、実施者による判断のばらつきを抑えられます。 UATでは経理・財務など実際の業務担当者も参加し、日常業務から決算まで本番に近い流れで確認します。 そして最終的な本番移行判断では、テスト件数や実施率だけを見るのではなく、残っている不具合や未確認範囲も含めて評価します。 「重要な会計業務を本番環境で最後まで正しく、安定して続けられるか」 を判断基準にすることで、テストを単なるチェック作業ではなく、本番稼働のリスクを減らすための実践的な工程にできます。 QA業務効率化ならPractiTest テスト管理の効率化 についてお悩みではありませんか？そんなときはテスト資産の一元管理をすることで 工数を20%削減できる 総合テスト管理ツール「 PractiTest 」がおすすめです！ PractiTest (プラクティテスト) に関する お問い合わせ トライアルアカウントお申し込みや、製品デモの依頼、 機能についての問い合わせなどお気軽にお問い合わせください。 お問い合わせ この記事の監修 Dr.T。テストエンジニア。 PractiTestエバンジェリスト。 大学卒業後、外車純正Navi開発のテストエンジニアとしてキャリアをスタート。DTVチューナ開発会社、第三者検証会社等、数々のプロダクトの検証業務に従事。 2017年株式会社モンテカンポへ入社し、マネージメント業務の傍ら、自らもテストエンジニアとしテストコンサルやPractiTestの導入サポートなどを担当している。 記事制作： 川上サトシ （マーケター、合同会社ぎあはーと代表）

決済や送金などを扱うFinTechシステムでは、「一般的なWebシステムと同じテストをすれば十分なのか」と判断に迷う場面があります。 画面や機能が仕様どおり動くことはもちろん重要ですが、金融サービスでは、わずかな処理ミスでも残高不整合や二重決済といった大きな問題につながる可能性があります。 そのため、 取引・データの正確性、API（アプリケーション・プログラミング・インターフェース）による外部連携、性能、セキュリティ、障害時の復旧 まで含めて考えることが欠かせません。 また、テスト項目を大量に増やせば安心できるわけでもありません。 金融システムでは、システム障害やサイバー攻撃が事業や顧客へ与える影響を踏まえ、重要なリスクから優先して確認する考え方が必要です。 テストの完了だけをゴールにせず、障害発生時の復旧や代替手段まで確認し、リリース後もサービスを継続できる状態を作ることが重要になります。 そこで今回は、 FinTechシステムで押さえたいテストの全体像から7つの重要観点、効率化、リリース判断までを実務の流れに沿って整理しました！ 「何を、なぜ、どこまで確認すればよいのか」を整理し、テスト計画の抜け漏れを防ぐための判断材料として活用できます。 import haihaiInquiryFormClient from "https://form-gw.hm-f.jp/js/haihai.inquiry_form.client.js";haihaiInquiryFormClient.create({baseURL: "https://form-gw.hm-f.jp",formUUID: "927d2c4e-f06c-45b1-bd36-0240e55ccf72",}) ▼テストの種類について詳しい内容はこちら▼ 【保存版】テストの目的別タイプ一覧 FinTechのシステムテストは何が違う？まず押さえたい基本と重要性 FinTechのシステムテストでは、単に「仕様書に書かれた機能が動いた」という結果だけでは品質を判断できません。 金融サービスではシステムの停止や誤作動、不正利用などによって顧客や事業者が損失を受ける可能性があり、安全かつ安定的に稼働すること自体がサービスへの信頼につながります。 さらに、近年の金融システムはクラウドや外部サービス、APIなどを組み合わせて構築されるケースが増え、障害の原因が自社システム内部だけにあるとは限りません。 接続先の停止や通信遅延、不正なアクセス、データ連携の失敗まで含め、 サービス全体を一つのシステムとして捉える視点 が求められます。 また、品質を高めようとして確認項目を無制限に増やすと、開発期間やコストが膨らみます。 重要なのは、システムが抱えるリスクを整理し、影響の大きな領域へテスト工数を優先的に配分することです。 FinTechのテストでは、 品質、スピード、リスク管理を同時に成立させること が大きなテーマになります。 FinTechでは「動くこと」だけでなく「正しく安全に取引できること」を確認しよう！ 一般的なシステムテストでは、システム全体が要件を満たしているかを確認しますが、FinTechでは特に 取引結果の正確性 が重要です。 送金額や残高、手数料、決済ステータスなどが一つでも誤れば、単なる表示不具合では済まず、実際の資産や会計処理へ影響する可能性があります。 正常に処理できるケースだけでなく、通信が途中で切断された場合、外部APIから応答が返らない場合、同じ要求が複数回届いた場合なども確認する必要があります。 たとえば決済処理の途中でタイムアウトが発生した際、画面では「失敗」と表示されたにもかかわらず、実際には決済だけ完了している状態になれば、再操作によって二重決済が起こる可能性があります。 APIについても認証や認可、不適切なデータアクセス、外部APIの安全でない利用など、機能面とは別のリスクがあります。 FinTechではテストケース数の多さより、 誤取引やサービス停止につながる重要な失敗パターンを想定できているか を重視することが大切です。 単体・結合・システム・受け入れテストの役割を混同しない！ FinTechシステムの品質を効率よく確認するには、それぞれのテスト工程で「何を保証するのか」を明確にしておく必要があります。 単体テストでは、金額計算や入力チェックなど、プログラムや機能単位で想定した結果になるかを確認します。 結合テストでは、画面とAPI、APIとデータベース、決済基盤と自社サービスなど、複数の機能を接続した際に正しく連携できるかを確認します。 システムテストでは、本番に近い構成を用意し、機能だけでなく性能やセキュリティ、障害対応を含めてサービス全体の品質を評価します。 受け入れテストでは、実際の業務や利用シーンを想定し、業務要件を満たした状態でサービスを提供できるかを確認します。 特に金融システムでは、ユーザー部門とシステム部門の認識差や業務要件の漏れが障害原因になることがあるため、設計・開発段階から各工程の検証と承認を明確にすることが重要です。 どの工程で、誰が、何を確認するのか を決めておけば、同じ確認の繰り返しと重要項目の確認漏れを同時に減らせます。 金融システムならではのリスクをテスト計画の出発点にしよう！ FinTechのテスト計画では、機能一覧からテストケースを作り始める前に、サービスで発生すると困る事象を洗い出すことが重要です。 最初に考えたいのは、 誤送金、二重決済、残高不整合、情報漏えい、サービス停止 など、顧客や事業への影響が大きいリスクです。 次に、それらの問題がどの機能やシステム連携で発生し得るのかを整理し、重要度の高い領域へテストを割り当てます。 24時間提供するサービスであれば、「障害を発生させないこと」だけではなく、障害発生後に代替手段へ切り替えられるか、必要な時間内に復旧できるかという観点も欠かせません。 金融分野では、サイバーセキュリティだけでなく、障害や外部環境の変化が起きても重要な業務を維持・復旧できる ITレジリエンス も重視されています。 外部API、クラウド、決済事業者、認証サービスなどへの依存関係も可視化し、自社以外の障害を含めたシナリオを用意すると、より実運用に近いテスト計画になります。 抜け漏れを防ぐ！FinTechシステムで優先したい7つのテスト観点 FinTechシステムには多くの確認項目がありますが、すべてをばらばらに考えるとテストケースが膨大になり、優先順位を付けにくくなります。 そこで、 ①機能・取引、②API・外部連携、③データ整合性・同時実行、④性能・負荷、⑤セキュリティ、⑥障害・復旧、⑦規制・監査・証跡 の7つに分けて整理すると、全体像を把握しやすくなります。 重要なのは、7種類を同じ密度で実施することではありません。 決済サービスであれば取引処理や外部連携、個人情報を多く扱うサービスであれば認証・権限やデータ保護など、事業特性によって優先順位を変えます。 また、システムの重要度やリスクに応じた安全対策を考えることは、金融情報システム全体の安全性を確保するうえでも重要な考え方です。 以下の7つをチェックリストとして機械的に消化するのではなく、 重大事故を防ぐための確認軸 として活用することがポイントです。 ①機能・取引テスト｜「正しく処理されたか」を金額とステータスまで確認！ 機能・取引テストでは、入金、出金、送金、決済、返金、取消など、サービスの中核となる取引が仕様どおり処理されるかを確認します。 特にFinTechでは、画面上で「成功」と表示されることだけでなく、 金額、残高、手数料、取引ステータス、後続処理まで一貫して正しいか を見ることが重要です。 正常系だけでなく、残高不足、上限超過、不正な入力、処理途中の通信断なども確認対象になります。 同じ決済要求が何らかの理由で再送された際に、二重で処理されないことも重要な確認ポイントです。 処理途中で障害が起きた場合は、取引を取り消すのか、途中から再開するのか、最初からやり直すのかを仕様として明確にし、その結果がデータベースや外部サービスにも正しく反映されるか確認します。 金融システムでは誤作動そのものが顧客や事業者の損失につながり得るため、 画面表示ではなく取引全体の最終状態を確認する ことが基本となります。 ②API・外部連携テスト｜接続先が変わっても止まらない仕組みを確認！ FinTechサービスでは、決済、本人確認、認証、銀行口座連携などを外部サービスのAPIと組み合わせて提供することがあります。 そのためAPI・外部連携テストでは、正常なデータ交換だけでなく、 接続先で異常が起きた場合の振る舞い まで確認することが重要です。 タイムアウト、通信切断、エラー応答、想定外のデータ、レスポンス遅延などを発生させ、待機や再試行、エラー処理が設計どおり機能するかを確認します。 再試行の結果として同じ取引が重複しないことや、アクセス権限のないデータをAPI経由で取得・更新できないことも確認が必要です。 APIではオブジェクト単位の認可不備、認証の問題、リソース消費の制御不足、外部APIを安全性の確認なしに利用する問題など、さまざまなセキュリティリスクも想定されています。 外部サービスを自由に停止させられない場合はモックやサービス仮想化を使い、異常応答を再現して、 接続先に問題が起きても自社サービスが安全に振る舞えるか を確認します。 ③データ整合性・同時実行テスト｜残高や取引履歴のズレを防ぐ！ FinTechでは、一つの取引情報が画面、API、データベース、会計システム、外部決済基盤など複数の場所へ反映されることがあります。 このとき一部の処理だけが成功すると、利用者が確認する残高と実際の取引記録が異なるなど、深刻な不整合につながります。 データ整合性テストでは、 一つの取引が関係するすべてのシステムで同じ状態になっているか を確認します。 また、複数の利用者や処理が同時に同じ口座やデータへアクセスする状況も重要です。 同時更新によって残高計算がずれる、更新内容が上書きされる、処理が互いに待ち続けるといった問題が起きないかを確認します。 日次や月次のバッチ処理、締め処理とオンライン取引が重なる時間帯など、実際の運用で発生する組み合わせもテスト対象に含めます。 少量のテストデータでは発生しない問題もあるため、本番に近い件数や処理パターンを使い、 取引量が増えても正しいデータ状態を維持できるか を見ることが重要です。 ④性能・負荷テスト｜アクセス集中時でも取引を止めない！ 性能・負荷テストでは、通常時に画面が速く表示されるかだけでなく、アクセスや取引が集中した際にも要求するサービス水準を維持できるか確認します。 FinTechでは給与日、キャンペーン、相場の急変、サービス開始直後など、短時間に利用が集中する場面を想定する必要があります。 実際に近い同時アクセス数や取引件数を発生させ、 応答時間、処理件数、エラー率、システム資源の使用状況 などを確認します。 負荷が上がった際には、Webサーバーだけではなく、API、データベース、外部サービスなど、どこがボトルネックになるかを切り分けることも重要です。 さらに、処理能力の限界を超えたときにシステム全体が一斉に停止するのか、アクセス制御や一部機能の制限によって重要サービスを継続できるのかも確認します。 金融サービスでは安全かつ安定的な稼働が重要であり、障害時の迅速な復旧もシステムリスク管理の重要な要素です。 平均的な性能だけでなく、最も厳しい利用状況でも重要取引を維持できるか まで確認することが大切です。 ⑤セキュリティテスト｜顧客の資産と情報を守れるか確認！ FinTechシステムでは個人情報や口座情報、取引情報などを扱うため、セキュリティテストを機能テストとは別の重要領域として考える必要があります。 まず、ログインや本人確認、多要素認証、権限管理が設計どおり働き、権限を持たない利用者が他人の情報や管理機能へアクセスできないことを確認します。 APIでも認証やオブジェクト単位のアクセス制御不備は重要なリスクとなるため、IDなどの値を書き換えるだけで他者の情報を参照できないかといった確認が必要です。 さらに、脆弱性診断や必要に応じた侵入テストを実施し、外部から悪用できる弱点が残っていないかを確認します。 通信時や保存時のデータ保護に加え、アプリケーションログへパスワードや認証情報、不要な個人情報が出力されていないかも確認したいポイントです。 金融分野ではサイバー攻撃への対応力と復旧力の強化が継続的な課題となっています。 そのため、 リリース前の一度だけ確認するのではなく、変更や脅威の変化に合わせて継続的に検証する仕組み まで考えることが重要です。 ⑥障害・復旧テスト｜「壊れない」だけでなく「壊れても戻せる」を確認！ どれだけ対策しても、システム障害を完全になくすことは困難です。 そのためFinTechでは、障害を防ぐテストに加え、 障害が起きても重要な取引を守り、サービスを復旧できるか を確認します。 サーバー、ネットワーク、データベース、クラウドサービスなどに障害が発生した状況を作り、冗長化された環境へ正しく切り替わるかを検証します。 切り替えそのものが成功しても、処理途中だった取引が消えたり二重になったりしては問題があるため、復旧後のデータ整合性まで確認することが必要です。 バックアップについても「取得できている」だけではなく、実際に戻せるか、必要な時間内にサービスを再開できるかをテストします。 障害時の代替手段やコンティンジェンシープラン（緊急時対応計画）は、文書を用意するだけでなく、実際に訓練し、結果を踏まえて改善することが重要です。 障害を起こさない設計と、起きたときに戻せる設計をセットで検証する ことで、サービス全体のレジリエンスを高められます。 ⑦規制・監査・証跡テスト｜「なぜリリースできるのか」を説明できる状態に！ FinTechでは、システムが正常に動くことに加えて、適用される法令や監督上の要求、社内ルール、契約上の条件を満たしているかも確認する必要があります。 ただし、すべてのFinTechサービスへ同じ規制が適用されるわけではないため、提供するサービスや事業形態に応じて確認対象を整理することが大切です。 金融情報システムの安全対策を考える際には、FISC（金融情報システムセンター）の安全対策基準なども、開発・導入・運用における安全対策を整理する材料となります。 テストでは、監査ログが適切に記録され、 誰が、いつ、どの情報や取引へ、どのような操作を行ったか を追跡できるか確認します。 さらに、テスト結果だけでなく、発見した不具合、修正内容、再テスト結果、残っているリスクまで記録しておくことが重要です。 金融システムの移行判断では、必要なテストやリハーサルなどを終え、判断に必要な材料を揃えておく考え方が重視されています。 「テストを実施した」という記録ではなく、「主要なリスクを確認し、この根拠でリリースできる」と説明できる証跡 を残すことがポイントです。 品質とスピードを両立！失敗しにくいテスト計画と効率化の進め方 FinTechのシステムテストでは、安全性を重視するあまりテスト項目を増やし続けると、開発期間やコストが膨らみます。 反対に、納期を優先して必要な検証を省けば、本番障害や手戻りによって結果的に大きな負担が発生する可能性があります。 金融システムの開発では、納期を優先するあまり各工程の完了基準を満たさないまま次工程へ進まないことも重要な管理ポイントです。 そこで必要になるのが、 テストの量を増やすのではなく、リスクに応じて実施内容を最適化する考え方 です。 重大な影響につながる機能へ工数を集中させ、繰り返し確認する部分は自動化し、外部環境の待ち時間はモックなどで減らします。 さらに、「全ケースを消化したら終了」という管理から、品質基準と残存リスクを確認してリリース可否を判断する管理へ切り替えることも重要です。 これらを組み合わせることで、品質を犠牲にせず、限られた期間と人員の中でテストを進めやすくなります。 まずはリスクの高い機能から！優先順位を決めてテスト計画を作ろう テスト計画を作る際は、すべての機能を同じ深さで確認するのではなく、障害が発生した場合の影響と発生可能性を考えて優先順位を付けます。 たとえば金銭処理、本人認証、権限管理、個人情報、主要な外部連携、停止すると業務継続が難しくなる機能などは優先度が高くなりやすい領域です。 まず「 この機能が壊れた場合、顧客や事業に何が起こるか 」を整理し、その結果から必要なテストの種類と深さを決めます。 性能であれば許容する応答時間や処理件数、復旧であれば許容できる停止時間など、非機能要件についてもテスト前に合格条件を明確にしておきます。 要件とテストケースを対応付ければ、どの要件が確認済みで、どの部分が未確認なのかも把握しやすくなります。 また、ユーザー部門とシステム部門の認識差や要件漏れを後工程まで持ち越さないため、設計・開発の早い段階から品質確認を行うことが重要です。 リスクを先に決め、必要なテストを後から割り当てる 順番にすると、限られた工数を重要な確認へ使いやすくなります。 テスト自動化は「繰り返すもの」から始めよう！ テスト自動化では、「自動化率を高くすること」を目標にすると、作成や保守にかかる工数が増え、期待した効果が得られない場合があります。 まず候補にしたいのは、 何度も同じ条件で実行し、結果を機械的に判定できるテスト です。 たとえばAPIの基本的な正常系・異常系、回帰テスト、定型的なデータ検証などは、自動化によって繰り返し確認しやすくなります。 一方、仕様や画面変更が頻繁な部分、操作感や表示内容を人が判断する必要がある部分などは、手動テストのほうが効率的な場合があります。 CI/CD（継続的インテグレーション／継続的デリバリー）と自動テストを連携すれば、プログラム変更のたびに重要な確認を実行し、不具合を早い段階で発見しやすくなります。 セキュリティ領域でも、APIの代表的なリスクを対象とした自動テストの仕組みが整備されており、継続的な検証という考え方と相性があります。 ただし、 自動化はテスト設計の代わりではありません 。 重要なリスクが変化していないかを定期的に見直し、自動テストそのものも更新することが必要です。 外部環境の待ち時間を減らし、テストを前倒ししよう！ 複数企業やシステムが関わるFinTech開発では、「接続先がまだ完成していないためテストできない」という状況が起こりやすくなります。 外部APIの完成を待ってからテストを始めると、不具合の発見がプロジェクト終盤へ集中し、修正や再テストの時間を確保しにくくなります。 そこで活用できるのが、実際の接続先の代わりとなるモックやサービス仮想化です。 正常なレスポンスだけでなく、 タイムアウト、エラー、異常データ、応答遅延 などを意図的に返す環境を用意すれば、実サービスでは再現しづらい条件も早期に検証できます。 これにより、開発とテストを並行して進めやすくなり、外部環境が完成してから初めて連携不具合が見つかるリスクを減らせます。 ただし、仮想環境ですべての問題を再現できるわけではありません。 金融システムでは実際の接続条件を踏まえた接続テストも重要であり、過去の障害を踏まえて十分な接続テストを計画する考え方が示されています。 開発中は仮想環境で前倒しし、最終段階では本番に近い実環境で確認する という使い分けが効果的です。 「テスト完了」ではなく「リリースしてよい条件」を決めよう！ テストケースを100％実施しても、重大な不具合が残っていれば安全にリリースできるとは限りません。 一方で、軽微な表示上の問題が一件残っているだけで、必ずしもサービス全体を延期する必要があるとは限りません。 そのためリリース判断では、 テスト消化率ではなく、重要要件の達成状況、未解決不具合、性能・セキュリティの評価、残存リスク を組み合わせて確認します。 重大度ごとに未解決不具合をどこまで許容するか、性能や復旧能力をどの水準まで求めるかなどを事前に決めておくと、プロジェクト終盤で判断がぶれにくくなります。 未解決リスクを受容する場合は、内容と影響、代替策、判断者を記録し、後から経緯を確認できる状態にします。 金融システムの移行では、必要なテストやリハーサルなどを移行判定までに終え、安全性・安定性を踏まえた基準に沿って判断する考え方が重視されています。 つまり重要なのは、「予定していたテストが終わったか」ではなく、「 主要リスクが許容できる状態になり、その根拠を説明できるか 」です。 まとめ｜FinTechのシステムテストは「重要リスクから逆算」が成功のカギ！ FinTechのシステムテストでは、機能が仕様どおり動くことだけでなく、取引の正確性、API連携、データ整合性、性能、セキュリティ、障害復旧、規制・監査まで幅広く確認する必要があります。 特に金融サービスでは、システムの停止や誤作動、不正利用などが顧客や事業へ大きな影響を与えるため、安全かつ安定的な稼働を前提としてテストを設計することが重要です。 ただし、すべての機能を同じ密度でテストすると、工数や期間が膨らみます。 そこで、 重大障害につながるリスクから逆算して優先順位を決めること が、品質と効率を両立するポイントになります。 繰り返す確認は自動化し、外部環境を待つ工程はモックなどで前倒しすることで、重要な判断や探索的なテストへ時間を使いやすくなります。 また、障害対応や復旧計画は資料として整えるだけでなく、実際の訓練やリハーサルによって実効性まで確かめることが欠かせません。 最終的なゴールは「すべてのテストケースを消化した状態」ではなく、 主要なリスクを把握し、許容できる水準まで抑え、その根拠を関係者へ説明できる状態 です。 まずは開発中のサービスで障害が起きた場合に最も大きな損失につながる機能を洗い出し、7つの観点から現在のテスト計画に抜け漏れがないか確認するところから始めてみましょう。 QA業務効率化ならPractiTest テスト管理の効率化 についてお悩みではありませんか？そんなときはテスト資産の一元管理をすることで 工数を20%削減できる 総合テスト管理ツール「 PractiTest 」がおすすめです！ PractiTest (プラクティテスト) に関する お問い合わせ トライアルアカウントお申し込みや、製品デモの依頼、 機能についての問い合わせなどお気軽にお問い合わせください。 お問い合わせ この記事の監修 Dr.T。テストエンジニア。 PractiTestエバンジェリスト。 大学卒業後、外車純正Navi開発のテストエンジニアとしてキャリアをスタート。DTVチューナ開発会社、第三者検証会社等、数々のプロダクトの検証業務に従事。 2017年株式会社モンテカンポへ入社し、マネージメント業務の傍ら、自らもテストエンジニアとしテストコンサルやPractiTestの導入サポートなどを担当している。 記事制作： 川上サトシ （マーケター、合同会社ぎあはーと代表）

こんにちは、楽楽販売開発課のdon （頓花）です。 あるサブシステムをゼロから設計する機会があり、ADR（Architecture Decision Record／アーキテクチャ上の意思決定を記録するドキュメント）を書く場面が一気に増えました。 そこで Claude Code を検討プロセスそのものに組み込んでみたのですが、最初に作った仕組みは、実際に走らせてみるとひどいものでした。エージェントが 1 体で 約60分 動き続ける。工程の境界でユーザー確認が 20 回近く飛んでくる。レビューが 3 巡目に入ってもう何も新しい指摘が出ない。 この記事は、そこから何を直したかの記録です。 この記事で分かること 自分の検討プロセスを工程に分解して Skills に移植する手順 マルチエージェント構成で「全員が会話に参加し続ける」構成をやめた理由 前提情報をリポジトリに置いて AI に読ませる運用 動かしてみて初めて分かった、重い箇所の潰し方 【目次】 足りないのは AI の賢さではなかった 前提: 3 つの仕組みを使い分ける まず、自分が ADR を考える流れを分解する 工程をオーケストラ Skills ＋専門エージェントで構成 全員呼ばない、1 回に集約する 試行錯誤①: 全工程エージェントチームから、サブエージェントへ変更 試行錯誤②: 前提情報を AI が読める形に整理 試行錯誤③: ログを見て Skills 自体を改善 効果と、いまの課題 効果 課題 ADR 以外への応用 まとめ 参考リンク 足りないのは AI の賢さではなかった ADR に AI を使おうとすると下記のようなことがよく発生します。 ひとつは 単発チャット地獄 です。毎回ゼロから前提を説明し直す。「このプロダクトはこういう構成で、過去にこう決めていて……」と貼り直すだけで疲れて、本題に入る前に力尽きます。 もうひとつは 丸投げ です。「いい感じに ADR 書いて」で出てくるものは、形式は整っているのに検討が浅い。観点の抜け漏れが残り、レビューで結局やり直しになります。 どちらも AI の能力の問題ではありませんでした。足りていなかったのは、 自分の検討プロセスを AI が再現できる形にすること でした。 そしてこれは、単に開発が楽になるかどうかの話ではありません。AIへ委譲する割合を増やすことで並列で作業ができるようになり、開発速度を上げることができるようになります。 前提: 3 つの仕組みを使い分ける 本題ではないので手短に触れます。Claude Code には次の 3 つの仕組みがあります。 Skills : 「こういうときはこう進める」という手順書を Claude Code に持たせる仕組み サブエージェント（subagent） : タスクを独立したエージェントに渡し、結果だけ受け取る。呼ばれたときだけ動作するため、呼び出し元の文脈を汚さずに実施できる仕組み エージェントチーム（Agent Teams） : 複数のエージェントが互いにメッセージを送り合って議論する仕組み 。全員が会話に参加し続ける のが特徴 ※ 詳細は公式ドキュメントを参照: Skills ／ subagents ／ Agent Teams まず、自分が ADR を考える流れを分解する AI に渡す前にやったのは、 自分の頭の中の工程を言語化する ことでした。ここを飛ばして skills を書き始めると、結局「いい感じに」と書いてあるだけの手順書になります。 ADR 検討を、動詞ベースで次の工程に分けました。 前提固め → 計画 → 案出し →（検証）→ 独立評価 → 合議 → ドラフト化 →（実装） 工程 要否 やること 前提固め 前提・スコープ境界・完了条件をユーザーと対話して合意する。 既存の決定・仕様・API 定義もここで走査する 計画 この論点ではどの専門家を呼ぶか、どこまでやるかを決める 案出し 選択肢を出し、各案を最新の一次情報で詳細に調べる 検証 任意 判断に動作確認が要るなら、使い捨ての PoC を作る 独立評価 専門家が各自 独立に 案を評価する（あえて合議させない） 合議 出そろった評価をもとに方針を確定する ドラフト化 ADR 本体を書く 実装 任意 採用案を試しに実装する 設計時に気にした点は2点です。 先頭の「前提固め」で、人間の判断を最初に組み込む。 ここでスコープ境界と完了条件をこちらが合意します。後工程がいくら賢くても、前提がずれていれば的を外した ADR が出てくるだけです。 明確にステップを区切る。 これにより作業ごとにコンテキストを分けられるためトークンの節約やコンテキスト肥大化の抑制につながります。 工程をオーケストラ Skills ＋専門エージェントで構成 分解した工程を、ひとつの大きな Skills（オーケストラ役）が指揮し、工程ごとに専門エージェントを呼ぶ構成にしました。 編成は次のようになっています。読者のみなさんが自分のプロセスに置き換えるときの参照にしてください。 区分 体数 役割 モデル 指揮役 1 計画を立て、呼ぶ専門家を選ぶ 重め 調査・案出し役 1 前提の下調べと選択肢の整理 軽め 集約・執筆役 1 議論をまとめ ADR をドラフト 重め 検証役 1 使い捨て PoC（任意工程） 軽め 常駐レビュアー 1 全工程に伴走し観点を採点 軽め 反論役（Devil's Advocate） 1 必ず 1 件以上の反論・Blocker を出す 軽め 領域別の専門家 5 言語 2・DB・API 契約・Python 系 軽め 横断的な専門家 4 運用・インフラ・クラウド・セキュリティ 軽め プロダクト知見の専門家 1 既存プロダクトとの整合・移行・業務観点 軽め 横断ルールのチェックリストを常駐レビュアーの必須参照にし、逸脱を Blocker として報告させ、事例を追記して育てる循環 進行を指揮する役と、最後に決定をまとめる役だけ重いモデルを割り当てています。ここは判断の質が成果物に直結するためです。それ以外は軽いモデルで十分でした。 全員呼ばない、1 回に集約する エージェントを 16 体も定義すると、素直に組めばコストが爆発します。抑えるために入れた工夫が 4 つあります。 専門家を毎回全員呼ばない。 指揮役が論点を分類し、必要な数体だけ起動する。 （ex: DB の話が出てこない ADR に DB の専門家は不要なため起動しない。） 専門家の起動を 1 工程に集約する。 同じ専門家を案出しから実装まで何度も叩き直さず、独立評価の工程で 1 回だけ評価させます。 重いレビューはドラフト工程の 1 回だけにする。 別系統のレビューを挟むのは仕上げの手前だけです。 常駐の 2 体は工程ごとに起動して破棄する。 常駐レビュアーと反論役は全工程に伴走しますが、チームとして常駐させるのではなく、工程ごとにサブエージェントとして呼び直しています。 エージェントを増やすのは簡単ですが、実際に重いのは「どの工程で、どの論点のときに呼ぶか」を決める作業のほうでした。 試行錯誤①: 全工程エージェントチームから、サブエージェントへ変更 最初は 全工程をエージェントチームでやろうとしました 。 複数の専門家が議論しながら設計を詰める構成にしました。理論上はコンテキストも節約しながら進められる想定でした。 しかし、実際には全員が会話に参加し続けるので コンテキストが急速に肥大 し、評価が出そろう前から議論が混線するようになりました。それによりそれぞれの主張が曖昧になり、セッションが長くなりトークン消費量も増大しました。 （ Claude Code でMaxプランの5時間制限の30%近くを1セッションで消費しました。） そこで構成を切り替えました。 既定はサブエージェント方式 にする。独立に呼び出し、結果はファイルで受け渡す。 合議の工程も、まずは指揮役が評価を読んで直接まとめる 方式を既定にする。 エージェントチームは明示的に指定したときだけ 使う（重い論点で本当に対話が要るケース） 試しに同じタスクを比較すると、セッションの稼働時間が改善後（サブエージェント案）は改善前（エージェントチーム）の 約 1／3 になりました。 ※ ただしこれは 1セッションのみ での計測結果です。 得られた教訓は「マルチエージェント＝エージェントチームを常用する」ではなかった、ということです。 対話が本当に要る工程だけチーム、それ以外は独立したサブエージェント という使い分けが、コンテキスト効率に効きました。 もっともこれは私のケースでの結果です。エージェントチームの使い方を詰めれば別の最適点があるはずで、エージェントチーム自体が悪いという話ではないと考えてはいます。 試行錯誤②: 前提情報を AI が読める形に整理 手順（Skills）が良くても、 前提が無ければ検討は浅くなります 。専門家エージェントに「このプロダクトならこの方針」という前提が無いと、教科書的な一般論しか返ってきません。 そこで前提情報を 4 カテゴリに整理して、コンテキストとしてAIに明示的に渡すようにしました。 プロダクトの特性・大方針 既存の決定 : 決定済みのADR のリスト 横断ルールのチェックリスト : 承認済みの ADR で確定した設計判断のうち、議論で逸脱されやすい項目だけを 1〜数行に圧縮 調査方針 : 学習データの記憶に頼らせず、案出しのたびに最新の一次ソースの調査を必須化 3 番目のチェックリストは、実際の失敗から生まれました。 たとえばマルチテナントのデータ分離方式を「スキーマを分ける」と決めていたとします。ところがエージェントは、論点が変わるたびに「識別カラムを持たせる方式ではどうか」と提案してきます。一般論としては妥当な案なので、毎回それらしい理屈がついてきます。決定済みの前提が渡っていないと、こうした「もっともらしい差し戻し」が延々と発生します。 これを毎回人間が指摘して回るのは無理があります。そこで確定事項をチェックリストにまとめ、 常駐レビュアーと反論役の必須参照 にしました。逸脱を見つけたら Blocker として報告させる、という構造的な対策です。 このチェックリストは、逸脱事例を観測したら都度追記する運用にしています。最初から完璧なものは書けないので、育てる前提で置いています。 試行錯誤③: ログを見て Skills 自体を改善 Skills を書いて終わりにはできませんでした。実際に ADR を通して走らせ、ログを見て重い箇所を 1 つずつ潰しました。 実走で見えた問題 直した内容 単発で 約60分 動き続けるエージェント 出力件数・文字数・想定時間に上限を設ける 工程の境界でユーザー確認が 約20回 既定で自動進行にし、Blocker 検出時だけ停止する レビューが 3巡目 で空転 レビューは2巡までとし、超えたらユーザーに引き継ぐ 通しで走らせた後に「これ ADR で扱う話？」となる事故 冒頭に適格性ゲートを1問だけ置く とくに 2 番目は、自分で書いた Skills に「条件付き自動進行」と謳っておきながら、実際は毎境界で確認を飛ばしていたという間抜けな話です。動かしてみるまで気づきませんでした。 4 番目も同じです。ドラフトまで通した後に「これは ADR ではなく機能方針の話では？」と自分で疑問を持ってしまった。なので最初に「本件は ADR で扱うべきか」だけを 1 問聞き、そうでなければ別の進め方を提案して終わる、というゲートを置きました。 ここで狙ったのは平均時間の短縮ではなく、 極端に重いケースを抑えること です。約 60 分動き続けるエージェントが 1 体いれば、平均がどうであれ体験は破綻します。 効果と、いまの課題 効果 体感として得られたものは 3 つあります。 前提の貼り直し回数が低減 毎回の説明から解放され、検討の中身に時間を使えます。 浮いた時間は、業務課題そのものを理解する側に回せるようになりました。 観点の欠落が低減 反論役が必ず 1 件以上の反論を出すので、後工程で気づいて手戻りする回数が減りました。 AI同士の議論が建設的に 変更前はAI同士の議論が追認会になることがありましたが、 独立評価 → 合議の順にしたことと、合議には反対の立場を持つメンバーを必ず 1 名入れるようにしたことにより建設的な議論になった。（気がします。） 課題 一方で課題も残っています。 効果は体感どまりで、定量的な比較ができていない 前提チェックリストや上限設定の効果は、再実走で検証待ち ADR 専用で、機能要件や詳細設計は対象外 ADR 以外への応用 ここまで ADR を例に書きましたが、同じ型は「検討プロセスを持つ仕事」全般に使えるはずです。実装設計、技術選定、障害の振り返りなど、頭の中に工程がある仕事ならどれも当てはまります。 共通する型はこうです。 プロセスを分解する → 工程を Skills 化する → 前提を AI が読める形にする → 対話が要る工程だけチームにする まとめ AI に丸投げするのでも、単発質問を繰り返すのでもなく、 自分の検討プロセスを移植する 。これが今回いちばん効いた考え方でした。 AI に任せる範囲を広げることが AI ネイティブな進め方だと思っていましたが、実際は逆でした。 人が判断する場所を先に決めるほど、残りを安心して任せられる 。冒頭に「前提固め」を置いたのは、まさにそのためです。 最初の一歩は Skills を書くことではありません。 まず自分が普段どう考えているかを書き出してみること です。 それを Skills に移植し、試し、改善していくことによってAIによる効率化を進めていくことができると思います！ 参考リンク Claude Code 公式ドキュメント Extend Claude with skills Create custom subagents Agent teams