安全なファイル共有システム

01FIRST OF ALL

はじめてこのページに来てくださった方へ

私たちは、このシステムをまず自分たちが使うために作りました。実際に動かして整えたうえで、みなさまにご紹介しています。お客様ごとに、環境や運用に合わせてカスタマイズしてご提供します。

01検証を積み重ねています

実機での検証プロセスで、合計 242 件のテストをすべて通過しました（失敗・保留はゼロ、製品側の不具合もゼロ）。確認の証跡は 273 枚、一件ずつ画面を残しています。脱・パスワード別送の中核となる「発行 → 受領 → ダウンロード」が実機で端から端まで成立することを確かめ、受け取ったあとにダウンロード回数が正しく一つ増えるところまで、実際のデータで検算しました。
02自分たちが最初の使い手です

本システムは、まず自社（Leapcom）自身が使うために開発しました。設計から実装まで、一貫して自社で手がけています。
03お客様に合わせてご提供します

お客様ごとに、環境や運用に合わせてカスタマイズしてご提供します。クラウド専用の SaaS ではなく、ご利用の環境に構築してお届けする形です。
04積み重ねた開発力の上に立っています

製造業をはじめ、長年の受託開発で培った基盤の上に構築しました。積み上げた仕組みを別の課題へ活かす進め方は、開発事例や会社情報でもご覧いただけます。

02THREE FEATURES

3 つの特長

FEATURE 01

PPAP を"名ばかりでなく"本当に廃止する認証設計

受け取りは、毎回のメール確認コードでの本人確認（本人性）、あて先の二重の絞り込み（ファイルのあて先＋その案件への参加）、公開期限、ダウンロード回数の上限。この四つをすべて満たしたときだけ通す設計です。ふだんの共有パスワードの別送そのものをやめたので、以前の PPAP 運用が知らぬ間に戻ってしまうこともありません。
FEATURE 02

「会社 × 担当者 × 案件」を、正式なデータの形として持つ

お取引先を、会社（Partner）＞担当者（PartnerContact）＞案件（Project）の三階層で、そのまま持ちます。さらに案件の期限とファイル一枚ごとの期限を、別々にかけられる「二層の期限」を備え、「案件はまだ続くけれど、この一枚だけ早めに締めたい」という現場の感覚に、素直に重なります。
FEATURE 03

権限・期限・監査ログを、標準で厚く（追加費用なし）

社内は管理者／担当者の二段階の権限、お取引先の担当者は「割り当てられた案件の、自分あてのファイル」だけが見えます。誰が・いつ・何を（閲覧／ダウンロード／アップロード）したかは、操作履歴（監査ログ）に標準で記録されます。あとから上位プランで足す機能ではなく、最初から入っている土台です。

受け取りは、4 つの条件をすべて満たしたときだけ受領のたびに、4 つの条件をすべて評価します。ふだんの共有パスワードの別送は、廃止しました。

1

確認コード

毎回、メールの確認コードで本人を確認
2

あて先の二重の絞り込み

ファイルのあて先＋その案件への参加
3

公開期限

期限が来たら、自動で締まる
4

回数の上限

上限に達したら、失効
受け取れる

解凍もパスワード探しもいりません

03USE CASES

こんな場面で

お取引先とのファイルのやり取りに、こんな場面はないでしょうか。攻めるためではなく、「よくある困りごと」として並べます。

NOWパスワードの別送と、解凍のお問い合わせ見積書や図面、請求書を送るたびに、パスワードを別のメールで送るひと手間がかかる。受け取った側からは「解凍できない」というお問い合わせが返ってくることもある。

WITH THIS SYSTEM安全な共有リンクでお渡し。受け取る側は、その場の確認コードだけ。解凍もパスワード探しもいりません。
NOW「会社・担当者・案件」の感覚とのずれ取引先とのやり取りは、頭のなかでは自然と「あの会社の・あの担当の方の・あの案件の」という形で整理されている。けれども多くのツールでは、それをフォルダやグループに置き換えて持たなければならず、業務の感覚とすこしずれてしまう。

WITH THIS SYSTEM会社＞担当者＞案件を、いつもの捉え方そのままの形で持ちます。
NOW社外向けの、きめ細かな調整「このお取引先の方はログインできてよいか」「この監査記録はいつまで残すか」といった社外向けのきめ細かな調整を、必要なぶんだけ効かせたい（既製のサービスでは、上位プランの追加機能になりがちなところです）。

