データコントラクトとは何か？｜AIに渡す前の取り決め

「先月まで取れていた項目が、今月になったら全部空でした。誰からも連絡は来ていません」「社内のデータをAIに読ませて集計させているのですが、ある時期から答えが少しずつずれ始めました。エラーは出ないので、気づいたのは現場から数字がおかしいと言われたときです」。——データを受け取る側に回ると、この2つはほぼ必ず一度は通ります。この言葉が広まるきっかけになった2022年の文章の日本語訳では、本番のデータベースから列を1つ消したことで、会社の売上の8割を生んでいた価格算出の仕組みが壊れた例が挙げられています。消した側に悪意はありません。使われていないと思った列を整理しただけです。足りなかったのは注意深さではありません。本当は、データを出す側と受け取る側のあいだに、先に文書にした約束が無いことです。この約束を指す言葉がデータコントラクトです。この記事では、何を約束するのか、どういう順番で作るのか、AIに社内のデータを渡す前にどこまで決めておけば壊れないのかを整理します。

先月まであった項目が、今月は空。取り決めのない受け渡し

多くの社内のデータは、取り決めのないまま流れています。基幹の仕組みから毎晩ファイルが出てきて、それを分析の基盤が取り込み、レポートやダッシュボードになる。この流れのどこにも、どの項目を、どの意味で、いつまでに、どの形で出すかを書いた文書がありません。動いているあいだは誰も困らないので、無いことにも気づきません。

困るのは、出す側が変えたときです。列の名前を分かりやすく直した。使われていないと判断した列を消した。1つのテーブルを2つに分けた。どれも出す側から見れば改善で、止める理由がありません。出す側にはその項目を今どこの誰が使っているかが見えていないからです。見えていないものについて、事前に相談することはできません。

受ける側の対処は、たいてい見張りになります。毎朝ファイルを開いて件数を目で見る。前日と比べて極端に減っていないかを確かめる。これは仕組みではなく人力なので、流れが5本から20本に増えた時点で回らなくなります。そして、見張りを外した流れから順に壊れます。壊れたことに気づくのは、その数字を使って判断した後です。

ここで必要なのは、変更を止めることではありません。変更は事業が動いている限り必ず起きます。必要なのは、変えるときに誰に何日前に知らせるかを、先に決めておくことです。止めようとすると出す側の開発が遅くなり、結局は取り決めごと無視されます。予告と並行期間で吸収する、という形にしておくのが現実的です。

データコントラクトとは何か。二者間の約束という一点

データコントラクトは、データを出す側と受け取る側のあいだで、渡すデータについて先に文書にしておく約束です。分かりやすい言い方をすると、APIの仕様書を、システムの機能ではなくデータについて書いたものです。出す側は「この形で、この頻度で、この意味の値を出す」と宣言し、受ける側はそれを前提に集計や画面を組み立てます。約束にないものには依存しない、というのが裏返しの約束になります。

言葉の出どころははっきりしています。2022年に米国の実務者が公開した文章が起点で、2023年1月に日本語訳が公開されています。そこでは、業務のデータを作る開発者と、それを使う分析や機械学習の担当者のあいだの合意として説明されています。約束に含めるものとして挙げられているのは、構造と型、必須の項目と形式、守る水準、版の管理と変更の手続き、そして実体どうしの関係が1対1であることといった業務上の保証までです。形だけでなく意味に踏み込むのが特徴です。

書き方の共通の書式も公開されています。2026年9月時点で公開されている仕様のページでは、約束を11の区分に分けています。基本情報、構造、参照、データ品質、問い合わせと連絡の経路、費用、体制、役割、守る水準の取り決め、置き場所と基盤、独自に足す項目です。この書式が特定の会社の社内の雛形から始まったという説明も見かけますが、取得できた仕様のページには由来の記載がなかったため、ここでは、共通の書式が公開されていて区分はこの11個だ、という事実だけを扱います。

