SaaS向けSLAガイドライン｜経産省の構成・項目例と契約前の確認点

SaaS向けSLAガイドラインとは、経済産業省が2008年1月21日に公表した、SaaSの利用者と提供者が事前に合意しておくべき事項と、望ましいサービスレベルの考え方を示した指針です。SaaS型取引をめぐる紛争を未然に防ぐため、実際のSaaSのサービスレベル設定事例をもとにまとめられました。この記事では、経済産業省のPDF本文を読み、SLAの6つの構成要素、サービスレベル項目の4分類と別表の設定例、未達のときの結果対応、締結後のSLM、情報セキュリティの確認事項を整理します。公表から年数がたつため、その後に出た総務省の情報開示指針との関係と、今使うときの注意点も取り上げます。

目次

開く

閉じる

1. SaaS向けSLAガイドラインとは｜公表の経緯と全体の構成
2. SLAの6つの構成要素とサービスレベル項目の4分類
3. SLAの導入の進め方｜作成・締結・管理の3段階
4. 未達のときの結果対応と、目標保証型・努力目標型の違い
5. SLM（サービスレベル管理）と運営ルール｜締結後の測定と見直し
6. 情報セキュリティを中心とした確認事項｜6章の6つの視点
7. 2008年の指針を今使うときの注意｜その後に出た資料との関係
8. 契約前にSLAを確認する手順｜ガイドラインを使った5ステップ
9. よくある質問(FAQ)
10. まとめ｜SaaS向けSLAガイドラインを使うために押さえる5つのこと
11. 参考文献

SaaS向けSLAガイドラインとは｜公表の経緯と全体の構成

SaaS向けSLAガイドラインとは、経済産業省が2008年1月21日に公表した、SaaS型取引の紛争を防ぐために、利用者と提供者が事前に合意すべき事項を示した指針です。

ガイドラインの冒頭では、経済産業省が中小企業のIT化支援の中でSaaSを有力な手段と位置づけ、財務や顧客のデータをサービス提供者に預けることになるため、利用者と提供者の間でサービスレベルの取り決めが重要になると述べています。検討は、経済産業省の「中小企業のＩＴ化推進のための意見交換会（SaaS・ASPの活用を目指して）」と、情報処理推進機構（IPA）に設けられた「SaaS利用者の観点からのセキュリティ要件検討会」で行われました。対象は企業などの利用者で、契約に基づいてセキュリティを含むサービスレベルを確保することを想定しています（2頁）。ガイドラインでSaaSとは「インターネット経由でアプリケーション機能を提供するサービスの形態」を指し、SIerから納品されて自社で所有するシステムは含まれません（3-4頁）。

ガイドラインは、まず1-2章でSaaSの特徴を理解し、3章で分野ごとの適用状況を見たうえで、4-6章のSLAの内容を考慮しながら提供者を選ぶ、という使い方を想定しています（2頁）。この記事が確認したのは、平成20年1月21日付の経済産業省のPDF（本文40頁と別表5頁）です。確認日は2026年10月23日です。

確認したあとに社内に残る仕事｜SLAの承認と、障害時の連絡

ガイドラインを使ってSLAを確認すると、そのあとに社内の仕事が2つ残ります。1つは、確認した内容を経営の側で検証し、承認を得ることです。7章は、提案されるSLAが自社のビジネスを強化するために必要十分なサービスレベルかを、経営面から検証することが望ましいとしています（37頁）。もう1つは、締結したあとの連絡の仕組みです。5章は、SLAの運営で、責任者や報告・連絡の経路といった運営ルールを、利用者と提供者の間で明確にしておくことを求めています（26頁）。

この2つを、メールや表計算で個別に回すと、誰がいつ何を承認し、障害のときに誰へ連絡したかを、あとからさかのぼりにくくなることがあります。承認の記録を残す場合の一例がワークフローシステム、連絡の窓口を1か所に集める場合の一例がビジネスチャットです。次の表は、2つのサービスを、商品ページで確認した範囲で並べたものです。

SLAの確認結果を、稟議や承認の流れに載せて記録に残したい場合の一例が、株式会社コラボスタイルのコラボフローです。商品ページでは、シンプルかつ直感的な操作で承認経路を設計できること、運用中にフォームレイアウトの追加・修正ができることが紹介されています。一方で、クラウド版には1ユーザーにつき5GBの容量制限があります。料金はプランによって異なるため、資料や公式サイトで確認してください。

