社内サイト、
何でつくる？

SharePointを含む契約か確認が必要です。Copilotや追加サービスの権利も契約ごとに確認します。

会話の場に加えて、全社案内や継続的に参照する資料を体系立てて見せたいときにSharePointのサイトが役立ちます。

移行は可能ですが、先に重複・保存期限・アクセス権を整理すると、古い問題を持ち込みにくくなります。

標準のページ作成はドラッグ操作で行えます。複雑な業務アプリまで必要な場合は別の仕組みとの組み合わせを検討します。

公開先と共有範囲を設定します。管理者の外部共有ポリシーも確認し、実際の社員アカウントで閲覧をテストします。

サイトの閲覧権限だけで判断せず、埋め込む資料の共有設定も確認します。

複数ポータルを作り、ユーザー・組織・ロールでアクセス権を設定できます。

標準ポートレットとテンプレートをドラッグ操作で配置できます。独自表現にはHTML等による拡張も可能です。

kintoneグラフなどのポートレットを利用できます。連携先の契約と閲覧権限を含めて設計します。

標準機能のトップページを使って始められます。自由なデザインを主目的とするCMSとは役割が異なります。

トップページの表示パーツやレイアウトを利用者が設定できます。管理者からのお知らせも表示できます。

パッケージ版の販売は2026年9月30日に終了しています。新規導入はクラウド版を中心に検討します。

全社・部署・個人のポータルを使い分けられます。

簡易ホームページエディタとドラッグ操作で画像・動画や情報パーツを配置できます。

クラウド版とパッケージ版があります。保守体制・データ管理・連携要件を基に選びます。

お知らせやアプリへのリンクを掲載するポータル、チーム別のスペースを利用できます。

追加ポータルを作成できますが、ライトコースは対象外です。2枚目以降はPC版のみ表示され、ゲストユーザーには表示されません。

スペースの参加メンバーと公開範囲を設定できます。アプリやレコードのアクセス権も別途設計します。

全社向けの案内やナレッジの入口にできます。見た目の自由度より、ページの体系と更新運用を重視する構成に向きます。

Confluence単独で文書作成や情報共有に使えます。Jiraとの連携は用途に応じて選びます。

通常のページ運用から始められます。Rovo等を利用する場合は、対象契約・接続先・公開権限を確認します。

公開と共有の設定を管理します。社内ページを公開サイトにしない運用と、ゲスト権限の定期点検が必要です。

ページの分類、データベースの項目、所有者、アーカイブルールを先に決めると整理しやすくなります。

組織向けの管理機能がありますが、SSOや監査等の対象プランと要件を照合して選定します。

両方との連携を提供しています。既存の文書や業務環境に合わせて連携範囲を設計します。

モバイルでの利用に対応しています。端末、認証、利用者への通知方法を含めて設計します。

属性や所属などを使ったパーソナライズと対象者別の情報配信が可能です。

Microsoft 365やSlack等の連携も案内されています。自社が必要とする連携範囲と認証方式を個別に確認します。

既存資料を参照する構成も考えられます。検索対象、権限、リンク切れを検証して移行範囲を決めます。

分類と管理責任者の設定は必要です。PagesとChannelsの用途、見直し周期を決めます。

ニュースや情報整理の設計が基礎になります。AI機能の採否は情報の品質、対象範囲、契約に合わせて判断します。

必要な情報や業務の入口をまとめる役割で検討できます。置換が必要な機能は別途比較します。

情報を探す時間、問い合わせ内容、ニュースの到達状況など、導入前から測れる指標を選びます。

従業員アプリを含む構成が用意されています。社員のアカウント、端末、通信環境を合わせて設計します。

対象者別の情報提供に対応します。全社情報と拠点情報の責任者を分けると運用しやすくなります。

利用する画面、翻訳、管理者向け支援の言語を導入前に確認し、実データで表示を検証します。

両方の連携が案内されています。同期・検索・認証のうち何が必要かを切り分けて確認します。

SSOやSCIM、Microsoft Entra ID等との連携が案内されています。契約と実際の入退社運用を確認します。

社内交流に加え、ホームやナレッジハブを使うイントラネット機能も用意されています。

公式は大規模な企業利用を重視しています。機能だけでなく、運用体制と費用が規模に合うか比較します。

翻訳後の承認、地域固有の制度、更新時の追従を担当する体制も必要です。

連携機能が用意されています。対象システムごとに、認証、表示できる情報、追加開発の範囲を確認します。

現場社員向けの発信手段が案内されています。個人端末の扱いや勤務時間内の閲覧方法も設計します。

情報検索に加えて、社内ニュースや従業員向けコミュニケーションをまとめる用途があります。

情報の分類、公開対象、承認者、更新期限、利用状況の確認方法を決めると、継続的に運用しやすくなります。

ポータルはリッチテキストを使って編集できます。複雑な外部連携は個別に確認します。

会社全体、部門、プロジェクトなどの単位に合わせたポータルを作成できます。

メニューパレットに外部サイトへの入口を設定できます。リンクの掲載だけで認証やデータが統合されるわけではありません。

クラウドサービスとして利用できます。インターネット接続とアカウント管理などの利用環境を準備します。

