条件の変更を読むときに見る箇所
全文は読めないので、見る箇所を決めました。

この記事の結論
- 全文は読まない。見る箇所を決める
- 入力した内容の扱いを先に見る
- 変更履歴があれば、差分だけ読む
- 全文は読まない。見る箇所を決める
- 入力した内容の扱いを先に見る
- 変更履歴があれば、差分だけ読む
条件の文書は長い。全部読むのは無理なので、見る箇所を決めた。
全文を読もうとして止まった
最初は通して読もうとしていた。
- 量が多く、途中でやめる
- 読んでも、どこが重要か分からない
- 結局、読んだつもりになる
3つ目が一番危ない。読んだつもりの箇所が、確認できていない。
見る箇所を決めた
いまは、4箇所だけ見ている。
- 入力した内容がどう扱われるか
- 商用で使えるか
- 出力したものの権利
- 保存される期間
1つ目を最初に見る。仕事で扱う内容を入れる場合、ここが判断を分ける。
入力の扱いを見る
何を確認するか、具体的に書く。
- 学習に使われるか
- 人が見る可能性があるか
- 設定で変えられるか
3つ目を確認する。既定では使われる設定になっている場合がある。
商用の可否
仕事で使う場合、必ず見ている。
- 商用で使えると書いてあるか
- 条件が付いていないか
- 有料の契約が必要か
2つ目を見落としやすい。使えるが、表示が必要などの条件がある。
出力の権利
作ったものをどう扱えるかも見る。
- 誰のものになるか
- 独占できるのか
- 同じものが他に出る可能性があるか
3つ目も確認する。同じ指示で、似たものが出る可能性がある。
保存される期間
データの扱いも見ている。
- いつまで保存されるか
- 消せるのか
- 消したら、本当に消えるのか
2つ目を確認する。消せない仕組みだと、入れる内容を選ぶ必要がある。
変更履歴を使う
更新されたときは、差分だけ読む。
- 変更履歴があるか探す
- あれば、変わった箇所だけ読む
- 無ければ、見る箇所だけ読み直す
2つ目が最も速い。全文を読み直す必要が無くなる。
公式の記述
料金表の「から」に注意する。Claudeの公式一覧で Haiku 5.5 は「From $0.10 / input MTok」と書かれている。他のモデルには「から」が付いていない。
この一語が、条件によって単価が上がることを示している。実際、10万トークンを超える要求では入力 $0.50・出力 $2.50 になる。
条件の変更を読むときに見る箇所は、だいたいこの種の一語だ。
- 「から」「最大」「標準で」 … 条件によって変わる
- 「より早くはしない」 … 約束の下限であって、予定日ではない
- 「独自の日程を設定する」 … その提供先では別の条件になる
出典: Anthropic「Models overview」(2026年10月12日確認)
履歴が無い場合
履歴が無い場合の対処も決めた。
- 以前の版を保存しておく
- 新しい版と見比べる
- 差分を自分で出す
1つ目を習慣にした。保存しておかないと、比べられない。
保存のしかた
条件の文書は、控えを取っている。
- 確認した日の版を保存する
- 日付を名前に入れる
- どの箇所を確認したか記録する
3つ目を書く。確認した箇所が分かれば、再確認の範囲が決まる。
読み方の順番
読むときの順番も決めている。
- 目次を見る
- 該当する見出しを探す
- その節だけ読む
1つ目から始める。目次があれば、探す範囲が絞れる。
探すのを頼む
長い文書は、探すのを頼んでいる。
- 「この条件に該当する箇所を探して」と頼む
- 該当箇所を引用させる
- 引用を元の文書で確認する
3つ目を必ずやる。探すのは頼んでも、読んで判断するのは自分でやる。
判断は自分でする
要約だけで判断しないようにしている。
- 要約は、読む前の下見として使う
- 該当箇所は、原文で読む
- 判断は、原文を読んでから
3つ目が原則だ。条件は、言い換えると意味が変わる。
分からない場合
読んでも分からない箇所もある。
- 提供元に問い合わせる
- 回答を記録に残す
- 分からないまま使わない
3つ目を守っている。条件が不明なものは、仕事で使わない。
仕事で使う場合
案件で使う場合は、さらに慎重にしている。
- 依頼元に、使う旨を伝える
- 条件を確認した日を記録する
- 依頼元の資料は入れない
3つ目が原則だ。他社から受け取った資料は、自分の判断で渡せない。
確認の周期
一度読んで終わりにしない。
- 年に1度、見る箇所を読み直す
- 更新の連絡が来たら、差分を読む
- 確認した日を記録する
1つ目を予定に入れた。連絡が来ない変更もある。
読まない箇所
読まないと決めた箇所も書いておく。
- 一般的な免責の記述
- 準拠法や管轄の記述
- サービスの説明部分
3つ目は、条件ではなく説明なので、判断に関わらない。
あわせて読む
- 使っているサービスの条件を、まとめて確認した — 半年ぶりに全部読み直しました。変わっていた点を記録します。
- AIに関する決まりごとで、使う側として知っておいたこと — 法律の専門家ではありませんが、使う立場で押さえておくべき点を整理しました。
- 「AIで仕事がなくなる」という話を、自分の仕事で検証した — 不安を煽る話も、楽観的な話も見ます。自分の作業で実際に何が変わったか記録しました。
まとめ
- 全文は読まない。見る箇所を4つに絞る
- 入力した内容の扱いを、最初に見る
- 商用可でも、条件が付いている場合がある
- 確認した日の版を保存し、次は差分だけ読む
- 探すのは頼んでも、判断は原文を読んでからする
新しい記事が出たら、ブラウザの通知でお知らせします。
メールアドレスの登録は要りません。いつでも止められます。
関連記事
RELATED
2年前に兆候はあった。直せなかったのは、決められなかったから
PHP財団が、今回の脆弱性の修正が遅れた理由を自ら書いています。技術ではなく、決め方と人手の問題でした。AIで足りない部…
デジモン公式が、エンジニアに感謝した。その裏で何人が起きていたか
PHPの騒動で、デジモン公式がエンジニアへの感謝を投稿して話題になりました。PHP財団の声明と並べると、感謝されている人…
破れると示したのもAIだった。攻撃側の話を書いた2日後に、逆側が出てきた
PHPの脆弱性を最初に見つけたのはAIでした。過去10年のすべてのPHPが対象で、WordPressでの実証も済んでいま…