仕事道具は「増やす」より「分ける」：ITエンジニアの道具箱を7つの棚で棚卸しし、乗り換えられる状態を保つ手順

エディタ、ターミナル、ノート、チャット、CI、AIエージェント。試したい道具は毎月のように増えるのに、増えたぶんだけ速くなった実感はない。この記事を読み終えると、自分の仕事道具を7つの棚に一気に棚卸しし、役割ごとに1つへ絞り、ツールが値上げ・終了・方針変更をしても乗り換えられる状態を、今日の5分から作り始められるようになります。

🧰 主役の紹介：「棚割り」——道具を機能ではなく役割で分ける

この記事の主役は棚割り（たなわり）です。一言で言えば、仕事道具を「機能」ではなく「仕事の中での役割」で分け、役割ごとに定位置を決めること。道具の数より先に、役割の数を決める考え方です。

日常の例えは、プロの厨房の「ミザンプラス（mise en place）」です。フランス語で「所定の位置に置く」という意味で、調理が始まる前に材料と道具を役割ごとの定位置に並べておく習慣を指します。プロの厨房が速いのは、高い包丁を持っているからではありません。包丁の場所、まな板の場所、味見用の皿の場所が決まっていて、考えなくても手が動くからです。逆に、どれだけ広い厨房でも、包丁が3本あってどれが切れ物か分からなければ、料理は遅くなります。

エンジニアの道具箱も同じ構造です。棚割りができていると、次の3つが起きます。

• 道具を増やしても、「どこに何があるか」で迷わなくなる
• 値上げ・サービス終了・方針変更があっても、役割単位で乗り換えられる
• 自分の道具を、チームに渡せる形（他人が再現できる形）で説明できる

逆に棚割りができていないと、道具を1つ足すたびに全部の配置を考え直すことになります。新しいAIツールを試すたびに「これまでの作業はどこでやるんだっけ」と迷い、設定ファイルの場所を探し、結局元のやり方に戻る。道具が増えているのに、仕事の速度は変わらないという現象は、たいていここから生まれます。

この図のポイントは、道具の数ではなく棚の数が先に決まっていることです。棚が同じなら、包丁が新しくなっても仕事は回ります。逆に、棚がないまま道具だけが増えると、増えた道具は「探し物」に変わります。

なお、この記事は一般的な整理の提案です。道具の選定は職種・チーム・契約・規制によって変わります。会社のセキュリティポリシーや契約条件がある場合は、そちらが常に優先です。

😓 動機：道具は「便利」で増えるのに、速くならないのはなぜか

思い当たる節から始めます。半年前に導入したツールの名前を、いま全部言えますか。無料トライアルのまま残っているサービス、チームの誰かが入れたまま誰も使っていないツール、理由は忘れたが外せないブラウザ拡張。道具は「便利そう」で増えるのに、速くなった実感は増えません。

しかも、いまは増える速度が上がっています。AIコーディングツール、エージェント、ノート、議事録、監視、CI、デザイン。毎月のように「これが新しい標準になる」という話が届きます。全部を試すのは不可能なうえ、試すこと自体に時間がかかります。ここで多くの人が誤解します。「情報収集が足りないから選べないのだ」と。しかし実際に足りないのは情報ではなく、道具を置く棚のほうです。

棚がない状態で新しい道具を入れると、何が起きるか。まず既存の作業と重複します。次に、どちらを使うべきかの判断が毎回発生します。最後に、両方の設定が中途半端なまま残ります。道具が1つ増えるたびに、判断の回数が増えていく。これが「便利なはずなのに遅い」の正体です。

🧪 仮説：速度を決めるのは道具の数ではなく、切替コストと出口の広さだ

仮説を立てます。仕事道具の速度は、道具の数ではなく、①切替コストの合計、②出口（データの可搬性）の広さ、③チームで再現できるか、の3つで決まる。役割ごとに1つへ絞り、出口で選び、設定をコードにすれば、道具が増えても遅くならない。

この仮説を4つの方向から確かめます。切替コストの研究、乗り換えの判断基準、7つの棚の実態、そして個人の道具とチームの道具の境界です。

🔬 検証1：道具を増やすと遅くなる——切替コストは「掛け算」で効く

最初に確かめるのは、道具を増やすと本当に遅くなるのか、という素朴な疑問です。結論から言えば、能力は足し算で増えるのに、切替のコストは掛け算で増えるため、ある地点から逆転します。

