【2026年】CryptPad セルフホストオフィス構築ガイド｜E2E暗号化Office

2026 年時点におけるデータ主権と自己所有の新たな潮流

情報社会が高度に発展した 2026 年、企業の機密情報や個人のプライバシーは、かつてないほど重要な価値を持ち続けています。特にクラウドサービスへの依存度が高まる中、「データを誰が管理しているのか」という問いに対する回答が、組織の信頼性を決定づける要因となっています。従来の Office ソフトウェアや Google ドキュメントのような SaaS（Software as a Service）型ツールは、利便性において群を抜いていますが、その代償として「サーバー側でのデータ処理」および「プロバイダーによるアクセス可能性」というリスクを抱えています。特に欧州の GDPR 規制強化や、中国などにおけるデータローカライゼーション法の普及により、自社のネットワーク外にデータを置きたがらない組織は増加傾向にあります。

このような背景において、エンドツーエンド暗号化（E2EE）を実現するオフィススイート「CryptPad」のセルフホスト版への関度が急激に高まっています。特に 2026 年現在、XWiki Labs によって維持・開発が進む CryptPad は、単なるドキュメントエディタを超え、完全なプライバシー保護型コラボレーションプラットフォームとして進化を遂げています。本ガイドでは、CryptPad のサーバー構築から運用までの全過程を解説します。特に「ゼロ知識アーキテクチャ」がどのように機能し、なぜこれがセキュリティにおいて最強の選択肢となり得るのかを技術的な観点から深掘りしていきます。

また、単にインストールするだけでなく、Nginx や Caddy によるリバースプロキシ設定、Docker Compose を活用したコンテナ化構成、そして ONLYOFFICE や Collabora Online との明確な違いについて比較検討します。読者には、PC 自作やサーバー管理の初心者から中級者を想定し、専門用語は初出時に簡潔に説明しながらも、具体的なコマンドや設定値を提示して実践的なスキル習得を支援します。本記事を読み終えた後、読者は自社のネットワーク環境下で完全に制御された、安全な共同作業プラットフォームを構築できるでしょう。

エンドツーエンド暗号化の仕組みとゼロ知識アーキテクチャ

CryptPad の最大の特徴は、「エンドツーエンド暗号化（End-to-End Encryption）」です。これは、データが送信元から宛先に送られるまでの全経路で暗号化され、中間のサーバー管理者やネットワーク監視者でも中身を見られない技術的保証を指します。一般的な Web サービスでは、ブラウザからサーバーへの通信は TLS によって暗号化されていますが、サーバー上でデータが平文（あるいはサーバー側で復号可能な状態で）保存されていることが一般的です。しかし、CryptPad では「ゼロ知識アーキテクチャ」を採用しており、ユーザーの鍵がなければサーバー側も内容を解読できません。

技術的なプロセスとしては、ドキュメント作成時にクライアントサイドで暗号化キーが生成されます。このキーはパスワードやトークンベースで管理され、ブラウザのメモリ上で処理された後、暗号化済みデータとしてサーバーに送られます。つまり、CryptPad のサーバーに保存されているのは「暗号化されたバイナリデータ」のみであり、それを解読する鍵はクライアント側のブラウザ内に保持されます。これにより、万が一サーバーがハッキングされても、攻撃者が取得したデータは暗号の壁によって意味のない文字列として機能し続けます。2026 年の現在では、AES-256-bit 暗号や ECC（楕円曲線暗号）といった最新のアルゴリズムが標準的に採用されており、量子コンピュータによる攻撃耐性も考慮された設計になっています。

さらに、このアーキテクチャは「ランタイムでの共同編集」においても維持されます。複数のユーザーが同時に編集する場合でも、変更データは個別の暗号化ストリームとして送受信され、キー交換プロトコルを通じてのみ復号化されます。これにより、サーバー管理者であっても誰が何を見ているかを追跡することができず、完全な匿名性と機密性が担保されます。ただし、このセキュリティの強さはユーザー側の責任も伴います。鍵を紛失した場合、バックアップデータが存在しない限り、データを復元することは不可能です。この「自己責任の範囲内での最高レベルの安全性」を理解した上で構築を行う必要があります。

CryptPad 2026.x の機能要件とドキュメント種別