そして、何でないかも先に置いておきます。データコントラクトは全社の規程ではありません。誰がどのデータの持ち主かを決める枠組みでもありません。それらは別の話で、粒度がまったく違います。データコントラクトの粒度は、この1本の流れについての1対1の約束です。全社の話に広げた瞬間に、合意する相手が増えすぎて、いつまでも決まらなくなります。

取り決めが無いときの壊れ方を、4つの型で見る

壊れ方には型があります。型で覚えておくと、約束に何を書けばよいかが逆算できます。実務で見かけるのは次の4つです。

• 黙って消える。使われていないと判断された列が削られ、受ける側では空欄の列が並ぶ。集計は動き続けるので、合計だけが小さくなる
• 意味が変わる。契約日という項目が、申込を受けた日から検収が終わった日に変わる。形も型も同じなので検査を素通りし、月ごとの数字だけが後ろにずれる
• 型が変わる。数値だけが入っていた項目に、未定という文字が混ざる。合計が出なくなるか、その行だけが無視されて件数が合わなくなる
• 遅れる。毎朝6時に届いていたものが不定期になり、朝の会議の数字が前日のままになる。誰も落ちていないと思っているので、古い数字で議論が進む

この4つのうち、いちばん厄介なのは2つめの意味が変わる型です。消えた項目や型の違いは機械で検出できますが、意味の変化は形に出ません。同じ名前の同じ型の列に、違う日付が入っているだけです。気づく手がかりは、月ごとの件数の並びが不自然に動いたときの違和感しかありません。だから約束の文書には、項目の名前だけでなくその値がいつの時点の何を指すのかを、1行で書き残す必要があります。

4つめの遅れは、軽く見られがちですが影響は広いです。遅れたときに待つのか、前日の値で進めるのか、止めるのかが決まっていないと、処理は待ち続けて後続が全部止まります。遅れの上限と、超えたときにどうするかはセットで決めます。上限だけ書いて、超えたときの動きを書かない約束は、実務では機能しません。

もう1つ、型として足しておきたいのが区分の値が増える形です。契約の区分に新しい値が1つ加わると、受ける側の集計では想定外の値がその他に落ちます。合計は合っているのに内訳だけが狂うので、数字を見ている人ほど気づきにくい。区分の項目は、取りうる値の一覧そのものを約束に書くのが実務的です。

AIに渡すと、壊れ方が静かになる

従来の集計では、データが壊れると処理が落ちました。型が合わない、必須の項目が無い、件数がゼロ。落ちれば誰かが気づきます。ところが、同じデータをAIに読ませる形にすると、壊れていても処理は落ちず、それらしい答えが返ってきます。ここが、取り決めの必要性が一段上がる理由です。

具体的には、こう出ます。参照させている表から項目が消えていても、AIは残った項目だけで文章を組み立てます。古い版の資料が残っていれば、それを根拠として引きます。区分の値が増えていれば、知らない値を無視するか、近い意味の区分に寄せて説明します。どれも出力の見た目は正常で、注意書きも付きません。人が気づくのは、その答えを使って動いた後です。

この静かな劣化に対しては、答えの側で見張っても間に合いません。答えの良し悪しを人が毎回判定するのは現実的ではないからです。だから検知は入力の側に置きます。AIに渡す直前のデータが、約束した項目をそろえているか、型が合っているか、空の割合がいつもの範囲か、到着が遅れていないか。ここで止めれば、劣化した答えはそもそも出ません。

あわせて、AIが答えるときにどの資料のどの部分を見たのかを必ず添えさせる設計にしておきます。根拠が付いていれば、答えがずれ始めたときに原因をさかのぼれます。根拠が無いと、ずれているかどうかを判定するために元の資料を全部開くことになり、AIを入れる前より時間がかかります。取り決めと根拠の表示は、片方だけでは効きません。

約束に書く7つの欄

