公開2026.08.22更新2026.09.27 CMS

Googleサイトで社内ポータルを作る実装手順：ドライブ権限・共有ドライブ上限・検索の限界から逆算する

Googleサイトで社内ポータルを作る作業は、画面を組むところだけなら半日で形になります。詰まるのはその先です。誰に何を見せるかをどこで決めるのか、資料の実体をどこに置くのか、増えたページをどうやって探させるのか。この三つはGoogleサイトの編集画面には出てきません。判断材料はGoogleドライブ側の共有設定と共有ドライブの上限値、そして契約しているエディションの側にあります。この記事ではGoogle Workspaceを前提に、実装で先に決める判断だけを順に並べました。社内ポータルの定義や内製と外注の分かれ目を先に押さえたい場合は、社内ポータルサイトとは？機能・作り方・内製と外注の判断基準まで解説から読むと前提が揃います。

まとめ：公開範囲・資料の器・検索の三点をドライブ側で先に決める

結論から言えば、Googleサイトの画面に触る前に確定させる判断は三つです。一つ目は公開範囲をどこで縛るかになります。新しいGoogleサイトはGoogleドライブのサービスの一つで、組織内のユーザーがサイトを共有・公開する方法は管理コンソールのドライブ設定で定義されます。サイト側でいくら閲覧者を絞っても、テナントのドライブ設定が外部共有を許していれば、公開範囲の上限はそちらが握ったままです。

二つ目は資料の置き場です。Googleサイトのページに載るのはリンクと埋め込みで、実体の多くは共有ドライブに残ります。一つの共有ドライブが持てるアイテムは最大50万個、直接共有できるのは最大100グループ、メンバーの合計は600、フォルダのネストは100レベルまで。器の側の数字を知らずに全社分を一箇所へ積むと、あとから分割して回る作業が発生します。

三つ目は検索です。新しいGoogleサイトに、公開したサイトの中だけを全文検索させる標準ウィジェットはありません。横断検索を担うクラウドサーチは対応エディションが限られており、Business Starterでは選べません。検索で拾わせる前提に寄りかからず、ページ階層と入口の数で到達させる設計にしておく必要があります。

Googleサイトの実体はドライブ上のファイルで公開範囲もそこで決まる

実装の前提として、Googleサイトを独立したCMSだと考えると設計を外します。実体はドライブ上のオブジェクトで、権限のモデルもドライブから受け継いでいます。

管理コンソールのドライブ設定がサイトの公開先を先に縛っている理由

Googleサイトはコアサービスの一つで、既定では組織に対して有効になっています。ここで見落とされやすいのは依存関係です。組織でGoogleサイトを使うには、対象ユーザーに対してGoogleサイトとGoogleドライブの両方が有効になっている必要があります。ドライブを止めている組織部門ではサイトも成立しません。

そして公開の側です。組織内のユーザーがサイトを共有・公開する方法は、ドライブの設定で定義できるとGoogleは明記しています。つまり「社外に出せるサイトを作れるかどうか」は、Googleサイトの管理画面ではなくドライブの共有ポリシー側で決まる構造です。社内限定のポータルを作るつもりなら、まず対象の組織部門でドライブの外部共有がどう設定されているかを確認してから着手します。

作成と編集の可否は、管理コンソールの［アプリ］［Google Workspace］［Googleサイト］から組織部門またはアクセスグループの単位で制御できます。既定では「ユーザーはサイトを編集できる」と「ユーザーによる新しいサイトの作成を許可する」がどちらも有効です。全社ポータルを情報システム部門の管理下に置きたい場合、他部門での新規作成を止める判断がここで入ります。設定変更の反映には最長で24時間ほどかかる前提で段取りを組みます。

編集者と公開済みアイテムの閲覧者という二つのロールで足りる範囲

サイト側で選べる公開対象は、［制限付き］と［公開］の二択が基本形です。職場や学校のアカウントであれば、これに加えて組織向けのオプションが表示される場合があります。［制限付き］を選ぶと、個人またはグループを「公開済みアイテムの閲覧者」として追加していく形になります。

ここで押さえたいのは、権限の粒度がサイト単位だという点です。編集する側と公開済みのサイトを見る側という二層しかなく、ページ単位で閲覧者を切り替える仕組みは用意されていません。SharePointのように一意のアクセス許可を掘っていく設計とは、前提から違います。Microsoft 365側の実装判断はSharePointで社内ポータルを作る実装手順｜サイト構成・Webパーツ・権限・ナビ設計を上限値から解説で別途整理しました。

したがってGoogleサイトでは、見せる相手が違う情報は「ページを分ける」のではなく「サイトを分ける」ことになります。全社向けの本体サイトを一つ立て、役員向けや特定部門向けは別サイトとして起こし、本体からリンクで束ねる。この形が権限モデルに素直な構成です。分けたサイトが増えたときの入口整理については、見やすい社内ポータルのデザイン｜掲載の優先順位と四つのレイアウト型、作り込む判断基準で掲載順序の考え方をまとめています。