WITH THIS SYSTEMお取引先の担当者がログインできるかどうかは、自社側でいつでも切り替え。監査ログも、標準の機能として最初から。
NOW版数・受け渡し履歴の管理大きな図面の版数や、「誰に・いつまで渡したか」を、メールの記憶をたどりながら管理している。

WITH THIS SYSTEM誰が・いつ・何をしたかは操作履歴に。期限は、案件とファイルの二層で一望できます（ファイルのバージョン管理は予定）。

パスワードを別送して大切に届けるやり方は、長く多くの職場で使われてきた、まじめで丁寧な習慣です。その丁寧さはそのままに、渡す側と受け取る側の手数だけを減らせないか。そこが、私たちの出発点でした。

04HOW IT WORKS

仕組み・技術（どう動くか）

基盤は、ASP.NET MVC／C#／.NET 10 ＋ SQL Server で構築する Web システムです。クラウド専用の SaaS ではなく、自社で構築・運用する形態でお届けします。

STEP 1 ・社内

発行する

期限・回数・必要なら発番パスワード

STEP 2 ・通知

共有通知メール

推測されにくい共有リンク（パスワードは送らない）

STEP 3 ・お取引先

確認コードで受け取る

4 つの条件を、受領のたびに評価

STEP 4 ・記録

操作履歴に残る

誰が・いつ・何を（追記専用）

なぜこの構成にしたのか。パスワードを"同じメール経路で別送する"こと自体が、PPAP のいちばんの弱点でした。だから、それを廃し、別の経路のログイン（メールの確認コード）＋あて先の限定＋期限＋回数＋監査で上回ることを目標にしています。

技術的な見どころ（本製品の核＝セキュリティ設計）

01

完全パスワードレスのメール OTP 認証

確認コードをメールでお送りし、入力していただいて本人確認する、社内メンバーもお取引先担当者も共通の、唯一のログイン手段です。利用者はパスワードを覚える必要も、入力する必要もありません。
02

推測されにくい共有リンク

外部に出る共有 URL の識別子は、内部の主キーとは切り離した暗号論的な乱数（128 ビット以上・ハッシュにして保管）で作ります。URL を順に試して他人のファイルを探し当てる、といったことを防ぎます。
03

「存在するかどうか」も漏らさない中立設計

「対象が無い／権限が無い／他人あて」を、画面の見た目・応答・文言で区別できないようにしています。他人の ID を差し込んでのぞこうとする操作（4 つの経路）で、外から見える反応がすべて一致することを、実機で確かめました。
04

秘密情報を、構造として載せない

共有パスワードや確認コードの平文は、通知メールにもログにも監査記録にも一切載せません。パスワードは元に戻せない形へ多層に変換して保管し、仮にデータベースだけが漏れても中身を取り出せない形にしています。
05

たどれるエラー処理

利用者に起因するものと、システムに起因するものを型で分け、日本語のカタログで一元管理します。システムエラーの画面には相関 ID を表示し、内部の記録と同じ ID で、その一回のやり取りを追えるようにしています。
06

すべての操作部品に目印を付け、機械で厳しく検証

画面のすべての操作部品に安定した id を付け、ブラウザの自動テストと境界値テスト（文字数の ±1、件数の ±1、サイズ上限ちょうど／超過、回数の下限・上限・範囲外、試行上限の直前・到達など）を徹底しています。

05CAPABILITIES

できること（機能一覧）

専門用語をなるべく避けて、実際にできることを並べます。いまご提供できる機能を軸に、これから広げていく機能は分けてお示しします。

ログイン・本人確認

メールの確認コード（OTP）でのログイン（全利用者に共通の、唯一の手段）
お取引先担当者のログイン／ログアウト
ログインできるかどうかの反映（オフにした担当者はログインさせない）
ログイン試行の保護（続けて失敗したときのロックなど）

社内メンバーの管理

メンバーの登録／一覧・検索／編集
権限の設定（管理者／担当者の二段階）
メンバーの無効化（論理削除）／自分のプロフィール編集

お取引先（会社）の管理

取引先の登録／一覧・検索／詳細（会社・担当者・案件をまとめて表示）／編集／無効化

お取引先担当者の管理

担当者の登録（1 社に複数可）／一覧／編集
ログインできるかどうかの設定（自社側でいつでも切替）
担当者の案件への割り当て／担当者の無効化

