PRO+ 公開サンプル · ログイン不要で全文をご覧いただけます。
インストール前の試食 · ログイン不要
appwrite/appwrite バックエンド・DB
会員が自分の記録と写真を見るアプリを例に、ログイン・記録保存・ファイル保管を6段階の手描き動画で理解します。他の会員へデータを見せないために、何を決めるかも確認します。
69秒の動画公式画面3枚選び方01 · 動画でひと目に
韓国語音声・字幕の動画です。ログインと権限、記録と写真の保存、2アカウントでの確認を手描きで説明します。ギット飯の説明図で、実行やセキュリティテストの結果ではありません。
02 · 公式画面を読む
利用者向けのアプリ画面ではなく、開発・運用担当者が見るAppwriteの管理画面です。以下の活用案は、個人の記録アプリにつなぐと仮定したギット飯の解説です。
01 / Auth · 会員アカウント
画面内の英語・名前・メールアドレスは原作のサンプルデータです。画面内のPro表示はAppwriteのプランで、ギット飯PRO+とは別です。この画像だけでは必要なプランや権限設定を判断できません。
画面：Appwriteおよび貢献者 · BSD-3-Clause。手描き・解説・動画：ギット飯。文書確認：2026年10月15日 / 元画像確認：2026年10月11日。 画像資料のライセンス ↗
03 · 選び方
以下の状況を仮定した選び方です。条件が変わると、向いている道具も変わります。
今回の二候補では、Appwrite Cloud の有料運用から検討します。PocketBase も会員・データ機能を提供しますが、このチームが担えないサーバー管理と更新の責任が残ります。個人データの公開範囲と復元対象は、アプリに合わせて決める必要があります。
どちらも会員・データ・ファイルの機能を自分のアプリに組み込む候補です。以下では同じ質問で Appwrite Cloud と自己運用の PocketBase を比較します。Appwrite の自己運用は Cloud と運用責任が異なります。
自分の選択では仮定したチームでは、機能の数よりこの差が Appwrite Cloud を先に選ぶ理由です。
自分の選択ではどちらも可能なので「個人データがある」だけで一方に決まりません。どちらもログインをつなぐだけでは保護は完成しません。
自分の選択ではこのチームでは無料かどうかより、停止や版の変更に対応できる条件が先です。有料 Cloud も無停止を実測・保証したという結論ではありません。
自分の選択ではどちらも完成済みの会員事業や決済サービスを作ってはくれません。既存の業務コードがあるなら、実行環境が合うかも選択条件です。
自分の選択ではCloud の利用料と自前サーバー料金だけでは、運用時間や復旧の費用が抜けます。実際の利用量が不明な今、どちらが安いかは決められません。
新しい会員サービスを作る開発者はいるがサーバー運用者はおらず、管理型サービスの費用を払えるなら Appwrite Cloud を先に見ます。
小さな自前サーバーを担当する人がいて、更新・復旧・版の変更を自分で扱い、シンプルな構成を望むなら PocketBase を検討します。
PocketBase を先に検討します。
一つの実行ファイルにアカウント・データ管理がまとまり、小さな自前サーバーを構成しやすいからです。ただし、1.0 前の版変更に伴う手動の変更作業も引き受ける必要があります。
既存システムを維持し、不足する機能だけを比較します。
候補の基本機能があるというだけで移す必要はありません。解決したい不便が明確なら、アカウント・データ・業務コードを変更する理由が生まれます。
どちらかにすぐ決めません。
Appwrite Free は開発活動がなければ一時停止する場合があり、PocketBase は運用する人が必要です。無料であることだけでは運用条件を満たせません。
Appwrite Cloud の推薦を取り下げ、自己運用の候補を比較し直します。
Appwrite の自己運用と PocketBase が候補になります。どちらもサーバー・復旧の担当と保管場所の条件が先に必要なので、自動的に PocketBase とは決めません。
ここでは答えを仮定していません。ご自身の状況と照らし合わせて読んでください。
現在のログイン・データ保存ツールと変えたい不便を一つ書き出し、既存機能や設定で解決できるか確認します。
その後の選び方既存機能で解決できるなら維持します。交換が必要なら、アカウント・データ・参照権限の移行範囲を決めてから比較し直します。
更新失敗やデータ削除時に復旧を担う人と、許容できる停止時間を書き出します。コードを書けることと運用を担当できることを分けて確認します。
その後の選び方担当者がいなければ管理型の候補を優先します。担当者がいて停止・版変更への対応を許容できるなら PocketBase も残します。厳しい可用性保証が必要なら、この解説だけでは確定しません。
想定アクティブ会員数・月間保存量・転送量・メール数を現在の Cloud 料金と上限に当てはめます。自前運用はサーバー・メール・バックアップ費用と担当者の時間を加え、アカウント・記録・添付ファイルの復元方法を個別に確認します。
その後の選び方予算内で必要な復元範囲を満たす候補を残します。費用や復元方法が未確認なら判断を保留します。導入・測定前に速度や最大処理量の優劣は確定しません。
Appwrite はアプリの裏側で本人確認・データ保存・アクセスの許可を担当する開発ツールです。会員が自分のメモを保存し、後から開くアプリに使えます。利用者が押すボタンやメモ画面は開発者が作ります。
会員ごとに記録を残し、ほかの会員には見せたくない。
ログインした人と各メモの閲覧範囲を結び付け、個人データを管理します。
保存した記事の題名と URL を、自分の一覧から探せるようにしたい。
会員別に題名と URL を保存できます。記事の自動読み取りや要約は別に作ります。
今日学んだ内容や進み具合を会員別に残したい。
記録を保存し、誰が見られるかを決めます。カレンダー・進捗表示・学習の提案はアプリ側で作ります。
上の場面と以下の流れは、公式のログイン・個人データの例と取得・更新の文書をつないだ利用案です。完成アプリの実演ではなく、メモ画面を作って接続した場合を想定しています。
利用者に見えるのは自分のメモ画面。その裏のログイン確認とデータ保存を Appwrite に任せる仕組みです。
まず小さな記録アプリでログイン・権限・保存・復元をつなぎます。別の会員の記録と写真を開けないことまで確かめてから、機能を広げます。
動画の要点はログインとアクセス権限を分けることです。Authが誰からの要求かを確認し、データベースとStorageが設定された権限に従って記録とファイルを提供します。画面・業務ルール・公開範囲と復元方法はアプリを作るチームが決めます。
接続先とプロジェクトを選び、メール・パスワードから以降の要求で使うログイン状態を作ります。この結果は「全データへアクセス可能」という権限ではありません。
この行の参照・更新・削除を特定会員へ与えます。公式文書は行単位権限を有効にする Row Security、テーブルの作成許可、全体の参照・更新・削除を許可しない設定を組み合わせます。
以下は自分の条件に照らして確認するための手順です。ギット飯による実行結果ではありません。
残すもの所有者だけに三操作を許す九マスの表と、公開資料の別方針。
残すもの全体の読み取りが個人メモの方針を広げるか分かる権限設定一覧。
残すものブラウザーに置く値とサーバー専用秘密値の配置表、実装後に確認する拒否応答一覧。
権限表の全マスが設定項目へつながれば、試験用アカウントとメモで実アクセス確認を計画します。
テーブルの広い許可が残る、またはサーバーキーをブラウザーへ置く設計なら公開しません。
画面や使用例は公式資料から。説明と活用案をギット飯が加えました。
公式例は接続するアプリを指定し、メールとパスワードが合えばログイン状態を作ります。画面のログインボタンからつなぐ処理に当たります。下のアカウント値は説明用で、登録画面やログイン画面自体を作るコードではありません。
会員が自分のデータを見る前に、本人を確認するとき。
import { Client, Account } from "appwrite";
const client = new Client()
.setEndpoint('https://<REGION>.cloud.appwrite.io/v1') // Your API Endpoint
.setProject('<YOUR_PROJECT_ID>'); // Your project ID
const account = new Account(client);
const result = await account.createEmailPasswordSession({
email: 'email@example.com',
password: 'password'
});
console.log(result);appwrite contributors · BSD-3-Clause
元の資料を見る ↗題名一つを保存し、特定の会員へ読み取り・更新・削除を許可する公式コードです。個人メモや保存一覧に応用できます。本人だけに見せるには保存先全体を全員に開放せず、一件ごとの権限を適用する Row Security も有効にします。
同じアプリでも、会員ごとに自分の記録だけを見せたいとき。
let promise = tablesDB.createRow({
databaseId: '<DATABASE_ID>',
tableId: '<TABLE_ID>',
rowId: ID.unique(),
data: { 'title': 'My Private Row' },
permissions: [
Permission.read(Role.user('<USER_ID>')), // Only this user can read
Permission.update(Role.user('<USER_ID>')), // Only this user can update
Permission.delete(Role.user('<USER_ID>')) // Only this user can delete
]
});appwrite contributors · BSD-3-Clause
元の資料を見る ↗選んだ理由：ログインとアクセス権限を分け、Cloud・自己運用の責任と2アカウントでの確認をつなげます。公式画面は理解を助ける別の例として残しています。
公式資料を読み解いた編集記事です。新しい動作確認や導入効果の測定を行った記録ではありません。原作の画面内の言語・数値は保持しています。