ベンダーロックインの対策｜契約前に名義と引き継ぎを決める

保守契約の更新の書類に、ドメインやサーバーの更新費まで開発会社の請求として並んでいたら、その入口の名義は開発会社の側にあるかもしれません。名義を移す手順も、作り替える権利の扱いも、手元の契約書には書かれていないことがあります。契約前・開発中・終了時に契約書へ書く項目の対応表と、いま動いているシステムで名義・権利・文書・引き継ぎ先を確かめる順番を、公的な文書の記述に沿って並べました。

本記事は民間の会社が開発会社やSaaSと契約する場面を扱い、官公庁や自治体の調達手続きそのものは対象にしていません。引用する公的文書には官公庁の調達を主な対象にしたものが含まれるため、民間の取引にも当てはまる論点に限って引きます。著作権と契約についての記述は一般的な説明であって法的助言ではないので、個別の契約は弁護士などの専門家に確認してください。外部の記述はいずれも2026年10月19日に読んだ範囲です。当社について書くのは自責〜JISEKI〜のページとプレスリリースに載せた契約の設計で、事業の実績ではありません。

ベンダーロックインとは、特定の開発会社や製品から乗り換える費用と手間が大きくなり、発注側が選び直せなくなる状態である

ベンダーロックインとは、システムを使い続けるのに要る改修や保守を最初に作った会社以外が引き受けられなくなり、発注側が相手を選び直せなくなった状態です。乗り換えにかかる費用と手間が大きすぎて、同じ会社に頼み続けるほかなくなります。

公正取引委員会の2022年2月の報告書は、機能改修やバージョンアップやハードウェアのメンテナンスといった情報システムを使い続けるために必要な作業を導入した事業者以外が実施できず、特定のベンダーを利用し続けなくてはならない状態をベンダーロックインと定義しています（公正取引委員会「官公庁における情報システム調達に関する実態調査報告書」（PDF）／2026年10月19日閲覧）。

この定義の要は「導入した事業者以外が実施することができない」の部分です。作業の中身はほかの会社にもこなせる内容でも、名義や権利や資料が最初の会社の側にしかなければ、ほかの会社は手を付けられません。

再契約の理由で最も多いのは、既存ベンダーしか中身を把握できないことである

ロックインは古い技術や珍しい製品を選んだことだけで起きるのではありません。契約の段階で名義と権利と文書の置き場所を決めなかったことからも起き、作ったあとに決め直そうとすると相手の合意が要る交渉になります。

公正取引委員会が官公庁に既存ベンダーと再度契約した理由を尋ねた質問（複数回答・有効回答1,000機関）では、最も多かった回答が「既存ベンダーしか既存システムの機能の詳細を把握することができなかったため」の483機関（48.3％）でした。既存ベンダーしかシステムに保存されたデータの内容を把握できなかったためという回答も211機関（21.1％）あります（公正取引委員会「官公庁における情報システム調達に関する実態調査報告書」（PDF）／2026年10月19日閲覧）。

権利の側では、システムの機能（技術）に係る権利が既存ベンダーに帰属していたためという回答が243機関（24.3％）で、データに係る権利が既存ベンダーに帰属していたためが71機関（7.1％）でした。報告書は、機能（技術）に係る権利が帰属していたという回答には、市販のパッケージソフトを導入している機関が含まれると注記しています。そのうえで背景として、仕様が特定のベンダーに偏っていたり権利処理が適切になされていなかったりする可能性を挙げています（公正取引委員会「官公庁における情報システム調達に関する実態調査報告書」（PDF）／2026年10月19日閲覧）。

同じ報告書が紹介する国の機関の意見では、システムの改修でプログラムに係る著作権が既存ベンダーに帰属していたために運用主体を別のベンダーへ変えられず、既存ベンダーと再度契約することになりました（公正取引委員会「官公庁における情報システム調達に関する実態調査報告書」（PDF）／2026年10月19日閲覧）。当社の見方では、把握できないという理由は文書と引き継ぎの問題で、権利が帰属していたという理由は契約の問題です。どちらも作り始める前に置き場所を決めていれば、乗り換えの段階で初めて気づく形にはなりにくくなります。