CryptPad は単一のエディタではなく、複数のアプリケーション機能を一つのプラットフォームに統合した集合体です。2026 年現在、標準で提供される主要な機能には「Pad（リッチテキスト）」「Sheet（スプレッドシート）」「Presentation（スライド）」「Kanban（カンバンボード）」「Whiteboard（ホワイトボード）」などがあります。それぞれが独自の暗号化メカニズムを持ち、用途に合わせた最適化が施されています。

Pad 機能は、従来の Word や Google Docs に相当するリッチテキストエディタです。フォントサイズの変更や画像の埋め込みが可能ですが、CryptPad ではすべてのスタイル情報も暗号化ストリームに含まれます。これにより、ドキュメントのフォーマット自体も第三者から隠蔽されます。Sheet 機能は Excel と互換性がありますが、計算式の実行ロジックがクライアントサイドで実行されるため、サーバーへの負荷が軽減されています。Presentation はスライドショー形式での共有を想定しており、アニメーション効果やトランジションも暗号化された状態で保存されます。

さらに、2026 年時点では「Code Editor（コードエディタ）」と「Form（フォーム）」、「Drive（ファイルストレージ）」の機能強化が著しいです。Code Editor は開発者向けに構文_highlighting やターミナル接続をサポートし、チームでのコードレビューを安全に行えます。Form 機能はアンケート作成に使われますが、回答データも E2E で保護され、管理者には集計結果のみが表示される設定が可能です。Drive はファイル管理システムとして機能しますが、暗号化ストレージとして実装されており、アップロードされたファイルも復号鍵なしでは閲覧できません。

また、「Team（チーム）」機能により、組織内のユーザーグループを管理できます。特定のプロジェクトに対してアクセス権限を付与し、外部との共有リンクを個別に発行することが可能です。これにより、機密情報の漏洩リスクを最小化しつつ、必要な情報共有を円滑に行うことができます。以下に、主要な機能とその主な用途をまとめました。

このように、CryptPad は従来のオフィススイートと同様の機能性を保ちつつ、セキュリティ要件を劇的に強化しています。特に、共同編集時の競合状態やバージョン管理において、暗号化キーの同期メカニズムが効率的に設計されているため、ネットワーク遅延による影響も最小限に抑えられています。

システム要件とインフラ構成の事前準備

CryptPad をセルフホストする前に、必要なハードウェアリソースや OS 環境を正しく理解しておくことが重要です。2026 年現在、Docker コンテナ技術が標準化されているため、特定の OS に縛られることは少なくなりましたが、安定した運用には適切なスペックのサーバーが必要です。特に、暗号化処理は CPU サイクルを消費する傾向があるため、低スペックな VPS（仮想専用サーバー）では編集時の遅延が発生する可能性があります。

CPU については、Intel Core i3 または AMD Ryzen 3 相当の 2 コア以上を推奨します。ただし、同時接続ユーザー数が多い場合や、大きなスプレッドシートを処理する場合、4 コア以上の CPU がある方が安定します。メモリ（RAM）は、最小で 2GB を確保する必要がありますが、快適な運用のためには 4GB 以上を用意すべきです。CryptPad のバックエンドである Node.js サービスと Redis キャッシュサービスがメモリを消費するため、30 人規模のチーム利用でも 4GB で動作するよう最適化されていますが、余裕を持たせることでキャッシュヒット率を上げることが可能です。

ストレージ容量については、暗号化されたデータが保存されるため、圧縮効率が通常のファイルよりも低くなる傾向があります。また、データベース（SQLite または PostgreSQL）のサイズも増大します。初期設定では 50GB もあれば十分ですが、長期的な運用を想定し、100GB 以上の SSD を用意することをお勧めします。SSD を使用することで、暗号化キーの読み書き速度が向上し、レスポンス時間が短縮されます。また、バックアップ用として別のストレージ領域（NAS やクラウドオブジェクトストレージ）も確保しておく必要があります。

OS の選定については、Ubuntu 24.04 LTS または Debian 13 が最も推奨されています。これらは Docker のサポートが安定しており、セキュリティアップデートの頻度も高いです。Windows サーバーでも動作しますが、Docker Desktop のオーバーヘッドやファイアウォールの設定複雑さから、Linux ベースの環境での構築が圧倒的にスムーズです。以下に、推奨されるシステム構成を詳細な仕様で示します。

