社内ポータルをClaude Codeで自作する｜チームボードの作り方と公開前チェック

社内ポータルの自作とは、チームの連絡や情報共有に使う社内向けのWebサイトを、SaaSを契約せずに自社で作って運用することです。Claude Codeを使えば、作りたいものを日本語で伝えるだけで、チームボードのような社内ツールを動く形まで作れます。公開前にログインやデータの公開範囲を人が確認すれば、小さなチームでも自社に合った社内ポータルを持てます。

「チャットツールや社内ポータルのSaaSは人数分の料金がかかる」「必要な機能はもっと少なくてよい」と感じている総務や情報システムの担当者は多いはずです。一方で、AIで作れそうだと分かっても「社内の情報が外から見えてしまわないか」が気になって、一歩を踏み出せないこともあります。

この記事では、自作とSaaSの選び方、Claude Codeに任せることと人が確認すること、社内LANで使うかログイン付きで公開するかの判断、筆者のチームがClaude Codeで作ったチームボードの構成、作り方の手順、そして公開前に確認する設定のチェックリストを、IPAやNISTの公的資料を根拠に整理します。データベースの設計を詳しく知りたい方はチームツールのDB設計パターンもあわせてご覧ください。記載の内容は2026年10月9日時点の情報です。

社内ポータルは自作とSaaSのどちらを選ぶか

使う人が社内の決まったメンバーに限られ、ほしい機能がはっきりしているなら自作、機能の幅や保守の手間を任せたいならSaaSが向いています。どちらが正解というより、自社が何を自分で持ちたいかで決まります。

SaaSを選んだ場合でも、利用者側で確認することは残ります。IPA「中小企業の情報セキュリティ対策ガイドライン 第4.0版」の付録7「中小企業のためのクラウドサービス安全利用の手引き」には、チェック項目として「8 利用者の範囲を決める クラウドサービスを適切な利用者のみが利用可能となるように管理できていますか？」が挙げられています。自作でもSaaSでも、誰が使えるかを管理するのは自社の仕事です。

自作が向いているかどうかは、次の3つで判断できます。

1. 使う人が社内の決まったメンバーに限られている
2. ほしい機能を一言で言える（例：チャンネル別の連絡、ファイル添付、未読の管理）
3. 公開前の設定を確認する担当者を決められる

Claude Codeに任せること・人が確認すること

画面と機能の実装はClaude Codeに任せ、誰が何を見られるかの決定と公開前の確認は人が受け持つ、という分担が基本です。コードを書く速さはAIに頼れますが、社内のどの情報を誰に見せるかは会社が決めることだからです。

Anthropicも、Claude Codeのセキュリティに関する公式ドキュメントで「承認前に、提案されたコードとコマンドの安全性を確認する責任があります。」と明記しています。IPA「中小企業の情報セキュリティ対策ガイドライン 第4.0版」も生成AIの利用について「生成された成果物は必ず人間が確認し、正確性や法的リスクをチェックする」としています。AIが書いたコードをどこまで受け入れてよいかの判断手順は、vibe codingの記事で詳しく解説しています。

社内LANで使うか、ログイン付きで公開するか

社外から使う必要がなければ社内LANの中だけで動かし、外出先やスマホからも使うならログイン付きで公開して、アクセスできる人や場所を絞る構成が基本です。どちらを選ぶかで、必要な準備と確認することが変わります。

社内LANで使う場合

Claude Codeで作ったアプリを社内の1台で起動し、同じネットワークにつながった端末のブラウザから開いて使います。インターネットに出さないぶん設定は少なく済みますが、社内のネットワークにも複数の人や端末がつながります。社内LANだけで使う場合も、ログインと「誰が何を見られるか」の設定は省きません。

ログイン付きで公開する場合

インターネットに公開するときは、アプリ自体のログインに加えて、アプリの手前でアクセスできる人を絞る仕組みを重ねられます。

• Cloudflare Access：公式ドキュメントに「All Access applications are deny by default — a user must match an Allow policy before they are granted access.」とあり、許可した人以外はアプリに届く前に止められます
• Vercel Deployment Protection：公式ドキュメントでは「Deployment Protection lets you control who can access your preview and production URLs.」と説明されています。ただし接続元IPで絞るTrusted IPsはEnterpriseプラン限定、パスワード保護はHobbyプランでは使えないなど、プランによって使える機能が変わります