ノウハウと文書が開発会社の側にたまると、権利があっても読み解けなくなる

ノウハウが開発会社の側にたまる構造も指摘されています。経済産業省のDXレポート（2018年9月7日）は、日本ではユーザ企業よりベンダー企業にITエンジニアの多くが所属し、受託開発の構造のためにユーザ企業の内部へ情報システムのノウハウが蓄積しにくいとしています。外部のベンダー企業への委託が主な場合はメンテナンスをある程度の間隔でまとめて行うことになり、ベンダー企業側にノウハウが蓄積されるとも書いています（経済産業省「DXレポート ～ITシステム『2025年の崖』の克服とDXの本格的な展開～」本文（PDF・国立国会図書館WARPの保存版）／2026年10月19日閲覧）。

デジタル庁の実践ガイドブック（DS-120・2026年6月12日改定）は、設計・開発を進めたあとに設計情報等が受注者側の人質のようになり次の作業や調達の制約になり得るとして、ロックインの発生原因を3つ挙げています。設計情報が専門的で大量にあり作成者以外には理解しにくいこと、発注者側が調達仕様書や設計書等のドキュメント類を適切に管理していないこと、特定のベンダーだけが権利を持つ排他的な独自技術等が採用されていることです（デジタル庁「DS-120 デジタル・ガバメント推進標準ガイドライン実践ガイドブック」（PDF）／2026年10月19日閲覧）。

3つのうち発注側が契約と日々の運用で手を打てるのは、文書の管理と権利の扱いの2つです。設計情報が専門的で大量にあるという1つ目も、文書を発注側で最新に保っていれば読み解く入口が残ります。

図は、乗り換えを止めるものを名義・権利・文書・データの順に4つの行で並べた対応表です。左の列は開発会社の側にだけある状態で、ここに当てはまる行が多いほど乗り換えは難しくなります。右の列は発注側にも残す状態で、下の帯は契約前・開発中・終了時の各時点について契約書に書く項目を示しています。以下の節は図の行の順に、この左右の差を埋める方法を扱います。

アカウントとドメインは発注側の名義か管理者の権限で持ち、開発会社には作業に要る権限だけを渡す

アカウントとドメインは発注側の名義で作るか、少なくとも管理者の権限を発注側が持ち、開発会社には作業に要る権限だけを渡します。ここでいうアカウントは、ドメイン（サイトやメールの住所に当たる名前）の登録・クラウドやサーバーの契約・ソースコードの置き場・外部サービスや分析ツールの管理画面のように、システムが動き続けるために誰かが持っていなければならない入口のことです。

名義が開発会社にあると、契約を終えるときに入口の持ち主を変える手続きを相手に頼むことになります。相手に悪意がなくても、担当者の異動や会社の事情で手続きが遅れれば、その間はシステムを止めずに乗り換える作業が進みません。名義を発注側に置くのは相手を疑うための手当てではなく、終わり方を穏やかにするための手当てです。

作り始める前に決めておくと、手順は単純になります。入口は発注側の名義で作り、開発会社の担当者をメンバーとして招いて作業に要る範囲の権限だけを付けます。終わるときは招いた権限を外せば済み、名義を移す手続きは要りません。

支払いの名義も入口の一部です。外部サービスの利用料や広告の出稿費を開発会社が立て替えて請求する形にすると、契約や管理画面の名義まで開発会社の側に置かれることがあります。どの費用を誰の名義で契約するかは、開発の費用とは別の項目として契約書に書いておきます。

契約書に書くのは3点です。作る入口の名義を発注側にすること、開発会社に渡す権限の範囲、終了時に権限を外す日と外す役割を持つ人です。担当者の個人のメールアドレスで入口を作らないことも、同じ条項に入れておくと後で探さずに済みます。

納品物にはソースコードと設計書を含め、権利の帰属とデータの取り出し方を契約書に書く

