kintoneポータルカスタマイズの設計方法｜社内業務の入口を整える

kintoneを使うアプリが増えると、最初に詰まりやすいのがポータルです。

アプリが多すぎて探せない。

部署ごとに見るべきアプリが違う。

未対応タスクや承認待ちがどこにあるか分からない。

社内リンク、マニュアル、スケジュール、申請導線がばらばらに置かれている。

お知らせは出ているが、業務上の次アクションに結びつかない。

スマートフォンで見ると、導線が長くて使いにくい。

この状態でポータルを「きれいにする」だけでは、問題は残ります。

よくある失敗は次の通りです。

• 全社員に同じアプリ一覧を見せてしまう
• 部署別に必要な導線を整理せず、リンク集だけ増える
• 未対応、承認待ち、期限超過などの実務タスクが見えない
• お知らせ、社内規程、申請フォーム、業務アプリが並んでいるだけになる
• PC画面だけ整えて、モバイル利用を確認していない
• JavaScript/CSSの保守担当がいない
• kintone全体カスタマイズとアプリ個別カスタマイズの読み込み順を考えていない
• 退職や異動で、ポータルのリンクや表示条件を直せなくなる

ポータルは、ログイン後に最初に見る画面です。

だからこそ、最初に見せるべきなのは「会社の情報すべて」ではありません。

その人が今日見るべき業務、対応すべきタスク、使うべきアプリ、確認すべきお知らせです。

kintoneポータルカスタマイズで最初に決めるべきなのは、デザインではなく、部署別に誰が何を見て、どの業務へ入るかです。

この記事では、kintoneポータルカスタマイズを、見た目の変更ではなく、社内業務の入口を整える設計として整理します。

kintoneカスタマイズの設計方法はこちら
kintoneタスク管理の設計方法はこちら
kintoneワークフローの設計方法はこちら
kintoneダッシュボードの設計方法はこちら

ポータルは社内業務の入口

kintoneポータルは、単なるアプリ一覧ではありません。

社内の業務入口です。

ポータルに何を置くかで、社員の動き方が変わります。

ポータルに置くもの	目的
重要アプリ	よく使う業務へ迷わず入る
未対応タスク	今日対応すべき仕事を見つける
申請・承認	ワークフローを開始・確認する
お知らせ	会社や部署からの重要情報を確認する
社内リンク	規程、マニュアル、外部システムへ移動する
部署別メニュー	自分の業務に関係する導線だけ見る
集計サマリー	期限超過、未対応、件数の変化を確認する

kintone公式ヘルプでは、ポータルの初期表示として、お知らせ、通知、未処理、スペース、アプリが表示されると説明されています。

kintoneヘルプ：ポータルの設定／変更

標準ポータルでも、表示するコンテンツの選択やカバー画像の設定はできます。

ただし、各エリアの表示位置を変えたり、ユーザーごとにポータル設定を変えたりはできません。

そのため、部署別の導線や独自のタスク表示を作る場合は、JavaScript/CSSやプラグイン、制作サービスを検討します。

ここで注意すべきなのは、ポータルを全部入りの画面にしないことです。

すべてのアプリ、すべてのリンク、すべてのお知らせを置くと、結局探す画面になります。

ポータルは、探す場所ではなく、次に動く場所として設計します。

部署別に必要な導線を整理する

ポータルカスタマイズでは、部署別に必要な導線を洗い出します。

営業、経理、管理部、現場、開発、役員では、朝いちばんに見るべきものが違います。

部署・役割	見たいもの	入りたい業務
営業	本日の商談、未対応顧客、見積承認待ち	顧客管理、案件管理、見積、日報
経理	請求予定、入金確認、承認待ち	請求管理、支払申請、会計連携
管理部	社内申請、備品、入退社、規程	ワークフロー、社内手続き、マニュアル
現場	本日の作業、未完了報告、写真登録	作業日報、点検、在庫、トラブル報告
マネージャー	期限超過、未対応、承認待ち	タスク一覧、承認、レポート
役員	重要指標、滞留、リスク	ダッシュボード、重要案件、稟議

全員に同じポータルを見せる場合でも、部署ごとの導線を固めることはできます。

たとえば、上部に全社共通のお知らせを置く。