案件（プロジェクト）の管理

案件の登録／一覧／詳細／編集
案件の期限設定（二層の期限の、案件側）／案件担当者の紐付け／案件のクローズ

共有ファイルの管理

ファイルのアップロード／一覧／ダウンロード
ファイルの期限設定（二層の期限の、ファイル側）
期限が来たら自動で締まる状態遷移（グレーアウト＋バッジ表示）
ファイルの論理削除／お取引先からのアップロード（双方向）
猶予期間のあとの実体削除（メタ情報・ログは残す）

共有リンク・通知

共有リンクの発行（期限・回数・機密時パスワードの土台）／有効期限／アクセス回数の上限
高機密文書向けの自動発番パスワード（発行時にオプトイン）
共有通知メール／リンクの失効・無効化／リンクの再発行

操作履歴・監査

アクセスログの記録（閲覧・ダウンロード・アップロード）／会社・案件の軸での閲覧／検索・絞り込み

支える土台

社内向け／社外向けのダッシュボード
エラー処理・メッセージ管理／メール送信の基盤／期限を見張るバッチ

これから広げていく機能予定

お取引先担当者への招待メール（初回ログインのご案内）
ファイルのバージョン管理
ログの外部エクスポート／外部システムとの API 直結

06THE CORE

評価のポイント：検証の徹底

ファイル共有の評価のポイントは、読み取り精度のような％ではなく、「どれだけ丁寧に作り込み、確かめたか」に表れると、私たちは考えています。

242件

実機テスト全通過（PASS 242／242）

273枚

確認の証跡（スクリーンショット）

5系統

正常 68／エラー系 133／新端末検知 6／契約書級 PW 15／受領 PW 短縮 20

作り込みの事実として

実機での検証プロセスで、合計 242 件のテストをすべて通過しました（PASS 242／242＝100%・失敗・保留はゼロ・製品側の不具合もゼロ）。証跡のスクリーンショットは 273 枚。5 つの系統（正常な流れ 68／エラー系 133／新しい端末の検知 6／契約書級パスワード 15／受領パスワードの短縮対応 20）に分けて実施しています。
加えて、実装フェーズの自動テストは、単体で 800 本超・結合で 130 本超がすべて緑、ビルドは警告ゼロ・エラーゼロです。
脱・パスワード別送の中核フロー（発行 → 受領 → 実ダウンロード）が、決められた検証データのうえで端から端まで成立することを、実機で確かめました。受け取ったあとにダウンロード回数が実際のデータベースで正しく一つ増えるところまで、検算しています。
セキュリティの面も確かめました。境界値の拒否、存在を漏らさない中立化、他人の ID を差し込む操作（4 経路）で外から見える反応が一致すること、受領パスワードの試行上限に達したら中立的に失効へ移すこと、そしてよくある攻撃や内部エラーで秘密が漏れないこと。いずれも実機で確認済みです。

これは「業務がどれだけ減るか」という効果の数字ではなく、「ここまで丁寧に確かめた」という作り込みの事実です。まず自社で使うために作り、設計から実装まで一貫して手がけました。お客様の環境に合わせてカスタマイズしてご提供します。

07SCREENS

画面イメージ

実際の操作画面のイメージです。ブランド表記を伏せた状態のモックで、実データの写り込みはありません。

社外のファイル受領画面のイメージ: その場の確認コードで受け取る — 受け取る側は、その場の確認コードだけ。パスワードを探す手間はありません。

案件詳細画面のイメージ: 会社・担当者・案件と、二層の期限を一望できる — 会社・担当者・案件を、いつもの捉え方そのままに。二層の期限も一望できます。

08SPECIFICATIONS

スペック表

事実のみを記載します。実装済みは断定で、これから広げる機能は「予定」、設計上の値・運用で調整する値は「設計値」「設定値」と明記します。

共通仕様