ソースコードと設計書・構成図・運用手順は納品物の一覧に明記し、著作権を発注側に移すのか開発会社に残して使ってよい範囲を決めるのかを契約書に書きます。データは、標準的な形式で取り出せることを要件にします。この節は契約の一般的な考え方を公的なひな型から整理したもので法的助言ではなく、個別の契約は弁護士などの専門家に確認してください。

ソースコードと著作権は、帰属か使ってよい範囲を作り替える権利まで含めて書く

IPA（情報処理推進機構）の「情報システム・モデル取引・契約書」は第二版が2020年12月22日に公開され、受託開発・保守運用の本文とパッケージ・SaaS/ASP活用の追補版は2025年4月8日に国際仲裁の解説を追記して差し替えられています。掲載ページの最終更新日は2026年9月11日で、2026年8月1日の組織改編に伴う問い合わせ先の更新です（IPA「情報システム・モデル取引・契約書（第二版）」／2026年10月19日閲覧）。

このひな型は、納入物の著作権について3つの案を用意しています。A案は開発会社（ひな型の用語ではベンダ）にすべての著作権を帰属させ、B案は汎用的に使えるプログラム等の著作権を開発会社に残してそれ以外を発注側（ユーザ）に帰属させます。C案は汎用的なプログラム等の著作権を開発会社に残し、それ以外を発注側と開発会社の共有にします（IPA「情報システム・モデル取引・契約書＜第二版＞（ひな型）」（Word）／2026年10月19日閲覧）。

解説は、原則として開発会社に著作権を帰属させる規定をA案にしたと説明しています（IPA「情報システム・モデル取引・契約書＜第二版＞（2025年4月8日更新）」（Word）／2026年10月19日閲覧）。原則どおりA案を選べば権利は開発会社の側に置かれるので、発注側はA案のままでよいかを契約の前に確かめることになります。A案を原則にした理由は、乗り換えないほうが合理的な場面を扱う節で取り上げます。

著作権を発注側に移すなら、翻案（元の著作物を作り替えること）の権利まで書いてあるかを確かめます。著作権法第61条第2項は、著作権を譲渡する契約で第27条（翻訳権・翻案権等）か第28条（二次的著作物の利用に関する原著作者の権利）の権利が譲渡の目的として特掲（個別に書き出すこと）されていないときは、これらの権利は譲渡した者に留保されたものと推定すると定めています（e-Gov法令検索「著作権法」／2026年10月19日閲覧）。IPAのB案はこの推定があるため、第27条と第28条の権利も譲渡されることを条文に明記しています（IPA「情報システム・モデル取引・契約書＜第二版＞（2025年4月8日更新）」（Word）／2026年10月19日閲覧）。

譲渡の条文に第27条と第28条の権利を含むと書かれているかは、契約書を開いて最初に探す1行です。改修を続けるシステムほど、作り替える権利の扱いが後から効いてきます。

開発会社が倒産したときの備えも、この条項の近くで決めます。IPAのモデル契約の論点整理は、倒産したときの著作権の行方について対抗要件（第三者に権利を主張するための要件）を備える制度はないとしています。そのうえで、ソースコードや付帯するドキュメントの開示・交付を受けることは、納入物にソースコードを明記するかエスクロウ制度を活用することで対応できるとしています（IPA「情報システム・モデル取引・契約書＜第二版＞（2025年4月8日更新）」（Word）／2026年10月19日閲覧）。エスクロウは、ソースコードを第三者に預けておき決めた条件のときに受け取れるようにする仕組みです。

設定書・構成図と運用手順は発注側で最新に保ち、データは標準的な形式で取り出せるようにする

ソースコードと権利が手元にあっても、設定書・構成図と運用手順がなければ、ほかの会社は引き受けるかどうかを判断しにくくなります。これらは納品物に入れたうえで、発注側で最新に保ちます。