共有ドライブとGoogleグループを権限の単位に据える設計の順序

サイトを分ける方針を採ると、次に効いてくるのが「誰を追加するか」の管理コストです。ここでグループを噛ませておくかどうかで、運用開始後の手間が変わります。

個人アカウントではなくグループにアクセス権を持たせる実装上の利点

サイトの閲覧者にも共有ドライブのメンバーにも、個人アカウントとGoogleグループの双方を追加できます。実装としてはグループ側へ寄せるのが扱いやすい形です。人事異動のたびにサイトと共有ドライブを一つずつ開いて付け替える作業が消え、グループのメンバー変更だけで両方に反映されます。

数の面でも差が出ます。共有ドライブのメンバーは合計600までですが、この600という枠は「メンバーとして追加されたグループと個人アカウントの合計」で数えます。グループを一つ追加すればカウントは1です。中の人数は個人の合計50,000という別の上限で管理され、複数グループに属している人は50,000に対して1人としか数えられません。個人を直接並べる運用は、600の枠を早い段階で使い切ります。

ただしグループの側にも制限があります。共有ドライブ内のファイルを直接共有できるグループは最大100、共有ドライブのメンバーとして追加できるグループも最大100です。600の枠内で100グループと100人を入れた時点で、それ以上グループは足せません（個人ならまだ追加できます）。部署ごとに細かくグループを切る設計は、この100で頭打ちになると見ておきます。

埋め込んだドライブファイルの権限がサイトの権限とは別に動く点

公開直後に必ず出る問い合わせが「サイトは見えるのに中の資料が開けない」です。原因は権限が二層になっていることにあります。ファイルが共有ドライブに保存されている場合や共有権限が制限されている場合、そのファイルを表示できるのはアクセス権を持つユーザーだけです。サイトの閲覧権限は、埋め込んだファイルの閲覧権限を肩代わりしません。

Googleはこの点について、サイトに埋め込んだファイルへ共同編集者と閲覧者の全員がアクセスできるようにするには、サイトの公開時にファイルのアクセス権も共有する必要があると案内しています。共有権限は埋め込み時か公開・共有の操作時に更新できます。実装上は公開作業をチェックリスト化し、埋め込み資産の権限確認を必ず一項目として置く運用です。

もう一つの落とし穴が、サイトの共同編集者に埋め込みファイルの共有設定を変える権限がない場合です。このときダイアログに共有オプションは表示されず、全員がアクセスできるわけではない旨だけが示されます。作成担当者が資料の所有者と別部門になっている構成では、これが公開直前で止まる原因です。資料の所有権を共有ドライブへ寄せておくと、この行き止まりを避けられます。

共有ドライブの上限値から逆算する資料の置き場とメンバーの設定

ポータルが抱える資料は、時間とともに増えます。器の上限を先に知っておくと、分割の判断を後回しにせずに済みます。

50万アイテムと100レベルのネストという器の上限が効く場面

一つの共有ドライブに保存できるアイテムは最大50万個です。この数にはファイルだけでなく、フォルダ、ショートカット、ゴミ箱の中身も含まれる扱いです。Googleは上限そのものよりかなり少なめに保つことを推奨しており、追加できる残りが50万個の20%を切ると警告バナーが表示される場合があります。現在地は管理コンソールの共有ドライブの管理から「アイテムの上限」列で確認できます。

フォルダのネストは最大100レベルまでですが、実務でこの深さに到達する設計はまず破綻しています。Googleも一つの共有ドライブ内のフォルダ数は絞り、複数の共有ドライブに分けて整理する方を勧めています。ポータルの資料棚は「業務の単位で共有ドライブを分ける」のが素直な形です。

項目	上限
アイテム数	50万個
直接共有できるグループ	100グループ
メンバー合計	600
個人の合計	50,000
フォルダのネスト	100レベル
左ナビの表示件数	1,000個

メンバー600人の枠と1000人超で自動的に非表示になる挙動

全社規模で運用するときに引っかかりやすいのが、スパム防止のための自動非表示です。共有ドライブが1,000人を超えるグループと直接共有されている場合、超過分のユーザーに対して共有ドライブは既定で非表示になります。1,200人のグループと共有すれば、200人からは見えない状態で始まる計算です。

間接的な共有にも別の閾値があります。2,500人を超えるユーザーと間接的に共有されている場合も、超過分は自動で非表示です。500人ずつの6グループと共有したなら、先に追加された5グループ2,500人には表示され、最後の1グループには表示されません。従業員1,000人を超える組織でGoogleサイトのポータルを設計するなら、資料の共有ドライブは全社一括ではなく部門や業務の単位へ割る前提で組みます。