公開されている共通の書式は11区分あって、最初から全部を埋めるのは重すぎます。社内の1本の流れで実際に効くのは、次の7つです。この7つが埋まっていれば、先に挙げた4つの壊れ方はほぼ拾えます。

欄	書く内容	書いていないと起きること
項目の名前と意味	その項目が何を指し、いつの時点の値なのか。1行で書く	同じ名前で違うものを数え、月ごとの数字が静かにずれる
型と取りうる値	数値か文字か日付か。区分なら値の一覧そのもの	想定外の値が混ざり、計算が止まるか内訳だけが狂う
欠けてよいか	空でよい項目と、空なら異常として止める項目を分ける	空欄を埋めた推測が下流に流れ、根拠のない数字になる
更新の頻度と時刻	何時までに、どの範囲のデータがそろうか	そろう前の途中の数字で判断してしまう
遅れの上限	何分または何時間まで待つか。超えたら止めるか前日の値で進むか	待ち続けて後続が全部止まる、または古い数字が残る
変えるときの予告	何日前に、誰に、どの経路で知らせるか。並行して出す期間	知らないうちに変わり、気づくのは壊れた後になる
破ったときの扱い	誰が受け、何を止め、いつまでに戻すか	連絡先を探すところから始まり、復旧が半日単位で遅れる

7つのうち、いちばん時間がかかるのは1つめの項目の意味です。型や頻度は調べれば分かりますが、意味は人の頭の中にしかありません。契約日、稼働開始日、計上日。どれも似ていて、部門ごとに指しているものが違います。ここを詰めるために、出す側と受ける側が同じ机に着く必要があり、それ自体がこの取り組みの価値の半分です。

6つめの予告は、日数を先に決めます。項目を足すだけなら予告なしでかまいません。足しても受ける側は壊れないからです。意味を変えるときと、消すときだけ予告を必須にする。日数の目安は、受ける側の改修にかかる期間から逆算します。四半期ごとに改修の窓がある組織なら、90日は長すぎず短すぎない線になります。

• 約束はデータの全項目に対して書くものではありません。受ける側が実際に使っている項目だけを書きます。全項目を約束に入れると、使っていない項目の変更でも止まるようになり、出す側の負担だけが増えます
• 共通の書式に含まれる費用や置き場所の区分は、社外にデータを提供する場合には要りますが、社内の1本の流れでは省いてかまいません

作る順番を5工程に分ける

順番を間違えると、途中で止まります。よくある失敗は、出す側が今あるデータの一覧を作るところから始めることです。そうすると要らない項目まで約束に入り、守る手間だけが増えます。始点は受ける側です。

工程1と工程2は、往復の回数を先に決めておきます。2往復で決まらなかったら、その項目は今回の約束から外すという置き方です。決まらない項目は、たいてい業務側で定義そのものが割れています。割れている定義を約束の文書の中で決着させようとすると、取り組み全体が止まります。外して先に進み、定義の議論は別の場に出します。

工程3から先は、道具の話になります。ここで詰まる組織は少ないです。逆に言うと、詰まるのはほぼ工程1と工程2で、そこは道具では解けません。導入の計画を立てるときは、この2工程に全体の期間の半分以上を置いておくと、実態に合います。

工程1・受ける側が、要る項目と用途を先に出す

受ける側が出すのは、項目の一覧ではありません。項目の一覧だけを渡すと、出す側は「全部必須ということですね」と受け取ります。出すべきなのは、この項目が無いと、何ができなくなるのかです。用途が書いてあると、出す側が優先順位を付けられます。

• 使っている項目の名前と、そこから作っている数字
• その数字を誰が、どの会議で、何の判断に使っているか
• 欠けたときに止まるのか、近似で回せるのか
• 必要な鮮度（前日までで足りるか、当日中に要るか）
• さかのぼる期間（過去何年分が要るか、過去の値は書き換わるのか）
• AIに読ませている場合は、どの問いに答えるために読ませているか