IPA「中小企業の情報セキュリティ対策ガイドライン 第4.0版」も、「管理者権限のリモート接続や機密性の高い情報に対するインターネットを経由したアクセスについて、接続元制限や端末要件を規定して遵守状況を確認しましょう。」としています。社外から使えるようにするなら、どこから誰が入れるのかを決めてから公開します。

実例：Claude Codeで作ったチームボードの構成と機能

筆者のチームでは、Slackのようなメンバー限定のチームボードをClaude Codeで作り、2026年3月から運用しています。2026年3月20日に要件定義書と最初の実装を作り、10月9日までに194件のコミットを重ねました。そのうち192件にClaude Codeが共同作成者として記録されています。人は「何を作るか」を決めて動作を確かめ、コードはほぼClaude Codeが書いた形です。

実装した主な機能は次のとおりです。

• チャンネルとサブチャンネル、ダイレクトメッセージ
• メンション・返信・リアクション・ブックマーク・ピン留め
• 全チャンネルを横断する検索
• 未読数のバッジと「新着」ボタン
• プッシュ通知とメール通知
• ファイル添付（1ファイル50MBまで・複数同時）
• 管理者によるアカウントの追加・削除

運用しながら直したこと

使い始めてから、メッセージが増えるにつれてデータベースの読み書きが増えることが分かりました。そこでClaude Codeに状況を伝え、在席表示の仕組みの変更やインデックスの追加でデータベースの負荷を減らし、画面を開いたときは最新の30件だけを読み込んで、上にスクロールしたら30件ずつ追加する形に直しました。最初から完璧を目指すより、使いながら直す前提で小さく始められるのが自作のよいところです。

未読の管理や通知、権限のテーブル設計はチームツールのDB設計パターンで解説しています。なお、この記事では本番環境のURLや設定値は掲載していません。

社内ポータルの作り方（7ステップ）

社内ポータルは、使う人と機能を絞ってから、ログインとデータの権限を先に作り、機能を1つずつ足していく順番で作ると進めやすくなります。

1. 使う人と目的を決める：人数、社外から使う必要があるか、何に困っているかを書き出す
2. ほしい機能を3〜5個に絞る：最初から全部入りにしない
3. 要件定義書をClaude Codeに書いてもらい、人が直す：画面・機能・使う人・権限を1つの文書にまとめる
4. CLAUDE.mdにルールを書く：セキュリティの決まりを先に渡しておく（次の章）
5. ログインとデータの権限を先に作る：誰がどのデータを読めるかを決めてから画面を作る
6. 機能を1つずつ足し、そのつど動かして確かめる
7. 公開前のチェックリストを通してから公開する

ステップ5を先に置くのは、権限を後から足すと、すでに作った画面やデータの読み込み処理をすべて見直すことになるためです。最初に「全員が全部を見られる」形で作り始めると、そのまま公開してしまいがちです。最初から「ログインした本人が見てよいものだけ」を前提に作ると、機能を足すときもその前提が引き継がれます。

Claude Codeへの指示の書き方（CLAUDE.mdに書くルール）

セキュリティに関わる決まりは、毎回の指示に書くのではなく、プロジェクトのCLAUDE.mdに書いておきます。CLAUDE.mdはClaude Codeがセッションの開始時に読み込むため、指示し忘れても同じ決まりで作業してくれます。たとえば次のような内容です。

# セキュリティのルール

- 秘密鍵（Supabaseのsecret key／service_role key）はサーバー側のコードだけで使う。NEXT_PUBLIC_ を付けない
- .env ファイルはコミットしない
- 新しいテーブルを作るときは RLS を有効にし、読める人・書ける人を絞るポリシーを同時に書く
- Storage のバケットは非公開で作り、ファイルは署名付きURLで渡す
- 管理者用のAPIは、呼び出した人が管理者かどうかをサーバー側で確認する
- 初期パスワードはランダムに発行し、初回ログイン時に変更してもらう
- パスワードはハッシュ化して保存し、ログに出力しない

