保護者と教員の連絡アプリを作る方法

保護者–教員連絡アプリが解決すべきこと

保護者–教員連絡アプリは単なる「携帯でのメッセージング」ではありません。本来の役割は、適切な人に対してタイムリーで関連性の高い情報を届けつつ、常時の中断を生まないことです。

目標：ノイズを増やさずに明確さを届ける

学校は既に紙の連絡、メール、複数のアプリで更新を送っています。アプリは「そのメッセージはどこに行った？」という問題を減らし、通知疲れを防ぐべきです。

良い成果の例：

• 保護者が時間に敏感な通知（例：早帰り、時間割変更）を確実に見る
• 教師が数秒で更新を共有できる
• すべての人が過去のメッセージを簡単に見つけられる

対象ユーザー（とそれぞれのニーズ）

最低でも下記3つのグループを設計対象にします：

• 教師： 手早く投稿できること、テンプレート、予約投稿、適切な家庭に届く安心感
• 保護者／法定代理人： 読みやすいシンプルな更新、必要な場合の翻訳サポート、受領確認や返信の簡便さ
• 学校管理者： 監督、ポリシー管理、全校向けの告知ツール

対応すべき典型的な更新

多くの学校では次のような構造化された更新が必要です：

宿題や教室のお知らせ、行動に関する通知（機微情報）、出席／欠席、リマインダー（書類、料金）、イベント通知、カレンダーの変更。

成功指標は早めに定義する

機能を作る前に「動いている」と判断する基準を合意してください。例えば：

• 重要メッセージの既読率
• 返信が必要な場合の平均応答時間
• 見落とし通知の削減（フォローアップの減少で追跡）

範囲：初回リリースと後続フェーズの区別

MVPでは、信頼できる配信に注力します：告知、1対1のメッセージ、添付ファイル、基本的な受領確認。

高度な機能（分析ダッシュボード、連携、自動化）は、実際の利用が示すニーズに応じて後回しにしてください。

ユーザーと日常のワークフローを理解する

アプリの成否は、実際の学校の日常にフィットするかどうかで決まります。機能を選ぶ前に、人々がコミュニケーションするその時に何をしているかを把握してください：子どもの見守り、教室間の移動、通勤、シフト勤務、家族のために翻訳する必要など。

既存ツールの痛みから始める

学校がすでに使っているもので繰り返し起きる摩擦を探します：

• 最新の指示が埋もれるメールチェーン（および「全員に返信」混乱）
• ランドセルから出てこない紙の連絡
• 境界が曖昧になりトピックが混ざり通知が洪水のようになるグループチャット
• カレンダー、成績、告知で食い違う複数アプリ

名前を消したスクリーンショットや匿名化したエピソード（「先週の木曜、下校後に〜」）のような具体例を集めると、意見よりも良い設計指針になります。

小規模でバランスの取れたインタビューを行う

まずは教師5～10名、保護者5～10名を目安に。質問は現実に即したものにします：

• 「最後に更新を送受信したときの流れを教えてください」
• 「迅速に返信するのが難しかったのは何ですか？」
• 「どの更新が緊急で、どれが情報提供ですか？」

代理の先生、離婚した共同親、接続が限られる家庭、翻訳に頼る保護者などのエッジケースも含めてください。

重要な瞬間をマップする

時間帯と文脈ごとのコミュニケーション要件をプロットします：

• 登校時（直前の変更）
• 下校時（迎えの調整、事案）
• 夕方（宿題の確認）
• 週末（イベント、リマインダー）

これにより通知ルールや期待される応答時間を定義できます。

インサイトを要件に落とす

早い段階でアクセシビリティ要件（対応言語、読みやすさ、十分なタップ領域、シンプルなナビゲーション）を文書化してください。そして必須要件（例：確実な配信、翻訳、サイレント時間）とあれば嬉しい要望（テーマ、ステッカーなど）を分け、MVPの範囲定義の基礎にします。

優先すべきコア機能

アプリはやり取りを減らし、教職員の工数を増やさずに家族が情報を把握できることが成功の条件です。最初は共通の通信場面をカバーする小さな機能セットから始め、学校が使い始めてから段階的に複雑さを追加してください。

セキュアな1:1メッセージ（教師 ↔ 保護者）