中央に部署別メニューを置く。

下部に社内リンクやマニュアルを置く。

ログインユーザーの組織やグループを見て表示を変える場合は、JavaScriptでの制御やAPI利用を検討します。

ただし、表示を変えることと権限を守ることは別です。

見せたくないデータは、アプリやレコードのアクセス権で守ります。

ポータルでリンクを非表示にするだけでは、権限制御にはなりません。

部署別ポータルは、リンクを部署ごとに並べるだけでは足りません。部署ごとの未対応、承認待ち、期限超過を見せる設計にします。

kintoneセキュリティ設計はこちら

アプリ一覧・タスク・申請・お知らせの配置

ポータルに置く要素は、役割で分けます。

要素	置く目的	注意点
アプリ一覧	よく使う業務アプリへ入る	全アプリを並べない
未対応タスク	自分が処理すべき仕事を見る	担当者、期限、ステータスを明確にする
申請・承認	ワークフローの開始と承認待ち確認	申請種別と承認待ちを分ける
お知らせ	全社・部署の重要情報を出す	古いお知らせを残し続けない
社内リンク	規程、マニュアル、外部システムへ行く	リンク切れと管理者を持つ
集計サマリー	件数や異常値を見て判断する	詳細アプリへの導線を付ける

たとえば、営業向けポータルなら、次の順番が自然です。

1. 今日の商談・対応予定
2. 未対応問い合わせ
3. 見積承認待ち
4. よく使うアプリ
5. 提案資料・社内マニュアル
6. 全社お知らせ

管理部向けなら、次のようになります。

1. 承認待ち申請
2. 期限超過の社内手続き
3. 入退社関連リンク
4. 規程・申請書
5. 全社お知らせ

このように、ポータルの配置は、見た目の好みではなく、業務の優先順位で決めます。

「よく使うアプリ」を上に置くのか。

「今日やるべきタスク」を上に置くのか。

「全社お知らせ」を最初に見せるのか。

この判断が、ポータルの使いやすさを決めます。

kintone通知の設計方法はこちら

デザイン変更と業務導線改善を分ける

ポータルカスタマイズでは、デザイン変更と業務導線改善を分けて考えます。

目的	内容	失敗しやすい点
デザイン変更	色、余白、アイコン、カード、見出し	きれいだが業務に入れない
業務導線改善	部署別メニュー、未対応、承認待ち、リンク	見た目は地味でも仕事が進む
情報整理	古いリンク、使わないアプリ、お知らせの整理	管理者が決まっていないと散らかる
判断支援	期限超過、件数、重要タスクの表示	数字の意味が決まっていないと見ない

こだわりkintoneのサービスページでは、スケジュール、ワークフロー申請、社内システム、お知らせなどをkintoneポータルへ集約する考え方が紹介されています。

こだわりkintone：ポータルカスタマイズサービス

このようなデザインサービスやプラグインは、ポータルを整える手段として有効です。

ただし、どの部署に何を見せるか、誰がリンクを更新するか、未対応タスクの定義は何か、という設計は自社側で決める必要があります。

見た目を整える前に、ポータルに置く情報を棚卸しします。

• 毎日見るもの
• 週に数回見るもの
• 緊急時だけ見るもの
• 新入社員だけ見るもの
• 管理者だけ見るもの
• もう使っていないもの

この分類をしないままカードやアイコンを増やすと、見た目は整っても、使われないポータルになります。

JavaScript/CSS・プラグイン・制作サービスの使い分け

kintoneポータルを変える方法は複数あります。

方法	向いているケース	注意点
標準ポータル設定	表示する標準エリアを選ぶ、カバー画像を変える	配置やユーザー別表示には限界がある
JavaScript/CSS	独自メニュー、タスク表示、リンク表示、API取得	保守担当、読み込み順、モバイル確認が必要
プラグイン	テンプレート化、ガジェット表示、簡易編集	製品の対応範囲と終了時の扱いを確認する
制作サービス	デザイン、設計、実装をまとめて依頼する	業務導線の要件を自社で説明できるようにする
ポータル運用アプリ	リンクやメニューをアプリで管理する	表示ロジックと権限の整理が必要