根拠は3つあります。1つ目は、実験心理学のタスク切り替え研究です。Rubinstein、Meyer、Evansらが2001年に発表した研究では、人間が2つの課題を切り替えるとき、課題そのものの処理に加えて「課題のルールを入れ替える」ための認知的コストがかかると報告されています。つまり、切り替えには必ず上乗せの時間が発生します。

2つ目は、中断からの復帰コストです。カリフォルニア大学アーバイン校のGloria Markらの一連の研究では、作業を中断された後、元の作業に完全に戻るまでに十数分から20分以上かかることがあると報告されています。ツールの切り替えは、中断を自分から起こしているわけです。エディタからタスク管理へ移り、戻ってくる。この往復に、私たちは毎回このコストを払っています。

3つ目は、AIツールに関する2025年の実験結果です。経験豊富なオープンソース開発者を対象にした実験で、AIツールの利用によってタスク完了が約19%遅くなった一方、本人たちは約20%速くなったと感じていた、と報告されています。ここから読み取れるのは、道具を足した効果は、体感よりも控えめに出るということです。道具の導入は能力の話である前に、切替の話なのです。

では、切替コストはどう減らすのか。打ち手は「減らす」「寄せる」「止める」の3つです。

この表の使い方は単純です。「切替が起きる場面」を上から潰していくだけで、道具の数は変えずに速度が戻ります。逆に、道具を増やす提案を受けたときは「どの切替が減るのか」を必ず聞く。答えられない提案は、たいてい切替を増やします。

この図で伝えたいのは、左の人物の能力が低いわけではない、ということです。同じ人物が、持つ数を変えるだけで右の状態になる。道具の選定とは、能力の問題ではなく配置の問題だと言い換えてもいいでしょう。

🔬 検証2：選ぶ基準は「機能」ではなく「出口」——3つの出口テスト

次に確かめるのは、道具を何で選ぶかです。機能表の比較は楽しいのですが、数年後には役に立たなくなります。機能は増え、料金は変わり、サービスは終わるからです。そこで残る基準が出口（でぐち）、つまり「この道具を使うのをやめたとき、中身をどれだけ持ち出せるか」です。

この考え方の土台には、Unix文化で長く語られてきた原則があります。データはコードより長生きするという原則です。エディタもサービスも数年で入れ替わりますが、書いた文章、設計の記録、設定、データは10年単位で残ります。だとすれば、道具を選ぶ基準は「いま何ができるか」ではなく「やめるときに何が残るか」であるべきです。

出口は、次の3つの質問でテストできます。

3つすべてに通る必要はありません。1つも通らない道具を「正本（しょうほん）」にしない、というのが実務的なラインです。正本とは、その情報の最終的な置き場所のことです。たとえばノートの正本をMarkdownのファイルにしておけば、ノートアプリを乗り換えても中身は残ります。逆に、独自形式のサービスを正本にしてしまうと、値上げのたびに「払うか、失うか」の選択を迫られます。

この図のポイントは、便利さで選ぶこと自体は間違いではないということです。間違いなのは、出口のない道具に正本を預けることです。便利さは使っている間だけの価値ですが、出口はやめた後にも効く価値です。

出口の考え方を、道具台帳という1枚のファイルにしておくと実務で使えます。道具の名前、棚、出口、代替手段、見直し時期の5項目だけです。

# tools.yml（道具台帳の最小形）
- name: ノート
  shelf: 残す
  tool: Markdownファイル（ローカル）
  exit: プレーンテキストなので常に取り出せる
  fallback: 任意のエディタ
  review: 2027-03

- name: タスク管理
  shelf: 残す
  tool: チームの課題管理サービス
  exit: CSVエクスポートとAPIあり
  fallback: リポジトリのIssue（一時退避）
  review: 2027-03

この台帳の効き目は、乗り換えの相談が「感情」から「手順」に変わることです。「このサービス高いね」で終わらず、「出口はCSVとAPI、代替はリポジトリのIssue、移行は半日」と話せるようになります。値上げの通知が来たとき、この1枚があるだけで判断が1回で済みます。

🔬 検証3：棚は7つで足りる——役割ごとに「定位置」を決める

ここからは棚の中身です。仕事道具を役割で分けると、読む・書く・動かす・確かめる・残す・つなぐ・任せるの7つにほぼ収まります。この7つは、仕事の流れ（理解して、作って、動かして、確かめて、残して、共有して、任せる）に対応しています。棚の数が仕事の責任の数と対応しているので、棚が増えるときは、仕事の責任が増えたときです。