プライベートメッセージはアプリの中核ですが、ガードレールが必要です。体験はシンプルに：生徒と教師の組み合わせごと（またはクラスごと）に単一スレッドを用意し、文脈を失わせないようにします。

PDFや画像などの添付、翻訳プレビュー（必要な場合）、明確な配信ステータス（送信済み／配達済み）といった基本をサポートします。チャット的な期待を避けるために、UIでオフィスアワーや自動応答オプションを提示するなどの規範を示してください。

クラス／学校のお知らせ（任意で既読機能）

お知らせは重複質問を減らし、全員が同じ情報を見ることを保証します。一対多の投稿として、タイトル、短い本文、重要日付、添付ファイル（任意）という読みやすい形式にしてください。

既読は重要な通知では有用ですが、家庭や教職員のプレッシャーを高めることもあります。投稿ごと（または学校ポリシーごと）にオプション化し、「閲覧した」など柔らかい指標を検討してください。

家族が実際に使うカレンダー

組み込みカレンダーは「何がいつ起きるか」を答えるべきです。保護者会、早帰り、締切、遠足、面談などを含めます。

操作性を重視：ワンタップでデバイスカレンダーに追加、明確なタイムゾーン、サイレント時間を尊重したリマインダー。既存の学校カレンダーフィードがあれば、職員に二重登録を求めずに同期を優先してください。

生徒個別の更新（適切なものだけ）

保護者は生徒個別のタイムリーな情報を望みます—進捗ノート、行動、出席、簡単なチェックインなど。学校ごとに共有できる内容が異なるため、これらは自由入力ではなく、構造化されたテンプレートとして設計し、カテゴリごとに設定可能にしてください。

例："進捗ノート"は短いテキスト＋タグ（練習が必要／改善中／素晴らしい）で一貫性を保ち、誤解を減らします。

検索とメッセージ履歴で文脈を素早く

保護者が「前回は何を決めた？」と聞くとき、アプリが数秒で答えられるようにしてください。メッセージとお知らせの全体検索、学年／クラス／日付でのフィルタ、デバイスを変えても消えない信頼できる履歴を追加します。

一貫したスレッド表現、添付の確実な参照、明確なタイムスタンプがあることで、忙しい週でもアプリへの信頼感が築けます。

ユーザーロール、アカウント、権限

ロールと権限を正しく設計することが、誤送信などの重大なミスを防ぎます。

実際の学校の役割に沿って定義する

多くのアプリで必要になる主要ロールは3つです：

• 保護者／法定代理人： 更新を受け取り、通知を受け取る。許可された範囲で職員にメッセージ可能。
• 教師／スタッフ： 担当クラスに告知、学級内で生徒関連のノートを送信、名簿管理は制限内で実施。
• 管理者： 学校全体の設定を管理、ユーザー確認、名簿インポート、アクセスの監査。

カウンセラー、コーチ、代行教員などがいる場合は、特別な新ロールを作るよりも、権限を限定した“スタッフ”として扱うのが管理しやすいです。

表示ルール：クラス対生徒レベル

2つの明確な通信チャネルを作ります：

• クラスレベル： お知らせ、宿題リマインダー、時間割変更。対象はそのクラスに紐づく保護者。
• 生徒レベル： 出席ノート、行動や進捗の機微な更新、個別のリマインダー。対象は該当生徒に紐づく保護者のみ。

UIは送信者が誤って対象を選ばないように工夫してください。例：送信前に「送信先：クラス3B」や「送信先：生徒：Maya K.」と目立つ確認を必須にする等。

学校が信頼できる認証とオンボーディング

一般的な認証オプション：招待コード、学校管理による名簿インポート（SIS/CSV）、管理者承認。多くの学校は名簿インポート＋例外は管理者承認の組み合わせを好みます。

複数保護者と複数クラスの関係

1人の生徒に複数の保護者、教師が複数のクラスを持つケースをサポートしてください。モデルは柔軟なリンク（Guardian ↔ Student、Teacher ↔ Class）にして、名簿が変われば権限が自動的に更新されるようにします。

ロックアウトさせないアカウント復旧

端末変更を簡単にするため、電話／メール認証、バックアップコード、管理者支援の復旧経路を提供します。復旧時にユーザーの権限が拡張されてしまわないよう注意してください。

効果的なメッセージと通知設計