コラボフローの導入事例では、南海電気鉄道株式会社が、押印文書の印鑑レス化・ペーパーレス化を目標に、社内で見つかった約100件の押印文書のうち約40件を早期にワークフロー化する必要があったと紹介されています。事例ページで、担当者がノーコードで開発できる点を次のように述べています。

基本的にノーコードで開発ができるため、IT初心者でSE経験のない私でも、早期に開発作業に着手することができました。

出典:コラボフロー 導入事例 南海電気鉄道株式会社

障害や報告の連絡を、メールや複数のツールに分けず、既製のチャットで1か所に集めたい場合の一例が、株式会社kubellが提供するChatworkです。商品ページでは、無料で始められるフリープランがあること、チャットに加えて通話やタスク・ファイル管理の機能が充実していることが紹介されています。一方で、より高いセキュリティとサポートの手厚さを求める場合は、エンタープライズの契約が必要です。料金はプランによって異なるため、資料や公式サイトで確認してください。

Chatworkの導入事例では、全国54の支部を持つ一般社団法人 全国介護事業者連盟が、連絡ツールをChatworkに一本化した経緯を紹介しています（取材は2023年8月）。事例ページで、支部の事務局長が、連絡が分散していた場合を次のように振り返っています。

仮に連絡がLINEやメールなど複数のツールに分散していたら、他の支部との連携はとりにくくなっていたでしょう。

出典:Chatwork 導入事例 一般社団法人 全国介護事業者連盟

SLAの6つの構成要素とサービスレベル項目の4分類

SLAは、前提条件、委託範囲、役割と責任、サービスレベル項目、結果対応、運営ルールの6つの要素で構成され、サービスレベル項目はアプリケーション運用、サポート、データ管理、セキュリティの4分類で示されます。

ガイドラインは、SLAを「サービス品質に対する利用者側の要求水準と提供者側の運営ルールについて明文化したもの」と説明しています（20頁）。サービス利用契約を結ぶ際に、双方の合意の結果として、契約文書の一部か独立した文書として締結されるケースが多いとしています。ただし、SLAは必ずしも独立した文書ではなく、後述する努力目標型の場合は、SLAを利用者向けホームページに公開するだけで、未達成時の補償を明確に規定していないこともあると注記しています（20頁の注）。

前提条件、委託範囲、役割と責任は、通常は契約書に書かれ、その内容を補う事項がある場合だけSLAにも補足事項を書きます（22頁）。つまり、SLAの文書だけを見ても、6つの要素がそろっているとは限りません。契約書と附属資料を合わせて確認することになります。

なお、解説記事の中には、サービスレベル項目を「可用性、信頼性、性能、拡張性、サポート」の5つで紹介しているものがあります。ガイドラインの表3は4分類で、可用性、信頼性、性能、拡張性は、そのうちの「アプリケーション運用」の中の種別として別表に並んでいます。

別表のモデルケース｜基幹業務とそれ以外の設定例

別表の設定例は、サービスを提供している事業者約40社（約80事例）へのアンケートをもとにまとめられたもので、基幹系業務の場合と、販売管理やグループウェアなどそれ以外の業務の場合に分けて示されています（23頁、別表1頁）。ガイドラインは、設定例を参考にしつつ、実際の設定値は業務内容など個々の状況に応じて決めるべきだと繰り返し述べています。次の表は、別表から数値や内容が読み取れる項目を抜き出したものです。

どの項目も、備考欄には「対象業務の重大性を考慮しつつ、サービス内容・特性・品質に応じて個々に検討」といった趣旨が書かれています。表の数字は、そのまま契約に使える基準ではなく、提供者の標準SLAを読むときの物差しとして使うものです。また、6章の冒頭は、高いレベルのSLAを設定すると、サービス価格も高くなることを理解しておく必要があると述べています（27頁）。計画的に停止できるシステムと、24時間365日停止しないシステムでは運用コストが大きく異なるため、業務に必要な条件で最適なサービスレベルを選ぶべきだという考え方です。

稼働率の数字を、止まってよい時間に置き換える