公正取引委員会の報告書は、再契約せざるを得ない状況を防ぐ対策の1つとして、人口5万人未満のある地方公共団体が情報システムの設定書や構成図といった資料を成果物として提出してもらうことを契約上定めている例を紹介しています（公正取引委員会「官公庁における情報システム調達に関する実態調査報告書」（PDF）／2026年10月19日閲覧）。設定書と構成図は、環境を作った会社以外が中身を読み解くための地図に当たります。

資料は揃えるだけでは足りません。デジタル庁のDS-120は、ロックインを未然に防ぐ留意事項として発注者側で最新のドキュメント類を管理するよう求め、フォルダに入れておく「保存」と最新の状態に保つ「管理」を分けています。仕様を変えたときはドキュメントとの矛盾や抜け漏れを確かめ、変更管理を行うことが重要だとしています（デジタル庁「DS-120 デジタル・ガバメント推進標準ガイドライン実践ガイドブック」（PDF）／2026年10月19日閲覧）。

納品の時点で資料が揃っていても、改修のたびに更新されなければ動いているシステムとの食い違いが積み重なります。契約書には資料を納品物にすることに加えて、改修のたびに誰が資料を更新し誰がそれを受け取るかを書いておきます。

データは権利と取り出し方の両方を決めます。DS-120は、権利のうえでデータが発注者に帰属していても、システムからデータを抽出する機能がなかったり特定の製品でしか読み込めない形式でしか抽出できなかったりすると別のシステムへ移行できないとしています。そのため、データを標準的な形式で取り出せることをあらかじめ要件として定めておく必要があるとしています（デジタル庁「DS-120 デジタル・ガバメント推進標準ガイドライン実践ガイドブック」（PDF）／2026年10月19日閲覧）。

運用の中でたまる記録も同じ扱いにします。問い合わせの履歴や設定の変更履歴のような記録は、終了時にどの形式で渡すかを決めておかないと引き継ぎの対象から漏れやすくなります。

終わり方は作り始める前の契約で決め、引き継ぐ相手と引き継ぐ日の段取りまで書いておく

終わり方は作り始める前の契約で決め、誰に・いつまでに・何を渡すかの段取りまで書いておきます。終わる段階になってから決めようとすると、引き継ぎの作業そのものが新しい発注になり、条件を決める交渉から始めることになります。

公正取引委員会の報告書は、構築した会社以外が改修や運用を行いやすいように、知的財産権の所有関係・費用負担の考え方・システムを理解するのに必要な資料の整備・ソースコードの提供等をシステム構築の際にあらかじめ契約書等に明記することが望まれるとしています。官公庁に向けた記述で、ベンダーロックインの回避のためにも重要な取組だと位置づけています（公正取引委員会「官公庁における情報システム調達に関する実態調査報告書」（PDF）／2026年10月19日閲覧）。

段取りとして契約書に書く項目は、次の4つです。

• 引き継ぐ相手: 発注側の担当者に戻すのか、次に頼む会社に渡すのか
• 引き継ぐ日: 名義と権限を移す日と、移行の間にどちらが運用を持つか
• 渡すもの: 図の右の列に並べた4つの行について、何をどの形式で渡すか
• 渡したあと: 引き継いだ側からの問い合わせに、どこまでどの方法で応じるか

渡すものの範囲を委託の準備として決める考え方は、新規事業の外注の記事で契約前に書いておく項目の1つとして扱いました。本記事の段取りは、その範囲をいつ・誰に渡すかを決める側の話です。

当社の自責〜JISEKI〜は、報酬を事業の売上に連動させる契約です（考え方はレベニューシェアの記事）。外部サービスの利用料や広告の出稿費は発注側の名義で契約する実費として扱い、その線引きは契約時に書面ではっきりさせます（自責〜JISEKI〜）。

作ったものの帰属について、同じページのよくある質問には「開発したコードやアカウントは両社に帰属します。どちらか一方の手元にしか残らない形にはしません。終了時の引き継ぎも、始める前の契約であらかじめ決めておきます。」と書いています。両社に帰属させるこの設計は、受託の開発で本記事が勧める「入口は発注側の名義で持つ」形とは違います。共通するのは、どちらか一方の手元にしか残らない形にしないことと、終了時の引き継ぎを始める前の契約で決めることの2点です。ここに書いたのは当社の契約の設計で、事業の実績ではありません。