この表は「どの製品を買うべきか」を決めるためのものではありません。いま持っている道具を、どの棚に置くかを決めるためのものです。実際に書き出してみると、棚が偏っていることに気づきます。読む道具が8個、確かめる道具が0個。書く道具は5個、残す道具は1個。偏りは悪ではありませんが、偏りに気づかないまま道具を足すのが問題です。

棚の使い方には、3つのルールがあります。1つ目は、1つの棚に正本を1つにする。同じ役割の道具を2つ持つのは自由ですが、正本は1つに決めます。2つ目は、棚をまたぐ道具は「主たる棚」を1つ決める。ノートとタスク管理の両方の顔を持つ道具は、どちらの正本なのかを決めておきます。3つ目は、棚が8つ目に増えるときは、仕事の責任が増えたかを確認する。AIエージェントを「任せる」棚として独立させたのも、丸投げの設計という新しい責任が生まれたからです。

この図のポイントは、それぞれの棚に「正本」が1つだけ入っていることです。道具は複数あってかまいませんが、正本が2つになると、どちらが最新かを確認する作業が毎回発生します。地味ですが、これが「探し物の時間」の最大の供給源です。

🔬 検証4：個人の道具と、チームの道具——線引きは「止まるかどうか」

最後に確かめるのは、どこまでを個人の道具にして、どこからをチームの道具にするかです。この線引きを間違えると、片側では属人化が起き、もう片側では自由度が失われます。

まず、両者の性質を並べます。

線引きの基準は、「あなたが明日いなくなっても、その道具がなければ仕事が止まるか」です。止まるならチームの道具です。止まらないなら個人の道具です。この基準で仕分けると、多くのチームで起きている誤りが見えます。個人の道具（自分のエディタの拡張機能、ローカルの設定ファイル、手元のスクリプト）がチームの必須手順に混ざっている。逆に、チームの道具であるべき開発環境の作り方が、各人のPCの履歴にだけ残っている。

チームの道具にする方法は、設定をコードにすることです。エディタの設定、シェルの設定、開発環境の定義を、Gitで管理するファイルに移します。開発環境そのものをコンテナの定義ファイルとして持つ方法も定着しており、環境構築の手順書を人間が読む文書から、機械が実行するファイルへ移せます。「12要素アプリ」として知られる設計の指針でも、開発環境と本番環境の差を小さく保つことが勧められています。環境の差は、バグの温床であると同時に、引き継ぎのコストだからです。

この図のポイントは、左側が「悪い人」の話ではないということです。個人の道具を磨くのは良いことです。問題は、それがチームの必須手順に混ざった瞬間に、他の人が扉を開けられなくなることです。個人の道具は学習の場、チームの道具は再現の場。役割が違うので、置き場所も分けたほうがうまくいきます。

📊 結果：道具は19個になり、迷う回数が半分になった

4つの検証を並べたので、最後に数字を置きます。先に断っておくと、以下は統計ではなく、道具箱の棚卸しを1回行った場合の想定記録です。数値そのものより、どの項目が動いて、どの項目が動かなかったかに意味があります。

最後の行をわざと残したのは、正直さのためです。棚卸しをしても、道具を覚える時間は減りません。減ったのは、探す時間と迷う時間です。ここを混同すると、「整理したのに速くならない」という誤った結論に着きます。速くなるのは手を動かす速度ではなく、動き出すまでの速度のほうです。

この図で言いたいのは、削って軽くすることが目的ではないということです。空けた時間をどこに回すかを決めないまま道具を減らすと、ただ手元が寂しくなるだけです。

📌 注目ポイント：記事の結論を5点に絞る

ここまでの内容を、先に短く並べます。どれも「道具を買い替える」話ではなく、置き場所を決める話です。

この5点は、どれも地味です。地味ですが、同じ棚卸しを半年後にもう一度やったときに、同じ結論が出るのがこの考え方の強みです。流行のツール名を並べた記事は半年で古びますが、棚と出口の話は古びません。

💭 考察：棚割りは「減らす」技術ではなく「戻れる場所を作る」技術

ここで一段深く考えます。棚卸しというと、まず「道具を減らす」ことだと思われがちです。しかし実際に効いていたのは、減らすことではありません。思考が中断したときに、戻ってこられる場所を決めておくことです。