kintone公式ヘルプでは、kintone全体のカスタマイズはkintoneシステム管理画面からJavaScript/CSSファイルを適用し、トップページのポータルやスペースのポータルをカスタマイズする場合も同様だと説明されています。

kintoneヘルプ：JavaScriptやCSSを使用したkintone全体のカスタマイズ

また、適用範囲として「すべてのユーザー」「kintoneのシステム管理者だけ」「適用しない」を選べること、すべてのユーザーに適用する前に管理者だけで確認すること、ゲストユーザーには適用されないことも案内されています。

さらに、kintone公式ヘルプでは、Kintone Portal Designerが2025年5月12日に開発終了したことも明記されています。

過去の記事や社内資料がKintone Portal Designer前提になっている場合は、そのまま使い続けるのではなく、現在の運用と保守リスクを確認します。

cybozu developer networkでは、ポータル画面表示後のイベントとして、PCのportal.show、モバイルのmobile.portal.showが説明されています。

cybozu developer network：ポータル画面を表示した後のイベント

このイベントを使うと、ポータルに独自のコンテンツを追加できます。

ただし、イベントは表示対象のウィジェット描画後に発生し、ゲストユーザーのポータル画面では発生しないなどの補足があります。

ポータルをカスタマイズするなら、こうした制約を踏まえて設計します。

kintoneポータルのJavaScript/CSSは、全体に効く変更です。アプリ個別カスタマイズより影響範囲が広い前提で、検証と戻し手順を用意します。

権限別表示とモバイル対応

ポータルは全社員が見る可能性があるため、権限設計が重要です。

論点	設計すること
部署別表示	組織、グループ、役割で表示メニューを分けるか
権限	リンク非表示とアプリ権限を混同しない
社外ユーザー	ゲストユーザーに見せる範囲を別に考える
管理者表示	管理者向けリンクや設定導線を分ける
個人タスク	ログインユーザーを基準に未対応を出すか
共有端末	ログインユーザーが変わる前提で確認する

ポータルでリンクを隠しても、アプリのアクセス権が広ければデータは見えます。

逆に、ポータルにリンクを出しても、アプリ権限がなければ開けません。

そのため、ポータルの表示制御とアプリのアクセス権を別々に確認します。

モバイルも同じです。

現場や外出先でポータルを使うなら、スマートフォンで本当に必要な導線だけに絞ります。

PC向けの大きなカード、横並びの一覧、複雑な集計は、スマートフォンでは読みづらくなります。

モバイル向けには、次のような構成が実務向きです。

• 今日のタスク
• 報告アプリ
• 申請アプリ
• 緊急連絡
• マニュアル
• よく使う外部リンク

Ribbitの記事では、portal.showイベントでタスク一覧や集計サマリーを表示する実践例が紹介され、API呼び出しが増えると表示速度に影響するため取得フィールドを絞る考え方も説明されています。

Ribbit：kintoneのポータル画面をJavaScript・CSSでカスタマイズする方法

ポータルは最初に開く画面なので、表示が重いと毎日の利用に響きます。

必要な情報を絞り、詳細は各アプリへ遷移させます。

保守しやすいポータル設計

ポータルカスタマイズは、作った後の保守が重要です。

保守対象は、JavaScriptやCSSだけではありません。

保守対象	管理すること
メニュー	追加、削除、部署変更、リンク切れ
重要アプリ	アプリ名変更、アプリ統廃合、権限変更
タスク表示	対象アプリ、ステータス、期限、担当者
お知らせ	掲載期限、管理者、古い情報の削除
社内リンク	URL、管理部署、利用対象
JavaScript/CSS	ファイル、読み込み順、変更履歴
プラグイン	バージョン、提供元、解約時の扱い
モバイル表示	画面崩れ、操作性、表示速度

ポータルのリンクやメニューをJavaScriptに直接書き込むと、変更のたびに開発者が必要になります。

頻繁に変わるものは、ポータル管理用のkintoneアプリで持たせる方法もあります。

たとえば、ポータルメニュー管理アプリを作り、次の項目を持たせます。

項目	目的
表示名	ポータルに出す名称
リンク先URL	アプリ、外部システム、マニュアル
表示部署	営業、経理、管理部など
表示順	並び順
有効/無効	一時的に非表示にする
管理者	リンクの責任者
更新日	古いリンクを見つける