サイト内検索が標準にない前提でナビゲーション全体を設計する手順

Googleサイトで社内ポータルを作るときに最も誤解されやすいのが、検索の守備範囲です。ここは代替手段のコストまで含めて先に判断しておきます。

クラウドサーチが使えるエディションと使えないエディションの差

Googleサイト上部にある検索バーは、自分が編集できる共有サイトを探すためのものです。職場または学校のアカウントであれば、公開済みの共有サイトも検索できます。いずれも「サイトを探す」機能であって、公開したポータルの本文を横断して全文検索させる標準ウィジェットとは別物です。

横断検索を担うのはクラウドサーチです。対応エディションはBusiness StandardとBusiness Plus、Enterprise StandardとEnterprise Plus、Education Plus、G Suite Business、そしてCloud サーチ Platformに限られます。Business Starterのままでは選択肢に入りません。この一点でポータルの情報設計が変わるため、エディションの確認は要件定義の初日に済ませます。

権限の扱いは素直です。クラウドサーチが扱うGoogle Workspaceのコンテンツには、他のサービスと同じ共有モデルが適用されます。ドライブ、カレンダー、サイト、グループの共有設定に基づいて検索結果が出るため、検索経由で見えてはいけないものが漏れる心配は薄い構造です。アクセスはcloudsearch.google.comとモバイルアプリからで、組織側でサービスが有効になっていることが前提になります。

検索に頼れないぶんをページ階層と入口の数で埋める設計の考え方

Business Starterや、横断検索を全社へ配らない方針の組織では、到達手段はナビゲーションだけになります。ここでの設計指針は単純で、深さを削って入口を増やすことです。二階層で目的の資料に触れる構成を目標値に置き、三階層目が必要になったらページではなくサイトの分割を検討します。

もう一つの手が、閲覧者ツールのアンカーリンクです。公開済みのサイトで特定のヘッダーやサブヘッダーへ直接リンクできる機能で、設定アイコンから閲覧者ツールを開いて切り替えます。長い規程ページや手順ページを持つポータルでは、章単位のURLを社内チャットやマニュアルへ貼れる状態にしておくと、検索の弱さをリンクの共有で補えます。

掲載する情報の並べ方そのものは、検索の有無とは別の論点です。何を上に出し何を畳むかの判断基準は見やすい社内ポータルのデザインに、用途パターンごとの構成例は社内ポータルの事例を四つの用途パターンで読み解く｜自社に再現できる条件と設計の勘所にまとめてあります。

埋め込みとApps Scriptで広げられる範囲と外部開発へ渡す線引き

標準機能で足りるかどうかの判断は、埋め込みで何ができるかを正確に知ってから下します。ここを曖昧にしたまま要件を膨らませると、途中で作り直しになります。

HTMLとCSSとJavaScriptを差し込める箱としての埋め込みの実際

Googleサイトに追加できるのは、YouTube動画やカレンダー、地図といったGoogle側の部品と、他サイトのページまたはコンテンツのセクション、そしてHTML・CSS・JavaScriptのコードです。埋め込みではウェブアドレスのほか、Apps Scriptやデータポータルのレポートも差し込めます。1ページ全体を埋め込み専用にする配置も選べるため、外部で作った画面を丸ごと載せる構成が取れます。

この自由度をどう読むかが分かれ目になります。Apps Scriptを噛ませれば、スプレッドシートを台帳にした簡易的な申請フォームや、ドライブの新着一覧を出すパネルまでは標準の範囲で組めます。逆に言えば、Googleサイト自体は表示の器であり、処理はすべて埋め込み先が持つ構造です。ポータルの機能を増やすとは、埋め込む先を増やすことに他なりません。

申請や承認が絡んだ時点で別システムに寄せたほうが早くなる理由

判断の線はここに引きます。閲覧・周知・リンク集約までであれば、Googleサイトと共有ドライブとGoogleグループの組み合わせで十分に成立します。ここへ「誰がいつ承認したかを残す」「差し戻しの状態を持つ」「基幹システムのデータを条件付きで出し分ける」が入った時点で、標準機能の外側です。

Apps Scriptで書けなくはありませんが、承認履歴と権限判定をスクリプトで持つ構成は、作った人が異動した時点で保守が止まります。ページ単位の閲覧制御が存在しない以上、出し分けは埋め込み先のアプリケーション側で実装するしかなく、その時点で開発物の管理責任が生じる構造です。ここを社内で抱えるか外へ出すかは費用構造の話になるため、社内ポータルの費用相場と内訳｜SaaSと個別開発が逆転する規模と年数の分岐点の分岐点と突き合わせて決めます。

