Leapcom 株式会社

SECURE FILE SHARING

安全なファイル共有システム (正式名称は準備中)

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

お取引先とのやり取りから、パスワード付きZIPを別のメールで送るひと手間(いわゆるPPAP)をなくします。ファイルは、有効期限・アクセス回数・必要なときだけのパスワード発番を備えた安全な共有リンクでお渡しする、社内向けのWebシステムです。しかも「会社 × 担当者 × 案件」という現場の捉え方そのままに整理できるので、渡す側は迷わず、受け取る側は解凍もパスワード探しもいりません。

まず自社で使うために作ったシステムです。発行 → 受領 → ダウンロードの一連を、一つの流れとして整えました。お客様の環境に合わせてカスタマイズしてご提供します。
共有ファイル発行画面のモック
渡すときに、期限・回数・必要なら発番パスワードを、この一画面で。3点セットが一目でそろいます。

FIRST OF ALL

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

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

検証を積み重ねています

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

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

本システムは、まず自社(Leapcom)自身が使うために開発しました。設計から実装まで、一貫して自社で手がけています。

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

お客様ごとに、環境や運用に合わせてカスタマイズしてご提供します。クラウド専用のSaaSではなく、ご利用の環境に構築してお届けする形です。

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

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

THREE FEATURES

3つの特長

FEATURE 01

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

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

FEATURE 02

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

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

FEATURE 03

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

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

USE CASES

こんな場面で

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

パスワードの別送と、解凍のお問い合わせ

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

「会社・担当者・案件」の感覚とのずれ

取引先とのやり取りは、頭のなかでは自然と「あの会社の・あの担当の方の・あの案件の」という形で整理されている。けれども多くのツールでは、それをフォルダやグループに置き換えて持たなければならず、業務の感覚とすこしずれてしまう。

社外向けの、きめ細かな調整

「このお取引先の方はログインできてよいか」「この監査記録はいつまで残すか」といった社外向けのきめ細かな調整を、必要なぶんだけ効かせたい(既製のサービスでは、上位プランの追加機能になりがちなところです)。

版数・受け渡し履歴の管理

大きな図面の版数や、「誰に・いつまで渡したか」を、メールの記憶をたどりながら管理している。

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

HOW IT WORKS

仕組み・技術(どう動くか)

基盤は、ASP.NET MVC/C#/.NET 10 + SQL Server で構築するWebシステムです。クラウド専用のSaaSではなく、自社で構築・運用する形態でお届けします。脱・パスワード別送の受け渡しは、次の流れで動きます。

1 発行 社内担当者がファイルを案件にアップロードし、安全な共有リンクを発行(有効期限・アクセス回数・必要なら発番パスワードを設定)
2 通知 お取引先の担当者へ共有通知メールが届く(パスワードの平文も確認コードも、メールには載せない)
3 ログイン お取引先担当者が、メールの確認コード(OTP)でその場の本人確認(毎回)
4 判定 サーバが受領のたびに「本人性(OTP)× あて先の二重絞り込み × 公開期限 × ダウンロード回数の上限」を、すべて満たすか評価
5 配信 すべて満たしたときだけ実ファイルを配信し、ダウンロード回数を確実に +1(同時にダウンロードが重なっても、上限を超えない条件付き更新)

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

技術的な見どころ(本製品の核=セキュリティ設計)

  • 完全パスワードレスのメールOTP認証 確認コードをメールでお送りし、入力していただいて本人確認する、社内メンバーもお取引先担当者も共通の、唯一のログイン手段です。利用者はパスワードを覚える必要も、入力する必要もありません。
  • 推測されにくい共有リンク 外部に出る共有URLの識別子は、内部の主キーとは切り離した暗号論的な乱数(128ビット以上・ハッシュにして保管)で作ります。URLを順に試して他人のファイルを探し当てる、といったことを防ぎます。
  • 「存在するかどうか」も漏らさない中立設計 「対象が無い/権限が無い/他人あて」を、画面の見た目・応答・文言で区別できないようにしています。他人のIDを差し込んでのぞこうとする操作(4つの経路)で、外から見える反応がすべて一致することを、実機で確かめました。
  • 秘密情報を、構造として載せない 共有パスワードや確認コードの平文は、通知メールにもログにも監査記録にも一切載せません。パスワードは元に戻せない形へ多層に変換して保管し、仮にデータベースだけが漏れても中身を取り出せない形にしています。
  • たどれるエラー処理 利用者に起因するものと、システムに起因するものを型で分け、日本語のカタログで一元管理します。システムエラーの画面には相関IDを表示し、内部の記録と同じIDで、その一回のやり取りを追えるようにしています。
  • すべての操作部品に安定した目印を付け、機械で厳しく検証 画面のすべての操作部品に安定した id を付け、ブラウザの自動テストと境界値テスト(文字数の±1、件数の±1、サイズ上限ちょうど/超過、回数の下限・上限・範囲外、試行上限の直前・到達など)を徹底しています。

