---
title: "AT Protocol（atproto）とは？ブロックチェーンとの違いと仕組み【2026年10月】"
url: "https://www.issoh.co.jp/column/details/1935/"
published: 2024-02-07
updated: 2026-10-12
categories: ["プラットフォーム"]
publisher: "株式会社一創"
---

# AT Protocol（atproto）とは？ブロックチェーンとの違いと仕組み【2026年10月】

AT Protocol（atproto）は、Blueskyをはじめとするソーシャルアプリ群が動いている土台のプロトコルです。「分散型」という言葉からブロックチェーンを連想されがちですが、公式FAQは「ブロックチェーンではないし、使ってもいない」と明確に否定しています。この記事ではそこを起点に、三層の構成、ハンドルとDID、ActivityPub・Nostrとの違い、2026年8月にアルファ版が出た非公開データ機能「Atproto Spaces」、IETFでの標準化までを、公式仕様で整理します（2026年10月12日時点）。

## まとめ｜AT Protocolの要点と誤解されやすい箇所

- AT Protocolは連合型（federated）プロトコルです。ブロックチェーンもトークンも使わず、データの正しさはアカウントの署名鍵で検証します。
- 設計の中心はアカウントの持ち運びです。ホスティング先を移してもIDとフォロー関係が壊れません。
- Block傘下のTBDが進めていた「Web5」は別系統の構想で、TBDは2024年11月に事業の終了が表明されています。
- 2026年8月20日、非公開データを扱うAtproto Spacesのアルファ版が公開されました。暗号化ではなくアクセス制御で、本番利用は禁止されています。
- IETFでは2026年3月にATPワーキンググループが承認されました。ただし2026年10月時点でワーキンググループとして採択された文書はなく、標準はまだ1本もできていません。
- did:plcは中央ディレクトリに依存しています。運営は2026年設立のスイスの社団PLC Organizationへ移る途中です。

## AT Protocolの全体像｜アカウント移行を前提にした連合型プロトコル

正式名称はAuthenticated Transfer Protocolで、公式ドキュメントでは略称の「atproto」が使われます。Blueskyはこの上に作られたアプリケーションの1つで、両者は同義ではありません。周辺のアプリとサービスの集まりは「Atmosphere」と呼ばれます。

### 解決しようとしている課題｜サーバーを移ってもアカウントが壊れないこと