最後の1行は、AIに渡す流れに特有の項目です。AIが参照するとだけ書いても、出す側は何を守ればよいか分かりません。たとえば、過去の商談の記録を読ませて似た案件を探させているなら、守ってほしいのは失注の理由の欄が空でないことと、区分の値が増えたら知らせてもらうことです。用途まで書けば、守る対象が3つか4つに絞れます。

この工程でよく起きる落とし穴は、受ける側が全項目を必須に倒すことです。念のため全部、という出し方をすると、出す側は守れないと判断して取り組み自体を断ります。必須は、欠けたら止まるものだけに限ります。実際にやってみると、必須に残るのは5つか6つで、残りはあれば使うという扱いで足ります。

あわせて、過去の値が後から書き換わるかどうかを必ず聞いておきます。受注の金額が検収のときに確定する、返品で過去の月の数字が動く、といった業務は珍しくありません。ここを知らずに集計を組むと、先月出したレポートと今月出したレポートで先月の数字が違う、という形の食い違いが出ます。

工程2・出す側が、出せる形と守れる線を返す

出す側が返すのは3つです。出せる項目、守れる時刻と頻度、そして守れない項目。3つめが要ります。守れないものを守れると書いた約束は、1か月で破られ、破られた瞬間に約束そのものが信用されなくなります。1つ守られなかった取り決めは、残り全部も守らなくてよいものとして扱われます。

• この項目は基幹の仕組みの改修予定に入っているので、4月以降は名前が変わります。今は約束に入れず、改修後に足します
• 毎朝6時までにそろうのは前日分までです。当日分が要るなら、確定前の値だという印を付けた形でなら出せます
• 区分の値は業務側が随時足すので一覧を固定できません。代わりに、値が増えたら翌営業日までに知らせる運用にします

遅れの上限は、願望ではなく実績から決めます。過去3か月の到着時刻を並べて、いちばん遅かった日を見る。そこから少しだけ余裕を取った線が、守れる上限です。上限は、いつもの時刻ではなく、いちばん遅かった日から決める。いつもの時刻で約束すると、月末や連休明けに必ず破ります。

出す側にとって、この約束は負担が増える話です。今までは自由に変えられたものが、予告と並行期間の対象になります。だからこそ、対象を絞ることが出す側の利益にもなります。約束に入れた項目以外は、これまでどおり自由に変えてよいと明示しておくと、合意が取りやすくなります。全部を守らせる話ではない、という点を最初に共有しておきます。

工程3・合意を機械が読める形で1か所に置く

合意しただけでは守られません。会議で決めて議事録に書いた約束は、半年で誰も見なくなります。見なくなる理由は、その文書が仕組みのどこにもつながっていないからです。だから、約束は文章ではなく、機械が読み取れる書式で書きます。仕組みが読める形にしておけば、次の工程の検査が同じ文書から自動で作れます。

置き場所は、そのデータを出している仕組みのソースコードと同じ場所にします。こうすると、出す側が項目を変えるときに、同じ変更の手続きの中で約束の文書も目に入ります。別のフォルダや別の管理台帳に置くと、片方だけが更新されて、実態と文書が違うという最悪の状態になります。文書と実態が違うくらいなら、文書が無いほうがまだ安全です。

約束そのものにも版を付けます。人が読む文書の版ではなく、機械が区別できる版です。受ける側は、どの版を前提に組んだかを記録しておく。こうしておくと、壊れたときに「どの版からどの版で何が変わったか」を1手で出せます。版が無いと、壊れた原因を探すのに出す側と受ける側で記憶を突き合わせることになります。

書き方は、先に挙げた公開されている共通の書式を借りるのが早いです。区分の名前と並び順が決まっているので、何を書き忘れているかが一目で分かります。自社で1から欄を設計すると、最初の数本は欄が足りず、後から全部を書き直すことになります。書式は借りて、中身だけ自社で決めるのが省力です。

工程4・検査を自動で回し、落ちたときの受け先を決める