通知がうるさく不明瞭だと保護者はアプリをミュートします。良い設計は各メッセージを「誰に、どれくらい急いで、どの形式で届けるか」という判断として扱います。

緊急アラートと通常リマインダーを分ける

すべての更新がロック画面の割り込みに値するわけではありません。少なくとも2種類の通知を用意します：

• 緊急アラート（休校、安全、直前の時間変更）：既定でプッシュ、学校ポリシーに応じてSMS／メールを続ける。
• 通常リマインダー（翌日の遠足、提出物、週次の宿題）：通常のプッシュまたはアプリ内受信箱で配信、可能ならグループ化する。

この分離により、家族は今対応すべきか後でで良いかを判断しやすくなります。

サイレント時間と頻度コントロール

保護者と教師はスケジュールが違います。サイレント時間（例：21:00–7:00）や頻度設定を提供してください：

• 非緊急アイテムのデイリー／ウィークリーのダイジェスト
• クラスや生徒ごとの購読トグル
• 「1週間ミュート」機能

教師向けには「翌朝に送信」や、何家庭に通知が届くかをプレビューで見せるなどの安全策を追加してください。

教師の時間を節約するテンプレート

教師は同じ内容を繰り返し送ることが多いです：リマインダー、持ち物、降園方法の変更、未提出の連絡など。編集可能なテンプレートを用意します：

• クイック選択カテゴリ（宿題、時間割、行動、お知らせ）
• 自動で入る件名や推奨文言
• よく使うアクションボタン（RSVP、許諾書に署名、カレンダーに追加）

テンプレートはモバイルでの入力を減らし、クラス全体で表現の一貫性を保ちます。

混乱を招かない翻訳サポート

翻訳は早期に計画してください。選択肢：

• 組み込み翻訳（速度重視、"Translated"ラベルと原文表示）
• 手動翻訳（重要度の高いメッセージ）
• 外部ワークフロー（通訳者を使う地区向けのドラフト→校閲→送信）

作成画面でどの方式が使われるか明示し、教師が受信者に何が届くか把握できるようにします。

オフライン時でも見られるように

保護者は移動中や下校時に更新を確認することが多いです。最近のメッセージとお知らせをキャッシュしてオフラインでも閲覧できるようにし、接続回復時に新着が明確に分かる表示をしてください。

忙しい保護者と教師のためのUX/UIパターン

多くのユーザーは20〜60秒だけアプリを開きます。今日何が必要か確認し、返信やイベント確認を素早くできる設計にしてください。

ホーム画面は予測しやすく

シンプルなホーム画面は認知負荷とサポート要請を減らします。実用的な構成：

• Today（今日）： 対処が必要なもの（未読、今日のイベント、緊急告知）
• Messages（メッセージ）： 子ども／クラス別スレッド
• Announcements（お知らせ）： 学校／クラスの一斉投稿
• Calendar（カレンダー）： 開始／終了時刻、場所、メモ

必須をメニューの奥に隠さないでください。「Today」で重要なことが一目で分かれば、ユーザーは探す必要がなくなります。

アクションは分かりやすく（間違えにくく）

忙しい教師がどこをタップして教室の更新を送るのか迷わないようにし、保護者はどう返信すればよいか常に分かるようにします。

明確な主要アクション（例：「更新を送る」「返信」「イベントを追加」）を使い、重要な操作（クラス全体への送信など）には誰が受け取るかを示す短い確認ステップを入れてください。

平易な言葉のラベルを使う

アイコンだけに頼らず言葉を優先します。「Announcements」はメガホンアイコンより分かりやすいです。「欠席連絡」は「Attendance request」より直感的。アイコンを使う場合はラベルを併記してください。

メッセージのメタ情報も「Delivered」「Read」「Needs reply」のような平易な表現にします。

アクセシビリティは誰にとっても助けになる

アクセシビリティ機能は端のユーザーだけでなく、疲れている、注意散漫なユーザー全員に役立ちます。チェック項目：

• フォント拡大でレイアウトが壊れないこと
• 屋外での使用や古い端末を想定した高コントラスト
• スクリーンリーダー対応（論理的な読み順、ボタンにラベル）
• 片手操作を想定した大きなタップ領域

主要フローはプロトタイプで検証する

以下の2〜3のクリティカルフローをプロトタイプし、実際の保護者と教師でテストしてください：

