GeminiとGoogle サイトで社内ポータルを効率よく作る方法
｜GASによる更新の省力化も解説

「社内のお知らせやマニュアルを1か所にまとめたい。しかし、Webサイトを一から開発するほどの予算や人員は確保できない」。
Google Workspaceを利用する企業では、このような場面でGoogle サイトが選択肢にすることができます。

Google サイトは、Google Workspaceのファイルや申請フォームを組み合わせ、社内ポータルをノーコードで作成できるサービスです。Geminiにコード作成を支援してもらえば、検索や計算を行う小さなWebアプリも埋め込めます。ただし、公開後の更新や権限管理まで自動化されるわけではありません。Google サイトを土台にした作成方法、Google Apps Script（以下、GAS）による更新の省力化、LumAppsを検討する基準を整理します。

Google サイトなら社内ポータルを小さく始められる

Google サイトは、固定情報や Google Workspace 上のファイルを集約する社内ポータルに向いています。専門的なコーディングをせずにページを作成し、閲覧者を特定のユーザーやグループに制限できます。

一方、サイトの公開範囲と、埋め込むファイルやWebアプリのアクセス権は同じとは限りません。作成の手軽さだけでなく、閲覧者が各コンテンツを実際に開けるかまで確認する必要があります。

Google Workspace のファイルやリンクをまとめられる

Google サイトには、Google ドキュメント、スプレッドシート、スライド、フォーム、カレンダー、マップなどを画面上の操作で配置できます。申請フォームや業務システムへのリンクもまとめられるため、情報の入口を1か所に集約できます。

社内ポータルとして作りやすい例は次のとおりです。

• 社内規程や業務マニュアルをまとめたサイト
• 各種申請フォームや業務システムへのリンク集
• 部門内のお知らせページ
• 新入社員向けのオンボーディングサイト
• プロジェクトメンバー向けの情報共有サイト
• 災害時の連絡先や対応手順を掲載したサイト

編集内容を閲覧者へ反映するには、サイトを公開または再公開します。
基本的な作成手順は、Google公式の Google サイトの使い方で確認できます。

公開範囲と埋め込みファイルの権限は別に確認する

Google サイトは、公開済みサイトを「制限付き」にして、特定のユーザーやグループへ共有できます。ただし、サイト内に配置したGoogle ドライブのファイルは、それぞれの共有権限が反映されます。サイトを開けても、埋め込んだマニュアルやスプレッドシートへの権限がなければ、その部分は閲覧できません。

できれば、公開前に編集者のアカウントだけでなく、一般の閲覧者を想定したテストアカウントでも表示を確認しましょう。Google公式のサイトを公開して共有する手順では、公開対象の設定方法が案内されています。

Geminiは Google サイトの設計とコード作成を支援する

Geminiの活用タイミングは、社内ポータルの構成案、掲載文、HTML、CSS、JavaScriptの作成などを行うタイミングです。Google サイトの編集や公開を自動で完了する機能はなく、人が設計と公開を進める際の制作支援として使うことができます。

小さな検索・計算ツールのたたき台も作れますが、データの扱い、外部通信、表示環境、出力形式をプロンプトで指定し、生成後はしっかり人が確認しましょう。

Geminiがサイトを直接作成・公開するわけではない

Gemini アプリのCanvas機能を使うと、ミニアプリやコードを作成・編集できます。ただし、Canvasで作った内容がGoogle サイトへ自動的に配置されるわけではありません。

実際の作業は次のように分かれます。

1. Geminiにサイト構成やコードの作成を依頼する
2. 生成された内容を人が確認・修正する
3. Google サイトでページを作成する
4. 文章、画像、リンク、コードを配置する
5. 公開範囲を確認して公開する

Geminiは構成案やコードの作成を補助できますが、サイトの権限設定、コードの安全性、掲載内容の正確性は利用者が判断する必要があります。Canvasの機能はGoogle公式ヘルプで確認できます。

小さなWebアプリを埋め込み領域へ追加できる

Google サイトは、HTML・CSS・JavaScriptのコード埋め込みに対応しています。外部サービスへ通信せず、埋め込み領域内で完結する小さなアプリであれば、比較的試しやすい構成です。

たとえば、次のような用途が考えられます。

• 出張費や経費の簡易計算
• 研修受講状況のチェックリスト
• 担当部署の案内表
• 製品や社内制度の選択支援

埋め込んだコードは、Google サイト全体のデザインを変更するのではなく、独立した埋め込み領域で動作します。サイト全体を自由に開発できる機能ではない点に注意が必要です。

Geminiへ依頼するプロンプトを具体化する

Geminiへは、機能に加えてデータの扱い、外部通信、表示環境、出力形式も指定します。たとえば、次のように依頼すると良いでしょう。