検査は2か所に置きます。出す側から出る直前と、受ける側が取り込んだ直後です。出る直前で止めれば、壊れたデータがそもそも流れません。受け取った直後でも見るのは、経路の途中で起きる欠落や重複を拾うためです。片方だけだと、どちら側で起きたのかが分からず、原因の押し付け合いになります。

見る中身は、約束の7つの欄からそのまま作れます。項目がそろっているか、型が合っているか、空の割合がいつもの範囲に収まっているか、区分の値に知らないものが混ざっていないか、件数が前日から何割の範囲か、到着時刻が上限内か。この6つで、先に挙げた壊れ方はほぼ拾えます。

難しいのは、落ちたときにどうするかです。止めるのか、通して印を付けるのか。集計の用途なら止めるほうが安全ですが、AIに読ませる流れでは、古い版のまま止めておくほうが安全な場面がある。欠けたデータで新しい答えを出すより、前の答えのまま更新を止めて、更新が止まっていることを画面に出す。どちらを選ぶかは、その答えが使われる場面によって変わります。用途ごとに先に決めておきます。

警報の出しすぎにも注意が要ります。最初から厳しい線を引くと、毎日何本も警報が出て、2週間で誰も見なくなります。初期の線は緩めに置き、実際の変動を1か月見てから締める。そして、警報を受け取る先を個人ではなく役割にしておきます。個人宛にすると、その人が異動した日から誰も受け取らなくなります。

工程5・変えるときの予告と、破ったときの手順

変更は3種類に分けます。足す、意味を変える、消す。足すのは受ける側を壊さないので、予告なしで自由にしてかまいません。危ないのは残り2つです。この分け方をしておかないと、すべての変更に重い手続きがかかり、出す側が取り決めを避けるようになります。

3つめが要点です。意味を変えるときは、同じ名前のまま中身を入れ替えないことです。意味が変わるなら、名前も変えて、しばらく両方を出す。そうすれば受ける側は自分の都合で切り替えられますし、切り替え忘れも古い項目が消える日に気づけます。同じ名前のまま中身を変えると、気づく手段が残りません。

破ったときの手順は、責任を問う形にしないのが実務の要点です。破った人を探す運用にすると、次からは黙って変えられます。決めるのは、誰が第一報を受け、何を止め、いつまでに元に戻すかの3つだけです。そのうえで破った回数だけを流れごとに数えます。数えると、どの流れの取り決めが実態に合っていないかが浮かびます。多いのは、たいてい守れない時刻を書いてしまった流れです。

AIに判断させない線を、作業名で引く

最終的には人が確認する、という一文は運用に落ちません。落とすには、作業の名前で分けます。並べる・要約する・下書きするはAI、意味を決めるは人。この線で仕分けると、どの作業をどちらに置くかで迷わなくなります。

作業	AIに渡すか	理由
2つの版の差分を要約する	渡せる	事実の並べ替えで、決めごとが動かない。ただし見た場所を必ず添えさせる
検査の条件を下書きする	渡せる	出てくるのは案。そのまま入れず、人が値を決めて採否を判断する
項目の説明文の文案を作る	渡せる	言い回しの整形。意味の確定は別の作業として人が行う
項目の意味を決める	渡さない	業務の定義そのもの。間違えると下流の数字が全部ずれる
欠けてよいかを決める	渡さない	欠けたときに何が止まるかは、業務側の人しか知らない
遅れの上限を決める	渡さない	相手の運用の実態と、自社の締め切りの折衝になる
破ったときに止めるか通すか	渡さない	その答えが誰の判断に使われるかで変わる。影響範囲の判断

表の上3行は渡してよい作業ですが、条件が付きます。根拠を書かせることです。差分の要約なら、どの版のどの行を見たのか。検査の条件の案なら、なぜその値にしたのか。根拠が無い出力は、確かめる時間のほうが作る時間より長くなるので、結局は使われません。出どころに答えられない出力は採らない、という扱いにしておきます。