理由は、中断のコストの構造にあります。Gloria Markらの研究では、作業を中断された後、元の作業に戻るまでに長い時間がかかると報告されています。ここで失われているのは、作業そのものの時間より、「いま何をしていたか」を再構築する時間です。だとすれば、切替をゼロにしようとするより、戻り先を一意にしておくほうが効きます。「調べ物はブラウザのあの場所、記録はあの1ファイル、タスクはあの1画面」。戻り先が決まっていれば、再構築が「開くだけ」になります。

この考え方から、棚割りの原則が4つ導けます。

もう1つ、期待値を正しく持つための話を書いておきます。仮に道具が2倍速くなっても、仕事全体が2倍速くなることはありません。たとえば仕事の半分が「手を動かす作業」で、残りの半分が「考える・確かめる・人に渡す」だとします。作業の速度が2倍になっても、全体は次の式のとおりです。

全体の速さ ＝ 1 ÷（0.5 ＋ 0.5 ÷ 2）＝ 約1.33倍

つまり、半分を2倍にしても全体は3割しか速くならない。この計算の形は、並列化の効果の上限を論じたアムダールの法則と同じです。ここから言えるのは、道具の選定で追えるのは最後の3割だということです。残りの7割は、考える速さ、確かめる速さ、渡す速さで決まります。道具箱を整えるのは、その7割を削るためではなく、7割に時間を回すためなのです。

💡 活用事例：3つの現場で、道具箱をどう整えたか

ここからは3つの物語です。特定企業の実績ではなく、再現しやすい想定シナリオとして書きます。数値は現実に起こりうる想定値です。

1つ目の話で効いたのは、作業用ツールを縛らなかったことです。正本を1つに固定しただけで、日々の道具は自由にしたまま事務の迷いが消えました。整える対象は「正本」だけであり、それ以外は触らない。これが棚卸しの成功率を上げます。全部を一気に統一しようとすると、途中で必ず止まります。

2つ目の話の土台になっているのは、開発環境を定義ファイルとして共有するという、いま広く使われているやり方です。Docker社のComposeや、Microsoft社が提唱し仕様が公開されているDevelopment Containers（開発環境の構成を定義ファイルで宣言する仕組み）を使うと、「環境の作り方」を人間が読む文書から機械が実行するファイルへ移せます。12要素アプリとして知られる設計の指針でも、開発環境と本番環境の差を小さく保つことが勧められています。環境の差はバグの温床であり、同時に引き継ぎのコストだからです。ここで効くのは、手順書を丁寧に書き直すことではなく、手順そのものを実行可能な形に置き換えることでした。

3つ目の話は、道具箱の考え方がセキュリティの運用にも効く例です。「残す」棚に入っている道具は、たいてい顧客データや認証情報に触れます。だから棚卸しの対象は、道具の数ではなく権限の一覧であるべきです。逆に「読む」「書く」の棚の道具は、失われても仕事が止まりにくいので、管理の重さを下げられます。全部を同じ強さで管理すると、管理そのものが破綻する。棚が分かれていると、力の入れどころも分かれます。

最後に、実在する取り組みから1つ。Thoughtworks社が半年ごとに公開しているTechnology Radarは、技術やツールをAdopt（採用）・Trial（試用）・Assess（評価）・Hold（保留）の4つのリングに分類し、半年ごとに位置を見直すという運用を続けています。これは組織レベルで行われている棚卸しそのものです。注目したいのは、リングの位置が「良い・悪い」ではなく「いまどう関わるか」を示している点です。Holdは失敗の烙印ではなく、いまは触らないという配置にすぎません。個人の道具箱でも同じで、外した道具は捨てるのではなく、いまの棚から降ろすだけと考えれば気楽です。

✅ 要点まとめ：持ち帰るならこの6つ

道具箱の話は、つい「おすすめの道具一覧」に流れがちです。そうではなく、自分の道具をどう配置するかという視点で持ち帰ってください。ここまでの内容を、別の言い方で圧縮します。

• 道具が増えて遅くなるのは、能力ではなく切替が増えるから。まず「どの切替を消すか」で考える
• 棚は7つ（読む・書く・動かす・確かめる・残す・つなぐ・任せる）。増やすときは責任が増えたかを確認する
• 道具を選ぶときは機能表ではなく出口を見る。取り出せない形式は最終置き場にしない
• 個人の道具は磨いてよい。ただしチームの必須手順に混ぜない。止まるかどうかが線引きの基準
• 中断のコストは「戻り先を探す時間」に宿る。だから正本を1つに決めるだけで効く
• 道具で速くできるのは仕事の一部。残りは考える・確かめる・渡す時間に残しておく