稼働率は、別表の項目の説明で「（計画サービス時間-停止時間）÷計画サービス時間」と定義されています。別表の設定例を30日（720時間）で換算すると、次の表のようになります。これはガイドラインの数値から計算した目安で、実際の算出方法や計画停止の扱いは、各SLAで確認してください。

基幹業務の設定例と、それ以外の設定例とでは、1か月で許容される停止時間が10倍違います。自社の業務が止まったときの影響をもとに、どちらの水準が必要かを決めます。稼働率の数字を見るときの追加の論点は、SaaS契約とは？利用規約・SLA・解約条項の確認ポイントでも整理しています。

SLAの導入の進め方｜作成・締結・管理の3段階

ガイドラインが示すSLA導入の手順は、SLAの作成、締結、SLAに基づく管理の3段階で、提供者が標準的なSLAを用意している場合は、その内容が明確かを確認します。

作成の段階では、SLAの構成要素に沿って、次の7つを進めるのが一般的とされています（23頁）。

1. 前提条件の整理:利用者側の前提条件（業務量、利用者数など）を洗い出します。
2. 委託内容と範囲の定義:業務要件に基づいて、サービス内容と範囲を決めます。
3. 役割と責任分担の定義:利用者と提供者の作業分担を明確にします。
4. 提供者の免責範囲の定義:利用者の過失や故意による障害など、免責事項を検討します。
5. サービスレベルの定義:具体的な項目と測定方法を決め、目標保証型と努力目標型を設定します。
6. 結果対応の定義:未達成のときの対応手順と補償を検討します。
7. 運営ルールの設定:運用段階での報告・連絡のルールを決めます。

サービスレベルの定義は、SLAの作成で中心になる作業です。万一トラブルが起きたときの業務への影響を考えて優先順位を決め、重要度の高いものから定義します。項目を増やすと管理の負担やコストが増えることがあるため、必要なものに絞ること、数値や数式で測れる客観的な項目にして、双方の認識の相違を防ぐことがポイントとされています（24頁）。

標準SLAを受け取る場合の注意

情報システム部門を持たない中小企業は、個別のSLA策定や継続的なSLMの実施が難しいのが実情だとして、ガイドラインは、一般には提供者があらかじめ用意した標準的なSLAを締結することになると述べています（21頁）。その場合は、6章の確認事項や別表のモデルケースを参考に、提供サービスの品質や保証条件を確認し、提供者が公開するサービスレベルの運用報告の内容と頻度も考慮するよう求めています。標準SLAで6つの要素が明確になっているかを確認し、不明確なら提供者と協議するとされています（23頁）。ただし、マルチテナントの場合は、協議をしても必ずしも利用者の要求事項が実現できるわけではないと注記されています（23頁の注）。

また、SLAでは担保されない作業もあります。データ移行、アプリケーションの導入、既存システムとの連携、教育・トレーニングは、基本的に利用者が自ら行う必要があり、提供者が有償または無償の支援サービスを用意している場合も多いため、あらかじめ作業を洗い出して、利用者と提供者の役割分担表を作っておくことが望ましいとされています（24頁）。

確認した項目と判断は、誰がいつ承認したかとともに残しておくと、更新や見直しのときに経緯を追えます。7章が経営面からの検証を求めていることもあり、承認の記録を仕組みにする場合は、前の章で紹介したワークフローシステムが一例です。

未達のときの結果対応と、目標保証型・努力目標型の違い

サービスレベルが達成されなかった場合の結果対応には、運用上、財務上、契約上の3つが考えられ、補償を明確に決めるのは目標保証型で、努力目標型では補償が明確に規定されません。

ガイドラインは、SLAに記載するサービスレベル項目が、すべて目標保証型（保証義務が発生する）とは限らず、努力目標型（努力目標にとどまる）として設定されるものもあるとしています（26頁）。どちらの型か、項目ごとに文言で確かめることが、SLAを読むときの出発点になります。

目標保証型の項目が未達成だった場合の結果対応は、主に次の3つです（25頁）。いずれも、業務への影響、緊急性、重要性を踏まえて具体的な内容を定義するとされています。

財務上の対応については、払い戻しではなく、将来の請求額から差し引く形をとり、上限を設けることが一般的だとされています。例として、月の請求額に対する10%、1日分の請求額といった上限が挙げられています（25-26頁）。また、結果対応に関する瑕疵担保責任は、主契約書に明記する必要があるとされています（26頁）。さらに、自然災害、電力供給の停止、通信遮断などのインフラ障害や、利用者側の問題に起因する事由で水準を達成できない場合を想定して、SLAの適用対象外とする免責事項が設定されるのが通例です（26頁）。