1. お知らせを読み、受領確認する
2. 教師が生徒更新を送信し、保護者が返信する
3. カレンダーイベントを追加して通知を受け取る

これでどのラベルが混乱を招くか、どこで迷うかが早期に分かり、工数を掛ける前に簡素化できます。

プライバシー、安全、データ取り扱いの基本

家庭が重要視する情報を扱うため、最小限のデータ収集を設計の第一原則にしてください。選択は可視化し、ユーザーに説明できるようにします。

本当に必要な情報だけを集める

必須データの短いリストから始めます：保護者の氏名、生徒やクラスへの紐付け、サインインやアラート用の連絡先、メッセージ内容。その他はオプションにし、正当な理由がない限り求めないでください。

プッシュ通知の本文には生徒の詳細を極力入れないようにします。ロック画面プレビューは「Ms. Riveraから新着メッセージ」程度にとどめるのが安全です。ユーザーにプレビュー表示の選択肢を与えてください。

アプリ内でデータ利用を明示する

プライバシー情報を法務ページだけに隠さないでください。センシティブな項目の近くに「なぜこの情報が必要か」を短く書き、アプリ内で設定できるコントロール（通知プレビュー、連絡先の可視性、データのエクスポート／削除など）を用意してください。

保持と削除の方針（添付を含む）

メッセージや写真、ファイルの保持ルールを決めます。「削除」が意味する範囲：端末上のみか、サーバーから完全に削除するか、バックアップからも一定期間後に削除するか、教師が全員分を消せるのか自分だけかを明記してください。

管理者ツールで驚きを防ぐ

学校側の管理と説明責任のために管理者機能を早めに計画します：

• 監査ログ（誰がいつ何にアクセスしたか）
• 生徒のクラス変更時の迅速な対応ツール
• 職員の離籍や保護者からの削除要請に対応する機能

これらはリスクを減らし、将来的なコンプライアンス要件への対応を容易にします。

適切な構築アプローチとアーキテクチャの選択

構築方法はローンチまでの速度、ネイティブ感、保守コストに影響します。

方法の選定

**ネイティブ（iOSとAndroidを別々に）**は最高のパフォーマンス、カメラやプッシュの深い連携、プラットフォームに最適化されたUIが必要な場合に適します。

**クロスプラットフォーム（Flutter/React Native）**は学校アプリではバランスが良い選択です：コードベースを共有でき、反復が速く、デバイス機能にも良くアクセスできます。

**レスポンシブWebアプリ（PWA）**はパイロットや小規模校に向きます。配布や更新が簡単ですが、プッシュ通知やオフラインの挙動で制約が出ることがあります。

比較で考えるべきトレードオフ

• コストと速度： PWAが最速／最安、次いでクロスプラットフォーム、ネイティブは最も投資が必要
• デバイス機能： ネイティブが有利、クロスプラットフォームは近い、PWAはブラウザ依存
• 保守： 単一コードベース（クロスプラットフォーム／PWA）は簡単、2つのネイティブアプリは同期運用が必要

連携は早めに決める

手戻りを避けるために“真の情報源”を確認します：

• 名簿／SIS同期（生徒、保護者、クラス、職員）
• カレンダー（学校行事、授業スケジュール）
• メール／SMSフォールバック（プッシュが使えない場合の代替）

スケールを見据える：一校から学区全体へ

最初は単一キャンパスでも、将来的に複数校を扱えるように設計してください：テナント対応データ、役割ベースのアクセス、監査ログなど。これにより拡張が予測可能になります。

現実的なタイムライン（MVPからv2へ）

• Week 1–2： 要件、データモデル、連携方針の決定
• Week 3–6： MVP構築（メッセージ、告知、基本通知）
• Week 7–8： テスト、パイロットローンチ、サポートワークフロー
• v2（次の4–8週間）： 権限強化、テンプレート、カレンダー同期、分析の改善（参照：/blog/mvp-planning-and-feature-scoping）

速くパイロットを動かす現実的な道筋（手を抜かずに）

スピードが最大のリスクであれば、早期に実際にデプロイ可能なアプリを作り、学校のフィードバックで反復する方法が有効です。例えば、Koder.aiのようにチャットで画面やロール、メッセージフローを説明すると、動くReactウェブアプリ（とバックエンド）を素早く生成できるプラットフォームがあります。プロトタイプ、スナップショット、ロールバックといった機能は、権限ルールや通知ロジックを安全に試す際に役立ちます。