人が確認する範囲も、先に決めておきます。全部見るという決め方は、忙しい日には何も見ないのと同じ結果になります。実務的な線は、意味に関わる欄だけは毎回人が読み、型や頻度の欄は前の版からの差分だけを見るという置き方です。差分を出す作業はAIに渡せるので、人が読む量は版を重ねるほど減ります。

もう1つ、AIが作った検査の条件をそのまま入れないことです。もっともらしい条件が出てきますが、値の根拠は過去のデータではなく一般論から来ています。件数の変動の幅を2割と書かれても、その2割がどこから来たのかは説明できません。値は自社の過去3か月の実績から人が決める。条件の骨組みだけを借りる、という使い方に留めます。

持ち主と、決める場所。既存の整え方との関係

約束には持ち主が要ります。出す側に1人、受ける側に1人です。部門名で書くと、誰も自分のことだと思いません。役割名と個人名の両方を書くのが実務的です。役割名だけだと異動のときに引き継がれず、個人名だけだと退職した瞬間に持ち主が消えます。

決める場所は、新しい会議を作らないのが鉄則です。データの取り決めのための定例を新設すると、3か月で出席率が下がります。既にある運用の会議か、システムの変更を決める会議の議題に10分を足すのが続きます。約束の見直しは、変更を決める会議の中に置く。変更が議題に上がった場所で、約束も一緒に動かすのが自然です。

全社のデータの整え方との関係も、はっきりさせておきます。全社の分類や保管の規程は、どこに何があり、誰が持ち主で、どれくらいの期間残すかを決めるものです。データコントラクトは、その中の特定の1本の受け渡しについて、何を守るかを決めるものです。上下関係ではなく、粒度が違います。全社の規程が無くてもデータコントラクトは作れますし、逆に規程だけあっても受け渡しは壊れます。

組織の変更にも備えておきます。ある解説では、変化はコードと業務と組織図の3か所で同時に起きるため、いったん取った合意はすぐ古くなる、と指摘されています。対策は難しくありません。半年に一度、持ち主の欄だけを見直す。中身の見直しより先に、相手がまだそこにいるかを確かめる。これを飛ばすと、壊れた日に連絡先が誰も分からない状態になります。

小さく始める範囲。全社の前に、AIに渡している1つの流れから

全社で一斉に始めると、まず合意が取れません。採用の難しさを論じた解説では、完全に網羅するには組織全体の合意が要るが、組織全体の合意はめったに得られない、と書かれています。同じ解説には、データコントラクトは合意を作る道具ではなく、既にある合意を守らせる道具にすぎないという指摘もあります。合意が無いところに書式を持ち込んでも、何も決まりません。

到達点の目安も出ています。同じ解説が引用している例では、ある決済事業者が半年で約30本の取り決めを作り、サービス間のやり取りの5割から6割を覆ったとされています。先に動いたのはサービス間の連携を担う開発チームで、分析や機械学習の側は遅かったとも書かれています。半年で5割から6割が、うまくいった場合の到達点だと置いておくと、計画の目標が現実に寄ります。

• この本数と割合は、採用の難しさを論じた解説記事が別の事例として引用している数字です。一次の記事は取得できなかったため、桁の感覚として読んでください
• 自社の目標として使う場合は、全体の何割ではなく、決めた対象のうち何本という数え方にしてください。分母を全社に置くと、達成の見込みが立ちません

選ぶ1本は、次の3つを満たすものにします。壊れたときにいちばん困ること。AIに実際に渡していること。出す側の担当者と受ける側の担当者が、どちらも顔と名前で分かること。3つめが効きます。相手が分かっていれば、工程1と工程2の往復が数日で終わります。相手を探すところから始めると、そこで1か月が過ぎます。

最初の1本は、項目を10個以下に絞ります。全項目を入れたくなりますが、1本目の目的は守ることではなく、決め方と検査の回し方を1周させることです。1周してみると、自社では何が決まらないのかが分かります。だいたいは項目の意味で、そこが分かれば2本目以降は同じところに時間を置けます。