🚀 取り込み方：今日5分、今週1ファイル、今月1回の見直し

ここからは、明日から使うための段階です。道具箱の整理は「時間ができたらやる」ものに見えて、実際に効くのは対象を絞った小さな一歩です。だから今日の5分から始められます。

今日（5分でできること）：いま使っている道具を、紙でもテキストでもよいので7つの棚に振り分けて書き出します。道具名だけで十分です。書き出した瞬間に「確かめる」の棚が空いている、といった偏りが見えます。偏りを見つけることが今日の目的で、直すのは後回しでかまいません。

今週（1ファイル作る）：書き出した道具を、tools.yml のような1つのファイルに移します。項目は名前・棚・出口・代替手段・見直し時期の5つだけ。これが道具台帳になります。あわせて、出口テストで1つも通らない道具を1つだけ選び、正本から外して作業用に降格します。ここで全部を直そうとしないことが、続けるコツです。

今月（乗り換えを1つ試す）：台帳を見て、いちばん出口が狭い道具を1つ選び、代替へ移す練習をします。移す対象は、仕事のクリティカルパスから外れたものでかまいません。目的は引っ越し自体ではなく、「乗り換えられる」という状態を一度体験しておくことです。加えて、チームで使っている道具については、開発環境や手順がファイルとして共有されているかを確認します。個人のPCの履歴にしか手順がない項目が1つでもあれば、それが今月の宿題です。

🔥 ハマりポイント：道具箱が崩れる5つのパターン

ここからは、実際に崩れる場面を並べます。どれも「知らないうちに起きる」タイプの失敗で、原因は意志の弱さではなく配置の設計にあります。まず1枚の絵で、この状態を表しておきます。

この図のポイントは、道具の数が問題なのではなく、絡まりが問題だということです。道具は1本ずつは良いものです。絡まるのは、置き場所が決まっていないからです。

その1：オールインワンに寄せれば解決すると思い込む

症状は、1つのサービスに寄せたとたん、代わりになるものがなくなること。原因は、統合が「切替の削減」と「出口の喪失」を同時に起こすからです。対処は、寄せてよい棚と寄せてはいけない棚を分けること。記録の正本は寄せてよいが、出口のない形式には寄せない。統合の便利さは、やめる自由と引き換えになっていることを覚えておきます。

その2：無料枠が積み上がり、いつの間にか有料化している

症状は、クレジットカードの請求を見て初めて気づく。原因は、道具が「無料で試す」段階のまま台帳に載っていないこと。対処は、試す段階の道具も台帳に「評価中」として載せること。棚卸しの対象から外れた道具は、たいてい評価中のまま残ります。評価中は棚ではなく状態なので、状態を書く場所を決めておくのが正解です。

その3：手順書を丁寧に書き直して満足する

症状は、半年後にその手順書が誰にも読まれず、内容も古くなっている。原因は、手順が人間の記憶と文書に依存していること。対処は、実行できる形に移すこと。設定ファイル、コンテナ定義、スクリプト。文書は「なぜ」を書き、手順は「実行できる形」に置く。この分担にすると、更新すべき箇所が減ります。

その4：道具を減らすこと自体を目的にする

症状は、手元が寂しくなったのに仕事は速くならない。原因は、削ることで学習の機会まで削っていること。対処は、削る対象を「正本と重複」に限定すること。試すための道具は、棚の外に置いてかまいません。個人の道具は学習の場なので、数を絞る必要はないのです。

その5：チームの道具を個人の判断で置き換える

症状は、ある日ほかのメンバーの環境で動かなくなる。原因は、チームの必須手順に個人の道具が混ざること。対処は、置き換える前に「これは止まるかどうか」を確認すること。止まるなら、置き換えではなく提案として扱います。個人の道具は自分の机の上、チームの道具は共有の棚。この線を越えるときは、必ず一言添える習慣をつけておくと事故が減ります。

🔄 他の選択肢との比較：道具箱の整え方は4通り

最後に、整え方そのものを比べます。棚割りは唯一の正解ではありません。

正直に書くと、探索の時期に「何も変えない」は正しい選択です。新しい道具を試す量がそのまま学習量になる段階では、整理は後回しでよい。危ないのは、探索の時期が終わったのに気づかず、同じ勢いで増やし続けることです。判断の目安は、「新しい道具を試すとき、既存のどの道具が置き換わるかを言えるか」。言えなくなったら、それが棚卸しの合図です。

📅 今後の展望：道具は「人を介さず使われる」方向へ動いている