CAPABILITIES

できること(機能一覧)

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

ログイン・本人確認

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

社内メンバーの管理

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

お取引先(会社)の管理

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

お取引先担当者の管理

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

案件(プロジェクト)の管理

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

共有ファイルの管理

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

共有リンク・通知

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

操作履歴・監査

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

支える土台

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

これから広げていく機能

(現時点は設計余地)
  • お取引先担当者への招待メール(初回ログインのご案内)
  • ファイルのバージョン管理
  • ログの外部エクスポート/外部システムとのAPI直結

THE CORE

評価の核:検証の徹底

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

242

実機テスト全通過(PASS 242/242)

273

確認の証跡(スクリーンショット)

5系統

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

作り込みの事実として

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

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

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

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

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

認証(パスワードレスOTP)

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

アクセス制御(会社 × 担当者 × 案件)

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

多層の受領の守り(脱PPAPの核)

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

監査ログ(記録すること・しないこと)

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

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

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

SCOPE

対応範囲

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

  • 対応ファイル

    拡張子のホワイトリスト方式(許可された形式だけを受け入れ)。基本的にどんなファイルも想定していますが、危険な拡張子・多重の拡張子・危険なファイル名は、無害化または拒否します。許可する拡張子は、運用に合わせて設定します(設定値)。

  • サイズ上限

    単一ファイル100MB/1回の合計300MB/件数20件/0バイトは拒否。【設定値】

  • 受け渡しの方向

    社内 → 社外の配布と、社外 → 社内のアップロード(双方向)。

  • 出力・連携

    共有リンク経由のダウンロード(アプリを経由したストリーム配信)。監査ログはシステム内で閲覧・検索できます。ログの外部エクスポート・外部API連携は【予定】

  • 動作環境

    サーバは ASP.NET MVC/C#/.NET 10 + SQL Server、クライアントはWebブラウザ。最新の主要ブラウザ(Chrome/Edge/Firefox/Safari など)での利用を想定しています。

INTEGRATION & API

連携・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は再発する

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

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

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

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

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

受領パスワードを「S+5桁」に。短くしたぶんは、別の守りで補う

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

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

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

PARTNER MODEL · 3 TIERS

会社 Partner
担当者 PartnerContact
案件 Project
共有ファイル Shared File

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

TWO-LAYER EXPIRY

案件の期限
ファイルの期限

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

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

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

HOW TO START

導入までの流れ

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

1 ご相談 いまのファイルのやり取りの困りごと(パスワード別送の範囲・取引先の数・機密の度合い)をうかがいます。
2 デモ/画面確認 実際の画面イメージ(モックや実機)で、使う場面を一緒に確認します。
3 試行(スモールスタート) 自社の一部門など、小さく始められる規模で設計します。
4 段階的な構築・確認 各段階で、目に見える資料や画面をご用意し、OKをいただいてから次へ進みます。
5 運用・保守 取引先・担当者・案件、そして期限・回数・権限を、管理画面から運用いただきます。

FAQ

よくあるご質問

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

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

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

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

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

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

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

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

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

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

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

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

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

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

CONTACT

お問い合わせ

まず自社で使うために作り、お客様の環境に合わせてカスタマイズしてご提供するシステムです。「うちの取引先とのやり取りだと、どう使えそうか」――そんなご相談から、よろこんでお受けします。料金は、ご利用の範囲や運用にあわせて、内容をうかがってご相談のうえお見積りします(金額は掲載していません)。自社の一部門から始めるスモールスタートも、もちろんできます。

まずはお気軽に、お問い合わせフォームからお声がけください。

※ お問い合わせは、スパム対策のためフォームに集約しています。