FEATURE 01
PPAPを“名ばかりでなく”本当に廃止する認証設計
受け取りは、毎回のメール確認コードでの本人確認(本人性)、あて先の二重の絞り込み(ファイルのあて先+その案件への参加)、公開期限、ダウンロード回数の上限――この四つをすべて満たしたときだけ通す設計です。ふだんの共有パスワードの別送そのものをやめたので、以前のPPAP運用が知らぬ間に戻ってしまうこともありません。
SECURE FILE SHARING
安全なファイル共有システム (正式名称は準備中)
お取引先とのやり取りから、パスワード付きZIPを別のメールで送るひと手間(いわゆるPPAP)をなくします。ファイルは、有効期限・アクセス回数・必要なときだけのパスワード発番を備えた安全な共有リンクでお渡しする、社内向けのWebシステムです。しかも「会社 × 担当者 × 案件」という現場の捉え方そのままに整理できるので、渡す側は迷わず、受け取る側は解凍もパスワード探しもいりません。
まず自社で使うために作ったシステムです。発行 → 受領 → ダウンロードの一連を、一つの流れとして整えました。お客様の環境に合わせてカスタマイズしてご提供します。
FIRST OF ALL
私たちは、このシステムをまず自分たちが使うために作りました。実際に動かして整えたうえで、みなさまにご紹介しています。お客様ごとに、環境や運用に合わせてカスタマイズしてご提供します。
検証を積み重ねています
実機での検証プロセスで、合計242件のテストをすべて通過しました(失敗・保留はゼロ、製品側の不具合もゼロ)。確認の証跡は273枚、一件ずつ画面を残しています。脱・パスワード別送の中核となる「発行 → 受領 → ダウンロード」が実機で端から端まで成立することを確かめ、受け取ったあとにダウンロード回数が正しく一つ増えるところまで、実際のデータで検算しました。
自分たちが最初の使い手です
本システムは、まず自社(Leapcom)自身が使うために開発しました。設計から実装まで、一貫して自社で手がけています。
お客様に合わせてご提供します
お客様ごとに、環境や運用に合わせてカスタマイズしてご提供します。クラウド専用のSaaSではなく、ご利用の環境に構築してお届けする形です。
THREE FEATURES
FEATURE 01
受け取りは、毎回のメール確認コードでの本人確認(本人性)、あて先の二重の絞り込み(ファイルのあて先+その案件への参加)、公開期限、ダウンロード回数の上限――この四つをすべて満たしたときだけ通す設計です。ふだんの共有パスワードの別送そのものをやめたので、以前のPPAP運用が知らぬ間に戻ってしまうこともありません。
FEATURE 02
お取引先を、会社(Partner)> 担当者(PartnerContact)> 案件(Project)の三階層で、そのまま持ちます。さらに案件の期限とファイル一枚ごとの期限を、別々にかけられる「二層の期限」を備え、「案件はまだ続くけれど、この一枚だけ早めに締めたい」という現場の感覚に、素直に重なります。
FEATURE 03
社内は管理者/担当者の二段階の権限、お取引先の担当者は「割り当てられた案件の、自分あてのファイル」だけが見えます。誰が・いつ・何を(閲覧/ダウンロード/アップロード)したかは、操作履歴(監査ログ)に標準で記録されます。あとから上位プランで足す機能ではなく、最初から入っている土台です。
USE CASES
お取引先とのファイルのやり取りに、こんな場面はないでしょうか。攻めるためではなく、「よくある困りごと」として、そっと並べます。
パスワードの別送と、解凍のお問い合わせ
見積書や図面、請求書を送るたびに、パスワードを別のメールで送るひと手間がかかる。受け取った側からは「解凍できない」というお問い合わせが返ってくることもある。
「会社・担当者・案件」の感覚とのずれ
取引先とのやり取りは、頭のなかでは自然と「あの会社の・あの担当の方の・あの案件の」という形で整理されている。けれども多くのツールでは、それをフォルダやグループに置き換えて持たなければならず、業務の感覚とすこしずれてしまう。
社外向けの、きめ細かな調整
「このお取引先の方はログインできてよいか」「この監査記録はいつまで残すか」といった社外向けのきめ細かな調整を、必要なぶんだけ効かせたい(既製のサービスでは、上位プランの追加機能になりがちなところです)。
版数・受け渡し履歴の管理
大きな図面の版数や、「誰に・いつまで渡したか」を、メールの記憶をたどりながら管理している。
パスワードを別送して大切に届けるやり方は、長く多くの職場で使われてきた、まじめで丁寧な習慣です。その丁寧さはそのままに、渡す側と受け取る側の手数だけをそっと減らせないか――そこが、私たちの出発点でした。
HOW IT WORKS
基盤は、ASP.NET MVC/C#/.NET 10 + SQL Server で構築するWebシステムです。クラウド専用のSaaSではなく、自社で構築・運用する形態でお届けします。脱・パスワード別送の受け渡しは、次の流れで動きます。
なぜこの構成にしたのか。 パスワードを“同じメール経路で別送する”こと自体が、PPAPのいちばんの弱点でした。だから、それを廃し、別の経路のログイン(メールの確認コード)+あて先の限定+期限+回数+監査で上回ることを目標にしています。
技術的な見どころ(本製品の核=セキュリティ設計)
id を付け、ブラウザの自動テストと境界値テスト(文字数の±1、件数の±1、サイズ上限ちょうど/超過、回数の下限・上限・範囲外、試行上限の直前・到達など)を徹底しています。CAPABILITIES
専門用語をなるべく避けて、実際にできることを並べます。いまご提供できる機能を軸に、これから広げていく機能は分けてお示しします。
THE CORE
ファイル共有の評価の核は、読み取り精度のような%ではなく、「どれだけ丁寧に作り込み、確かめたか」に表れると、私たちは考えています。
242件
実機テスト全通過(PASS 242/242)
273枚
確認の証跡(スクリーンショット)
5系統
正常68/エラー系133/新端末検知6/契約書級PW15/受領PW短縮20
作り込みの事実として
これは「業務がどれだけ減るか」という効果の数字ではなく、「ここまで丁寧に確かめた」という作り込みの事実です。まず自社で使うために作り、設計から実装まで一貫して手がけました。お客様の環境に合わせてカスタマイズしてご提供します。
SCREENS
実際の操作画面のイメージです。ブランド表記を伏せた状態のモックで、実データの写り込みはありません。
SPECIFICATIONS
事実のみを記載します。実装済みは断定で、これから広げる機能は「予定」、設計上の値・運用で調整する値は「設計値」「設定値」と明記します。
| 提供形態 | 自社構築・運用型の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直結は【予定】。 |
| サポート・提供体制 | スクラッチ開発の案件として提供(⑭・⑰参照)。料金は非掲載=要相談。 |
| ファイルサイズ上限 | 単一ファイル100MB/1回の合計300MB/件数20件(0バイトは拒否)。取込のゲートで検証。【設定値】 |
|---|---|
| 対応形式の検証 | 拡張子のホワイトリスト+MIME+ファイル先頭のマジックバイトの三重チェック+危険なファイル名の無害化。許可する拡張子は、運用に合わせて設定します(設定値)。 |
| ウイルススキャン | 非同期のスキャンを実装(未スキャン/Pending・Clean・Infected の状態を保持し、Clean と確定するまで配信しない)。スキャンエンジンは、ご利用の環境に合わせて構成します。 |
| 期限制御(二層) | 案件の期限 × ファイルの期限の二層。案件は継続したまま、特定のファイルだけ先に締められる。 |
| アクセス回数の上限 | 共有リンク単位で最大ダウンロード回数を設定。ダウンロードのたびに数え、上限に達したら失効。同時にダウンロードが重なっても超過しない、条件付きの確実な更新。 |
| パスワードの自動発番 | 既定の共有では付けない(ふだんのパスワード別送を廃止)。契約書級の高機密文書に限り、発行時のオプトインで自動発番。 |
| 発番パスワードの形式 | 契約書級=「S+5桁の数字」(例 S49271・口頭で伝えやすい形式)。桁数は設定で調整。【設定値】 |
| 発番パスワードの強度補償 | 元に戻せない形への多層のハッシュ化(データベースだけの漏えいでは解読不能)+受け取る方ごとのロック(一人の打ち間違いで全員が締め出されない)。 |
| 受領時の試行制限 | 受け取る方ごと(リンク×担当者)に試行上限+クールダウン(例:5回で15分ロック・自然に回復・受領成功でリセット)。【設定値】 |
| 権限段階 | 社内=管理者/担当者の二段階。お取引先担当者=割り当てられた案件の、自分あてのファイルのみ。 |
| 受け渡しの方向 | 社内 → 社外の配布と、社外 → 社内のアップロード(双方向)。 |
| 相手先のモデル | 会社(Partner)× 担当者(PartnerContact)× 案件(Project)の三階層を、正式なデータの形として保持。 |
| あて先の絞り込み | 二重の絞り込み=ファイルのあて先+その案件への参加。両方を満たす方だけが受領可。 |
| 共有リンクの失効・再発行 | 途中での失効・再発行に対応(再発行時は設定を引き継ぐ)。 |
| 新しい端末の検知 | 見慣れない端末からのログイン成功を検知し、ご本人と自社のご担当(独立した観測者)の双方に通知(検知に特化・毎回の確認コードは維持)。 |
| ファイル実体の保管 | データベースの外・Webから直接は見えない領域に、サーバーが生成する推測できない名前で保存。配信は必ずアプリを経由したストリーム(ダウンロード指定・キャッシュ無効・内容の推測防止)。 |
SECURITY & DATA
「大切なファイルを預けたら、それはどこにあって、誰が触れられるのか」――このお気持ちに先回りして、認証・アクセス制御・受領の守り・監査・データの行き先までを、抜けなく事実でお示しします。
SCOPE
「うちのファイル、送れる?」にすぐ見当をつけていただけるよう、具体的に並べます。
対応ファイル
拡張子のホワイトリスト方式(許可された形式だけを受け入れ)。基本的にどんなファイルも想定していますが、危険な拡張子・多重の拡張子・危険なファイル名は、無害化または拒否します。許可する拡張子は、運用に合わせて設定します(設定値)。
サイズ上限
単一ファイル100MB/1回の合計300MB/件数20件/0バイトは拒否。【設定値】
受け渡しの方向
社内 → 社外の配布と、社外 → 社内のアップロード(双方向)。
出力・連携
共有リンク経由のダウンロード(アプリを経由したストリーム配信)。監査ログはシステム内で閲覧・検索できます。ログの外部エクスポート・外部API連携は【予定】。
動作環境
サーバは ASP.NET MVC/C#/.NET 10 + SQL Server、クライアントはWebブラウザ。最新の主要ブラウザ(Chrome/Edge/Firefox/Safari など)での利用を想定しています。
INTEGRATION & API
システム内で完結(実装済み)
共有リンクの発行 → 通知 → 受領 → ダウンロード、そして監査ログの閲覧まで、システムの中で一つの流れとして完結します。
メール送信の基盤(実装済み)
確認コード・共有通知・招待のためのメール送信を、共通の基盤として持っています。差出人は固定、SMTP経由で、秘密情報は焼き込まず、起動時のガードで守っています。
API直結・ログの外部エクスポート
外部システムへのAPI直結と、ログの外部エクスポートは【予定】です。
お取引先担当者への招待メール
初回ログインのご案内メールは、これから広げていく機能です(現状は発行まで)。
A NEUTRAL VIEW
発注先を見極めるうえで、他社との位置づけも気になるところだと思います。ここでは優劣を断じず、他社が公開している情報にもとづいて、中立に整理します。
| 観点 | 一般に、既製のサービスでは | 本システムでは |
|---|---|---|
| 会社・担当者・案件の扱い | 取引先ごとのグループ、外部アカウント+あて先+グループ、ユーザー・グループ・フォルダ等で表現することが多い | 会社 > 担当者 > 案件を、正式なデータの構造として保持 |
| 共有リンクの安全策 | 期限+パスワード(自動発番・必須化)などを提供 | 期限+回数+(機密時のみ)自動発番パスワードを標準。ふだんのパスワード別送は廃止 |
| 期限の持ち方(二層) | ファイル期限+アカウント/所属期限、リンク期限+アクセス権期限など | 案件の期限+ファイルの期限の二層を標準 |
| 社外向けの制御・許可設定 | 承認・ログ延長・許可ドメイン等が、上位プランやオプションになりがち | 標準の機能として、最初から |
| 操作履歴(監査ログ)の項目数 | 200〜250項目超と、非常に充実した製品もある | 会社/案件の軸で標準記録(項目数の網羅では、既製の大手が上回る場合があります) |
他社が公開している値の例(中立の参照):DirectCloud=保存 AES-256/通信 SSL 256bit・全プランでウイルスチェック標準/GigaCC=SSL・TLS・ウイルスチェック・2要素認証を全プラン標準/Proself=サーバー上でのファイル暗号化保存・Gateway Editionで拡張子制限や上長承認 など。(各社の公開情報より・2026-07時点の概算)
網羅の広さでは、既製の大手サービスが上回る面もあります。私たちが立とうとしているのは、「会社と会社の業務に、ちょうど合う」設計――取引先とのやり取りを、頭の中の捉え方そのままの形で持ち、脱PPAPの守りを標準で厚くする、というところです。
※ この比較は検討用の整理です。各製品は上位プランや追加オプションで、本表以上の機能を備える場合があります。掲載値は各社の公開情報にもとづく概算で、2026年7月時点のものです。
DESIGN RATIONALE
デモでいちばんお見せしたいのは、機能そのものより「なぜこう作ったか」です。少し長くなりますが、「PPAPを、名ばかりでなく本当に廃止する」ための再設計の物語を、お伝えします。
パスワードを“同じメール経路で別送する”こと自体が、PPAPのいちばんの弱点でした。メールを見られてしまえば、ファイルもパスワードも同じ場所にある。だから、安全な共有リンクでファイルを渡し、本人確認は別の経路のログイン(メールの確認コード)で行う――ここまでは、素直な出発点でした。
ところが、「共有のたびにパスワードを付けて別送する」運用を残してしまうと、結局PPAPがそのまま戻ってきてしまうことに気づきました。お取引先の担当者は、いくつもの案件に関わります。案件をまたいで事前に共有するパスワードは、形だけのものになりやすく、安全の価値もそう大きくありません。ここを直視して、受領の認証そのものを、三段階に分けて作り直しました。
ふだんの共有パスワードを、廃止する
本人であることは確認コードが、あて先はファイルのあて先とその案件への参加の二重の絞り込みが担保します。だからパスワードは、契約書級の高機密文書に限った、発行時のオプションへと位置づけを変えました。
見慣れない端末の検知と、お知らせ
便利さのために本人確認を省く「信頼済みの端末」は、あえて採用しませんでした。パスワードレスの下では、端末に持たせる目印が単独で長く効く資格になってしまい、認証が弱るからです。代わりに、“見慣れない端末からのログイン成功を、ご本人と自社のご担当(独立した観測者)にお知らせする”検知に特化した形にとどめ、毎回の確認コードは死守しました。
受領パスワードを「S+5桁」に。短くしたぶんは、別の守りで補う
契約書級のパスワードを、口頭でも伝えやすい短い形式にしました。短くすると強度が下がりそうに見えますが、そこは元に戻せない形への多層のハッシュ化(データベースだけの漏えいでは解読できない)と、受け取る方ごとのロック(一人の打ち間違いで全員が締め出されるのを防ぐ)で、しっかり補っています。
もうひとつの土台が、取引先の捉え方です。私たちは日ごろ、「あの会社の・あの担当の方の・あの案件の」という形で、頭の中を整理しています。それを、フォルダやグループに置き換えるのではなく、会社 > 担当者 > 案件という正式なデータの構造として、そのまま持ちました。案件の期限とファイルの期限を別々にかけられる二層の期限が、「案件は続くけれど、この一枚だけ早く締めたい」という現場の感覚に、素直に重なります。
PARTNER MODEL · 3 TIERS
会社 > 担当者 > 案件 > 共有ファイルを、入れ子の正式なデータ構造として保持。あて先は「ファイルのあて先+その案件への参加」の二重で絞り込みます。
TWO-LAYER EXPIRY
案件の期限とは別に、ファイル一枚ごとの期限をかけられます。「案件はまだ続くけれど、この一枚だけ早めに締めたい」に素直に重なります。
本製品で確立した認証・主キー・エラー処理の基盤は、別のプロダクト(AI帳票読取システム)が受け継いで、開発を加速させました。一度きちんと作り込んだ土台を、別の課題へ手早く活かす――自社の開発基盤を横に展開できることの、ひとつのあらわれです。
HOW TO START
「相談したら、次はどうなる?」にお答えします。スクラッチ開発の案件として、段階を踏んで、都度ご確認いただきながら進めます。
FAQ
むしろ高める設計です。ログインは毎回のメールの確認コード(パスワードレス)で本人を確認し、受け取れるのは「あて先に登録された、かつその案件に参加している担当者」だけに、二重で絞り込みます。パスワードを同じメール経路で別送しないこと自体が、PPAPからの大きな安全改善です。
できます。お取引先の担当者も、同じパスワードレスの方式でログインできます。その担当者がログインできるかどうかは、自社側でいつでも設定できます。見えるのは「割り当てられた案件の、自分あてのファイル」だけです。
操作履歴(監査ログ)に、誰が・いつ・何を(閲覧/ダウンロード/アップロード)したかを記録します。会社・案件の軸で確認でき、追記専用なので、あとから書き換えることはできません。
契約書級の文書には、発行時のオプションとして、自動で発番したパスワードを付けられます。口頭で伝えやすい短い形式にしつつ、元に戻せない形への多層のハッシュ化と、受け取る方ごとのロックで、強さを補っています。※ふだんの共有では、形だけになってPPAPが再発するのを避けるため、付けません。
新しい端末からのログイン成功を検知し、ご本人と自社のご担当の双方にお知らせします。便利さのために本人確認を省く“信頼済みの端末”は採用せず、毎回の確認コードは維持しています。
単一ファイル100MB/1回あたり合計300MB/一度に20件までを目安に受け付けます(設定で調整できます)。拡張子・MIME・ファイル先頭のマジックバイトを照合し、危険なファイルは受け付けません。
自社が構築・運用する環境内に保存し、外部サービスへファイルやデータを送信することはありません。AIによる学習利用もありません。
CONTACT
まず自社で使うために作り、お客様の環境に合わせてカスタマイズしてご提供するシステムです。「うちの取引先とのやり取りだと、どう使えそうか」――そんなご相談から、よろこんでお受けします。料金は、ご利用の範囲や運用にあわせて、内容をうかがってご相談のうえお見積りします(金額は掲載していません)。自社の一部門から始めるスモールスタートも、もちろんできます。
まずはお気軽に、お問い合わせフォームからお声がけください。
※ お問い合わせは、スパム対策のためフォームに集約しています。