提供形態	自社構築・運用型の Web システム（ASP.NET MVC／C#／.NET 10 ＋ SQL Server）。クラウド専用 SaaS ではなく、ご利用の環境に構築して運用する形態。
動作環境	Web ブラウザ（サーバは .NET 10 ＋ SQL Server）。検証は Chromium（1440×900・ja-JP）で自動テストを実施。最新の主要ブラウザ（Chrome／Edge／Firefox／Safari など）での利用を想定しています。
認証方式	完全パスワードレスのメール OTP（確認コード）。社内メンバー・お取引先担当者に共通。多要素認証・Entra ID 連携は予定。
OTP の仕様	再送の上限・時間の窓による保護あり（例：5 分の窓で 5 回までの運用を検証）。コードの桁数＝6 桁、有効期限＝5〜10 分は設計値（設定で調整）。設計値
通信の暗号化	TLS（運用の前提として必須）。
保管時の暗号化	保管時（保存されたデータ）の暗号化は、これから対応する項目です。保管方式の確定にあわせて整えます。将来
アクセス制御の粒度	社内＝管理者／担当者の二段階の役割＋案件ごとの行レベルの認可。社外＝会社×担当者×案件＋あて先の二重絞り込み（下記・固有仕様）。
監査ログ（記録すること）	誰が（利用者・種別）・いつ（UTC）・何を（ログイン／閲覧／ダウンロード／アップロード／共有／失効／期限到来など）・対象・IP・結果。追記専用（更新・削除の API を持たない）・全保持（自動では消さない）。
監査ログ（記録しないこと）	共有パスワードの平文・確認コードの平文・生の共有トークンは記録しない（ハッシュや ID で参照）。
データの送信（外部）	外部サービスへのファイル・データの送信は行わない（自社構築・運用型）。AI による学習利用もなし。
データの保持期間	監査ログ＝全保持（自動では消さない）。ファイルの実体＝論理削除 → 猶予後に実体削除（メタ情報・ログは残す）。猶予の日数は運用で設定。設定値
データの所在	自社が構築・運用する環境内（自社保有）。
外部連携（出力・API）	現状はシステム内で完結（下の「連携・API」参照）。外部 API 直結は予定。
サポート・提供体制	スクラッチ開発の案件として提供（「導入までの流れ」参照）。料金は非掲載＝要相談。

安全なファイル共有固有仕様

ファイルサイズ上限	単一ファイル 100MB／1 回の合計 300MB／件数 20 件（0 バイトは拒否）。取込のゲートで検証。設定値
対応形式の検証	拡張子のホワイトリスト＋MIME＋ファイル先頭のマジックバイトの三重チェック＋危険なファイル名の無害化。許可する拡張子は、運用に合わせて設定します（設定値）。
ウイルススキャン	非同期のスキャンを実装（未スキャン／Pending・Clean・Infected の状態を保持し、Clean と確定するまで配信しない）。スキャンエンジンは、ご利用の環境に合わせて構成します。
期限制御（二層）	案件の期限 × ファイルの期限の二層。案件は継続したまま、特定のファイルだけ先に締められる。
アクセス回数の上限	共有リンク単位で最大ダウンロード回数を設定。ダウンロードのたびに数え、上限に達したら失効。同時にダウンロードが重なっても超過しない、条件付きの確実な更新。
パスワードの自動発番	既定の共有では付けない（ふだんのパスワード別送を廃止）。契約書級の高機密文書に限り、発行時のオプトインで自動発番。
発番パスワードの形式	契約書級＝「S＋5 桁の数字」（例 S49271・口頭で伝えやすい形式）。桁数は設定で調整。設定値
発番パスワードの強度補償	元に戻せない形への多層のハッシュ化（データベースだけの漏えいでは解読不能）＋受け取る方ごとのロック（一人の打ち間違いで全員が締め出されない）。
受領時の試行制限	受け取る方ごと（リンク×担当者）に試行上限＋クールダウン（例：5 回で 15 分ロック・自然に回復・受領成功でリセット）。設定値
権限段階	社内＝管理者／担当者の二段階。お取引先担当者＝割り当てられた案件の、自分あてのファイルのみ。
受け渡しの方向	社内 → 社外の配布と、社外 → 社内のアップロード（双方向）。
相手先のモデル	会社（Partner）× 担当者（PartnerContact）× 案件（Project）の三階層を、正式なデータの形として保持。
あて先の絞り込み	二重の絞り込み＝ファイルのあて先＋その案件への参加。両方を満たす方だけが受領可。
共有リンクの失効・再発行	途中での失効・再発行に対応（再発行時は設定を引き継ぐ）。
新しい端末の検知	見慣れない端末からのログイン成功を検知し、ご本人と自社のご担当（独立した観測者）の双方に通知（検知に特化・毎回の確認コードは維持）。
ファイル実体の保管	データベースの外・Web から直接は見えない領域に、サーバーが生成する推測できない名前で保存。配信は必ずアプリを経由したストリーム（ダウンロード指定・キャッシュ無効・内容の推測防止）。