MVP計画と機能スコーピング

MVP（最小実用製品）は「最小で出せるアプリ」ではなく、「次週から実際のクラスで通信が明らかに楽になる最小の機能セット」です。

価値を証明する3〜5機能を選ぶ

最初のパイロットでは、コアループを支える機能に注力します：教師が送る → 保護者が素早く見る → 保護者が返信または受領確認する。

有効なMVPの例：

• クラス告知フィード（テキスト + シンプルな添付）
• ターゲット通知（プッシュ + 任意のメール）
• 双方向メッセージング（教師 ↔ 保護者、境界を明確に）
• 基本的な名簿と招待（管理者または教師主導）
• 簡易カレンダー項目（パイロットに必要なら）

多言語の自動化、詳細分析、複雑なスケジューリングは、基本が証明された後に回してください。

ユーザーストーリーと“完了”基準を書く

実際のタスクに即した短いユーザーストーリーを作成します：

• 教師がクラスに告知を投稿し、予約してPDFを添付できる
• 保護者が告知に返信またはメッセージを送り、配信状況が確認できる
• 管理者が教師と保護者を招待し、必要に応じて権限を剥奪できる

各ストーリーに受け入れ基準を定義します。例：「教師が投稿すると、該当クラスの全保護者に30秒以内に通知が届き、アプリ未インストールの保護者にはメールが送られ、投稿はクラスフィードに表示され、キーワードで検索可能である」など。

プロトタイプ → パイロット → 大胆に切る

まずクリック可能なプロトタイプ（Figma等）でフローを検証し、その後1クラスまたは1学年で1〜2週間の短いパイロットを実施します。

フィードバックを基に機能を削る・簡素化する・優先度を変える判断をしてください。教師が「投稿に時間がかかる」と言ったら、新機能を追加する前に作成速度を改善します。保護者が「通知が多すぎる」と言ったら、通知コントロールを改善してから範囲を拡げます。

ワイヤーフレームからビルド仕様へ

ワイヤーフレームは“何がどこにあるか”の合意形成を助け、ビルド仕様はそれを設計／開発／テストに落とし込みます。これにより学校向けアプリが場当たり的な決定で迷走するのを防げます。

画面一覧と各画面の役割（1段落ずつ）

最小限の画面を挙げ、それぞれの目的を一段落で記述します：

• オンボーディング： 学校選択、本人確認、ポリシー同意、通知設定
• クラス一覧： 保護者なら自分の子どもとそのクラス、教師なら担当クラスと最近のスレッドへのクイックアクセス
• メッセージスレッド： 1:1またはグループスレッド、既読（任意）、添付、翻訳（計画している場合）
• 告知フィード： クラス／学年／全校フィルタ付きの投稿とピン留め

データモデルの高レベル（DB議論は不要）

主要オブジェクトとその接続を文書化します：

• Users（ユーザー）（役割、連絡先、通知設定）
• Students（生徒）（1人以上の保護者と紐づく）
• Classes（クラス）（担任、名簿、学期）
• Messages（メッセージ）（スレッド、送信者、受信者、タイムスタンプ、ステータス）
• Events（イベント）（日付／時刻、場所、RSVP）

簡単な図でも、誰が誰にメッセージできるかの混乱を防げます。

コンテンツガイドライン：トーン、カテゴリ、緊急アラート

フォローすべきルールを書いてください。カテゴリ例：宿題、時間割、行動、健康、管理、緊急。緊急アラートの定義（誰が送れるか）と推奨トーン（短く、敬意を持ち、行動指示が明確）を示します。

添付ルールで全員を守る

許可するファイルタイプ（写真、PDF）、サイズ制限、教師のアップロードが承認制かどうかを規定します。生徒の写真に関する制限や同意の保存場所も明記してください。

利用を検証するための分析イベント

学生向け更新アプリの主要シグナルを選びます：

• message_sent, message_opened, message_replied
• announcement_viewed

プロパティ（役割、クラスID、カテゴリ）を付けて、必要以上の個人データを集めずに何が機能しているかを把握できるようにします。

テスト、品質、学校向けサポート