このように、変わる情報をデータとして持つと、保守担当が開発者だけに偏りにくくなります。

一方で、表示ロジックや権限制御は慎重に設計します。

「誰でもメニューを変えられる」状態にすると、ポータルがまた散らかります。

変更申請、レビュー、公開日、戻し手順を決めます。

よくある失敗

kintoneポータルカスタマイズでは、次の失敗が起きやすいです。

見た目から作り始める

色やカードを決める前に、部署別の業務導線を決めます。

何を上に置くかは、デザインではなく業務の優先順位で決まります。

全員に同じメニューを出す

全社員向けの導線と、部署別の導線は分けます。

全員に同じ情報を出すと、必要なものが埋もれます。

タスク一覧の定義が曖昧

未対応、期限超過、承認待ち、差し戻しなど、何をタスクとして出すかを決めます。

アプリごとにステータス名が違う場合は、ポータルに出す条件を統一します。

ポータルに情報を置きすぎる

ポータルは詳細画面ではありません。

件数、期限、重要度、リンクだけを出し、詳細は各アプリへ遷移させます。

モバイルで確認しない

現場利用があるのにPCだけで作ると、スマートフォンで使われません。

モバイルでは、上位数件のタスクと主要リンクに絞ります。

JavaScriptにリンクを直書きする

リンクが変わるたびにコード修正が必要になります。

頻繁に変わるリンクは、管理アプリや設定データとして持たせます。

Kintone Portal Designer前提のまま止まる

古い社内手順や過去のテンプレートに依存している場合、現在の公式情報を確認します。

開発終了したツールを使い続けるなら、移行方針と保守リスクを明示します。

実装前チェックリスト

kintoneポータルカスタマイズを始める前に、次の項目を確認します。

確認項目	判断すること
目的	アプリを探しやすくするのか、未対応を見せるのか
対象部署	全社共通か、部署別か、役職別か
主要アプリ	本当に毎日使うアプリだけに絞れているか
タスク定義	未対応、期限超過、承認待ちの条件が決まっているか
お知らせ	掲載期限、管理者、更新ルールがあるか
社内リンク	規程、マニュアル、外部システムの責任者がいるか
権限	表示制御とアプリ権限を分けて確認したか
モバイル	スマートフォンで必要な導線だけに絞ったか
実装方法	標準設定、JavaScript/CSS、プラグイン、制作サービスのどれか
保守	メニュー変更、リンク切れ、ファイル更新を誰が行うか
検証	管理者だけに適用して確認する手順があるか
戻し方	表示崩れや障害時に元へ戻せるか

この表が埋まると、ポータルをどこまで作り込むべきか見えてきます。

部署別メニューだけで足りるのか。

未対応タスクを表示すべきか。

申請や承認の導線を上に置くべきか。

JavaScript/CSSで作るべきか、プラグインや制作サービスを使うべきか。

判断しやすくなります。

Bitlightに相談できること

Bitlightでは、kintoneポータルカスタマイズを、見た目の変更ではなく、社内業務の入口設計として整理します。

相談できる内容は次の通りです。

• 部署別メニューと全社共通メニューの整理
• 未対応タスク、承認待ち、期限超過の表示条件設計
• 重要アプリ、申請、社内リンク、お知らせの配置設計
• ポータル管理アプリによるリンク・メニュー管理
• JavaScript/CSS、プラグイン、制作サービスの使い分け
• 権限別表示とアプリアクセス権の整理
• PC・モバイル両方で使える導線設計
• 保守担当、変更履歴、戻し手順の整備

ポータルは、kintoneを開いた人が最初に触る画面です。

ここが散らかっていると、どれだけ各アプリを作り込んでも、社員は迷います。

kintoneポータルカスタマイズは、見た目を変える作業ではなく、社内の人が今日見るべき業務へ最短で入るための入口設計です。

部署別に見るものを分ける。

未対応、承認待ち、期限超過を見えるようにする。

詳細は各アプリへ戻す。

保守担当と更新ルールを決める。

この順番で設計すれば、ポータルはリンク集ではなく、社内業務を動かす入口になります。