09SECURITY & DATA

セキュリティとデータの取り扱い

「大切なファイルを預けたら、それはどこにあって、誰が触れられるのか」。このお気持ちに先回りして、認証・アクセス制御・受け取りの安全対策・監査・データの行き先までを、抜けなく事実でお示しします。

認証（パスワードレス OTP）

パスワードは存在しません。社内もお取引先も、メールの確認コード（OTP）で、毎回その場で本人確認します。パスワードを覚えたり、別送したりする必要がありません。（内部で使う仕組み上のパスワードは、利用者には見せず、システム内部でのみ保持します。）

アクセス制御（会社 × 担当者 × 案件）

会社×担当者×案件に、社内の管理者／担当者の二段階を重ねます。お取引先担当者が見られるのは、あて先の二重絞り込み（ファイルのあて先＋その案件への参加）を満たす、自分あてのファイルだけです。お取引先担当者がログインできるかどうかは、自社側でいつでも制御できます。

受け取りを守る、多層の安全対策（脱 PPAP の要）

受け取りは、「確認コード（本人性）× あて先の二重絞り込み × 公開期限 × ダウンロード回数の上限」を、受領のたびにすべて満たすか評価します。ふだんの共有パスワードは廃止し、この多層の条件で上回ることを目標にしました。

監査ログ（記録すること・しないこと）

記録すること 誰が・いつ・何を（閲覧／ダウンロード／アップロードなど）したかを、追記専用・全保持で記録します。
記録しないこと 共有パスワードの平文・確認コード・生の共有トークンは記録しません（構造として排除しています）。

データの送信・保持・所在・学習利用と、通信・保管の暗号化

送信外部サービスへのファイル・データの送信は行いません（自社構築・運用型のため）。AI による学習利用もありません。
保持監査ログは全保持。ファイルの実体は、論理削除のあと猶予期間を置いて実体削除します（メタ情報・ログは残します）。
所在自社が構築・運用する環境内（自社保有）です。
提供形態 自社構築・運用型です。製品名・ロゴ・画面の色は、設定で差し替えられる形にしてあります。共有パスワードの桁数やロックの回数・時間も、設定で調整できます。
通信と保管の暗号化 通信は TLS（運用の前提として必須）で保護します。保管時（保存されたデータそのもの）の暗号化は、これから対応する項目としています。いまは、通信の TLS 保護に加えて、ファイルの実体をデータベースの外・Web から直接は見えない領域に、推測できない名前で保管し、配信は必ずアプリを経由したストリームで行うという、実装済みの多層の安全対策で、お預かりのファイルを守っています。

10SCOPE

対応範囲

「うちのファイル、送れる？」にすぐ見当をつけていただけるよう、具体的に並べます。

対応ファイル: 拡張子のホワイトリスト方式（許可された形式だけを受け入れ）。基本的にどんなファイルも想定していますが、危険な拡張子・多重の拡張子・危険なファイル名は、無害化または拒否します。許可する拡張子は、運用に合わせて設定します（設定値）。
サイズ上限: 単一ファイル 100MB／1 回の合計 300MB／件数 20 件／0 バイトは拒否。設定値
受け渡しの方向: 社内 → 社外の配布と、社外 → 社内のアップロード（双方向）。
出力・連携: 共有リンク経由のダウンロード（アプリを経由したストリーム配信）。監査ログはシステム内で閲覧・検索できます。ログの外部エクスポート・外部 API 連携は予定。
動作環境: サーバは ASP.NET MVC／C#／.NET 10 ＋ SQL Server、クライアントは Web ブラウザ。最新の主要ブラウザ（Chrome／Edge／Firefox／Safari など）での利用を想定しています。

API

連携・API

システム内で完結（実装済み）: 共有リンクの発行 → 通知 → 受領 → ダウンロード、そして監査ログの閲覧まで、システムの中で一つの流れとして完結します。
メール送信の基盤（実装済み）: 確認コード・共有通知・招待のためのメール送信を、共通の基盤として持っています。差出人は固定、SMTP 経由で、秘密情報は焼き込まず、起動時のガードで守っています。
API 直結・ログの外部エクスポート: 外部システムへの API 直結と、ログの外部エクスポートは予定です。
お取引先担当者への招待メール: 初回ログインのご案内メールは、これから広げていく機能です（現状は発行まで）。