乗り換えないほうが合理的な場面もあり、そのときは抜け出す条件だけを契約に残す

同じ会社に任せ続けることは、それだけでロックインとは言えません。システムを一番よく知る会社に頼み続けるのが合理的な場面はあり、そのときに要るのは乗り換えの準備ではなく、乗り換えたくなったときに抜け出せる条件だけを契約に残しておくことです。

公正取引委員会の報告書も、既存ベンダーと再度契約する事例が直ちにベンダーロックインの事例というわけではないとしています。そのうえで、理由や状況によってはロックインの状態であるものも含まれていると十分に考えられる、と書いています（公正取引委員会「官公庁における情報システム調達に関する実態調査報告書」（PDF）／2026年10月19日閲覧）。

権利を開発会社に残すことにも理由があります。IPAのモデル契約がA案を原則にしたのはソフトウェアの再利用を促すためで、開発会社に著作権を帰属させても秘密保持義務を課すことで発注側のノウハウの流出は防げるという立場です。同じ文書の論点整理は、ベンダに著作権を帰属させる側の論点も挙げています。プログラムの著作物の一定の改変・複製・翻案は複製物の所有者にも著作権法で許容されていて、著作権を持たない発注側でも情報システム子会社やほかの外部の会社に保守運用を委託できる、という点です（IPA「情報システム・モデル取引・契約書＜第二版＞（2025年4月8日更新）」（Word）／2026年10月19日閲覧）。権利を移すかどうかだけで乗り換えの可否が決まるわけではなく、ほかの会社が読めるソースコードと資料が手元にあるかもあわせて効きます。

クラウドの選び方にも、同じ相手を使い続けること自体を問題にしない記述があります。デジタル庁のDS-310（2025年5月27日 デジタル社会推進会議幹事会決定）は政府のクラウド利用の基本方針で、クラウド事業者によるロックインを懸念して複数の事業者を積極的に使う考え方に触れています。そのうえで、データの移行性と公開された合理的な価格体系と導入プロセスを含む透明性が担保されていれば、ベンダーロックインには該当しないとしています（デジタル庁「DS-310 政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」（PDF）／2026年10月19日閲覧）。これはクラウドの選定に限った記述です。

開発会社との契約でも、相手を替えるかどうかより先に、抜け出せる条件がそろっているかを確かめるのが順番です。続けると決めた場合に契約へ残す条件は、次の3つに絞れます。

• ソースコードと資料の写しを、改修のたびに発注側が受け取ること
• データを標準的な形式で取り出せること
• 終了を決めたときの引き継ぎの段取り

この3つがそろっていれば、続けるという判断はロックインではなく選んだ結果になります。

いまのシステムで確かめる順番は、名義・権利・文書・引き継ぎ先の順である

すでに動いているシステムでは、名義・権利・文書・引き継ぎ先の順に誰が何を持っているかを確かめます。名義から始めるのは止まったときの影響が最も大きく、確かめるのに契約書を読む必要もないからです。

名義：入口ごとに持ち主と管理者の権限を持つ人を書き出す

アカウントの節で挙げた入口を一覧にし、入口ごとに名義と管理者の権限を持つ人と支払いの名義を書き出します。開発会社の担当者の個人のメールアドレスで作られた入口があれば、発注側の管理下に移す相談を最初に始めます。

権利：著作権の条文と納品物の一覧にソースコードがあるかを見る

契約書で著作権の条文を探し、どの案に近い書き方か、第27条と第28条の権利に触れているかを見ます。納品物の一覧にソースコードがなければ、写しを受け取れるかを開発会社に相談します。条文の読み方は、弁護士などの専門家に確認してください。

文書：設計書と運用手順がいまのシステムと合っているかを確かめる

