社内ポータルの作り方｜GASで自作した設計と工数
社内ポータルを作りました。Google Workspaceに標準で含まれるGoogleサイトは使わず、Google Apps Script（GAS）で構築しています。 作ったきっかけは、人が増えたことでした。
目次全13章
社内ポータルを作りました。Google Workspaceに標準で含まれるGoogleサイトは使わず、Google Apps Script（GAS）で構築しています。
作ったきっかけは、人が増えたことでした。ポータルが欲しかったからではありません。
この記事では、何を載せたのか、何が効いたのかを書きます。
書き手は、従業員約50人の建築・内装会社で総務部長とIT部長を兼任しています。前職はシステムエンジニアを約15年。情シスの専任担当はいません。
きっかけは採用だった
新卒採用に着手し、あわせて中途を一斉に採用しました。短期間で、社内に「何も知らない人」が複数人生まれたわけです。
そこで起きたのが、次のような状態でした。
- どこに何のファイルがあるか分からない
- 誰が何の担当か分からない
- 会議に呼ばれたが、資料がどこにあるか分からない
- 分からないことを、誰に聞けばいいか分からない
そして既存の社員は、これらに困っていませんでした。 何年も働いていれば、どこに何があるかは体で覚えています。誰に聞けばいいかも分かっている。
つまり、社内ポータルを必要としていたのは、既存社員ではなく新しく入った人でした。
社内ポータルとは何か
この経験から、定義がはっきりしました。
社内ポータルとは、情報を集める箱ではなく、新しく入った人が自分で動けるようになるための装置である。
情報の置き場としてなら、共有ドライブで足ります。実際、当社は社内ファイルサーバーを廃止して共有ドライブに移行済みでした。それでも足りなかったのは、置いてあることと、辿り着けることが別だったからです。
目的をここに定めたことで、載せるものが決まりました。
何を載せたか
構成は大きく7つです。
| 機能 | 内容 |
|---|---|
| お知らせ・掲示板 | 全社通達。重要なものはトップに固定表示 |
| ヒヤリハット | 現場の安全情報。流れて消えないようにした |
| 経営数字 | 月次の売上サマリー |
| リンク集 | 共有ドライブの中身を体系的に案内 |
| 定例会議 | 日時・出席者・資料・Web会議URL・議事録を集約 |
| 従業員ページ | 顔写真・氏名・連絡先 |
| FAQ・問い合わせ | 質問と回答の蓄積、フォームからの受付 |
これにサイト内の全文検索を付けています。
効いたこと1｜流れて消える情報を固定した
導入前、社内の連絡はチャットで流れていました。速報性は高いのですが、問題は流れて消えることです。
ヒヤリハットが消えていた
当社は建築・内装業なので、現場の安全情報は重要です。ヒヤリハットの共有は、事故を防ぐための基本になります。
ところがチャットで流すと、その日のうちに他の話題に埋もれます。 後から探しても見つからない。新しく入った人は、過去に何があったかを知る手段がありません。
ポータルに掲示板を置き、ヒヤリハットを蓄積される情報として扱うようにしました。
重要なものはトップに固定
あわせて、重要な通達をトップに固定表示できるようにしました。
チャットの弱点は、重要度に関係なく時系列で流れることです。「必ず読んでほしい通達」と「今日の雑談」が同じ扱いになる。
固定表示にすると、見ていない人が「知らなかった」と言えなくなります。 運用上、地味に効きます。
効いたこと2｜共有ドライブの「どこにあるか分からない」を解いた
社内ファイルサーバーを廃止し、共有ドライブに2TBを移行しました。それで解決したかというと、していませんでした。
階層が深くなる
共有ドライブは、放っておくと階層が深くなります。部署ごと、年度ごと、案件ごとにフォルダが増え、目的のファイルまで何回もクリックすることになる。
そしてどこに何があるかを知っているのは、それを作った部署だけです。他部署から見ると、どのフォルダを開けばいいのか見当がつきません。
リンク集で「地図」をかぶせた
そこで、ポータル側に共有ドライブの体系的な案内を置きました。
「規程類はここ」「見積フォーマットはここ」「議事録はここ」という形で、深い階層へ直接飛べるリンクを並べる。 共有ドライブの構造そのものは変えず、上から地図をかぶせるイメージです。
フォルダ構成を作り直すより、はるかに現実的でした。 各部署のフォルダに手を入れるのは合意形成が必要ですが、リンクを並べるだけなら誰にも影響しません。
効いたこと3｜定例会議をワンクリックにした
これが最も日常的に使われています。
定例会議ごとに、次の情報をひとまとめにしました。
- 開催日時と、誰が出席するか
- 使用する報告資料へのリンク
- Web会議のURL（固定）
- 過去の議事録
導入前は、会議のたびに「資料はどこ」「URLはどれ」というやり取りが発生していました。Web会議のURLを固定にしたのも効いています。 毎回発行して共有する手間がなくなりました。
新しく入った人にとっても、会議に呼ばれた時点で必要なものが全部揃っている状態になります。
効いたこと4｜質問が資産になる仕組み
FAQと問い合わせフォームを置きました。ただ並べたのではなく、つないでいます。
フォームから届いた質問に回答すると、その内容がFAQに蓄積される構成です。
なぜこの形にしたか
FAQは、最初から完成させることができません。何が分からないのかは、分からない人にしか分からないからです。
管理者が想像で作ったFAQは、たいてい的を外します。 実際に聞かれたことだけが、本当に必要な項目です。
採用で人が増えた時期は、同じ質問が繰り返し来ます。1回答えたものが自動的に残っていく仕組みにしておくと、答える回数が減っていきます。
従業員ページと全文検索
あわせて、顔写真・氏名・連絡先をまとめた従業員ページを作りました。新しく入った人にとって、社内の人の顔と名前が一致しないのは想像以上のストレスです。
そしてサイト内の全文検索。どこに何があるか分からなくても、言葉で探せる状態にしました。ポータルを作る目的が「新しい人が自走できること」である以上、ここは必須でした。
設計の原則｜どのページからでもワンクリックで飛べる
機能の話をしてきましたが、設計上で最も強く意識したのはこれです。
社内ポータルは、目的地ではなく通り道である。
ポータルに来てもらうのではなく、通過してもらう
社内ポータルが使われなくなる典型的な理由は、「見に行く場所」になってしまうことです。
お知らせを読むためだけに開くページは、忙しい日には開かれません。数日開かなければ習慣が切れ、そのまま存在を忘れられます。
そこで、業務で毎日使うものへの入口をすべてポータルに集約しました。
- 勤怠システム
- 見積システム
- 現場管理システム
- チャット
- カレンダー
- 共有ドライブの主要フォルダ
これらに行くには、ポータルを通るのが最も早い状態を作る。 そうすれば、お知らせを読ませようとしなくても、毎日必ず目に入ります。
どのページにいても、ワンクリック
さらに徹底したのが、ポータル内のどのページを開いていても、これらに1クリックで飛べることでした。
FAQを読んでいる途中で勤怠を打刻したくなる。議事録を探している最中にチャットを確認したくなる。そのたびにトップページへ戻るのは、1回あたり数秒の話ですが、1日に何度も起きます。
この数秒を削ることが、使われるかどうかを分けると考えました。
使われない理由は、たいてい機能ではない
社内ポータルが定着しない原因は、載っている情報が足りないからではありません。開くのが面倒だからです。
- 開くまでに手数がかかる
- 目的のものに辿り着くまでにクリックが多い
- 結局ブックマークから直接行ったほうが早い
3つ目が起きた時点で、ポータルは負けています。 ブックマークより速くなければ、誰も経由しません。
この基準で設計すると、求められる自由度がかなり高くなります。 常時表示のナビゲーション、階層に依存しない導線、画面幅に応じた配置。ここが、既製のツールでは足りなくなった原因でした。
経営数字を社内に公開した
ポータルには、月次の売上サマリーを載せています。
これは機能ではなく経営判断です。中小企業で社内に数字を出すのは、一定の勇気が要ります。
それでも載せたのは、従業員に会社の状態を意識してもらうためでした。自分の仕事が全体のどこに効いているのかが見えないと、当事者意識は育ちません。
どこまで開示するかは、会社ごとに判断が分かれる部分だと思います。 当社は売上のサマリーに留めており、原価や個別案件の利益までは出していません。
Googleサイトではなく、GASで作った
Google Workspaceには標準でGoogleサイトが含まれています。社内ポータルの作り方としては、これが定番です。
当社も最初はGoogleサイトで作ろうとしました。そして途中でやめました。
理由は、ノーコードゆえに自由度が足りなかったことです。具体的には3点でした。
- レイアウトが固定される。 配置の自由が利かず、余白も調整できない
- 動的な表示ができない。スプレッドシートの内容をリアルタイムに出せない
- スマートフォンでの見え方。どうしても野暮ったく、素人が作ったものに見える
3つ目は些細に見えて重要でした。現場の社員が最も多く開くのはスマートフォンです。そこで見栄えが悪いと、使う気になりません。
そして前章で書いた「どのページからでもワンクリック」という要件が決定的でした。常時表示のナビゲーションを自由に組めなければ、この設計は成立しません。
判断の分かれ目は、「使ってもらえるかどうか」の一点でした。ブックマークより速くなければ、誰も経由しません。
ストレスなく使えるかを限界まで詰めた結果、GASに行き着きました。
この判断の詳細は別記事で扱います。Googleサイトで足りる会社も多いはずなので、無条件にGASを勧めるつもりはありません。
実装はすべてAIに任せた
もう1点、書いておくべきことがあります。
コードは1行も自分で書いていません。実装はすべてAIに任せ、私は設計とテストに特化しました。
前職でシステムエンジニアを15年やっていたので、書こうと思えば書けます。それでも書かなかったのは、兼任で回している以上、時間を投じる先を選ぶ必要があったからです。
情報システムを兼任している立場では、コードを書く時間よりも、何を作るべきかを決める時間のほうが希少です。
- 設計 — 何を載せるか、どういう画面にするか、どこまでやるか
- テスト — 意図通りに動くか、使う人がつまずかないか
この2つは、社内の事情を知っている人間にしかできません。逆に実装は、指示さえ正確なら任せられます。
使い分けの境界線は、下がり続けている
実装に使うAIは、当時は対象の規模で変えていました。
単機能の業務効率化ツール、たとえばスプレッドシートの内容を整形して通知を送るといった程度のものは、Geminiのようなチャット型の生成AIで実装していました。対話しながらコードを受け取り、貼り付けて動かす。この規模ならこれで足ります。
社内ポータルはその規模を超えました。複数のページ、権限の制御、データの読み書き、画面ごとの状態管理。ファイルが増え、複数箇所を同時に直す必要が出てきます。
そこで、Claude Codeを導入して実装しました。 対話で1ファイルずつ受け取るのではなく、プロジェクト全体を対象に作業を進めるタイプのツールです。
当時の判断の目安は、「作るものが1画面で完結するか」でした。完結するならチャット型で足り、複数の画面と機能が絡み合うならエージェント型が必要になる、という線引きです。
ただし、この線引きはすでに動いている
ただし付け加えると、2026年7月現在、同じものを作るなら最初からすべてエージェント型で作ると思います。
チャット型で足りる規模のものであっても、エージェント型で作ったほうが速く、修正も楽です。わざわざ使い分ける理由が薄くなりました。
つまり判断すべきは規模ではなく、従来型の生成AIで足りるか、エージェント型に頼らざるを得ないかという一線です。そしてこの線は、下がり続けています。
この記事を読んでいる時点では、さらに下がっているはずです。具体的なツール名や使い分けの基準は、そのまま真似しないでください。 数ヶ月単位で変わります。
変わらないのは、実装を任せられる範囲が広がり続けているという方向だけです。
技術者としての経験は、別のところで効いた
ただし、まったくの未経験者が同じことをできるとは思っていません。
AIが出したコードが妥当かどうかを判断する、動かない原因を切り分ける、そもそも実現可能な設計を描く。この部分に、15年の経験が効いています。
「AIがあれば誰でも作れる」とは書きません。AIによって、書ける人が書かなくてよくなったというのが正確な表現だと思います。
かかった工数
実績を書いておきます。合計で約1人月でした。
| フェーズ | 工数 | 内容 |
|---|---|---|
| 準備・設計 | 約0.3人月 | 何を載せるか、画面構成、既製品の検討 |
| 実装 | 約0.2人月 | エージェント型AIによる構築 |
| テスト・改修 | 約0.5人月 | 動作確認、使い勝手の調整 |
実装が最も短い
注目していただきたいのは、実装が全体の2割しかないことです。
従来、社内システムを作るといえば、時間の大半はコードを書くことに費やされました。その部分がAIに移った結果、比率が逆転しています。
代わりに増えたのが、前後の工程です。
準備・設計に0.3人月。 何を載せるか、どういう画面にするか、既製品で足りないか。ここは社内の事情を知っている人間にしかできません。
テスト・改修に0.5人月と、最も多くかかっています。 意図通りに動くか、使う人がつまずかないか。この確認は、実装より時間がかかります。
改修フェーズは自動化した
補足すると、改修からデプロイまでの流れは自動化しています。
初回の構築後、修正が発生するたびに手作業で反映していると、それだけで時間が溶けます。ここを自動化したことで、改修のサイクルが短くなりました。
社内システムは、作って終わりではありません。使われ始めてから「ここが使いにくい」という声が出ます。 その反映を素早く回せるかどうかが、定着を左右します。
見積もりの目安として
同じ規模のものを検討している方への目安です。
「実装にどれくらいかかるか」で見積もると、大きく外します。 実装は2割です。
設計とテストに8割かかるという前提で計画してください。そしてこの8割は、AIに任せられない部分です。
作ってみて分かったこと
最後に、いま同じことをする人へ。
1. ポータルの目的を「新しく入った人が自走できること」に置く。 既存社員は困っていません。困っている人を基準に設計すると、載せるものが決まります。
- ポータルを目的地ではなく通り道にする。 業務で毎日使うものへの入口を集約し、どのページからでもワンクリックで飛べるようにする。ブックマークより速くなければ経由されません。
- 共有ドライブの構造は作り直さない。 上からリンクで地図をかぶせるほうが、合意形成のコストが圧倒的に低い。
- 流れて消える情報を、蓄積される形に変える。 チャットは伝えるのに向いていますが、残すのには向いていません。
- FAQは想像で作らない。 実際に聞かれた質問だけを蓄積する仕組みにする。
- 実装より、設計とテストに時間がかかる。 工数は8対2です。「実装にどれくらいか」で見積もると外します。
- 作る前に、既製品で足りないかを確認する。 当社はGoogleサイトを試してからGASに移りました。順序を逆にすると、必要のない開発をすることになります。
よくある質問
社内ポータルは、何人規模から必要ですか
人数ではなく、人の入れ替わりが基準だと考えています。当社が必要になったのは、採用で短期間に複数人が入ったときでした。既存社員だけで回っている間は、なくても困りません。
Googleサイトで作るのとどちらがいいですか
多くの会社はGoogleサイトで足ります。当社が自作したのは、動的な表示、ナビゲーションの自由度、スマートフォンでの見え方という3つの要件があったためです。判断の詳細は別記事にまとめています。
作るのにどのくらいかかりましたか
合計で約1人月です。準備・設計に0.3人月、実装に0.2人月、テスト・改修に0.5人月。実装は全体の2割しかありません。
プログラムが書けなくても作れますか
実装はAIに任せられます。ただし、何を作るべきかを決める設計と、意図通り動くかを確認するテストは残ります。この2つが工数の8割を占めており、社内の事情を知っている人にしかできません。
掲示板やワークフローは、製品を買ったほうが早くないですか
社内にプログラムを書ける人がいなければ、そのほうが確実です。自作したものは作った人以外が保守しにくくなります。外注して作らせるくらいなら、製品を買うほうが安く確実です。
作ったのに使われない、という失敗を避けるには
ポータルを目的地ではなく通り道にしてください。勤怠、見積、チャット、カレンダーといった毎日使うシステムへの入口を集約し、どのページからでもワンクリックで飛べる状態にする。ブックマークより速くなければ、誰も経由しません。
経営数字を社内に公開して、問題は起きませんでしたか
当社では起きていません。ただし開示範囲は売上のサマリーに留めており、原価や個別案件の利益までは出していません。どこまで公開するかは会社ごとの判断になります。
この話の、実例を持ち寄る場があります。
記事の内容を「自社ではどう回すか」まで落とすのが、月例の少人数ビジネス深掘り会です。新着コラムと開催案内は、公式LINEでお届けしています。