既存の連合型プロトコルとの違いとして[atproto.comのFAQ](https://atproto.com/guides/faq)が最初に挙げるのは、アカウントの可搬性です。ActivityPubについては「移行ツールは比較的限定的で、元のサーバーがリダイレクトを提供する必要があり、ユーザーの過去のデータを移行できない」と指摘しています。解決策として選んだのが、署名付きのデータリポジトリと恒久的な識別子（DID）の組み合わせです。

もう1つの論点はスケーラビリティです。同じFAQは、ActivityPubが「中小規模のノード間でのメッセージ配送に強く依存し、個々のノードがトラフィックで溢れることがある」のに対し、AT Protocolは集約役のアプリケーションがユーザーのホストからアクティビティをまとめることで全体のトラフィックを減らす、と書いています。後述するRelayとAppViewの分離はこの判断から来ています。

### データリポジトリとat:// URI｜署名付きコミットで改ざんを検出

ユーザーのデータは「データリポジトリ」という単位にまとまります。リポジトリ仕様はこれをコンテンツアドレス指定のMerkleツリーと規定し、キーと値の対応にMerkle Search Tree（MST）を使います。更新のたびに作られるコミットには、アカウントの署名鍵による署名が付きます。リポジトリはCAR v1形式（拡張子.car）でエクスポートできます。ただし画像・動画などのblobや非公開の設定は別途移行・保存する必要があり、アカウント全体のバックアップがこのファイルだけで完了するわけではありません。レコードの参照にはat://で始まるURIを使い、移行やハンドル変更に耐える参照ではハンドルではなくDIDを指定します。また、1リポジトリの規模は「最大で数百万件（single-digit millions）」が想定されています。

### LexiconとXRPC｜スキーマ定義とHTTP APIの規約

レコードの形はLexiconというスキーマ言語で決まり、読み書きの規約がXRPCです。XRPCはHTTPに少しの約束事を足したもので、`/xrpc/`の後ろにLexiconの識別子を並べたエンドポイントを叩きます。Bluesky公式アカウントのリポジトリに入っているコレクションを、そのアカウントのPDSに問い合わせると次の応答が返ります（2026年10月12日に実行。14件のうち先頭の4件を抜粋）。

```
$ curl -s "https://puffball.us-east.host.bsky.network/xrpc/com.atproto.repo.describeRepo?repo=bsky.app"
{
  "handle": "bsky.app",
  "did": "did:plc:z72i7hdynmk6r22z27h6tvur",
  "collections": [
    "app.bsky.actor.profile",
    "app.bsky.feed.generator",
    "app.bsky.feed.like",
    "app.bsky.feed.post"
  ],
  "handleIsCorrect": true
}
```

app.bsky.はBlueskyアプリ用の名前空間で、別のアプリは独自の名前空間のレコードを同じリポジトリへ足せます。この公開APIへの単発の問い合わせは、SDKを使わずHTTPクライアントだけで実装できます。継続的な収集では、再試行や取得量の制御なども設計します。

## ブロックチェーンとの関係｜公式の否定と、混同の出どころ

AT Protocolをブロックチェーン技術と結び付ける日本語の解説は今も残っていますが、誤りです。

### 公式FAQの回答｜「ブロックチェーンではないし、使ってもいない」

atproto.comのFAQは、AT Protocolがブロックチェーンかという問いに「No. The AT Protocol is a federated protocol. It’s not a blockchain nor does it use a blockchain.（いいえ。AT Protocolは連合型プロトコルです。ブロックチェーンではなく、ブロックチェーンを使ってもいません）」と答えています。仕様書にもコンセンサスアルゴリズムやガス代に当たる概念は出てきません。

### 検証の仕組み｜ネットワーク全体の合意ではなく、署名鍵の解決で完結

ブロックチェーンは改ざん耐性を参加者全体の合意で担保します。AT Protocolは「誰の鍵で署名されたか」を解決して担保します。[IETFのATPワーキンググループのcharter](https://datatracker.ietf.org/doc/charter-ietf-atp/)は、アカウント識別子を現在の署名鍵へ解決させることで、偽造コンテンツの注入や許可のない改変を防ぐと説明しています。

実務上の差は2つです。まず、書き込みにブロックチェーンの合意形成もガス代も要りません（PDSでの処理やRelay・AppViewへの反映には通常の通信・処理の遅延はあります）。次に、charterは同期の目標に「データ削除の通知」を含めており、追記しかできない台帳とは前提が逆です。個人データを扱う国内サービスでは、この差は無視できません。

### Web5との混同｜2024年11月のTBD終了方針の表明と別系統の設計

混同のもう1つの原因が「Web5」です。Web5はBlock傘下のTBDが進めていた分散型アイデンティティ構想で、AT Protocolの基盤技術だったことはありません。Blockは2024年11月7日の[2024年第3四半期の株主向けレター](https://www.sec.gov/Archives/edgar/data/1512673/000119312524253135/d835206dex991.htm)で「We are scaling back our investment in TIDAL and winding down TBD.」と述べました。TIDALは投資の縮小（scaling back）、TBDは事業の段階的終了（winding down）と書き分けられています。分散型を掲げた構想が停滞しやすい背景は[Web3.0が普及しない理由と将来性｜ガス代が100分の1になっても残る4つの壁【2026年】](/column/details/1283/)で扱っています。

## ActivityPub・Nostrとの違い｜移行・中継・識別子の比較

分散型SNSのプロトコルとして並べて語られるのが、Mastodonが使う[ActivityPub](https://www.w3.org/TR/activitypub/)（2018年1月にW3C勧告）と、鍵ペアだけで参加するNostrです。設計の違いは、アカウントを移すとき何が起きるかに一番よく表れます。

| 比較軸      | AT Protocol              | ActivityPub（名前・移行はMastodonの例） | Nostr           |
| -------- | ------------------------ | ----------------------------- | --------------- |
| アカウントの実体 | DID＋署名付きリポジトリ            | サーバー上のアカウント                   | secp256k1の鍵ペア   |
| 名前の形     | ドメイン名（例 bsky.app）        | ＠ユーザー＠サーバー                    | 公開鍵             |
| サーバー移行   | DIDを維持し、データ転送と鍵・所在の更新で移行 | 旧サーバーのリダイレクトが要り過去データは残る       | 鍵を持ったまま別のリレーへ移る |
| 中継の役割    | Relayが全PDSの更新を集約         | サーバー同士が直接配送                   | リレーが投稿を保存・配信    |
| 標準化      | IETFで作業中                 | W3C勧告（2018年）                  | NIPと呼ぶ文書群で管理    |

Nostrの[NIP-01](https://github.com/nostr-protocol/nips/blob/master/01.md)は「各ユーザーは鍵ペアを持つ」と定め、署名にsecp256k1のSchnorr署名を使います。鍵が本人そのものなので乗り換えは自由ですが、鍵を失えば本人性も失います。AT Protocolのdid:plcは、署名鍵とは別に回転用の鍵（rotation key）を持たせ、鍵の差し替えや回復ができるようにしている点が違います。

用語の衝突にも注意が要ります。Nostrの「リレー」は投稿を保存して配るサーバーで、ユーザーが自分で選びます。AT ProtocolのRelayは、収集対象のPDSの更新をまとめて配る集約役です。ネットワーク全体を対象にするRelayもありますが、すべてのRelayが全PDSを収集するとは限りません。同じ名前でも役割は別物です。

## アーキテクチャ｜PDS・Relay・AppViewの三層

### PDS｜ユーザーのリポジトリと署名鍵を持つホスト

PDS（Personal Data Server）は、[公式用語集](https://atproto.com/guides/glossary)で「ユーザーをホストするサーバー。常にユーザーのデータリポジトリと署名鍵を保存する」と定義されています。ユーザーは必ずどれか1つのPDSに所属します。Bluesky社が運営する大規模PDSに乗ることも、自分で立てることもできます。2026年6月の参照実装v0.4.5006からは、PDS上の`/account`で連携アプリの取り消しやパスワード変更ができ、Blueskyアプリを経由せずにアカウントを管理できます。

### RelayとJetstream｜全PDSの更新を1本に集約する層

Relayは、PDSからリポジトリの更新を集めて、変更イベントの流れ（firehose）を1本にして配る役割です。ただし用語集は「Relayは最適化であり、厳密に必要なものではない」と明記しており、小規模なアプリならPDSと直接やり取りしても構いません。

2025年のSync 1.1以降、Relayはリポジトリの全コピーを持たない軽量な運用に移り、直近のイベントだけを保持しています。CBORで符号化されたfirehoseの代わりに、必要な分だけを素のJSONで配るのがBluesky社のJetstreamです。2026年8月13日に公開された[Jetstream v2](https://atproto.com/blog/introducing-bluesky-protocol-services)は、過去の任意の時点から追いついてライブ配信へ切り替える「Network Replay」に対応しました。ライブ配信は認証なしで使えますが、アーカイブの取得にはAPIトークンが要ります。

### AppView｜同じデータから別々のサービスを作る層

AppViewは、ネットワーク全体のデータからタイムラインや検索のインデックスを作り、アプリの画面に渡す層です。Bluesky以外のアプリはこの層を差し替えて成り立ちます。モデレーション用のラベルを付けるLabelerと、表示順を決めるフィードジェネレーターも外部に出せます。「何を隠すか」「何を優先して見せるか」の判断を、プラットフォーム運営者から切り離せるのが、中央集権型SNSとの実務的な違いです。

## アイデンティティ｜ハンドルとDIDの二層構造

AT Protocolは、人が読む識別子（ハンドル）と機械が使う識別子（DID）を分けています。この二層がアカウント移行を可能にしています。

### ハンドル解決の2方式｜DNS TXTと.well-known

[ハンドルの仕様](https://atproto.com/specs/handle)は、ハンドルからDIDを引く方法を2つ定めています。1つはドメインの\_atprotoサブドメインにTXTレコードを置き、値を「did=」に続くDIDとする方式。もう1つはドメイン上の`/.well-known/atproto-did`でDIDを返す方式です。ハンドルとDIDの双方向の検証が必須で、片側だけの設定では有効になりません。企業がコーポレートドメインをそのままアカウント名にできるのは、この仕組みのおかげです。

2026年10月12日に実行した結果です。bsky.appはDNS方式で解決しており、.well-known側は404を返します。bsky.socialのサブドメインのハンドルは.well-known方式です。

```
$ dig +short TXT _atproto.bsky.app
"did=did:plc:z72i7hdynmk6r22z27h6tvur"
$ curl -s -o /dev/null -w "%{http_code}\n" https://bsky.app/.well-known/atproto-did
404
$ curl -s https://atproto.bsky.social/.well-known/atproto-did
did:plc:hrln33aoqxc5kdnwknaq3aki
```

自社ドメインで設定するなら、DNSを触れるならTXT方式、Webサーバーしか触れないなら.well-known方式を選びます。

### did:plcとdid:web｜DIDドキュメントが持つ3要素

[DIDの仕様](https://atproto.com/specs/did)がサポートする方式は2つです。AT Protocol向けに作られた自己認証型のdid:plcと、HTTPSに基づくW3Cコミュニティドラフトのdid:webです。DIDドキュメントには、そのDIDが名乗るハンドル（alsoKnownAs）、署名用の公開鍵（verificationMethod）、PDSの所在（service）の3つが入ります。PLCディレクトリで引くと、実物が確認できます（@contextは省略）。

```
$ curl -s https://plc.directory/did:plc:z72i7hdynmk6r22z27h6tvur
{
  "id": "did:plc:z72i7hdynmk6r22z27h6tvur",
  "alsoKnownAs": ["at://bsky.app"],
  "verificationMethod": [{
    "id": "did:plc:z72i7hdynmk6r22z27h6tvur#atproto",
    "type": "Multikey",
    "controller": "did:plc:z72i7hdynmk6r22z27h6tvur",
    "publicKeyMultibase": "zQ3shQo6TF2moaqMTrUZEM1jeuYRQXeHEx4evX9751y2qPqRA"
  }],
  "service": [{
    "id": "#atproto_pds",
    "type": "AtprotoPersonalDataServer",
    "serviceEndpoint": "https://puffball.us-east.host.bsky.network"
  }]
}
```

PDSを移してもDID自体は変わらないため、過去の投稿への参照やフォロー関係は壊れません。ただし移行ではDIDドキュメントのPDSの所在（serviceEndpoint）に加えて署名用の公開鍵なども更新し、リポジトリや画像・動画の転送も別に行います。

### did:plcのディレクトリ依存｜運営はPLC Organizationへ移行中

did:plcは完全な分散型ではありません。[did:plcのリポジトリ](https://github.com/did-method-plc/did-method-plc)は「中央のディレクトリサーバーが操作を収集・検証し、各DIDの操作の透明なログを維持する」と説明しています。同じREADMEによれば、登録されたアカウント識別子は4,000万を超え、その大半が1つのディレクトリに解決を頼っています。

運営主体は変わりつつあります。READMEは「2026年にPLC Organizationが中立的な管理者として設立された」と記し、[同組織のサイト](https://plcred.org/)はスイスの社団（Verein）で、方針づくりと運用体制の構築を進めている段階だと説明しています。Bluesky社は2026年2月、全データを複製して検証する読み取りレプリカも公開しました。ディレクトリが履歴を書き換えたときの証拠を残す「証人」の役割で、公式記事では2026年2月18日時点の全件同期に約150GBの空き容量が必要とされ、必要量は時間とともに増えると説明されています。

依存を切りたいならdid:webを選び、自社ドメインのHTTPSでDIDドキュメントを配ります。ただし識別子がホスト名そのものなので、ドメインを手放すと同じDIDを使い続けられません。鍵を失ったときに回転用の鍵で取り戻すdid:plcの仕組みもありません。可用性と回復性のどちらを重く見るかの判断です。

## 非公開データ｜2026年8月に始まったAtproto Spacesのアルファ版

AT Protocolのデータは、投稿もフォローも設計上すべて公開です。設定や会員限定の掲示板のような非公開データを扱うため、private data、permissioned dataと名前を変えてきた拡張が、2026年8月20日に[Atproto Spacesのアルファ版](https://atproto.com/blog/atproto-spaces-alpha)として公開されました。

### Spacesの仕組み｜space authorityによるDID単位のアクセス制御

公式ブログは、Spaceを「アクセスを限定できる小さなatprotoネットワーク」と説明しています。どのDIDがSpaceにアクセスできるかは、space authorityと呼ぶDID（自分のアカウントの場合もある）が決めます。レコードは書いた人のPDS上に、Spaceごとの専用リポジトリとして置かれます。公開データとの大きな違いはRelayを通らない点で、アプリはPDSから直接データを同期します。

誤解しやすいのは機密性です。公式ブログは「Spacesが与えるのはアクセス制御であって、機密性ではない」と明記しています。データは暗号化されず、アクセス権を持つユーザーとアプリなら誰でも読めます。アクセスを許可した相手やPDS運営者にも読ませたくない情報を、暗号化で保護する仕組みではありません。

### アルファ版の制約｜本番データを入れてはいけない段階

アルファ版では、試験用PDS、SDKのアルファ版（npmのalphaタグ）、サンプルアプリ、自前PDS用のDockerイメージが公開されています。一方で公式ブログは、セキュリティレビュー前であること、バックアップがないこと、試験用PDSはアルファ終了時に削除されることを挙げ、本番利用をはっきり禁じています。正式公開は「年内」が目標とされています。

## 標準化と運営｜IETF ATPワーキンググループと商標

### charterの範囲｜5項目の成果物と対象外の領域

Bluesky社の[2026年4月2日の告知](https://atproto.com/blog/kicking-off-the-atp-working-group)によれば、IETFのATP（Authenticated Transfer Protocol）ワーキンググループが承認されました。charter文書のリビジョン01は2026年3月19日付です。最初の作業範囲は、公開リポジトリのデータ構造、その同期の仕組み（firehose）、at URIスキーム、アカウント識別子の解決システムの要件・選定基準と推奨方式の登録簿、展開と相互運用性テストに関する運用上の考慮事項の5項目です。識別子については、既存のPLCとdid:webとの後方互換性も維持します。

charterが対象外とするのは、非公開・限定公開データの転送、アプリ固有のデータスキーマ、SNSとしての意味論の3つです。Bluesky社の告知は、Lexiconの公開方法やラベルによるモデレーションも当初の範囲に入らないと補足しています。Spacesもアプリの仕様も、当面はIETFの外で決まります。

### IETF 126の論点｜署名アルゴリズムとAT URIの書式

2026年7月23日にウィーンで開かれた[IETF 126の会合の議事録](https://datatracker.ietf.org/meeting/126/materials/minutes-126-atp-202607231430-00)では、リポジトリと同期の2本のドラフトを1本にまとめる案、識別子を先に進めてURIを後にする順序が話し合われました。署名アルゴリズムについてはsecp256k1を外してML-DSAへ向かう提案が出され、AT URIの書式も、現行の形を変えるべきかで意見が分かれています。

2026年10月時点で、ワーキンググループとして採択された文書はまだありません。ベースになっているのはBluesky社の個人ドラフトで、draft-holmgren-at-repositoryの最新版は2026年9月23日付のリビジョン03です。署名方式やURIの書式は今後変わりうると見ておくのが安全です。

### 商標の取得｜事業で名前を使うときの線引き

2026年7月15日、Bluesky社は「AT Protocol」「atproto」を含む[商標の権利を取得した](https://atproto.com/blog/at-protocol-trademark)と発表しました。法的措置を示唆していた他社から買い取った、防御目的の取得です。互換を名乗る、ドキュメントを書く、パッケージ名に使うといった記述的な利用にライセンスは要りません。製品名や社名を「AT Protocol」を軸に組み立てる場合や、ロゴを使う場合は必要です。

## 導入判断｜PDS自己ホストの要件と、採用を見送るべき場面

### 自己ホストのサーバー要件｜1コア・RAM 1GB・SSD 20GB

Bluesky社の[PDSリポジトリ](https://github.com/bluesky-social/pds)の推奨構成は次のとおりです。ほかに公開IPv4アドレス、公開DNS名、80番と443番のTCPポートへの受信許可が必須です。インストールスクリプトはUbuntu 20.04・22.04・24.04とDebian 11・12・13に対応しています。

| 項目      | 推奨値          |
| ------- | ------------ |
| OS      | Ubuntu 24.04 |
| メモリ     | 1 GB         |
| CPUコア数  | 1            |
| ストレージ   | 20 GB SSD    |
| 想定ユーザー数 | 1〜20         |

小規模チームならVPS 1台で足ります。2026年8月にはOpenTelemetryのメトリクス出力に対応し、PrometheusとGrafanaの監視一式も同梱されました。これはPDSの要件で、ネットワーク全体を同期するRelayの要件ではありません。自前で持つのはPDSだけ、RelayとAppViewは既存のものを使う、という構成が現実的な出発点です。

### 採用を見送るべき場面｜非公開データ・運営依存・互換性の要件

次のいずれかに当てはまる案件では、2026年10月時点でAT Protocolを基盤に選ぶべきではありません。

- 扱うデータの中心が非公開情報である。Spacesはアルファ版で本番利用が禁じられており、設計上もアクセス制御だけで暗号化はされません。
- 特定の運営主体への依存を排除することが要件になっている。did:plcのディレクトリはPLC Organizationへの移管途上で、商標もBluesky社が保有しています。
- 仕様の安定を前提に長期保守を約束する必要がある。SDKの@atproto/apiは2026年10月9日公開の0.24.3で1.0に達しておらず、Bluesky社はTypeScript SDKを@atproto/lexを土台に作り直しました。採用するパッケージの変更履歴と互換性方針の確認が要るうえ、IETFでは署名方式やURIの書式が議論されています。

逆に、公開コンテンツを扱い、アカウントの可搬性やモデレーション方針の独立性に価値がある用途なら、AT Protocolは採用候補になります。既存のPDS・Relay・AppViewを使う小さなアプリから始めれば、PDSの自己ホストは後回しにできます。ただしアプリの開発・運用と将来の移行の費用は別にかかるので、どの層を自前で持つかを先に決めてから見積もります。atprotoと連携する[業務用・Webアプリの開発](/service/apps/business/)でも、この線引きが見積もりの前提になります。did:plcの実装はMITとApache 2.0のデュアルライセンスで、Bluesky社がソフトウェア特許の不行使を表明している点も企業利用の材料です。

## よくある質問

### AT Protocolはブロックチェーンを使っているのですか？

使っていません。公式FAQは「AT Protocolは連合型プロトコルで、ブロックチェーンではなく、ブロックチェーンを使ってもいない」と答えています。ブロックチェーンとの関係を述べる解説は、Web5という別構想との混同か古い情報と考えてください。

### atprotoとBlueskyは何が違いますか？

atprotoはプロトコルの略称、Blueskyはその上に作られたアプリケーションと運営企業の名前です。Bluesky以外のアプリも同じアカウントで使えます。アプリとしての使い方は[ブルースカイ（Bluesky）とは？使い方・Xとの違い・始め方【2026年最新】](/tech/details/7493/)で扱っています。

### Web5とAT Protocolはどのような関係ですか？

直接の関係はありません。Web5はBlock傘下のTBDが進めていた分散型アイデンティティ構想で、Blockは2024年11月7日の株主向けレターでTBDの段階的終了（winding down）を表明しました。どちらもDIDを使いますが、DIDはW3C由来の汎用の仕組みで、同じ系統の根拠にはなりません。次世代Web全般の議論はWeb4.0とは？欧州委員会の定義とWeb3.0との違い、2026年の動向と予測もあわせてご覧ください。

### AT Protocolで非公開の投稿や限定公開のデータは扱えますか？

2026年10月時点では、試験用としてのみ扱えます。2026年8月20日にAtproto Spaces（旧称permissioned data）のアルファ版が公開され、Spaceごとにアクセスできる相手を限定できるようになりました。ただし暗号化はされず、アルファ版は本番利用が禁じられています。正式公開は2026年内が目標とされています。

### AT Protocolは標準化されているのですか？

作業が始まった段階です。IETFのATPワーキンググループが2026年3月に承認され、リポジトリの構造、同期、at URI、識別子の解決、運用上の考慮事項の5項目が成果物とされました。2026年10月時点でワーキンググループとして採択された文書はなく、確定した標準はまだありません。非公開データとアプリ固有のスキーマはスコープ外です。

## 関連記事

- [ブルースカイ（Bluesky）とは？使い方・Xとの違い・始め方【2026年最新】](/tech/details/7493/)
- [分散型メディアとは？定義とメリット・デメリット、BuzzFeedが示した10年後の答え](/column/details/6524/)
- [Web3.0が普及しない理由と将来性｜ガス代が100分の1になっても残る4つの壁【2026年】](/column/details/1283/)
- [OAuth 2.0とは？仕組み・認可フローと認証との違い、OAuth 2.1の変更点をわかりやすく解説](/tech/details/8369/)

---

出典: [AT Protocol（atproto）とは？ブロックチェーンとの違いと仕組み【2026年10月】](<https://www.issoh.co.jp/column/details/1935/>)（株式会社一創）