11A NEUTRAL VIEW

他社との比較（公開情報にもとづいて）

発注先を見極めるうえで、他社との位置づけも気になるところだと思います。ここでは優劣を断じず、他社が公開している情報にもとづいて、中立に整理します。

観点	一般に、既製のサービスでは	本システムでは
会社・担当者・案件の扱い	取引先ごとのグループ、外部アカウント＋あて先＋グループ、ユーザー・グループ・フォルダ等で表現することが多い	会社＞担当者＞案件を、正式なデータの構造として保持
共有リンクの安全策	期限＋パスワード（自動発番・必須化）などを提供	期限＋回数＋（機密時のみ）自動発番パスワードを標準。ふだんのパスワード別送は廃止
期限の持ち方（二層）	ファイル期限＋アカウント／所属期限、リンク期限＋アクセス権期限など	案件の期限＋ファイルの期限の二層を標準
社外向けの制御・許可設定	承認・ログ延長・許可ドメイン等が、上位プランやオプションになりがち	標準の機能として、最初から
操作履歴（監査ログ）の項目数	200〜250 項目超と、非常に充実した製品もある	会社／案件の軸で標準記録（項目数の網羅では、既製の大手が上回る場合があります）

他社が公開している値の例（中立の参照）：DirectCloud＝保存 AES-256／通信 SSL 256bit・全プランでウイルスチェック標準／GigaCC＝SSL・TLS・ウイルスチェック・2 要素認証を全プラン標準／Proself＝サーバー上でのファイル暗号化保存・Gateway Edition で拡張子制限や上長承認など。（各社の公開情報より・2026-07 時点の概算）

網羅の広さでは、既製の大手サービスが上回る面もあります。私たちが目指すのは、取引先とのやり取りを頭の中の捉え方そのままの形で持ち、脱 PPAP の安全対策を標準で厚くした、「会社と会社の業務に、ちょうど合う」設計です。

※ この比較は検討用の整理です。各製品は上位プランや追加オプションで、本表以上の機能を備える場合があります。掲載値は各社の公開情報にもとづく概算で、2026 年 7 月時点のものです。

12DESIGN RATIONALE

なぜ、この設計にしたのか

デモでいちばんお見せしたいのは、機能そのものより「なぜこう作ったか」です。少し長くなりますが、「PPAP を、名ばかりでなく本当に廃止する」ための再設計の物語を、お伝えします。

出発点：弱点は「同じ経路で別送すること」だった

パスワードを"同じメール経路で別送する"こと自体が、PPAP のいちばんの弱点でした。メールを見られてしまえば、ファイルもパスワードも同じ場所にある。だから、安全な共有リンクでファイルを渡し、本人確認は別の経路のログイン（メールの確認コード）で行う。ここまでは、素直な出発点でした。

気づき：「共有ごとにパスワードを別送」を残すと、PPAP は再発する

ところが、「共有のたびにパスワードを付けて別送する」運用を残してしまうと、結局 PPAP がそのまま戻ってきてしまうことに気づきました。お取引先の担当者は、いくつもの案件に関わります。案件をまたいで事前に共有するパスワードは、形だけのものになりやすく、安全の価値もそう大きくありません。ここを直視して、受領の認証そのものを、三段階に分けて作り直しました。

1

ふだんの共有パスワードを、廃止する

本人であることは確認コードが、あて先はファイルのあて先とその案件への参加の二重の絞り込みが担保します。だからパスワードは、契約書級の高機密文書に限った、発行時のオプションへと位置づけを変えました。
2

見慣れない端末の検知と、お知らせ

便利さのために本人確認を省く「信頼済みの端末」は、あえて採用しませんでした。パスワードレスの下では、端末に持たせる目印が単独で長く効く資格になってしまい、認証が弱るからです。代わりに、"見慣れない端末からのログイン成功を、ご本人と自社のご担当（独立した観測者）にお知らせする"検知に特化した形にとどめ、毎回の確認コードは死守しました。
3

受領パスワードを「S＋5 桁」に。短くしたぶんは、別の安全対策で補う

契約書級のパスワードを、口頭でも伝えやすい短い形式にしました。短くすると強度が下がりそうに見えますが、そこは元に戻せない形への多層のハッシュ化（データベースだけの漏えいでは解読できない）と、受け取る方ごとのロック（一人の打ち間違いで全員が締め出されるのを防ぐ）で、しっかり補っています。