道具箱の話は、いま少しずつ前提が変わりつつあります。理由は、道具を使うのが人間だけではなくなったからです。Anthropic社が2024年に公開し、その後に業界で広く採用が進んだModel Context Protocol（AIモデルと外部ツールをつなぐための共通仕様）のように、AIに道具を使わせるための共通の口が整備されてきました。CLIやAPIを持つ道具はAIからも扱えますが、GUIしか持たない道具は扱いにくい。つまり、出口テストの②「自動化の入口」が、人間の利便性だけでなく、AIから使えるかどうかの条件にもなりつつあります。

依存関係の扱いも厳しくなっています。ソフトウェア部品表（SBOM）の整備が進み、EUではサイバーレジリエンス法のような製品のセキュリティ要件を定める枠組みが成立し、段階的に適用が進むとされています。加えて、2023年にHashiCorp社がTerraformなどのライセンスを変更したことをきっかけに、OpenTofuのようなフォークが生まれた出来事は、道具は突然変わるという現実を広く知らしめました。

とくに2つ目の問いが、この記事を書いた理由です。AIに仕事を任せる流れが進むほど、「どの道具に、何を、どこまで任せるか」を人間が説明できる必要が出てきます。任せる相手は、棚と出口が見えている道具箱のほうが扱いやすい。自動化は、人間が決めた構造を機械に渡す作業です。構造がないまま自動化すると、速いだけの無秩序ができあがります。だから、道具箱を整えるのは、AI時代の準備でもあるのです。

まとめ

仕事道具は、増やすほど強くなるように見えて、実際は置き場所が決まっているほど速くなります。プロの厨房が速いのは高い包丁を持っているからではなく、包丁の場所が決まっているからでした。同じことがエンジニアの道具箱にも起きます。

だから、まず道具を7つの棚に振り分ける。正本を1棚に1つだけ置く。選ぶときは機能表ではなく出口を見る。個人の道具とチームの道具は、自分が消えたときに止まるかどうかで分ける。この4つを決めておけば、道具が値上げしても、終了しても、AIに渡すことになっても、あなたは落ち着いて次の一手を選べます。

これを読んだあなたは、次に新しいツールを試したくなったとき、「これまでのどの道具が置き換わるか」を先に言えるようになるはずです。そして、道具箱を開けたときに、どこに何があるかを迷わず答えられるようになります。

参考文献

1. The Twelve-Factor App — 設定をコードに置く考え方（III. Config）と、開発環境と本番環境の差を小さく保つ指針（X. Dev/prod parity）を確認（2026年9月12日参照）
2. Development Containers — 開発環境の構成を定義ファイルで宣言し、チームで共有する仕様（2026年9月12日参照）
3. Docker Docs — コンテナによる環境の再現、Composeによる複数コンテナの定義方法（2026年9月12日参照）
4. NixOS — 環境と依存関係を宣言的に固定し、再現可能にする仕組み（2026年9月12日参照）
5. Thoughtworks Technology Radar — Adopt・Trial・Assess・Holdの4リングで技術を定期評価する運用（2026年9月12日参照）
6. Model Context Protocol — AIモデルと外部ツール・データを接続するための共通仕様（2026年9月12日参照）
7. Git — 設定・手順・環境定義をバージョン管理下に置くための基本（2026年9月12日参照）
8. Semantic Versioning — 依存する道具の更新がどの種類の変更かを判断する基準（2026年9月12日参照）
9. Keep a Changelog — 道具や自作物の変更履歴を残す書式（2026年9月12日参照）
10. Open Source Initiative — ライセンスの違いと、道具の利用条件を確認するための基本情報（2026年9月12日参照）
11. SPDX — ソフトウェア部品表（SBOM）で用いられるライセンス表記の標準（2026年9月12日参照）
12. CycloneDX — SBOMを生成・共有するための仕様（2026年9月12日参照）
13. NIST SP 800-218（Secure Software Development Framework） — 開発に組み込むセキュリティ実践の整理（2026年9月12日参照）
14. HashiCorp — ライセンス変更の告知と、その後の方針に関する公式情報（2026年9月12日参照）
15. OpenTofu — ライセンス変更をきっかけに生まれたオープンソースのフォーク（2026年9月12日参照）
16. IPA（情報処理推進機構） — 情報セキュリティ10大脅威や、組織におけるIT利用の注意点（2026年9月12日参照）
17. 総務省 — テレワークやクラウドサービス利用に関する調査・ガイドライン（2026年9月12日参照）