つまり、SLAに補償の定めがあっても、補償の形や上限、免責される場合まで確認しないと、実際に何を受け取れるのかが分かりません。契約全体の確認ポイントは、SaaS契約とは？利用規約・SLA・解約条項の確認ポイントでまとめています。

損害賠償や免責の効力など、法的な解釈は個別の契約内容によって異なります。本記事は一般的な情報提供を目的としたもので、法的助言ではありません。必要に応じて、法務部門や弁護士に確認してください。

SLM（サービスレベル管理）と運営ルール｜締結後の測定と見直し

SLMとは、サービスに関わるルール、プロセス、体制などを改善して、サービスレベルの要求水準とサービス内容を、利用者の事業上の要求の変化に合わせていく、継続的な運営・管理手法です。

ガイドラインは、SLAは締結したら終わりではなく、定めたサービスレベルを定期的に測定、分析、評価して、継続的にサービスを改善する必要があるとしています（20-21頁）。SLMでは、利用者と提供者が協力して問題を確認し、根本原因の分析やプロセスの変更を通じて、問題の再発を防ぐことが重要とされています（25頁）。

運営ルールで決めておくこと

SLAは契約書の附属資料として締結されるのが一般的で、実際の業務に合わせて定期的に見直すことが望ましいとされています。例として、月次または四半期単位で微修正を行い、年次単位で公式な見直しを行う進め方が挙げられています（26頁）。現実的な水準に落とし込むまでには、相応の試行錯誤の期間が必要なため、SLA運営組織を立ち上げて、項目や設定値の変更プロセス、責任者、報告・連絡の経路といった運営ルールを、利用者と提供者の双方で明確にしておくことが求められます。また、SLMの成功には、計画の段階から利用部門（エンドユーザー）が参加することが欠かせないため、運営組織には利用部門の主要な関係者を配置するとされています（26頁）。

中小企業が標準SLAを使う場合でも、運営ルールのうち、社内で受け取る人、社内に共有する人、見直しの時期を決める人は、自社で決める必要があります。サービスレベルの測定結果の報告や、障害の連絡を受ける窓口を、あとで経緯を確認できる形で1か所に決める方法は、このあと紹介する確認の手順の最後のステップに入っています。

情報セキュリティを中心とした確認事項｜6章の6つの視点

ガイドライン6章は、SaaS提供者を選ぶときのSLA上の確認事項を、規格の準拠性、機密性、完全性、可用性、運用保守、コンプライアンス対応の6つの視点で示しています。

6章は、情報セキュリティ監査などで確認される事項の単なる繰り返しにならないよう、データを外部事業者に預け、ネットワーク経由でウェブアプリケーションの提供を受けるというSaaSの性質が持つリスクを減らすための要件に絞って考察しています（27頁）。

確認事項一覧（6.7）の6グループ

6章の最後には、確認事項が6つのグループにまとめられています（32-36頁）。SaaS提供者に質問するときのリストとして使えます。

ログ管理の項目は、SLAを読むときに見落としやすい部分です。ガイドラインは、何を障害や事故とみなすかの判断基準が、提供者と利用者で異なることが予想されるため、サービス利用の開始前に自社の基準と比べて、差がある部分は、ログを提供者から出してもらって判断を委ねる体制を整えておくよう求めています（34-35頁）。

2008年の指針を今使うときの注意｜その後に出た資料との関係

SaaS向けSLAガイドラインは2008年の文書で、引用される規格や用語は当時のままなので、後に公表された資料とあわせて確認します。

たとえば、6章が基準に挙げるのはJIS Q 27001:2006とJIS Q 20000:2007で、通信路の保護については、SSLを使う場合にSSL 3.0とTLS 1.0に限り、SSL 2.0は使用しないとしています（27-28頁、35頁）。「発刊に寄せて」にある市場規模も、2010年に1兆5,390億円になるという当時の予想値です。これらは、その時点の記述として読み、現在の規格や要求水準は、最新の資料や提供者の公式情報で確かめる必要があります。一方で、SLAの6つの構成要素、結果対応、SLMの考え方は、SLAを読み解く枠組みとして今も使えます。

