forge

[製品概要]

Forge（フォージ）は、監査調書を作成の段階から保管の段階まで一貫して扱う電子調書システムです。ファイルを置く場所ではなく、調書が作られ、査閲され、審査を受け、監査報告書の発行後に閉じられるまでの一連の過程を、そのまま記録として残すことを目的としています。作成・投入・保管・照合・査閲・閲覧のすべてが閉域内で完結し、データが外部へ送信されることはありません

Forgeは調書を上書きしません。差し替えられた古い版も、いつ誰が何をしたかの記録も残り続けます。監査報告書の発行後に閉じたものを、解除して開き直すことはできません。

Forgeは鍛冶場を意味します。金属を熱して形を作り、火から下ろして冷ますと、二度と動かせなくなる。監査調書も同じです。作成中は何度も手が入りますが、ある時点から先は動かしてはならない。その切り替わりを「運用の心がけ」ではなく「仕組み」として持たせる。モジュールの名はここから採りました（現在は研究開発・内部検証の段階にあります）。

[開発背景]

監査調書は、電子調書システムや共有フォルダで管理することが一般的です。しかし標準的な使い方のままでは、編集のたびに前の版が置き換えられ、なぜ差し替えたのかは残らず、査閲や審査のやりとりは別のエクセルやメールに散らばります。

整理期間が過ぎた後に調書を閉じる作業も、多くは手動の運用に委ねられています。誰かが閉じ忘れれば、その監査は開いたままになります。

実務は、ファイル名の末尾に日付を付ける、旧版フォルダへ退避させる、査閲の記録を別表で管理するといった工夫で補われています。いずれも正しい対応ですが、工夫である以上、誰かが手順を守らなかった時点で失われます。必要なのは、注意深く運用することではなく、注意深くなくても記録が残る仕組みです。

[Forgeの3つの特徴]

① 上書きをしない ― 直したファイルをそのまま投入すれば、それが新しい版になります。前の版は消えず、実体ごと残ります。差替えを行うときは理由の記入を必須としているため、どの版が、いつ、なぜ差し替えられたのかが履歴から分かります。物理削除は行いません。

② 記録を消させない ― 誰がいつ何をしたかの操作記録がログとしてすべて残ります。ログは書き加えられるだけで、後から書き換えることも消すこともできません。データベースの権限として更新と削除を与えていないことで担保しています。管理者であれば消せる、という抜け道を作らないこと。これがForgeの記録に対する考え方です。

③ 期限が来たら閉じ、閉じたものは触らせない ― 監査報告書日を入力するとそこから整理期間が始まり、期限を過ぎたエンゲージメントは調書ごとロックされます。ロックの解除は機能として実装していません。監査報告書の発行後に追記が必要となった場合は、原本を変更せず、追記調書として新しい調書を積みます。

[画面イメージ ]   ※  画像はイメージであり、実際の表示とは異なる場合があります。また法人名や人名は架空のもので実在するものではありません。

① 全体構成   

調書は、クライアント、エンゲージメント（会計年度）、ジョブ、勘定区分の四つの階層の下に置かれます。ジョブは監査契約、監査計画、期中レビュー、期末監査（会社法）、期末監査（金商法）の五種類で、審査はジョブごとに一度行います。実際の監査業務がこの単位で進み、監査報告書もこの単位で発行されるため、システム上の単位を実務の単位に一致させています。

調書の状態は、作成中から査閲待ち、査閲中、査閲済み、審査中、審査済みへと進みます。画面では、勘定区分とステータスで絞り込みながら、どの調書が今どの段階にあるかを一覧で確認できます。

未完了の調書が残っている間は、次の段階へ進めません。査閲を通っていない調書が残っていれば審査に回すことはできず、その件数と内訳を画面に表示します。

② 操作記録の完全把握

誰がいつ何をしたかの操作記録は、ログとしてすべて残ります。ログは書き加えられるだけで、後から書き換えることも消すこともできません。データベースの権限として、記録用のテーブルに更新と削除を与えていないことで担保しています。

画面は、ジョブの監査タイムラインです。調書の作成から査閲、審査、監査報告書日の入力、そして期限超過による強制ロックまでが、ひとつの時系列に並びます。監査の過程に時間的な矛盾があれば、この記録に現れます。