つまずく5つの型と、半年で見る数字

うまくいかない形は、だいたい5つに絞れます。どれも道具の性能ではなく、手をつける順番と範囲の問題です。

• 全項目を約束に入れる。守る手間だけが増え、使っていない項目の変更でも止まるようになる
• 道具から入る。検査の仕組みを先に入れても、約束の中身が無ければ何も検査できない
• 守れない時刻を書く。1か月で破られ、破られた瞬間に約束全体が守らなくてよいものになる
• 破ったときに責任を問う運用にする。次からは黙って変えられ、取り決めが無い状態より悪くなる
• 文書を作って終わりにする。機械が読める形で置かないと、半年で実態とずれ、ずれた文書が新しい混乱を生む

直し方はそれぞれ1行です。使っている項目だけに絞る。工程1と工程2に期間の半分を置き、道具はその後に選ぶ。上限はいちばん遅かった日から決める。破った回数だけを数えて、原因を人ではなく流れに置く。文書はソースコードと同じ場所に、機械が読める形で置く。どれも仕組みを触る前に決める類のことです。

効いたかどうかは、半年で4つの数字を見ます。取り決めのある流れの本数と、対象と決めた範囲のうち覆えた割合。検査で止まった件数を、出る前に止まったものと入ってから止まったものに分けた数。予告なしで変更された件数。そして、受ける側がおかしいと気づくまでにかかった時間です。

• 取り決めのある流れの本数と、決めた対象のうち覆えた割合
• 検査で止まった件数（出る前に止まった数と、入ってから止まった数を分ける）
• 予告なしで変更された件数
• 受ける側がおかしいと気づくまでの時間（前の半年と比べる）

読み方も先に決めておきます。止まった件数がゼロなら、検査が緩いか、対象の流れがそもそも安定している方です。前者なら線を締めます。予告なしの変更がゼロにならなくてよい。ゼロを目標にすると、出す側が変更そのものを申告しなくなります。見たいのは件数が減っているかと、気づくまでの時間が縮んでいるかの2つです。

この記事に出てきた言葉

最後に、この記事で使った言葉を短くまとめます。社内で説明するときに、そのまま読み上げられる長さにしています。

社内で説明するときは、この7つのうち最初の2つと、壊す変更の3つだけを先に伝えると通りやすいです。用語を全部そろえてから始める必要はありません。1本目の約束を作る過程で、必要な言葉だけが自然に共有されます。

まとめ

データコントラクトは、データを出す側と受け取る側のあいだで先に文書にしておく、二者間の約束です。全社の規程でも、持ち主を決める枠組みでもありません。書くのは7つで、項目の意味、型と取りうる値、欠けてよいか、更新の頻度と時刻、遅れの上限、変えるときの予告、破ったときの扱いです。作る順番は、受ける側が要る項目と用途を出し、出す側が出せる形と守れない項目を返し、合意を機械が読める形で1か所に置き、検査を自動で回し、破ったときの手順を決める、の5工程。詰まるのはほぼ最初の2工程で、そこは道具では解けません。AIに渡す流れでは壊れ方が静かになるので、検知は答えの側ではなく入力の側に置きます。項目の意味を決めるのは業務側の人で、AIに渡せるのは差分の要約と検査の下書きまでです。

始め方は1本からです。壊れたときにいちばん困り、AIに実際に渡していて、相手の顔と名前が分かる流れを1つ選び、項目を10個以下に絞って1周させる。半年で5割から6割という到達点が実例として報告されている以上、全社を一度に覆う計画は最初から立てないほうが進みます。覆う本数を増やすより、予告なしの変更が減っているか、受ける側が気づくまでの時間が縮んでいるかを見る。取り決めは合意を作る道具ではなく、既にある合意を守らせる道具です。合意そのものは、出す側と受ける側が同じ机で項目の意味を決めるところでしか生まれません。まずはその机を1つ作るところから始めてください。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。