AWS CLIをdosya S3に接続する

普段のAWS認証情報を変更せずにdosya S3をテストするには、専用の名前付きAWS CLIプロファイルを使います。この手順では1つのワークスペースを一覧表示し、固有の名前を付けたテキストファイルをアップロード、ダウンロードしてバイトを確認します。小さいファイルのテストを確認しやすいよう、s3apiを直接呼び出します。

始める前に

AWSのプラットフォーム別インストール手順に従ってAWS CLI v2をインストールし、aws --versionを実行してください。以下のシェル例はmacOS/LinuxのPOSIX構文を使います。awsコマンドはPowerShellでも実行できますが、ローカルのprintf、cmp、$?による確認はPowerShellに相当するものに置き換えてください。

対象のdosyaワークスペースで連携 → S3を開き、Bucket IDをコピーしてください。エンドポイントはhttps://api.dosya.dev/s3、リージョンはus-east-1で、アドレス指定はpathです。WebDAVのAll/プレフィックスはありません。フォルダーを起点とするキーでは、キーは起点より下から始まります。起点内に書き込むにはAnchorName/aws-check.txtではなくaws-check.txtを使ってください。

プロフィール → API（APIキー） → API：APIキーを作成から認証情報を用意します。3つすべてのテスト用にフルアクセス、対象のワークスペース、制限と有効期限 → プロトコル → 選択したもののみの**「S3」ゲートウェイを選択してください。生成後、キーの行を展開して「S3」認証情報 → 有効化を選択します。ダイアログからアクセスキーIDとシークレットアクセスキーをコピーしてください。dos_…トークンはAWS CLIのシークレットではありません。S3シークレットは生成時にのみ表示され、後から有効・表示**で取得することはできません。紛失した場合はキーとペアを交換し、クライアントを移行してから古いキーを取り消してください。

ロールにはS3とファイルの一覧表示、アップロード、ダウンロードの権限が必要です。新しい入れ子のプレフィックスにはフォルダー作成権限も必要です。無料プランでも許容量内で利用できます。無料アカウントのAPIキーは3個まで、全体の上限は20個です。明示的なアクセスや使用の制限はすべてのコマンドに適用されます。

手順：非公開の専用プロファイルを設定する

1. 既存のものとは異なるプロファイルを選択します。 この手順ではdosya-help-checkを使います。まずaws configure list-profilesを確認してください。そのプロファイルが既存の接続に使われている場合は、別の名前を一貫して使ってください。
2. ペアを対話形式で入力します。 次を実行してください：

aws configure --profile dosya-help-check

プロンプトで生成したS3アクセスID、対応するS3シークレット、us-east-1、jsonを入力してください。認証情報をコマンドの引数に貼り付けたり、生成されたファイルをコミットしたりしないでください。プロンプトを使うとシークレットはシェルのコマンド履歴に埋め込まれませんが、録画中のターミナルでは実行しないでください。AWS CLIの設定ではプロンプトの入力が隠されるとは限りません。

AWS CLIは通常、ペアを~/.aws/credentialsに、設定を~/.aws/configに保存します。Windowsでもユーザーのホーム内です。これらはローカルファイルであり、暗号化されたパスワード保管庫ではありません。非公開のUnixアカウントでは設定後にファイルのアクセスを制限してください：

chmod 600 ~/.aws/credentials ~/.aws/config

3. このプロファイルにS3のパス形式アドレス指定を設定します。 このプロファイルの設定だけが変更されます：

aws configure set s3.addressing_style path --profile dosya-help-check
aws configure get region --profile dosya-help-check
aws configure get s3.addressing_style --profile dosya-help-check

us-east-1とpathが表示されます。以下のリモートコマンドはすべて--endpoint-urlを明示的に指定します。省略すると、dosyaではなくAWSにリクエストが送られることがあります。この認証情報の検証にSTSのID確認コマンドを実行しないでください。dosyaが提供するのはS3ゲートウェイであり、AWS STSではありません。

4. 選択された取得元を非公開で確認します。 aws configure list --profile dosya-help-checkを実行してください。この名前付きプロファイルを明示する手順では、認証情報は共有認証情報ファイルから、リージョンはそのプロファイルの設定から取得されるはずです。--profileを省略したコマンドは別の解決経路を使い、代わりに環境変数の認証情報を選択することがあります。すべてのテストでプロファイルオプションを指定してください。一覧では認証情報の大部分が隠されますが、出力は非公開の診断情報として扱ってください。AWSの認証情報の優先順位を参照してください。

手順：サンプルの一覧表示、アップロード、ダウンロード

ws_exampleをすべてコピーしたワークスペースIDに、aws-check-20261014-unique.txtを未使用と確認した新しい名前に置き換えてください。使い捨てのローカル作業フォルダーから実行します。既存の重要なキーは選ばないでください。PUTにより現在の内容が新しいdosyaバージョンに置き換わることがあります。