信頼がすべてです。誤送信、遅延配信、アカウント乗っ取りが起きると学校は回避します。テストとサポートは最後の工程ではなく、信頼を作る主要な活動です。

重要なフローをエンドツーエンドでテスト

isolatedな機能テストよりも実際の利用シナリオを優先してください。テストアカウントを学校の実使用に近づけ、各ビルドで以下を実行します：

• オンボーディング：招待、サインアップ、本人確認、初回ログイン
• コンテキスト切替：保護者が複数の子どもを切替、教師が複数クラスを切替
• 更新送信：クラス告知、添付、重要通知の送付
• 返信と既読：配信確認、ミュート、誰が何を見たかの挙動確認

可能なら「1日の流れ」テストを実施：10件の更新を学内に送信し、保護者が異なるデバイスやネットワーク条件で受け取る場面を再現してください。

学校に必ずあるエッジケースを含める

教育現場には非標準の家族形態や人員配置があるので、テストフィクスチャを用意します：

• 別居・別居親：2人の保護者、異なる権限、迎え権の違い
• 生徒に複数の教師：共同担任、補助教員、専門教員、放課後スタッフ
• 代行教師：一時的アクセスで自動期限付き
• 緊急メッセージ：迅速送信、高優先度、監査証跡

これらは権限モデルの検証に役立ちます。

アクセシビリティ＋古い端末（実機）でのテスト

基本的なアクセシビリティチェック（フォント拡大、コントラスト、スクリーンリーダー、タップ領域）を実施してください。

また古いスマホや低速回線でも動作するか確認します。フラッグシップ端末でしか動かない機能は即座にサポートチケットの原因になります。

ローンチ前にサポートワークフローを決める

学校は安全性とプライバシーに係る問題のための明確な対応経路を必要とします：

• 通報されたメッセージ：エスカレーションルール、レビュー用ツール、返答テンプレート
• 誤送信：迅速な封じ込め手順と調査用の監査ログ
• アカウントの乗っ取り：ロックアウト、強制パスワードリセット、デバイス／セッションの無効化

サポートができること（と学校管理者だけができること）を明文化してください。

シンプルなリリースチェックリストを使う

軽量のチェックリストで教育アプリのリリースを予測可能にします：

• 重要フローのスモークテスト
• iOS／Androidでの通知確認
• エッジケースアカウントでの権限確認
• プライバシー変更とログの見直し
• ヘルプ記事とアプリ内「What's new」更新

各リリースは校長の電話に直接届く想定で扱ってください。

ローンチ、導入、反復

リリース後の成否は「どれだけ早く時間を節約してくれるか」で決まります。ローンチは完成ではなく学習のフェーズです。

集中したパイロットから始める

1校、1学年、または少数クラスでパイロットを始めます。これによりトレーニングが管理しやすく、問題の特定が容易になります。

採用は週次で追い、招待受諾率、初回メッセージ率、週次アクティブ保護者／教師、実際に閲覧された告知数などを監視します。数値だけでなく、事務局や数名の教師との短い打ち合わせで離脱理由の"なぜ"を掘り下げてください。多くは小さな摩擦（ログインが分かりにくい、通知が多すぎる、クラス設定が不明瞭）です。

オンボーディングをシンプルに

忙しいユーザーは長文を読みません。用意するもの：

• 保護者向け、教師向けの60–90秒ビデオ
• 1ページのクイックスタートガイドと入学説明会用の印刷用ハンドアウト
• 実務的FAQ（「言語はどう変える？」「両親とも参加できる？」など）

教師／管理者用のサンドボックスを用意するなら、本番メッセージと間違えないよう明確にラベルしてください。

製品内にフィードバック機能を組み込む

常に利用可能だが邪魔にならない位置にフィードバック入口を置きます（例：「ヘルプ & フィードバック」メニュー）。ワンタップ評価＋任意のメモとスクリーンショット、メッセージ／スレッド上の「問題を報告」オプションを提供してください。

学校の要望に基づき反復する

パイロットからの学びを基に改善を計画します。よくある要望：強化されたモデレーションツール、賢いメッセージテンプレート、スケジューリング（送信予約）、明確な通知コントロール。

パイロットから拡張する際は価格、サポート、展開スケジュール（参照：/pricing）を明示し、学校向けの構造化されたローンチ支援（参照：/contact）に簡単にアクセスできるようにしてください。