要件が申請導線や基幹連携まで伸びた場合は、埋め込む先を個別に開発する形が現実解になります。当社ではポータルサイトシステム開発として、Googleサイトを入口に残したまま権限分割と業務連携の部分だけを切り出す構成にも対応しています。

GoogleサイトとSharePointとNotionのどれに寄せるかの判断基準

最後に判断を言い切ります。三つは守備範囲が異なり、迷ったら選ぶという性質のものではありません。

Googleサイトを採用してよい条件を三つの前提から言い切る

Googleサイトを社内ポータルの土台に据えてよいのは、次の三つが同時に成り立つ場合に限られます。一つ目は、すでにGoogle Workspaceを全社で使っていて、資料の実体がドライブ側にあること。二つ目は、閲覧権限の分割単位が「サイト単位」で説明できること。部署ごとにページの見え方を変える要件があるなら、この時点で外れます。

三つ目は、ポータルに求める機能が周知・リンク集約・資料への到達までで収まっていることです。この三条件がそろっているなら、追加費用なしで運用でき、編集を各部門へ委ねられる点でGoogleサイトが最も軽い選択になります。従業員数の目安を挙げるなら、共有ドライブの自動非表示が効き始める1,000人が一つの区切りです。それを超える規模では、資料の共有ドライブを業務単位で割る設計が前提条件として乗ります。

逆に、Google Workspaceを使っていない組織がポータルのためだけに導入するのは筋が悪い判断になります。Googleサイトの利点はドライブ・グループ・カレンダーとの接続にあり、その周辺がなければ、単なる無料のページ作成ツールとして評価されるだけです。

見送るべき場面と乗り換え先をあらかじめ決めておく判断の置き方

見送るべき場面は二つに整理できます。一つは、閲覧権限をページやセクションの単位で細かく切る要件が確定している場合です。この要件が動かないなら、初手からSharePointを選ぶのが妥当です。一意のアクセス許可で継承を切る設計が標準機能として用意されており、Googleサイトで同じことをやろうとすればサイトが際限なく増えます。すでにMicrosoft 365を契約している組織なら、追加コストなしでこちらへ寄せられます。

もう一つは、ポータルが「読ませる場所」ではなく「書き込ませる場所」になる場合です。議事録やナレッジを社員が日常的に追記していく運用なら、編集と閲覧が同じ画面で完結するNotionのほうが摩擦が少なくなります。Googleサイトは編集画面と公開画面が分離しており、更新のたびに公開操作が要る構造です。更新頻度が日次に近づくほど、この一手間が滞留の原因になります。

判断を先送りにしないための置き方として、乗り換えの条件を最初の設計書へ書いておくことを勧めます。「権限をページ単位で分ける要望が二部門から出たらSharePointへ移す」「更新頻度が週次を超えたら書き込み型のツールを併設する」といった条件式にしておけば、作り直しの判断が属人的になりません。Googleサイトは撤退コストが低い選択なので、条件付きで始めて条件付きで手放す運用が取りやすい土台でもあります。

よくある質問

Googleサイトの社内ポータルは無料で使えますか？

Google Workspaceを契約していればサイト自体に追加費用はかかりません。ただし横断検索のクラウドサーチはBusiness Standard以上のエディションが対象で、Business Starterでは利用できません。検索を前提にした情報設計を採るなら、エディションの差額が実質的なポータルの費用になります。

ページごとに閲覧できる人を変えられますか？

できません。Googleサイトの権限は編集する側と公開済みサイトを見る側の二層で、粒度はサイト単位です。見せる相手が異なる情報は別サイトとして起こし、本体サイトからリンクで束ねる構成にします。ページ単位の制御が要件なら、SharePointなど別の土台を検討する場面です。

サイトは見えるのに埋め込んだ資料が開けないのはなぜですか？

サイトの閲覧権限と、埋め込んだファイルの共有権限が別に管理されているためです。共有ドライブ上のファイルや共有範囲を絞ったファイルは、アクセス権を持つユーザーにしか表示されません。公開時にファイル側のアクセス権も共有する手順を、公開作業のチェック項目に入れておきます。

社員が1,000人を超える会社でも使えますか？

使えますが、資料の共有ドライブを分ける前提が要ります。1,000人を超えるグループと共有ドライブを直接共有すると、超過分のユーザーには既定で非表示になります。間接的な共有でも2,500人が閾値です。全社一括の共有ドライブではなく、部門や業務の単位へ割る設計にしてください。

社外の取引先にも一部を見せられますか？

サイトの公開対象で［公開］を選ぶか、制限付きのまま外部アカウントを閲覧者に追加すれば技術的には可能です。ただし可否を握っているのは管理コンソールのドライブ共有設定なので、対象の組織部門で外部共有が許可されているかを先に確認します。社内向けと社外向けは、同じサイトに混ぜず分けたほうが事故が起きません。