管理者であれば消せる、という抜け道を作らないこと。これがForgeの記録に対する考え方です

③ 整合性スイープ

Forgeは、投入された時点でファイルの中身から算出した値（SHA-256）を記録しています。保管領域にあるすべての実体を復号して計算し直し、この記録と突き合わせれば、外から手を加えられたファイルは必ず一致しません。

ふだんの照合はファイルを開いたときに走るため、一度も開かれていないファイルは投入時の判定のままです。その空白を埋めるのがこの一括照合で、Forgeでは整合性スイープと呼びます。異常が疑われたときだけでなく、監査報告書の発行前など、任意の時点で実行できます。

別領域へ移した前期の調書についても、移送時に両側で保持したダイジェストを同じ手続で確認します。当期と前期を分けずに、保管しているもの全体を一度に洗うことができます。実行者と日時と件数は実行記録として残り、後から取り消すことはできません。

不一致が見つかった調書は、その時点から先へ進めなくなります。原因を確認して決着させるまで、査閲や審査に回すことはできません。

⑤ ロック後の追記調書

Forgeにロックの解除機能はありません。実装していないため、操作としても存在しません。

極めて例外的ではありますが、監査報告書の発行後に追記が必要となった場合は、追記調書として新しい調書を積みます。このとき原本には一切書き込みません。追記の処理が書き込むのは追記調書の行と、新しく投入されたファイル、そして操作の記録だけです。原本のファイルも、その記録された値も、一文字も変わりません。

追記できるのはマネージャーに限られ、理由の記入を必須としています。追記調書自体も後から編集や削除ができません。添付したファイルは、外へ出すことなく画面で確認できます。閉じた監査に例外的に手を入れる唯一の口を、狭く、記録の残る形で開けています。

[セキュリティ・閉域データフロー] 

Forgeは「データが外に出ない」ことを、設計だけでなく実装のレベルで担保することを目指しています。アプリケーション本体のコードに、外部へデータを送信する処理は存在しません。作成・投入・保管・照合・査閲・閲覧のすべてが閉域内で完結します。

1 調書を作る ― ジョブと勘定区分の下に調書の枠を作り、担当者を決める

2 ファイルを投入する ― 投入された実体からSHA-256を計算して記録する。同名なら差替え、別名なら追加として、新しい版を作る

3 暗号化して保管する ― ファイルごとの鍵で暗号化し、その鍵をさらに別の鍵で保護して格納する

4 査閲・審査を受ける ― 査閲メモと審査指摘を版ごとに残し、未対応が残っている間は次の段階へ進めない

5 取り出す ― 権限を判定し、記録したSHA-256と再計算した値が一致した資料だけを画面に表示するか、手元に取り出す

6 閉じる ― 監査報告書日から整理期間を算出し、期限を過ぎたエンゲージメントを配下の調書ごとロックする

7 記録する ― 作成・投入・遷移・閲覧・ロック・追記を、追記のみの記録として残す

保管領域の全ファイルを復号して再計算し、投入時に記録した値と突き合わせる整合性スイープを、任意の時点で実行できます。前期調書として別領域へ移した資料についても、移送時のダイジェストを両側で保持しているため、同じ方法で確認できます。

暗号化の鍵はサーバー側でのみ扱い、画面側には渡しません。ファイルの読み書きはすべてアプリケーションサーバーを経由し、ファイル共有などによる保管領域への直接のアクセスは、権限の判定と記録を迂回するため、設計として認めていません。

データベースは実行端末内、または閉域のオンプレミスサーバーに置きます。クラウドと同期される場所には保存しません。Forgeは大規模言語モデルを用いないため、導入後の運用にインターネット接続を要しません。

保管されるファイルはForge自身が暗号化して格納するため、保管領域のファイルをそのまま取り出しても中身は読めません。OSやディスクの暗号化（BitLocker等）との併用も可能です。

［詳細資料］

Forgeの設計思想、セキュリティ・閉域データフロー、技術仕様、AxiomCubeシリーズ全体での位置づけなどを、製品紹介PDFで詳しくご紹介しています。

▶ 製品紹介 PDF を見る（※ 本 PDF は研究開発中のソフトウェアを紹介する資料であり、営業資料ではありません。）

Trust by Architecture 

信頼を、構造からデザインする 

ホームに戻る