全社・組織・個人のポータルで情報の配置や表示内容を調整できます。

いいえ。J-MOTTOの累計利用企業数と、desknet’s NEO全体のライセンス数は集計対象が異なります。

無料版がありますが、自社サーバー、保守、バックアップなどの運用費は別に考える必要があります。有償版やオプションもあります。

クラウドサービスのbyCloudがあります。無料版や大規模向けZIONとの違いを確認して選びます。

ポータルのレイアウトはドラッグ操作、内容はリッチテキストなどで編集できます。

いいえ。ダッシュボードや高度な管理機能などはプランや追加契約によって異なります。必要な機能を列挙し、公式のプラン比較表と照合して選びます。

外部ユーザーを扱う機能がありますが、社員用ネットワーク・グループとの公開範囲、招待権限、契約条件を確認して設定します。社外共有を必要としない場合も、その範囲を管理します。

章と記事からなるマニュアル機能で、入社案内や手順書を整理できます。掲示や質問、タスクも同じ基盤で扱いたい場合に特に検討しやすい構成です。

連携やリンクによって既存システムへの入口を統合できます。認証、データ連携、検索対象の個別設計が必要です。

役割や属性に応じたパーソナライズが可能です。どの情報を誰に見せるかを事前に整理します。

SaaS、PaaS、セルフホストの選択肢があります。必要な運用責任と拡張性を比較して選定します。

いいえ。投稿単位の非公開・パスワード保護と、サイト全体の社員限定公開は別です。認証、利用者管理、添付ファイルへのアクセスまで含めて設計します。検索エンジンへの非掲載設定だけでは閲覧を制限できません。

WordPress.orgで配布されるソフトウェアを自社サーバー等で運用する方式と、WordPress.comのホスティングサービスは分けて検討します。WordPress.comの非公開サイトは承認されたWordPress.com利用者のログインを前提とします。

ソフトウェアのライセンス費と運用費は別です。サーバー、バックアップ、更新、プラグインの保守、認証連携などの費用と担当者を決める必要があります。

構築できますが、入力項目・権限・連携を細かく設計できる点に強みがあります。更新が少ない小規模サイトでは、構築と保守の負担も含めて他製品と比較します。

役割と権限を基本に設計できます。記事単位・部署単位の細かい制御では、Access Policyなどの追加モジュールや個別の実装が必要になる場合があります。標準機能と追加構成を分けて確認します。

サーバー、バックアップ、Drupal本体・モジュールの更新、権限の棚卸しが必要です。社内限定にする場合は、公開ページやファイルを含めたアクセス制御を検証します。

異なります。アクセスレベルは何を見られるか、権限はどの操作をできるかを制御します。利用者グループへの所属や継承も含めて設定します。

登録ユーザー等に閲覧範囲を限定できます。ただしPublicのままの記事は一般に閲覧可能です。サイト全体を社内限定にするときは、ページ・メニュー・メディアを含めて公開範囲を点検します。

自己ホスティングの場合は必要です。PHP等の稼働環境、本体と拡張機能の更新、バックアップ、認証方式の管理を継続します。

文章や添付の共同編集だけでなく、構造化データを用いたフォームや一覧を作れる点が特徴です。複雑なアプリでは、データ設計や開発・管理の知識が必要になる場合があります。

Wiki全体の閲覧を登録ユーザーに限定する構成を取れます。ページや子ページの権限も設定できるため、匿名ユーザーやグループに対する設定を含めて確認します。

オープンソース版の自己運用に加えて、XWiki SASが商用のホスティングや支援サービスを提供しています。認証連携、保守、バックアップを誰が担当するかも含めて選びます。

ビジュアルエディターも選べます。ページの構成や運用ルールを用意し、担当者が使う編集方式を統一すると運用しやすくなります。

LDAP・SAML・OpenID Connect等の認証連携を構成できます。対応モジュール、グループとの紐付け、利用停止の反映、多要素認証の適用範囲を確認します。

安定版とベータ版は区別します。公式サイトには2系の安定版と3系ベータの案内があるため、本番利用では必要機能・移行方法・保守条件を確認して選定します。公式にComing soonとされる機能は利用できる機能として扱いません。

本棚の権限は、その中に置いた本へ自動では引き継がれません。本は複数の本棚に所属できるためです。機密情報を扱う場合は、本・章・ページの権限も確認します。

日本語UIに対応し、OIDC・SAML2・LDAP等の認証方式を利用できます。利用する方式に合わせた管理者設定が必要です。

文章中心の案内やマニュアルの集約はできますが、本・章・ページの整理が中心です。ニュース配信、申請、勤怠などが必要なら、対応する別のツールとの役割分担を検討します。

MediaWikiは共同編集と情報共有を中心に設計されています。細かな機密領域の分離を当然にできるとは考えず、必要なアクセス制御を実装・検証できるかを先に確認します。要件によっては別の基盤が適しています。

閲覧制限とアップロードファイルへの直接アクセスは分けて確認する必要があります。公式マニュアルも、非公開構成の例だけで十分とせず、全体をテストするよう説明しています。

VisualEditorを使う構成があります。ソース編集と必要な編集方式を決め、採用バージョンや拡張機能との組み合わせを確認して導入します。