ルールを書いておいても、出てきたコードが本当にそうなっているかは人が確かめます。Claude Codeの承認のしかたは権限モードで変えられるので、慣れないうちは変更のたびに承認するモードで進めると、何が変わったかを把握しやすくなります。CLAUDE.mdの設計はClaude Codeのルール・エージェント設計術で詳しく解説しています。

公開前に確認する設定チェックリスト

公開前に確認するのは、ログイン、データの公開範囲、ファイルの公開範囲、鍵の置き場所、管理者機能、アクセスできる場所、記録の7つです。次の表を上から順に確かめてから公開します。

初期パスワードとパスワードの決まり

NIST SP 800-63B-4（2025年7月）は、パスワードを利用者が選ぶか、サービス側がランダムに発行する（”chosen by the subscriber or assigned randomly by the CSP”）ものとしています。そのうえで「Verifiers and CSPs SHALL NOT require subscribers to change passwords periodically.」と定期変更を求めないよう定め、「verifiers SHALL force a change if there is evidence that the authenticator has been compromised.」と、漏えいの疑いがあるときには変更させるよう求めています。

日本の資料では、IPA「中小企業の情報セキュリティ対策ガイドライン 第4.0版」が「□ 初期設定パスワードを変更する。」と「□ 特にVPNや重要なシステムを利用する場合は、強固なパスワードを設定し、可能な場合は多段階認証、多要素認証、パスキーなどの認証強化機能を利用する。」を挙げています。総務省の国民のためのサイバーセキュリティサイトも「定期的に変更するよりも、機器やサービスの間で使い回しのない、固有のパスワードを設定することが求められます。」としています。

長さの目安は資料によって違い、IPAのガイドラインは10文字以上、NISTはパスワードだけで認証する場合に15文字以上（”a minimum of 15 characters”）としています。社内ポータルでは、初期パスワードをランダムに発行して個別に渡し、本人が長く推測されにくいものに変える流れにしておけば、どちらの考え方にも沿えます。

データとファイルの公開範囲（SupabaseのRLSとStorage）

Supabaseでは、ブラウザに配られるキー（従来のanon key。現在の名称はpublishable key）でデータベースに直接アクセスできます。Supabaseの公式ドキュメントは「Enable RLS on every table in an exposed schema.」としたうえで、「A table in an exposed schema without RLS is readable and writable by any role with a grant on it.」と説明しています。RLSを有効にしても、ポリシーを「全員に許可」にしていれば制限にはならないため、ポリシーの中身まで確認します。

ファイルの保存先も同じです。Storageのバケットの説明では、公開バケットは「anyone who possesses the asset URL can readily access the file」、非公開バケットは「all operations are subject to access control via RLS policies」とされています。社内の添付ファイルは非公開バケットに置き、閲覧時は期限付きの署名付きURLで渡します。

鍵の置き場所

Supabaseの秘密鍵（従来のservice_role key。現在の名称はsecret key）は、公式ドキュメントに「A secret key bypasses every Row Level Security policy you have. Never put one in a browser, a shipped application, or source control.」とあるとおり、RLSを通らずにすべてのデータを読み書きできます。Next.jsでは、名前に NEXT_PUBLIC_ を付けた環境変数は公式ドキュメントのとおり「It will be inlined into any JavaScript sent to the browser.」となるため、秘密鍵には付けません。値はVercelの環境変数のようにホスティング側の設定に置き、コードやリポジトリには書きません。

記録を取って見返す

IPA「中小企業の情報セキュリティ対策ガイドライン 第4.0版」は「通信ログや認証ログを取得・保管するとともに、ログの改ざん防止を行った上で、定期的にレビューを行いましょう。」としています。社内ポータルでも、誰がいつログインしたかを残しておけば、見覚えのないログインに気づけます。記録をどのくらいの期間残すかも、公開前に決めておきます。

Claude Codeを社内で使うときのプラン選び

社内の情報を扱いながら開発するなら、入力が学習に使われない商用条件のプラン（Team・Enterprise・API）を選ぶか、個人向けプランなら学習への利用設定を確認してから使います。

Claude Codeのデータ使用に関する公式ドキュメントには「Anthropic は、商用条件の下で Claude Code に送信されたコードまたはプロンプトを使用して生成モデルをトレーニングしません。」と書かれています。個人向けプランで始める場合は、アカウントの設定で学習への利用がどうなっているかを先に確かめてください。

