Contents
導入
Inoreader チームを使った組織運用では、設定手順と運用ルールの両方を明確にすることが成功の鍵です。Inoreader チームの導入準備から管理者設定、招待、権限設計、自動化、外部連携まで、画面操作を意識した実務手順と担当・期限・合格基準を示します。
導入前の確認とプラン選定
導入前には利用規模と必須要件を洗い出し、試用で確認すべき項目を決めます。ここでは実務で使えるチェック項目と、管理画面での確認手順を提示します。
導入前に必ず確認する項目
導入判断に影響する要件を短く整理します。以下をチームで合意してください。
- 想定ユーザー数（初期／3か月／12か月の見込み）。
- 必須機能（共有フォルダ、Boards、ルール自動化、Webhookなど）。
- 外部連携先（Slack、Microsoft Teams、Zapier、社内Webhookなど）。
- 認証要件（SSO／SAML、2要素認証、IP制限）。
- データ保全とエクスポート要件（OPML、保存アイテム、ログ保持）。
- サポートとSLA（導入支援の有無、応答時間）。
- 請求形態（ユーザー単位かライセンスか、追加課金の反映タイミング）。
プラン選定の画面操作手順（確認フロー）
実際の管理画面でプランや機能の有無を確認する際の基本手順を示します。画面表記は変わる可能性があるため、手順の意味を理解して確認してください。
- Inoreader に管理者アカウントでログインします。
- 右上のアカウントアイコンをクリックして「Settings（設定）」を開きます。
- 「Organization」「Teams」「Billing」または「Account」などのタブを順に確認します。
- 「Subscription」「Plan」「Members」などの画面でユーザー上限や機能一覧を確認します。
- 必要ならサポート窓口に見積もりを依頼し、試用プランで主要ユースケースを検証します。
プラン比較テンプレート（簡易）
比較時に提示すると参照しやすい項目を表にまとめます。見積もり依頼や社内承認用に活用してください。
| 項目 | 確認内容 | 優先度 |
|---|---|---|
| ユーザー上限 | 初期と将来のユーザー数をカバーできるか | 高 |
| 共有フォルダ/Boards | チーム共有と権限設定の有無 | 高 |
| 自動化（Rules） | 条件とアクションの柔軟性 | 中 |
| 外部連携 | Slack/Teams/Webhook/Zapier対応 | 高 |
| SSO / 監査ログ | 企業要件に合致するか | 高 |
| データエクスポート | OPML等の出力可否 | 中 |
公式ドキュメントの参照方法（注意点の集約）
機能名や画面表記は更新されます。運用ルールを決定する前に、必ず Inoreader 公式ヘルプで該当ページを確認してください。検索キーワード例は「Teams」「Organization」「Import/Export」「SSO」「Webhooks」です。公式トップ: https://www.inoreader.com/ 、ヘルプ: https://www.inoreader.com/help
管理者アカウント作成と個人アカウントからの移行・招待
管理者設定とユーザー移行は導入初期の重要作業です。ここでは画面操作の手順、移行時の注意点、招待方法の具体例を提示します。
管理者アカウント作成の手順（画面操作）
管理者アカウントに設定すべき基本項目と、想定される画面遷移を示します。表記は環境で異なる場合があります。
- 管理者用のメールで Inoreader にログインします。
- 右上のアカウントアイコンをクリックして「Settings（設定）」を選びます。
- 「Organization」または「Teams」タブを開き、組織名／請求担当を登録します。
- 「Members」や「Admins」から管理者権限を割り当てます。
- 請求方法（クレジットカード／請求書）と請求連絡先を設定します。
運用安定化のため、複数の管理者アカウントとバックアップ手順を事前に決めてください。
個人アカウントからチームへの移行手順（具体）
移行はデータ整合性と課金タイミングを意識して実行します。主要な手順を示します。
- 個人アカウントで購読一覧をエクスポート（OPML）。
- 保存済み記事やBoardsの重要データをエクスポートまたは手動で保存。
- 組織アカウントでフォルダ構成と共有設定を作成。
- 組織側にOPMLをインポートして購読を復元。
- Boardsや保存済みアイテムは共有先に再保存し、所有権移譲の可否を確認。
- 重複課金を防ぐため、個人プランの解約時期を調整する。
移行の合格基準例: 全ユーザーの主要購読が漏れなく移行され、Boardsの承認ワークフローが稼働すること。
招待方法と運用テンプレート（メール／リンク／一括）
招待実務での選択肢と操作の流れ、テンプレートを示します。操作名は画面によって異なります。
- メール招待（個別）
- Settings > Organization > Members > Invite member を選択。
-
招待先メールアドレスとロール（Owner/Admin/Editor/Viewer）を指定して送信。
-
招待リンク（大量招待）
- Organization > Invite link を生成。
-
リンクは有効期限とロールを設定して配布。リンク管理ルールを別途運用。
-
ドメイン一括招待（対応がある場合）
- Domain allowlist 等の設定を有効化し、組織ドメインを登録。
- ドメイン内ユーザーを自動的に組織に招待/承認する設定を確認。
招待メール雛形（プレースホルダは {} で示します）:
件名: {組織名} からの Inoreader 招待
本文:
{氏名} 様
{送信者名} です。チームの情報共有用に Inoreader にご招待しました。
招待リンク: {invite_link}
初回手順: アカウント作成 → プロフィール設定 → 共有フォルダにアクセス
期限: {期限}
不明点は担当者 {担当者名} までご連絡ください。
CSV 一括招待の最小例（列見出し）:
|
1 2 3 |
email,full_name,role,group [メールアドレス削除],山田 太郎,Editor,マーケティング |
共有フォルダ・Boardsを使った記事共有とレビュー運用
共有設計とBoards運用は、記事の二重管理や見落としを防ぎます。ここではフォルダ設計、Boardsワークフロー、アーカイブ方針を示します。
フォルダ設計と命名規則（手順）
フォルダ構成を先に決めると運用が安定します。推奨する手順と命名規則を示します。
- 組織の情報分類（例：部門／プロジェクト／公開可否）を定義します。
- 左サイドバーで「New Folder」を作成し、命名規則に従って名称をつけます。
- 各フォルダに対して共有範囲と編集権を設定します。
- テンプレート例:
- 00-INBOX（未処理）
- INT-部署-プロジェクト（内部用）
- PUB-キャンペーン-公開（公開用）
承認基準: 全プロジェクトに命名規則が適用され、ユーザーへの教育が完了していること。
Boardsベースのレビュー手順（ステータス運用）
Boards をレビューと意思決定の場として使う運用手順を示します。
- 推奨ワークフロー例: 収集 → 一次判定タグ付け → Board に保存 → レビュワー割当 → コメントでやり取り → ステータス更新 → 承認済みは公開フォルダへ移動。
- Board のカラム例: 要確認 / レビュー中 / 修正待ち / 承認済み / 保留。
- 操作例（概略）: 記事を開いて「Save to Board」または「Save」→ 対象のBoardを指定 → コメントでレビュワーをメンション。
運用の合格基準例: レビュー完了までの平均処理日数が 2 営業日以内であること。
アーカイブと保持ポリシー
情報の寿命を決め、検索性と法務要件を満たします。
- 標準例: 公開記事は 12 か月でアーカイブ、内部資料は 36 か月でアーカイブ。
- 毎月 OPML と保存アイテムのバックアップを取得し、別ストレージで保管。
- 機密資料は限定フォルダに格納し、アクセスログと移動履歴を記録するルールを定めます。
法務要件に応じて保持期間は短縮または延長してください。
ルール設定と外部連携（Slack／Teams／Webhook／Zapier 等）
自動化と外部連携は運用効率を大きく向上させます。ここではルール作成の実際手順と、代表的な連携の具体設定例、Webhook ペイロード例を示します。
ルール（自動化）の作成手順（画面操作）
基本的なルール作成の流れとテスト手順を示します。
- Settings（設定）→ Automation／Rules（自動化／ルール）を開きます。
- 「Create rule」や「New filter」を選択します。
- 条件を設定（タイトルに特定キーワード、発信元フィード、タグ等）。
- アクションを設定（タグ付け、フォルダ移動、Board 保存、Webhook 通知など）。
- テスト実行して想定通りに動くか確認し、ログを保存します。
合格基準: テスト記事に対して期待するアクションが 1 回で発生すること。
Slack／Teams 連携の具体手順
代表的なチャネル連携の作成とテスト法を示します。
- Slack（Incoming Webhook）
- Slack 管理画面で Apps > Incoming Webhooks を追加。
- 通知先チャンネルを選び、Webhook URL を取得。
- Inoreader のルールで Webhook URL をアクションに設定してテスト送信。
-
受信フォーマット（本文、要約、リンク）を整形して表示確認。
-
Microsoft Teams（Incoming Webhook）
- Teams のチャンネルで「コネクタ」から Incoming Webhook を構成。
- Webhook URL をコピーし、Inoreader のルールに設定。
- メッセージカードの表示を確認し、必要に応じて JSON フォーマットを調整。
テストの合格基準: 指定チャンネルに想定の本文とリンクが表示されること。
Webhook のサンプルペイロードと検証方法
Webhook 受信側の実装を容易にするためのサンプルを示します。内容は例であり、必要に応じてフィールドを拡張してください。
サンプル JSON ペイロード:
|
1 2 3 4 5 6 7 8 9 10 |
{ "id": "item-12345", "title": "記事タイトルの例", "link": "https://example.com/article/123", "summary": "記事の要約。必要に応じてHTMLを含めます。", "feed_title": "配信元フィード名", "published": "2026-05-01T10:00:00Z", "tags": ["業界ニュース", "要対応"] } |
curl による送信テスト例:
|
1 2 |
curl -X POST -H "Content-Type: application/json" -d @payload.json https://your-webhook.example.com/receive |
検証ポイント:
- HTTP ステータスを確認（200 レスポンスを期待）。
- 受信側で JSON パースできるか確認。
- 再試行・レート制限のログを記録する設定を行う。
請求・認証・セキュリティ、導入チェックリストとトラブルシュート
請求や認証、法務・セキュリティ要件は導入の基盤です。ここでは実務で使えるチェックリスト、担当と期限、合格基準、よくある障害の切り分けをまとめます。テンプレートは本文内で提供します。
請求運用の具体手順と確認項目
請求関連は組織のルールに合わせて確実に設定します。主な手順を示します。
- 請求担当者を決定し、管理画面の Billing／Subscription に登録します。
- ライセンス追加時の請求反映タイミングをベンダーに確認します。
- 月次でアクティブユーザー数とライセンス数を突合します。
- 請求エラー時の連絡フロー（経理→管理者→ベンダー）を文書化します。
合格基準例: 月次のライセンス差分が 0、または差分理由が文書で説明可能であること。
認証・ログ・法務上の留意点（GDPR 等）
セキュリティ要件を満たすためのチェック項目です。法務や情報管理部門と調整してください。
- SSO（SAML）導入の可否と手順を確認し、テストユーザーでログイン検証を行う。
- 管理者は多要素認証（2FA）を必須にする運用を検討する。
- ログ保持期間、監査ログの取得方法、アカウントのライフサイクル管理を定義する。
- データの保存場所（データセンターの所在）やDPA（データ処理契約）についてベンダーと合意する。
合格基準例: SSO によるログインが 10 名のテストユーザーで成功し、監査ログが取得できること。
導入チェックリスト（短縮版・担当・期限・合格基準付き）
導入開始から本番化までの短縮チェックリストを示します。担当と期限の例はプロジェクト要件に合わせて調整してください。
| タスク | 担当 | 期限（例） | 合格基準 |
|---|---|---|---|
| 組織アカウント作成 | IT 管理者 | D+3 | 管理者画面に請求担当が登録されている |
| 初期フォルダ設計適用 | コンテンツ責任者 | D+7 | 主要 5 プロジェクトで命名規則が適用 |
| 招待（パイロット 10 名） | 人事/管理者 | D+10 | 10 名のうち 9 名が招待を受け取れる |
| 自動化ルールの作成とテスト | 編集チーム | D+14 | 主要ルールがテストデータで期待通り動作 |
| 外部連携テスト（Slack等） | ネットワーク担当 | D+14 | Slack に 200 ステータスで通知が届く |
| 本番展開 | プロジェクトリード | D+21 | 全ユーザーへの招待とガイダンス完了 |
よくある障害と切り分け手順（要約）
発生頻度の高い問題と優先的な確認ポイントを示します。
- 招待メールが届かない
- 迷惑メールフォルダを確認。
- 企業のメールフィルタや受信ポリシーを確認。
-
別アドレスで再送あるいは招待リンクで対応。
-
共有が反映されない／権限エラー
- フォルダのオーナーと割当ロールを確認。
-
権限変更後はユーザーの再ログインを指示。
-
Webhook 通知が届かない
- 受信側のエンドポイントでログを確認（HTTP ステータス）。
- curl で単純な POST テストを実行して応答を確認。
-
社内ファイアウォールやプロキシのブロックを確認。
-
同期遅延やフィード更新がない
- フィード元の配信間隔やレート制限を確認。
- Inoreader のステータスページやヘルプで既知障害を確認。
用語集（主要用語の翻訳と説明）
ここでは画面表示やチーム内で混乱しやすい用語を整理します。括弧内に原語を示します。
用語一覧
- Boards（Boards）: 記事を保存してレビューやコメントを行う機能。
- Owner（オーナー）: 組織アカウントの最上位管理者。請求や権限管理が可能。
- Admin（管理者）: ユーザーや設定の管理が可能なロール。請求操作は制限される場合あり。
- Editor（編集者）: コンテンツの保存や編集が可能なロール。
- Viewer（閲覧者）: 閲覧やコメントが主な権限のロール。
- OPML: 購読一覧のエクスポート/インポートに使う汎用フォーマット。
- Webhook: 外部サービスへイベントを通知する HTTP POST の仕組み。
用語の訳やロール名は画面表記と合わせて運用ドキュメントに明記してください。
まとめ
導入前に要件を精査し、管理者設定やフォルダ設計、招待手順を決めることが運用安定の第一歩です。Boards と自動化ルールでレビューと通知を仕組み化し、請求・認証・セキュリティの運用ルールを明文化して定期レビューを実施してください。導入時は必ず公式ヘルプで画面表記や機能の最新情報を確認し、提示したチェックリストとテンプレートを現場に合わせて調整して運用を開始してください。