会社情報
採用情報
お問い合わせ
Article

Softrで社内ポータルサイトを簡単構築

高田晃太郎
Softrで社内ポータルサイトを簡単構築

知的労働者は勤務時間の約20%を情報探索に費やすとされ¹²、検索の遅延が意思決定のボトルネックになりやすいことは各種調査で示されています²。公開データと事例を照合すると、部門横断のナレッジと業務導線をひとつに束ねるだけで、オンボーディング初期の立ち上がり時間が数十パーセント短縮しうるという傾向が見えます³。高価なフルスクラッチ開発に踏み切らなくても、ノーコードのSoftrで中堅規模までの社内ポータルを実装すれば、短期で仮説検証に進みやすくなります。平たく言えば、既存SaaSの“散らかった近道”を、権限で整理された“最短ルート”に置き換えるのが目的です。重要なのは、スピードとガバナンスを両立させる実務設計です。

なぜSoftrなのか：速度、ガバナンス、拡張の均衡

SoftrはAirtableやGoogle Sheets、Notionなどのデータソースを安全に表出し、ページ、検索、権限を組み合わせたアプリケーションを短時間で構築できます。CTO視点での価値は明快で、初期投資が小さいこと、UI/UXの反復改善が速いこと、そして役割ベースのアクセス制御（RBAC：Role-Based Access Control）を画面中心に運用へ委譲できることです。社内ポータルは“全員が毎日使うプロダクト”。完璧な要件定義より、2〜4週間でβ版を公開し、実利用データで磨くほうが費用対効果は高くなりがちです。SharePointのような巨大基盤は強力ですが、チーム主導の自律改修には重すぎる場面があり、一方でNotionの公開ページ運用は権限や監査の粒度で限界が出ます。その隙間をSoftrが埋めます。SAML/OIDCによるSSO（シングルサインオン）、ページやブロック単位のRBAC、フォームからの自動起票、セグメント別のお知らせ配信など、日々の運用に必要な機能が近道でつながるからです。

ただし万能ではありません。複雑なワークフローや厳密なトランザクションは、iPaaS（Integration Platform as a Service）や自前のミドル層に委ねる設計が現実的です。**Softrは“プレゼンテーションと軽量ロジック”、業務の重い部分は“APIで外出し”**という境界線を早めに引くと、のちの拡張がスムーズです。ロックインを避けるため、データの主系はAirtableや社内DBに置き、Softrはビューと体験の責務に徹する方針が効果的です。

要件の翻訳：ユースケースから逆算する情報設計

社内ニュース、社内Wiki、システム運用掲示、申請導線、社員・組織ディレクトリ、プロジェクト一覧、OKR/ロードマップ、ITヘルプ、オンボーディング教材。ポータルの実体はこのような“日常の入口”の集合です。情報はオブジェクトとして分解し、例えばPeople、Teams、Docs、Announcements、Apps、Requestsのように正規化（重複を排して構造化）してから、用途別のビューに再構築します。Softrのコレクションとリスト、ディテール、フィルタ、そしてロール・アビリティ（役割と許可）による視認性制御を組み合わせると、ユーザーごとに異なる最適化されたホームが得られます。重要なのは“どのデータが誰にいつ見えるか”という権限モデルを、最初に言語化しておくことです。

SSOと役割設計：グループクレームを単一の真実源に

認証はIdP（Identity Provider）を中心に据えます。OktaやAzure ADでSAML/OIDCを構成し、グループや部門などの属性をトークンのクレーム（IdPから渡される属性情報）として配布します。Softrのロールはこのクレームにマッピングして決定し、アプリ側に新たな“権限の真実源”を作らないことが運用負荷を抑えます。SCIM（アカウントの自動プロビジョニング規格）でユーザーライフサイクルを自動化し、入社・異動・退職が可視性に即時反映される状態を目指します⁶。

// OIDC IDトークンを検証し、グループからSoftrロールを導出（Node.js）
import { createRemoteJWKSet, jwtVerify } from 'jose'

const JWKS = createRemoteJWKSet(new URL(process.env.OKTA_JWKS_URL))

export async function mapRole(idToken) {
  const { payload } = await jwtVerify(idToken, JWKS, { issuer: process.env.OKTA_ISSUER })
  const groups = payload.groups || []
  if (groups.includes('it-admin')) return 'admin'
  if (groups.includes('manager')) return 'manager'
  return 'employee'
}

データ統合：Airtable中心の“見せ方”設計とAPI中継

速度重視であればAirtableをハブに据える判断は合理的です。テーブル設計はDocs、Announcements、Apps、People、Teams、Requestsを基本に、相互参照で関連付けます。履歴や承認フローはAirtable Automationsと外部のiPaaS、あるいは自前の軽量サーバレスを併用して補います。大量データや厳密な監査が必要な領域は、社内のRDB（リレーショナルデータベース）に主データを置き、読み取り専用ビューをSoftrへ公開します。整合性と監査要件を保ちながら、UIは高速に反復できます。