また、データベースの選定も重要な要素です。初期設定では SQLite がデフォルトですが、本番運用では PostgreSQL を使用することが推奨されます。SQLite はファイルベースで軽量ですが、同時書き込み時の競合や、大規模データでのパフォーマンス低下が懸念材料となります。PostgreSQL に切り替えることで、トランザクション処理能力が高まり、複数ユーザーによる同時編集の安定性が向上します。ただし、この場合、Docker Compose 設定ファイル内の DB サービス名と接続文字列を修正する必要があるため、事前の学習が必要です。

Docker Compose を活用したデプロイ手順详解

CryptPad のインストールは、手動で Node.js や Redis をセットアップする方法もありますが、2026 年現在では Docker Compose を利用したコンテナ化デプロイが標準的なベストプラクティスです。これにより、環境依存の排除やバージョン管理、バックアップの容易さが実現されます。まず、サーバー上に Docker と Docker Compose がインストールされていることを確認します。コマンド docker --version および docker compose version を実行し、両方が正常に動作しているか確認してください。

インストール作業は、まずプロジェクトディレクトリを作成することから始まります。例として /opt/cryptpad というパスを使用しますが、これは管理者の権限が必要です。以下のコマンドを実行してディレクトリを生成し、移動します。その後、Docker Compose の設定ファイル docker-compose.yml を作成します。このファイルの内容は、各サービスの定義と相互接続関係を記述した重要な構成要素です。

version: '3.8'
services:
  cryptpad:
    image: xwikilabs/cryptpad:latest
    container_name: cryptpad
    restart: always
    environment:
      - CRYPTPAD_HTTPS=true
      - CRYPTPAD_HOSTNAME=crpad.example.com
      - SECRET_KEY_12345678901234567890123456789012 (※実際は環境変数で管理)
    ports:
      - "5081:5081"
    volumes:
      - ./data:/opt/cryptpad/data

この設定例では、cryptpad サービスがコンテナ名として定義され、restart: always でサーバー再起動時に自動で起動するよう設定されています。重要なのは environment セクションです。ここでサーバーのドメイン名や暗号化用のシークレットキーを指定します。SECRET_KEY はランダムな文字列を設定する必要があり、これを紛失すると既存データへのアクセスが不能になるため、必ず安全な場所に保管してください。また、ポート 5081 は CryptPad の標準ポートですが、リバースプロキシを経由する場合はホスト側のポートを 443（HTTPS）にバインドするか、Nginx でフォワードします。

ボリューム（volumes）設定では、コンテナ内の /opt/cryptpad/data ディレクトリをホストマシンの ./data フォルダとマウントしています。これにより、コンテナが破損してもデータはホスト上に保存され続けます。バックアップの際は、この ./data フォルダ全体を圧縮して外部ストレージに移すだけで十分です。また、Redis などのデータベースも Docker コンテナとして起動されるため、ネットワーク内のサービス間通信が自動で設定されます。

インストール後の初期化プロセスでは、コンテナの起動後、ブラウザから指定した URL にアクセスし、管理者アカウントを作成します。ここでパスワードを設定しますが、これも復号キーの一部となるため注意が必要です。また、SMTP 設定もこの段階で行うか、または設定ファイルを通じて行います。メール通知機能（パスワードリセットや招待メールなど）を有効にするには、Gmail や Office365 などの SMTP サーバー情報を登録する必要があります。これらの手順を踏むことで、2026 年最新のセキュリティ基準を満たした CryptPad インスタンスが構築されます。

リバースプロキシとサブドメインの必須設定理由

CryptPad は、HTTPS 環境下でのみ安全に動作する設計になっています。そのため、Nginx や Caddy などのリバースプロキシを介して SSL/TLS 接続を提供する必要があります。また、CryptPad の内部システムでは「サンドボックス（Sandbox）」という概念が強く機能しており、特定のサブドメインを経由することで、暗号化セッションの分離やセキュリティ強化を図っています。したがって、単に IP アドレスでアクセスするのではなく、必ずサブドメインを設定することが必須要件となります。