aws --profile dosya-help-check --region us-east-1 --endpoint-url https://api.dosya.dev/s3 s3api list-objects-v2 --bucket ws_example --max-keys 10 --no-paginate
printf 'Dosya AWS CLI connection check\n' > ./aws-check-20261014-unique.txt
aws --profile dosya-help-check --region us-east-1 --endpoint-url https://api.dosya.dev/s3 s3api put-object --bucket ws_example --key aws-check-20261014-unique.txt --body ./aws-check-20261014-unique.txt
aws --profile dosya-help-check --region us-east-1 --endpoint-url https://api.dosya.dev/s3 s3api head-object --bucket ws_example --key aws-check-20261014-unique.txt
aws --profile dosya-help-check --region us-east-1 --endpoint-url https://api.dosya.dev/s3 s3api get-object --bucket ws_example --key aws-check-20261014-unique.txt ./aws-check-downloaded.txt
cmp ./aws-check-20261014-unique.txt ./aws-check-downloaded.txt

--max-keys 10 --no-paginateは小さな一覧ページを1ページ要求します。アクセスが許可された空のルートではContentsがなくても正常です。他のページが存在しないことの証明にはなりません。通常の大きな一覧取得ではページネーションをたどってください。ゲートウェイの1ページの上限は1,000件です。

PUTは通常、ETagを含むJSONを返します。HEADにはContentLengthが含まれ、GETは出力先ファイルを書き込み、レスポンスのメタデータを表示します。上のサンプル行は改行を含め31バイトです。既存のローカル出力ファイルが上書きされることがあるため、ダウンロード用にも新しいファイル名を選んでください。cmpはファイルが同一なら何も表示せず終了コード0を返します。PowerShellでは(Get-FileHash ./source.txt).Hashと(Get-FileHash ./download.txt).Hashを比較し、各AWSネイティブコマンドの直後に$LASTEXITCODEを確認してください。POSIXシェルでは直後にecho $?を使ってください。後続のコマンドでそのステータスは置き換わります。

dosyaのファイルで、選択したワークスペースまたはキーの起点に同じファイル名とサイズがあることを確認してください。CLIの終了コードが0で、ダウンロードしたバイトが一致すれば接続テストは成功です。マルチパートファイルのETagは通常のMD5ハッシュではありません。この手順で受信者に公開リンクが付与されることはありません。

期待される結果と後片付け

専用プロファイルからバケットの直接一覧表示が成功し、サンプルをダウンロードしてバイト単位で一致することを確認できました。プロファイルは使用する予定がある場合のみ保持し、認証情報ファイルは非公開にしてください。

この確認済みサンプルだけを削除するには、バケットとキーを再確認してから次を実行してください：

aws --profile dosya-help-check --region us-east-1 --endpoint-url https://api.dosya.dev/s3 s3api delete-object --bucket ws_example --key aws-check-20261014-unique.txt

DeleteObjectは存在しないキーに対しても204を返すため、出力がないことをオブジェクトが以前存在した証拠としないでください。実際に削除されるとファイルはdosyaのゴミ箱に移動し、共有は取り消されます。ストレージはすぐには空きません。ゴミ箱の完全削除には、オーナーに適用される無料プランの7日または有料プランの30日の保持期間が適用されます。完全削除すると復元可能なバイトは失われます。

接続の使用を終了するには、専用APIキーで招待を取り消すを実行してください。これは元に戻せず、S3ペアも無効になりますが、クラウドデータは削除されません。対象のプロファイルを編集していることを確認し、ローカル認証情報ファイルから[dosya-help-check]ブロックだけを、設定ファイルから[profile dosya-help-check]ブロックだけを削除してください。共有のAWS設定ファイルは削除しないでください。ローカルサンプルは必要な確認を終えてから消去してください。

トラブルシューティング

一覧表示またはダウンロード時にAccessDeniedが表示される。 アップロード専用では不十分です。キーのスコープ、S3プロトコル、ワークスペースの固定、メンバーのロール、アドレスと利用時間の制限を確認してください。S3のルート一覧はWebDAVのコレクション名ではなく通常のファイルパスを使います。

SignatureDoesNotMatch。 アクセスIDとシークレットが同じS3ダイアログから取得されたこと、およびクライアントが実際に送信されたエンドポイント、リージョン、パスに正確に署名していることを確認してください。プロキシによる書き換えやラッパーによる別プロファイルの選択によって、正しく保存されたプロファイルでも失敗することがあります。

使用制限またはフロントドアのスロットリング。 429 XMLのSlowDownはキーまたはロールの使用制限によるものです。Messageを読み、Retry-Afterがある場合は従ってください。同時実行数による拒否では並列転送を減らしてください。再試行してもバイトの許容量は補充されません。別のフロントドア制限では、ユーザーごとに毎分600件またはIPごとに毎分1,200件の上限に達すると、Retry-Afterとともに429 JSON **{“ok”:false,“error”:“Too many requests”}**が返されます。その時間が過ぎるまで待ち、リクエストの多いジョブの実行をずらしてください。ワークスペースのストレージとファイルのポリシー、日次の送信量は別の制限です。

バックアップクライアントがバケットのバージョニングまたはObject Lockを要求する。 これらのAWS設定機能はサポートされていません。パス形式を設定しても利用できません。同名のアップロードにはAWS S3のバージョンIDではなくdosyaの履歴が使われます。既定は10バージョンで、超過分の削除と無料オーナーの古いバージョンに対する7日間の保持が適用されます。別に元ファイルを保管してください。

完全な認証情報、署名付きリクエストURL、伏せ字にしていない--debugの出力を公開のissueに載せないでください。時刻や事前署名に関する拒否については、署名時刻の専用ガイドを参照してください。

関連ガイド

• S3の設定、対応操作、権限エラー
• S3リクエストの署名と有効期限からの復旧
• AWS CLI設定リファレンス