IPAのモデル契約は、長年運用・保守してきたシステムを作り直すときには仕様を理解する人材がいない・ドキュメントが散逸している・動いているシステムと設計書やソースコードが整合していないといった問題が少なくないとしています。そのため要件定義の前に現行システムの調査を行い、仕様を明らかにする必要があるとしています（IPA「情報システム・モデル取引・契約書＜第二版＞（2025年4月8日更新）」（Word）／2026年10月19日閲覧）。

経済産業省のDXレポートは、レガシー化を自社システムの中身が見えなくなり自分の手で直せない状況に陥ったことだと説明しています（経済産業省「DXレポート ～ITシステム『2025年の崖』の克服とDXの本格的な展開～」本文（PDF・国立国会図書館WARPの保存版）／2026年10月19日閲覧）。乗り換えを考えるときも、資料が揃っているかより先に、資料がいまのシステムと合っているかを確かめます。

引き継ぎ先：契約を終えたときに誰が運用を持つかを決める

発注側の担当者が持つなら、その人が名義と資料を読めるところまでを引き継ぎの完了の条件にします。次の会社に頼むなら、その会社が引き受けるかどうかを判断するために読む資料が揃っているかを先に確かめます。内製化の記事に書いたとおり、作った本人にしか直せない状態はベンダーにしか直せない状態と同じ形をしています。社内に戻す場合も、複数の人が読める形にしておきます。

ベンダーロックインの対策についてよくある質問

Q. 納品済みのシステムの著作権は、あとから発注側に移せますか？

著作権法第61条第1項は著作権の全部または一部を譲渡できると定めているので、開発会社と合意できれば納品後に移す契約を結ぶ余地があります（e-Gov法令検索「著作権法」／2026年10月19日閲覧）。その場合も、譲渡の条文に第27条と第28条の権利の行があるかを確かめます。合意が取れないときは、権利を移さずにソースコードと資料の写しを受け取って保守を別の会社へ頼めるかを検討します。個別の判断は、弁護士などの専門家に確認してください。

Q. SaaSを使う場合は、どこを確かめればよいですか？

SaaSは提供者が作ったアプリケーションを使う形なので、ソースコードの権利よりもデータの取り出し方を確かめます。DS-120は、SaaSのアプリケーションとデータレイアウト等は提供者に帰属するため、発注者が必要なデータを標準的な形式で出力できるサービスを選ぶ必要があるとしています（デジタル庁「DS-120 デジタル・ガバメント推進標準ガイドライン実践ガイドブック」（PDF）／2026年10月19日閲覧）。IPAのモデル契約の追補版も、クラウドで提供されるサービス（追補版の用語ではSaaS/ASP）を選ぶときのチェックリストの「データの取扱い」に、データの権利がユーザ側にあるか（サービスを終了した場合にデータを取り出せるか）・データ移行ツールがあるか・データをダウンロードできるかを挙げています（IPA「情報システム・モデル取引・契約書＜第二版追補版＞（2025年4月8日更新）」（Word）／2026年10月19日閲覧）。管理者のアカウントを発注側の名義で持つことは、SaaSでも同じです。

Q. ロックインを防ぐには、内製するしかありませんか？

内製だけが手段ではありません。経済産業省のDXレポートは、レガシー化は技術の側面だけでなくマネジメントの側面が大きな問題だとし、適切なメンテナンスを行うITシステムマネジメントをしていればブラックボックス化しにくいとしています（経済産業省「DXレポート ～ITシステム『2025年の崖』の克服とDXの本格的な展開～」本文（PDF・国立国会図書館WARPの保存版）／2026年10月19日閲覧）。外部に頼み続ける場合も、名義と資料と引き継ぎの段取りを発注側が持っていれば相手を選び直せます。社内に引き継ぐ相手を採用で用意するか外部と組むかはFDEの採用と外部活用の記事に、外部の伴走で社内に移す使いどころはFDE支援の使いどころの記事に書きました。

Q. 官公庁の調達の話と、民間の会社の契約は何が違いますか？