社員名簿のような個人データを扱う場合は、個人情報保護委員会の生成AIサービスに関する注意喚起（2023年6月）が「当該生成 AI サービスを提供する事業者が、当該個人データを機械学習に利用しないこと等を十分に確認すること。」と求めています。IPAのガイドラインも「機密性の高い情報や個人情報など、外部に漏れると問題になるデータは AI サービスに入力しない」としています。開発中は本物の社員データではなく、ダミーのデータで動作を確かめるのが基本です。

運用を始めてから確認すること

社内ポータルは公開したあとも、アカウントの棚卸しと記録の確認を定期的に行います。使う人が入れ替わっても、使える人が正しい状態を保つためです。

• 入社・退職・異動のたびにアカウントを追加・削除する（IPAのガイドラインは「IDの発行から削除までを管理するプロセスを定め、必要最小限の割り当てとなるようにしましょう。」としています）
• 共有のアカウントを作らず、1人1つにする
• ログインの記録を定期的に見返す
• 使っているパッケージの更新をClaude Codeに頼み、変更内容を人が確認する
• データベースと添付ファイルのバックアップを取る

よくある質問

Q. 社内ポータルはプログラミング未経験でも自作できますか？

作れます。Claude Codeに作りたいものを日本語で伝えれば、動く形までは作れます。ただし公開前にログインやデータの公開範囲を確認する必要があるため、確認する担当者を決めるか、制作会社に確認を依頼してから公開してください。

Q. 社内ポータルを自作する費用はどのくらいですか？

主な費用は、Claudeの利用料と、ホスティング・データベースの料金です。小規模なら各サービスの無料枠から始められる場合もありますが、業務で使えるかどうかは各サービスの料金プランと利用規約で確認してください。

Q. 社内LANだけで使うならログインは不要ですか？

社内LANだけで使う場合もログインは設定します。社内のネットワークにも複数の人や端末がつながるため、誰が何を見られるかの設定は社内LANでも必要です。

Q. Claude Codeに社内の情報を入力しても大丈夫ですか？

プランによって扱いが変わります。Team・Enterprise・APIの商用条件では入力が学習に使われず、個人向けプランでは設定がオンの場合に学習に使われます。どのプランでも、個人情報や機密情報は入力せず、ダミーのデータで開発するのが基本です。

Q. SupabaseのRLSを有効にすれば十分ですか？

RLSを有効にしたうえで、ポリシーで「誰が何を読めるか」を絞る必要があります。すべてを許可するポリシーのままでは、RLSを有効にしていても読み書きの制限になりません。

Q. ファイル保管や社内マニュアルも同じ方法で作れますか？

作れます。考え方は同じで、ファイルは非公開の保存先に置き、ログインと権限で閲覧できる人を絞ります。最初はチームボードのように機能を絞って作り、使いながら足していくと進めやすくなります。

まとめ

社内ポータルは、Claude Codeを使えば小さなチームでも自作できます。大切なのは、実装をAIに任せ、誰が何を見られるかと公開前の確認を人が受け持つことです。

• 使う人が限られ、ほしい機能がはっきりしているなら自作が向いている
• 社外から使うならログイン付きで公開し、入れる人と場所を絞る
• セキュリティの決まりはCLAUDE.mdに書いて、毎回同じ前提で作らせる
• 公開前に、初期パスワード・RLS・ファイルの公開範囲・鍵・管理者機能・アクセス制限・記録を確認する
• 社内の情報を扱うなら、学習に使われないプランか設定を選ぶ

自社で作る時間が取れない場合や、作った社内ツールの公開前の設定を確認してほしい場合は、制作の相談を受け付けています。

関連記事

• チームツールのDB設計パターン【未読管理・通知・権限をSupabaseで実装】
• vibe coding とは？原義と実務用法の違い・AIのコードを受け入れる判定手順
• Claude Codeのルール・エージェント設計術｜CLAUDE.mdとサブエージェント運用の実践知
• 「AI組織」は組織図から作ると失敗する｜1人会社をAI会社化する正しい順序
• FAQチャットウィジェットを自作する方法【Next.js×Cloudflare D1】
• Claude Codeでブログ見出しデザインツールを作ってみた｜プロンプト公開