Nginx を使用する場合の設定例を以下に示します。SSL 証明書は Let's Encrypt の Certbot を利用するのが一般的ですが、2026 年時点では ACME プロトコルが標準化されており、Caddy は自動で証明書を取得・更新する能力を持っています。どちらを選択するかはサーバーの管理方針によりますが、Nginx の方が設定の柔軟性が高く、Caddy が導入の容易さにおいて優れています。

server {
    listen 443 ssl http2;
    server_name crpad.example.com;

    ssl_certificate /etc/letsencrypt/live/crpad.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/crpad.example.com/privkey.pem;

    # 暗号化強度の強化設定
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;

    # CryptPad へのリダイレクト
    location / {
        proxy_pass http://localhost:5081;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        # セキュリティヘッダー
        add_header Strict-Transport-Security "max-age=31536000" always;
    }
}

この設定の重要な点は、セキュリティヘッダーの追加と SSL プロトコルの制限です。Strict-Transport-Security ヘッダーは、ブラウザに対して HTTPS 接続のみを強制する指示を出し、中間者攻撃（MITM）を防ぎます。また、TLSv1.0 や TLSv1.1 のような脆弱なプロトコルを無効化し、最新の TLSv1.3 を優先的に使用するように設定しています。これにより、通信経路の安全性が最大化されます。

さらに、サブドメインの使用は「サンドボックス分離」のために必要です。CryptPad には「public pad」と「private pad」があり、暗号化ストリームがそれぞれ独立しています。サブドメインごとに異なるセッション管理を行うことで、クロスサイトスクリプティング（XSS）攻撃のリスクを低減できます。例えば、pad.example.com と sheet.example.com を別々のサブドメインに割り当てることで、ドキュメント種別ごとのアクセス制御を細かく行うことが可能です。

また、リバースプロキシの設定においては、WebSocket 接続のサポートも必須です。CryptPad のリアルタイム共同編集機能は WebSocket 通信を利用しているため、Nginx や Caddy 側でもこれを適切にフォワードする必要があります。以下の設定を追加することで WebSocket 接続が可能になります。