セキュアなダウンロードは署名付きURL（期限付きのアクセス権を埋め込んだURL）で扱うのが安全です。ファイルはS3やGCSに置き、短寿命トークンを付与してSoftrから配布します。以下はCloudflare Workersでの簡易実装例です⁴。

// 署名付きURLを払い出すCloudflare Workersの例
export default {
  async fetch(req, env) {
    const url = new URL(req.url)
    const key = url.searchParams.get('key')
    if (!key) return new Response('Bad Request', { status: 400 })
    const expires = Math.floor(Date.now() / 1000) + 300
    const sig = await sign(`${key}:${expires}`, env.SECRET)
    const redirect = `${env.CDN_BASE}/${key}?e=${expires}&sig=${sig}`
    return Response.redirect(redirect, 302)
  }
}

async function sign(message, secret) {
  const enc = new TextEncoder().encode(message)
  const key = await crypto.subtle.importKey('raw', new TextEncoder().encode(secret), { name: 'HMAC', hash: 'SHA-256' }, false, ['sign'])
  const signature = await crypto.subtle.sign('HMAC', key, enc)
  return btoa(String.fromCharCode(...new Uint8Array(signature)))
}

検索体験は投資対効果が高い領域です。Softr標準の検索で足りなければ、AlgoliaやElastic Cloudを併設してインデックス更新をイベント駆動にします。Airtableの変更フックやSoftrフォームのサブミットをトリガーにし、非同期でサーチインデックスへ反映すると、公開から数秒程度で検索可能な鮮度を保てます。

// SoftrのWebhookからAlgoliaにインデックス更新（Node.js, Express）
import express from 'express'
import algoliasearch from 'algoliasearch'

const app = express()
app.use(express.json())
const index = algoliasearch(process.env.A_APP_ID, process.env.A_API_KEY).initIndex('docs')

app.post('/webhooks/softr', async (req, res) => {
  const { type, record } = req.body
  if (type === 'doc.updated' || type === 'doc.created') {
    await index.saveObject({ objectID: record.id, title: record.title, body: record.body, tags: record.tags })
  }
  if (type === 'doc.deleted') {
    await index.deleteObject(record.id)
  }
  res.sendStatus(204)
})

app.listen(3000)

チャットと申請導線：フォームからの自動起票

ヘルプデスク的な問い合わせはSoftrフォームを起点にJiraやZendeskへ自動起票し、Slackに通知します。ユーザーは進捗を常に可視化できます。以下はフォーム受付からSlack通知までの最小例です。

// フォーム投稿を受け取り、Jira起票とSlack通知（Node.js）
import fetch from 'node-fetch'

export async function handle(req) {
  const body = await req.json()
  const issue = await fetch(process.env.JIRA_URL + '/rest/api/3/issue', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json', 'Authorization': `Basic ${process.env.JIRA_TOKEN}` },
    body: JSON.stringify({
      fields: { project: { key: 'IT' }, summary: body.title, description: body.detail, issuetype: { name: 'Task' } }
    })
  }).then(r => r.json())

  await fetch(process.env.SLACK_WEBHOOK, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ text: `新規リクエスト: ${body.title} - JIRA ${issue.key}` })
  })

  return new Response(null, { status: 204 })
}

実装から展開：2〜4週間で“使われる”ポータルへ

初週は情報設計とトップページの骨格づくりに集中します。Softrでホーム、検索、ニュース、ディレクトリ、ヘルプ、アプリ一覧の枠を作成し、仮データで体験を確かめます。二週目にSSOとロールを接続し、監査ログと公開範囲の境界を詰めます。ここでベータ公開し、実ユーザーを入れて摩擦を観察します。三週目に検索と通知、申請導線の改善へ投資し、チュートリアルやオンボーディングの導線を整備します。四週目でSLA（サービス水準合意）観点の運用手順書とエスカレーション、バックアップ方針を固めると安定運用に乗ります。時間軸はあくまで目安ですが、“早く出して早く学ぶ”を合言葉に、毎週の反復で学習サイクルを作るのが成功率を上げます。

SSOの実運用では、IdPのグループ設計が最難所になりがちです。部門、役職、委任、拠点、雇用形態などの属性をどこまでグループに射影するかは、セキュリティと運用コストのトレードオフです。最小権限の原則を守りつつ、“表示は広く、更新は狭く”という境界を引くと、情報共有のスピードを落とさずに済みます。

パフォーマンスは体験の質に直結します。画像はSoftrの最適化機能に任せつつ、上流のストレージでWebP化、CDNキャッシュは1〜5分の短TTL（有効期限）とし、更新時はタグパージで即時反映します。クライアント側は遅延読み込みとスケルトン表示で体感を崩さず、初回表示1.5〜2.5秒、インタラクティブ3.0秒以内を経験則の目標に置くと、社内利用では十分な快適さになります。