公正取引委員会の報告書は官公庁を対象にした調査ですが、民間の情報システムの取引でも同様の論点を持つ部分には報告書の考え方が有用だとしています。官公庁にとどまらず広く情報システム調達に携わる関係者に、ベンダーロックインの未然防止に取り組むことを期待するとも書いています（公正取引委員会「官公庁における情報システム調達に関する実態調査報告書」（PDF）／2026年10月19日閲覧）。違うのは手続きで、入札や仕様書の公開といった官公庁の調達の決まりは民間の契約にはそのまま当てはまりません。本記事が扱うのは名義・権利・文書・引き継ぎという、民間の契約でも同じ形で効く論点だけです。

SAIの視点：終わり方の条件は、申し込む前に読める場所に書いておく

終わり方の条件が契約の場で初めて出てくると、ほかの相手と比べる材料がないまま判断することになりがちです。そこで自責〜JISEKI〜では、作ったものの帰属と引き継ぎを決める時期を、申し込む前に読めるサービスのページのよくある質問に書きました。2026年10月6日に配信したプレスリリースでも、同じ内容を公開しています（プレスリリースのお知らせ）。

FDE伴走開発は、貴社のメンバーと一緒に作りながらスキルを移し、ドキュメントと運用体制を整えて自社だけで改善が回る状態をゴールにしています。名義と資料を発注側に置くという本記事の対策と、同じ向きの進め方です。社内で作り続ける力を持ちたいならFDE伴走開発、新しい事業として作るなら自責〜JISEKI〜が入口になります。

契約書を開く前に、ドメインとクラウドの管理画面に社内の誰が管理者として入れるかを尋ねてみてください。答えられる人がいなければ、システムの一覧に「アカウント・ドメイン・ソースコードの持ち主」の3列を足し、分かる範囲で埋めてお問い合わせへ送ってください。パスワードや管理画面のログイン情報は送らないでください。

出典と確認日

外部の出典はいずれも2026年10月19日閲覧。IPAのモデル契約のひな型と解説はWord形式の文書で、版は掲載ページに示された版である。DS-120の日付は表紙と改定履歴に記載された改定年月日で、PDFの掲載先のパスにある日付とは異なる。当社の一次情報は自責〜JISEKI〜のページのよくある質問と2026年10月6日配信のプレスリリースに書いた契約の設計と、FDE伴走開発のページの記述で、事業の実績や顧客案件の数値ではない。

• 公正取引委員会「官公庁における情報システム調達に関する実態調査報告書」（PDF）（令和4年2月）
• IPA「情報システム・モデル取引・契約書（第二版）」（2020年12月22日公開・最終更新日2026年9月11日）
• IPA「情報システム・モデル取引・契約書（受託開発（一部企画を含む）、保守運用）＜第二版＞（ひな型）」（Word）
• IPA「情報システム・モデル取引・契約書（受託開発（一部企画を含む）、保守運用）＜第二版＞」（Word）（2025年4月8日更新）
• IPA「情報システム・モデル取引・契約書（パッケージ、SaaS/ASP活用、保守・運用）＜第二版追補版＞」（Word）（2025年4月8日更新）
• e-Gov法令検索「著作権法（昭和四十五年法律第四十八号）」（第61条）
• 経済産業省「DXレポート ～ITシステム『2025年の崖』の克服とDXの本格的な展開～」本文（PDF・国立国会図書館WARPの保存版）（2018年9月7日・デジタルトランスフォーメーションに向けた研究会）
• デジタル庁「DS-120 デジタル・ガバメント推進標準ガイドライン実践ガイドブック」（PDF）（2026年6月12日改定・表紙と改定履歴の日付）
• デジタル庁「DS-310 政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」（PDF）（2025年5月27日 デジタル社会推進会議幹事会決定）
• 当社の契約の設計: 自責〜JISEKI〜のよくある質問（終了時の帰属と引き継ぎ・実費の線引き）、プレスリリースのお知らせ（2026年10月6日配信）、FDE伴走開発の「内製化・技術移転」