ガイドラインの参考文献には、電子情報技術産業協会（JEITA）の「民間向けのITシステムのSLAガイドライン第三版」（2006年10月）や、IPAの「情報システムに係る政府調達へのSLA導入ガイドライン」（2004年3月）などが挙がっています（39頁）。SaaS向けの指針は、既存のSLAのガイドラインを土台に作られたことが分かります。

総務省の情報開示指針は、名称に「SLA」を含みませんが、利用者が提供者を比べて選ぶときに、どの情報を開示してもらうかを整理した資料です。本記事の整理では、提供者を比較して絞り込む段階では開示指針、契約でサービスレベルと補償を決める段階ではSLAガイドライン、と使い分けると読みやすくなります。総務省の資料の詳細は、総務省の報道資料から各指針を確認してください。

SLAと、SLO・SLI、非機能要件の関係を整理したい場合は、SaaSの非機能要件とはで、SaaSとは何かから確認したい場合は、SaaSとは？PaaSやIaaSとの違い、サービスの選び方も解説で説明しています。

契約前にSLAを確認する手順｜ガイドラインを使った5ステップ

契約前のSLAの確認は、自社の前提の整理、標準SLAの入手、項目の突き合わせ、不足の質問、結果の承認と運用担当の決定の5ステップで進めます。

この手順は、ガイドラインの5-7章の内容から本記事で組み立てた進め方で、ガイドラインそのものの手順ではありません。個別の契約の判断は、各社の公式情報や専門家に確認してください。

1. 自社の前提を整理する:業務量や利用者数、業務が止まったときの影響を整理します。ガイドラインは、自社の業務におけるITサービスの最大許容停止時間を明確にしておくと、トラブルへの備えができるとしています（38頁）。
2. 提供者の標準SLAと利用規約を入手する:標準SLAで、6つの構成要素が明確になっているかを確認します（23頁）。
3. 別表と突き合わせる:稼働率、復旧時間、障害の通知、バックアップの保存期間、公的認証などを、別表の項目と並べます。保証型か努力目標型かも項目ごとに確認します。数値は、業務の重要度と価格のバランスで判断します。
4. 6章の確認事項で、不足を質問する:ログの提供、データのダウンロード、サポート時間、最大停止時間の提示など、標準SLAに書かれていない事項を提供者に尋ねます。
5. 確認結果を承認して、運用の担当を決める:確認した内容を経営面から検証して承認を得ます（37頁）。そのうえで、測定結果の報告や障害の連絡を受ける窓口と、見直しの時期を決めます（26頁）。

利用者側で先に準備しておくこと（7章）

7章は、SaaSを効果的に使うために、利用者側にも準備が必要だとしています（37-38頁）。ネットワーク環境については、高速で安定したインターネット接続と、自社のLANの帯域の確保が必要です。端末については、利用者ごとのOSとブラウザの一覧表を作り、提供者がサポートしていない環境が使われていないかを確認します。さらに、ブラウザの一般的な脅威への教育、情報モラル教育、トラブルのときの問い合わせ先と判断基準の明確化も挙げられています。サービスレベルの検討では、ITベンダやITコーディネータなどの外部の専門家を活用して、客観的に評価する方法も紹介されています。

次のチェックは、ここまでの内容から作った簡易的な点検で、診断や認証ではありません。当てはまる数が少なければ、今の確認で足りる可能性があります。

SLAの確認結果の報告や、障害の連絡を受ける窓口は、SLAの運営ルールで決める事項です。連絡の場を1か所に決める場合の一例が、前の章で紹介したChatworkです。

よくある質問(FAQ)

Q1. SaaS向けSLAガイドラインとは何ですか？

A. 経済産業省が2008年1月21日に公表した、SaaS型取引の紛争を防ぐために、利用者と提供者が事前に合意すべき事項と、望ましいサービスレベルの考え方を示した指針です。実際のSaaSのサービスレベル設定事例をもとにまとめられ、別表にサービスレベル項目のモデルケースがあります。

Q2. SaaS向けSLAガイドラインでは、稼働率は何%とされていますか？

A. 別表の設定例では、サービス稼働率は基幹業務で99.9%以上、それ以外の業務で99%以上です。ただし、ガイドラインは設定例を参考とし、実際の設定値は業務内容など個々の状況に応じて決めるべきだとしています。