「会社 × 担当者 × 案件」を、そのままの形で持つ

もうひとつの土台が、取引先の捉え方です。私たちは日ごろ、「あの会社の・あの担当の方の・あの案件の」という形で、頭の中を整理しています。それを、フォルダやグループに置き換えるのではなく、会社＞担当者＞案件という正式なデータの構造として、そのまま持ちました。案件の期限とファイルの期限を別々にかけられる二層の期限が、「案件は続くけれど、この一枚だけ早く締めたい」という現場の感覚に、素直に重なります。

PARTNER MODEL · 3 TIERS会社＞担当者＞案件＞共有ファイルを、入れ子の正式なデータ構造として保持。あて先は「ファイルのあて先＋その案件への参加」の二重で絞り込みます。

TWO-LAYER EXPIRY案件の期限とは別に、ファイル一枚ごとの期限をかけられます。「案件はまだ続くけれど、この一枚だけ早めに締めたい」に素直に重なります。

そして、この基盤は横に展開できる

本製品で確立した認証・主キー・エラー処理の基盤は、別のプロダクト（AI 帳票読取システム）が受け継いで、開発を加速させました。一度きちんと作り込んだ土台を、別の課題へ手早く活かす。これは、自社の開発基盤を横に展開できることの、ひとつのあらわれです。

13HOW TO START

導入までの流れ

「相談したら、次はどうなる？」にお答えします。スクラッチ開発の案件として、段階を踏んで、都度ご確認いただきながら進めます。

1

ご相談

いまのファイルのやり取りの困りごと（パスワード別送の範囲・取引先の数・機密の度合い）をうかがいます。
2

デモ／画面確認

実際の画面イメージ（モックや実機）で、使う場面を一緒に確認します。
3

試行（スモールスタート）

自社の一部門など、小さく始められる規模で設計します。
4

段階的な構築・確認

各段階で、目に見える資料や画面をご用意し、OK をいただいてから次へ進みます。
5

運用・保守

取引先・担当者・案件、そして期限・回数・権限を、管理画面から運用いただきます。

よくあるご質問

PPAP をやめると、かえって安全性は下がりませんか。

むしろ高める設計です。ログインは毎回のメールの確認コード（パスワードレス）で本人を確認し、受け取れるのは「あて先に登録された、かつその案件に参加している担当者」だけに、二重で絞り込みます。パスワードを同じメール経路で別送しないこと自体が、PPAP からの大きな安全改善です。

お取引先の担当者もログインできますか。アクセスは制御できますか。

できます。お取引先の担当者も、同じパスワードレスの方式でログインできます。その担当者がログインできるかどうかは、自社側でいつでも設定できます。見えるのは「割り当てられた案件の、自分あてのファイル」だけです。

誰がいつ受け取ったか、分かりますか。

操作履歴（監査ログ）に、誰が・いつ・何を（閲覧／ダウンロード／アップロード）したかを記録します。会社・案件の軸で確認でき、追記専用なので、あとから書き換えることはできません。

高機密の書類には、パスワードも付けられますか。

契約書級の文書には、発行時のオプションとして、自動で発番したパスワードを付けられます。口頭で伝えやすい短い形式にしつつ、元に戻せない形への多層のハッシュ化と、受け取る方ごとのロックで、強さを補っています。※ふだんの共有では、形だけになって PPAP が再発するのを避けるため、付けません。

見慣れない端末からログインされたら、気づけますか。

新しい端末からのログイン成功を検知し、ご本人と自社のご担当の双方にお知らせします。便利さのために本人確認を省く"信頼済みの端末"は採用せず、毎回の確認コードは維持しています。

ファイルの大きさや形式に、制限はありますか。

単一ファイル 100MB／1 回あたり合計 300MB／一度に 20 件までを目安に受け付けます（設定で調整できます）。拡張子・MIME・ファイル先頭のマジックバイトを照合し、危険なファイルは受け付けません。

データはどこに保存され、外部に送られますか。

自社が構築・運用する環境内に保存し、外部サービスへファイルやデータを送信することはありません。AI による学習利用もありません。

パスワードを別便で送らない、相手にやさしいファイルの受け渡し。

はじめてこのページに来てくださった方へ

01検証を積み重ねています

02自分たちが最初の使い手です

03お客様に合わせてご提供します

04積み重ねた開発力の上に立っています