Google サイトでは、「挿入」から「埋め込む」を選び、「埋め込みコード」へ貼り付けます。JavaScriptはscriptタグ内、CSSはstyleタグ内に記述します。詳しい操作は Google 公式のコンテンツ追加手順で確認できます。

埋め込み後は、パソコン、タブレット、スマートフォンのプレビューで、文字切れ、スクロール、ボタンの押しやすさを確認します。

まずは架空の問い合わせ先などを数件作成して試しましょう。限定共有のテストサイトへ埋め込み、パソコンとスマートフォンで閲覧でき、外部通信がないことをコードで確認できれば、最小構成の検証は完了です。

GASとスプレッドシートで更新作業を省力化できる

更新頻度が高い情報は、Google スプレッドシートを登録画面にし、GASのWebアプリで表示すると更新作業を減らすことができます。Google サイト本体へ記事を自動投稿するのではなく、埋め込んだWebアプリの表示内容を変える構成です。

お知らせをスプレッドシートで管理する

社内のお知らせを Google サイト上で直接更新する運用では、担当者が編集画面を開き、変更のたびに再公開する必要があります。スプレッドシートを登録画面にすれば、更新担当者は表へ情報を追加するだけで済みます。

たとえば、次の列を用意します。

公開状態が「公開」の行だけを読み込み、公開日の新しい順に並べてHTMLとして表示するようにGASを構成できます。下書きや掲載終了の状態も列で管理すれば、コードを変更せず表示を切り替えられます。運用に応じてGASの動作を調整しましょう。

GAS WebアプリをGoogle サイトへ埋め込む

GASのWebアプリは、doGetまたはdoPost関数を用意し、HTMLまたはテキストを返すことで公開できます。デプロイ後に発行されたURLをGoogle サイトへ埋め込むと、スプレッドシートの内容をサイト内へ表示できます。

この構成では、担当者がスプレッドシートを更新すると、Webアプリが次にデータを読み込んだ際の表示も変わります。固定ページやメニューに変更がなければ、Google サイト本体を毎回再公開する必要はありません。

Apps Scriptの公式ガイドでは、Webアプリの要件、デプロイ、実行権限、Google サイトへの埋め込み方法が案内されています。

現在のGoogle サイト本体はGASから直接更新できない

現在のGoogle サイトに対して、GASからページを追加したり、ページ本文を書き換えたりする一般向けAPIは提供されていません。Google Sites APIは存在しますが、対象は以前のGoogle サイトのみです。

Google Sites APIの公式ページでは、APIが非推奨であり、2016年に提供開始された再構築版のGoogle サイトへアクセスできないと案内されています。

そのため、役割は次のように分けます。

• Google サイト：メニュー、固定ページ、リンク集など全体の枠組み
• Google スプレッドシート：お知らせやFAQの登録・管理
• GAS：スプレッドシートを読み込み、Web画面として表示
• Google サイトの埋め込み：GAS Webアプリをサイト内に表示

「GASでGoogle サイトへ自動投稿する」のではなく、「GASで生成した画面をGoogle サイトへ埋め込む」構成です。

GASの運用では権限・保守・利用上限を管理する

GASで更新を省力化しても、Webアプリの公開範囲、実行権限、生成コードの確認は忘れずに行いましょう。社内ポータルへ組み込む前に、Google サイトとWebアプリを別々のシステムとして点検することが重要です。

本番公開の判断には、正常に表示できることだけでなく、誰の権限で何を読み込むか、担当者変更や障害にどう備えるか、Apps Scriptの利用上限へ対応できるかという観点も忘れないようにしましょう。

Google サイトとWebアプリの公開範囲をそろえる

Google サイトを社内限定で公開しても、GAS Webアプリには別のアクセス権限が設定されます。Webアプリの公開範囲が広ければ、URLから直接アクセスされる可能性があります。反対に、権限が狭すぎると、サイトは見えても埋め込み部分だけ表示されません。

また、Webアプリは「デプロイしたユーザー」または「アクセスしたユーザー」のどちらとして実行するかで、利用できるデータと承認の流れが変わります。

• Google サイトとWebアプリの閲覧対象が一致しているか
• 実行ユーザーの設定が用途に合っているか
• スプレッドシートの共有範囲が必要以上に広くないか
• 閲覧者に追加の承認が必要か
• WebアプリのURLへ直接アクセスした場合も問題がないか

テストアカウントで、サイト経由のアクセスとURLへの直接アクセスの両方を確認してください。

生成コードは人が確認してから公開する

Gemini が生成したコードは、完成品ではなく開発のたたき台です。実在しない関数、古い仕様、不要な外部通信、広すぎる権限が含まれる可能性があります。

少なくとも次の項目を確認します。

• 要件どおりに動作するか
• パソコンとスマートフォンで表示できるか
• 入力内容を意図しない外部サービスへ送信していないか
• APIキーやパスワードがコードに書かれていないか
• 不要に広いGoogle Workspaceの権限を要求していないか
• エラー画面やログへ機密情報を出していないか
• キーボード操作、文字サイズ、色の見分けやすさに問題がないか