location / {
    proxy_pass http://localhost:5081;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

この Upgrade ヘッダーは、HTTP 接続を WebSocket 接続にアップグレードする指示です。これを設定しないと、リアルタイム編集機能が動作せず、ページリロードが必要になってしまいます。したがって、リバースプロキシの設定ミスが CryptPad の可用性に直結するため、十分なテストと確認が必要です。

ユーザー管理とアクセス権限の詳細制御

CryptPad を組織で運用する場合、ユーザー管理とアクセス権限の制御は不可欠な要素です。初期状態ではローカル認証のみが可能ですが、2026 年現在では LDAP や OIDC（OpenID Connect）、Google Workspace 連携などの外部認証プロトコルをサポートしています。これにより、既存の Active Directory や SSO システムと統合し、一元管理することが可能になります。

ユーザー登録方法としては、「オープンな公開」と「招待制」を選択できます。公開設定にすると、誰でもアクセスしてドキュメントを作成できる状態になりますが、セキュリティリスクが高まります。招待制では、管理者が生成したリンクのみで新規ユーザーが参加でき、組織外の不正アクセスを防げます。また、チーム機能を活用することで、特定のプロジェクトメンバーに対してのみのアクセス権限を付与できます。

アクセス権限には「閲覧」「編集」「管理」の 3 レベルが存在します。閲覧者はドキュメントの内容を確認できますが、変更はできません。編集者は内容を変更できますが、共有設定や削除はできません。管理者はすべての操作が可能で、ユーザーの追加削除も行えます。このように階層化された権限体系により、機密情報の漏洩リスクを抑制しつつ、必要な協働作業を円滑に進行させます。

さらに、匿名アクセスの設定も可能です。特定のドキュメントに対してトークンキーを発行し、パスワードなしで共有することができるようになります。ただし、このトークンは秘密鍵と同等の扱いを受けるため、漏洩した場合は即座に無効化または削除する必要があります。2026 年版の CryptPad では、トークンの有効期限を設定するオプションも強化されており、一定時間経過で自動的にアクセス権が失効するように設定できます。

セキュリティ対策として、IP フィルタリング機能も利用可能です。特定の IP アドレス範囲からのアクセスのみを許可し、外部からの不正な侵入を防ぐことができます。これらは Docker Compose の環境変数や、Nginx の設定ファイルを通じて制御されます。また、2FA（二要素認証）の導入も推奨されており、パスワードだけでなくモバイルアプリやハードウェアキーによる追加認証が必須化される組織向けオプションです。

他社製品との比較と CryptPad の立ち位置

CryptPad は、Office シート分野において多くの競合が存在します。主な競合には ONLYOFFICE、Collabora Online、Nextcloud Office、そして Google Docs が挙げられます。これらと比較した際、CryptPad が持つ決定的な強みは「暗号化レベル」と「データ主権」にあります。他の製品がサーバー側でデータを処理するのに対し、CryptPad はクライアントサイドでの暗号化を徹底している点が異なります。

ONLYOFFICE や Collabora Online は、LibreOffice ベースのオープンソースオフィススイートとして非常に人気があり、互換性において優れています。しかし、これらは通常、サーバー側でドキュメントを開くため、サーバー管理者が中身を確認できる可能性があります。一方、CryptPad はゼロ知識アーキテクチャにより、このリスクを排除しています。Google Docs はクラウド上で完結しており、セキュリティと利便性のバランスが取れていますが、データが Google のサーバーに保存される以上、完全なプライバシー保護は期待できません。

以下に、主要なオフィススイートとの機能およびセキュリティ特性を比較した表を示します。

この比較から明らかなように、CryptPad はセキュリティ最優先の組織にとって最適な選択肢です。ただし、互換性の観点では ONLYOFFICE の方が Microsoft Office 形式（.docx, .xlsx）との親和性が高い傾向があります。CryptPad も標準フォーマットをサポートしていますが、複雑な書式を持つ既存ファイルを取り込む際にはレイアウト崩れが発生する可能性があります。

また、UX（ユーザー体験）の観点でも違いが存在します。Google Docs は直感的で使い勝手が良いですが、CryptPad はセキュリティを優先した設計のため、設定オプションがやや複雑です。ただし、2026 年現在では UI の改善が進み、初心者でも問題なく操作できるようになっています。また、暗号化キーの管理やバックアップの手順が明確になっているため、運用コストは他社製品と同等かそれ以下です。

データ移行と運用維持のポイント

CryptPad を構築した後の重要ステップは、データ移行と運用維持です。既存のドキュメントを CryptPad に移行する場合、CSV 形式やテキストファイルとしてエクスポートし、再度インポートする方法が一般的です。ただし、暗号化されたデータを直接移植することはできないため、一度平文（または非暗号化）状態でデータを抽出する必要があります。これはセキュリティリスクを伴う作業であるため、ローカルネットワーク内でのみ行うことを強く推奨します。

運用維持においては、定期的なバックアップが最も重要です。Docker のボリュームマウント設定により、データはホスト上に保存されているため、tar コマンドなどで data フォルダ全体をアーカイブ化し、外部ストレージに格納します。バックアップの頻度は、業務の重要度によって異なりますが、最低でも週 1 回のスナップショットを取得することをお勧めします。また、データベース（[PostgreSQL）の場合、pg_dump などのツールを使用して SQL ダンプを作成する手法も有効です。

アップデートについても注意が必要です。Docker イメージの更新は比較的容易ですが、バージョンアップ時には互換性のあるデータ形式が保証されるかどうかを確認する必要があります。CryptPad の開発チームは通常、マイナーバージョン間では後方互換性を保っていますが、メジャーバージョンアップ時は設定ファイルの変更が必要な場合があります。そのため、アップデート前には必ずバックアップを取得し、テスト環境で検証してから本番環境へ適用するプロセスを確立してください。

また、監視体制の構築も重要です。Docker のログを確認してエラーが発生していないかチェックするか、Prometheus や Grafana を導入してリソース使用率（CPU/RAM/ディスク）を可視化します。特に、暗号化処理による CPU 負荷の急増や、Redis キャッシュのヒートマップ異常は、サーバーの安定性を損なう兆候です。これらを早期に検知することで、サービスのダウンタイムを防ぎます。

よくある質問（FAQ）

Q1. CryptPad の E2E 暗号化を解除することはできますか？ A1. いいえ、できません。CryptPad の核となる機能はエンドツーエンド暗号化であり、これを無効にするとセキュリティ保証が失われます。もしサーバー管理側で内容を閲覧したい場合は、代わりに ONLYOFFICE や Nextcloud を導入する必要があります。

Q2. サーバーを再起動してもデータが消えませんか？ A2. 設定ファイルとボリュームマウントを正しく行っていれば、データは保存されます。ただし、data フォルダがコンテナ内部にのみマウントされている場合は注意が必要です。外部ボリュームを使用していることを確認してください。

Q3. スマホからも編集できますか？ A3. はい、可能です。ブラウザベース（PWA）のサポートが進んでおり、iOS や Android の Safari/Chrome からアクセスして編集可能です。オフライン動作には一部制限がありますが、基本的な機能は利用できます。

Q4. 同時接続人数に制限はありますか？ A4. Docker コンテナのリソースに依存します。推奨構成（4GB RAM, 4 コア CPU）では 30-50 人の同時編集が可能です。これを超える場合は、Redis の設定を最適化するか、ロードバランサーを導入する必要があります。

Q5. Microsoft Office ファイルの互換性はどの程度ですか？ A5. 基本的なテキストや表は問題なく開けますが、複雑な書式やマクロ機能は破損する可能性があります。重要ファイルは事前にプレビューして確認し、可能であれば CryptPad 形式での保存を推奨します。

Q6. SMTP が失敗した場合、パスワードリセットはできますか？ A6. メール送信機能が停止している場合、管理者コンソールから手動でパスワードリセットを行う必要があります。SMTP 設定の修正が完了するまで、直接サーバーへのアクセス権限を持つ管理者による対応が必要です。

Q7. SSL 証明書の更新方法は？ A7. Let's Encrypt の Certbot を使用している場合は自動更新されます。Caddy を使用する場合も同様に自動処理されます。手動で証明書を取得している場合は、Nginx/Caddy の設定ファイルを更新しコンテナを再起動してください。

Q8. データを削除しても完全に復元不可ですか？ A8. はい、E2E 暗号化のためサーバー側からの完全消去は可能です。ただし、バックアップデータが存在する場合は、その暗号化キーが必要になります。管理下のデータを完全に消去することは推奨されません。

Q9. 他のクラウドから移行するにはどうすればいいですか？ A9. Google Docs や OneDrive などのファイルをダウンロードし、CryptPad のインポート機能を使用してアップロードします。ただし、ファイル形式の変換が必要な場合がありますので、事前にプレビューして確認してください。

Q10. サーバーのログを確認するコマンドは？ A10. docker logs -f cryptpad を実行するとリアルタイムでログが表示されます。エラーが発生している場合は、この出力を管理チームに報告し、原因特定を行ってください。また、journalctl でもシステム全体のログを確認可能です。

まとめ

本ガイドでは、2026 年時点の最新技術を反映させた CryptPad セルフホスト構築の全貌を解説しました。CryptPad は、E2E 暗号化とゼロ知識アーキテクチャにより、従来のオフィススイートにはないセキュリティレベルを提供します。特にデータ主権が重視される組織にとって、強力な味方となるでしょう。

本記事の要点を以下にまとめます。

• E2E 暗号化: クライアントサイドで鍵が生成され、サーバー側では暗号化されたデータのみが保存されるため、管理者すら内容を閲覧できない。
• [Docker Compose デプロイ: コンテナ技術を活用することで環境構築が容易になり、バックアップやメンテナンスもスムーズに行える。
• リバースプロキシ必須: Nginx または Caddy を使用して HTTPS 接続を提供し、サブドメイン設定によるサンドボックス分離を行う必要がある。
• 他製品との違い: ONLYOFFICE や Google Docs と比較し、セキュリティの強さとデータ主権において CryptPad が優位である。
• 運用と維持: 定期的なバックアップ、ログ監視、アップデート計画を策定することで、長期的かつ安定したサービス提供が可能となる。

CryptPad の導入は、セキュリティ意識の高いチームにとって重要なステップです。本ガイドが、安全で信頼性の高い共同作業環境の構築に貢献することを願っています。