Q3. 目標保証型と努力目標型の違いは何ですか？

A. 目標保証型は保証義務が発生し、未達成のときの結果対応（補償など）が設定されます。努力目標型は努力目標にとどまり、補償が明確に規定されません。どちらの型かは、項目ごとにSLAの文言で確認します。

Q4. 経済産業省の「クラウドサービスレベルのチェックリスト」とは別のものですか？

A. 別の文書です。解説記事によると、チェックリストは2010年8月に公開され、SaaS向けSLAガイドラインの別表を参照して項目を加えたものです。本記事の確認時点では、経済産業省のサイト上に同名の公開ページは確認できませんでした。

Q5. 総務省にもSLAに関するガイドラインはありますか？

A. 総務省は、利用者がクラウドサービスを比較・評価・選択するための情報の開示項目を示す「クラウドサービスの安全・信頼性に係る情報開示指針」を公表しています。7つの指針からなり、令和4年2月15日にAIを用いたクラウドサービス向けの指針が追加されました。

Q6. 提供者の標準SLAしかない場合、内容を交渉できますか？

A. ガイドラインは、標準SLAで必要な内容が明確かを確認し、不明確な場合は提供者と協議するとしています。ただし、マルチテナントの場合は、協議をしても必ずしも利用者の要求事項が実現できるわけではありません。協議できるかどうかは、事前に提供者へ確認してください。

まとめ｜SaaS向けSLAガイドラインを使うために押さえる5つのこと

SaaS向けSLAガイドラインは、利用者と提供者が事前に合意すべき事項を整理した指針で、2008年の文書として、今は枠組みとして使い、数値や規格は最新の情報で確かめるのが現実的です。次の5つから、取り組みやすいものを選んで確認してください。

1. 位置づけと構成を押さえる:2008年1月21日に公表された経済産業省の指針で、7章と別表からなる
2. 標準SLAを6つの要素と4分類で読む:前提条件、委託範囲、役割と責任、サービスレベル項目、結果対応、運営ルールがそろっているかを見る
3. 保証型か努力目標型か、結果対応を確認する:補償の形、上限、免責事項を項目ごとに確かめる
4. 締結後のSLMと運営ルールを決める:測定、分析、改善、報告・連絡の流れと、見直しの時期を決める
5. SLAの確認結果の承認と、障害時の連絡を仕組みにできるか、資料で検討する:ワークフローシステムやビジネスチャットの資料を請求して比べる

SLAは、締結して終わりの書類ではなく、サービスの品質を利用者と提供者が共有して、見直し続けるための約束です。ガイドラインの数字は、そのまま使える基準ではなく、提供者の標準SLAを読むときの物差しです。自社の業務が止まったときの影響を先に整理し、その水準に合う項目を、別表と6章の確認事項から選んでください。確認した結果は、誰がいつ承認したかとともに残し、締結後の連絡の窓口も決めておくと、障害のときに迷いにくくなります。

なお、本記事は一般的な情報提供を目的としたもので、法的助言ではありません。個別の契約条件や判断は、各社の公式情報や、法務部門・専門家にご確認ください。

参考文献

• 経済産業省「SaaS向けSLAガイドライン」（平成20年1月21日）:https://www.meti.go.jp/policy/netsecurity/secdoc/contents/downloadfils/080121saasgl.pdf
• 総務省「「クラウドサービスの安全・信頼性に係る情報開示指針」における「AIを用いたクラウドサービスの安全・信頼性に係る情報開示指針（ASP・SaaS編）」の追加」（令和4年2月15日）:https://www.soumu.go.jp/menu_news/s-news/01ryutsu06_02000306.html
• Assured「経済産業省の「クラウドサービスレベルのチェックリスト」とは？」（解説記事）:https://assured.jp/column/knowledge-meti-sla-checklist
• 株式会社kubell 会社情報:https://www.kubell.com/about/company/
• 株式会社コラボスタイル 会社情報:https://www.collabo-style.co.jp/company/
• コラボフロー 導入事例 南海電気鉄道株式会社:https://www.collabo-style.co.jp/case/case021/
• Chatwork 導入事例 一般社団法人 全国介護事業者連盟（取材2023年8月）:https://go.chatwork.com/ja/case/kaiziren.html