利用者が入力する機能では、入力値の検証とエラー時の表示も確認します。機密情報や個人情報を使ったテストは避けてください。

担当者変更と障害に備える

GAS Webアプリを継続運用するには、デプロイ担当者、コードの保管、更新手順、障害対応を決めておく必要があります。個人のマイドライブや特定担当者だけに依存すると、異動やアカウント削除で保守できなくなるおそれがあります。

Apps Scriptには、1日あたりの割り当てや実行時間、同時実行数などの制限があります。上限を超えると例外が発生し、処理が停止します。割り当ては変更される可能性があるため、重要な情報を表示する場合は、Apps Scriptの割り当てに関する公式情報を定期的に確認します。

本番公開の前には、非機密のテスト用Webアプリを、想定する実行ユーザーと公開範囲でデプロイします。一般閲覧者、権限のないユーザー、デプロイ担当者という3種類のアカウントで「サイト内表示」「URLへの直接アクセス」「要求される承認」を記録し、意図しない閲覧経路があれば公開を止めてください。

Google サイトとLumAppsは運用要件で使い分ける

Google サイトとLumAppsの使い分けは、企業規模や利用者数だけでは決まりません。固定情報の集約が中心なのか、複数部門から継続的に発信し、利用者ごとに情報を届け分けるのかで必要な仕組みが変わります。

Google サイトへGASを追加すれば対応範囲は広がります。ただし、追加した仕組みの保守も自社の仕事として増えていきます。

Google サイトが向いているケース

Google サイトは、少数の担当者が固定ページやリンク集を管理し、Google Workspace上のファイルを社内へ共有する用途に向いています。

たとえば、部門ポータル、オンボーディングサイト、規程集、プロジェクトサイトのように、対象者と情報源が比較的明確な場合です。高頻度のお知らせだけをGAS Webアプリへ分ければ、サイト全体を複雑にせず更新負担を抑えられます。

一方、個別に作成したGASが増えるほど、コード、権限、デプロイ、障害対応の管理対象も増えます。必要な機能を追加できることと、長期的に運用しやすいことは同じではありません。

LumAppsを検討したいケース

LumAppsは、Google Workspace と連携する社内ポータルとして、情報発信、従業員のつながり、横断検索などを一つの基盤へまとめたい場合の候補になります。

LumApps公式のGoogle Workspace 連携ページでは、Gmail、Google ドキュメント、Google ドライブなどとの連携、Google アカウントによるログイン、ユーザーディレクトリや組織部門の同期が案内されています。Enterprise Searchの公式ページでは、Google WorkspaceやMicrosoft365、Workday、ServiceNowなどの情報源を統合し、利用者の役割やアクセス権に応じた検索結果を提供すると説明されています。

複数部門の投稿、利用者属性に応じた情報配信、複数システムの横断検索、コミュニティなどが重要になる場合は、個別開発を増やす前に製品としての機能と運用支援を比較するとよいでしょう。

利用者数だけでなく運用の複雑さで判断する

比較するときは、現在の人数ではなく、投稿体制、情報の届け分け、検索対象、保守責任を整理します。

利用者が少なくても、複数組織への情報の届け分けや横断検索が必要なら、専用製品を検討する価値があります。反対に、利用者が多くても、固定情報の閲覧が中心で運用が単純なら、Google サイトで要件を満たせる場合があります。

固定情報から小さく始め、更新と権限の負担を見直す

Google サイトを使えば、大規模なWeb開発を行わなくても、社内規程、マニュアル、申請フォーム、業務システムへのリンクを集約できます。Gemini は構成案や埋め込み用コードの作成を支援し、GASとスプレッドシートを組み合わせれば、更新頻度の高いお知らせをサイト本体とは分けて管理できます。

ただし、Gemini がGoogle サイトを直接作成・公開するわけではありません。
GASが現在のGoogle サイト本体を直接更新することもできません。公開範囲、生成コードの確認、Webアプリの実行権限、担当者変更、利用上限は人が管理します。

最初は、固定情報をまとめた限定共有のテストサイトと、非機密データを使う小さなミニアプリから始めるのが安全です。投稿部門が増える、情報の届け分けが必要になる、横断検索やコミュニケーションを強化したくなるといった変化が現れた段階で、GASを追加し続けるか、LumApps（Microsoft や Google Workspace との連携も可能）のような社内ポータル製品へ移行するかを見直してください。

まずは社内情報を使わず、「架空の申請リンク3件」「架空のお知らせ3件」だけで限定共有のテストサイトを作ってみましょう。閲覧者用アカウントですべての情報を開ければ、Google サイトを土台にできるか判断する最初の材料になります。