// 逆プロキシでSoftr配信をCDNキャッシュ（例: Vercel Middleware）
import { NextResponse } from 'next/server'
export function middleware(req) {
  const res = NextResponse.next()
  res.headers.set('Cache-Control', 'public, max-age=60, s-maxage=300, stale-while-revalidate=120')
  return res
}

観測可能性：計測・検索クエリ・離脱の可視化

社内ポータルでも計測は必要です。PlausibleやGA4を匿名化設定で導入し、検索クエリとゼロヒット率（検索結果が0件の割合）、クリック先、離脱ページを日次でレビューします。ゼロヒットが多いキーワードは情報不足か表現のミスマッチを示唆します。編集カレンダーに落として改善し、週次で“見つかるまでの時間”をモニタリングします。ITヘルプの平均応答時間、フォーム到達率、申請の完了率も運用SLAとして扱うと、改善の議論が建設的になります。

// 検索ゼロヒットをBigQueryへ集計するサンプル（Apps Script）
function logNoHit(query, user) {
  const row = { ts: new Date().toISOString(), q: query, uid: user.email }
  const dataset = BigQuery.Dataset('portal')
  const table = dataset.getTable('no_hits')
  table.insertRows([row])
}

セキュリティとガバナンス：現実解を運用に落とす

ガバナンスは“仕組みで守る”が原則です。SSOは必須、多要素認証はIdP側で強制し、Softrの編集権限は最小限に限定します。データ主系はAirtableやRDBに置き、Softrはビューの責務に徹します。監査では、誰がどのページをいつ公開・変更したか、どのフォームからどのデータが作られたかをトレースできる状態を保ちます。PII（個人情報）を扱うページはリンク共有を禁止し、ゲスト公開を避けます。退職者のアクセス剥奪はSCIMのディプロビジョニングを用い、人手の手順に依存しない流れを構築します⁶。費用対効果は数字で説明できます。例えば従業員500人の組織で、一人当たり一日3分の探索時間短縮が実現したとします。500人×3分で一日1500分、つまり25時間の削減です。月20営業日なら500時間の削減になり、時間単価4000円なら月200万円相当の価値です。Softrと周辺SaaS費用、運用の人件費を合算しても、この規模では数週間で投資回収が視野に入る可能性があります³。重要なのは、最初から全部を載せないこと。利用頻度が高く、摩擦コストが大きい導線から着手し、反復で面を広げます。

より詳しい前提整理や比較検討の観点は、社内ナレッジ基盤の選定ガイドとしてまとめています。

まとめ：まずは“使われる”最小構成で走り出す

社内ポータルは“情報の高速道路”です。Softrを使えば、既存のAirtableやNotionの資産を活かしながら、SSOとRBACで守られた導線を短期間で立ち上げられます。大がかりな一発勝負ではなく、2〜4週間でβ版を出し、検索と申請、ニュース配信の三点に絞って体験を磨けば、利用率は自然に上がります。データの主系は外に置き、Softrは“見せ方と軽量ロジック”に集中させる。境界を明確にしておけば、将来の拡張や部分的なマイクロサービス化にも無理がありません。

次に何から始めるか。最初の一歩は、トップページの骨格と検索体験の仮組みです。社内の3チームに使ってもらい、ゼロヒット率と離脱点を一週間観察してみてください。そこで得た摩擦点こそが、あなたの組織に最適な要件定義です。スピードとガバナンスを両立する設計で、情報の遠回りを減らしていきましょう。

参考文献

  1. IDC findings cited in iTWire: https://itwire.com/guest-articles/empowering-knowledge-workers.html#:~:text=IDC%20found%20that%20knowledge%20workers,information%20assets%20that%20already%20existed
  2. KMWorld: https://www.kmworld.com/Articles/ReadArticle.aspx?ArticleID=135756&pageNum=2#:~:text=Further%2C%20IDC%20data%20shows%20that,silos%20are%20only%20increasing%20as
  3. Haiilo (citing Forrester) on intranet ROI and onboarding: https://haiilo.com/blog/intranet-roi/#:~:text=According%20to%20Forrester%2C%20when%20intranets,and%20sets%20them%20up%20for
  4. AWS S3 presigned URLs: https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-presigned-url.html#:~:text=You%20can%20use%20presigned%20URLs,user%20who%20generated%20the%20URL
  5. NIST SP 800-53 Rev. 5, AC-6 Least Privilege: https://nist-sp-800-53-r5.bsafes.com/docs/3-1-access-control/ac-6-least-privilege/#:~:text=AC
  6. Okta Developer Docs, SCIM and lifecycle management: https://developer.okta.com/docs/concepts/scim/#:~:text=Managing%20user%20lifecycles%20in%20your,prone