はじめに
こんにちは、アドベントカレンダー初日を担当させていただきます！
記事を書くのは今回が初めてなので、かなり拙い文章・構成になっています..
目を瞑っていただければ幸いです。
2025年もいよいよ最終局面に突入！！
個人的には去年の今頃はまだ制服を着ていたなんて信じられないです。
いろんなことがあった2025年、終わってしまうのは少し寂しい気もしますね。
ここらで、この記事の本題に入りたいと思います。
今回私が取り上げるのは、情報の特性と特性の技術的利用です。
まだまだ駆け出しの自分の興味・関心の範疇なので味気ないと思いますが、
最後まで読んでくれると嬉しいです！！
動機
今回この内容について記事を書きたいなと思った主な理由についてです。
記事を書くうえで自分が最初に思っていたことは...
- ゼロに等しい情報の知識を付け焼き刃ながら補いたい！
- この記事を書く体験を通して知識獲得したい！
- 自分の作るプロダクトに今後活かしたい！
こんな感じです。
所属団体での活動や個人開発を進める上で、情報の特性に関する最低限の知識を持っておくことが、プロダクトの仕組みや設計の意図を深く理解し、ユーザーの使用体験を高める助けになると考えました。この知識は、情報分野を扱う上で汎用性が非常に高いと思い、今回取り上げることにしました。
情報の3つの特性
情報の主な特性には、残存性（消えない）、複製性（容易にコピーできる）、
伝播性（広く伝わる) があります。
多分みなさん、「そらそやろ」ってなるのではないでしょうか。
よく考えたら当たり前のことですよね。
当たり前すぎてあまり気にしていなかった情報の特性ですが、
特性があるってことは長所にも短所にも成り得るということです。
特性の促進・抑制にどんな技術が生み出され、利用されているのか見ていきます！
残存性
- 残存性とは
情報における残存性とは
「情報が完全消えることなく、形を変えて存在し続ける特性」のことです。
これは、情報を伝えても発信元に残る、一度生成された情報は消えない、
削除しても記憶に残る、といった特徴として現れます。
SNS上での悪口の書き込みの注意でよく聞くアレですね。
ソフトウェア開発の工程（コーディング、設計）において「情報の残存性」は、
主に知識の共有、変更履歴の保持、そして機密情報の管理という観点で重要になります。
情報の残存性を促進するプロダクト・ツールは「知識の蓄積と共有」を助け、
抑制するものは「機密情報の漏洩リスク低減」に役立ちます。
残存性を促進するプロダクト・ツール
-
バージョン管理（Git/GitHub)
コードの全ての変更履歴を永続的に記録
いつ、誰が、なぜ変更したかを残存させ、過去の状態への復元を可能にする
-
ドキュメント・知識共有 (Notion)
設計図、アーキテクチャ、決定事項、手順などの非コード情報を
構造化して残存させてチーム全体での知識共有を促進する
-
コードレビュー (Pull Request/Merge Request機能)
コード変更に関する議論や、設計上の判断を
レビューコメントとしてコード変更と紐づけて残存させる
残存性を抑制するプロダクト・ツール
-
機密情報管理 (HashiCorp Vault/AWS Secrets Manager)
APIキー、データベースのパスワードなどの機密情報（シークレット）を、
コードや設定ファイルに直接残存させず、動的に取得し利用後に破棄させる
-
一時的なファイル/キャッシュ (ビルドツールのキャッシュクリア機能)
ビルドプロセスで生成された一時的な中間ファイルやログが、
開発環境やCI/CDパイプライン上に残り続けることを抑制し、
セキュリティとディスク容量を管理する
-
ローテーション (認証情報ローテーション機能)
データベースのパスワードなどの認証情報を定期的に自動更新し、
もし古い認証情報がどこかに残存していても、それが使えないように残存性を無効化する
複製性
1.複製性とは
情報における複製性とは「情報が容易にコピーできる特性」のことです。
これは元の情報と全く同じものが、劣化することなく短時間で大量に作れる
といった特徴として現れます。
印刷やコピー＆ペーストもこの中の一つですね。
2.プロダクト開発時の情報の複製性
ソフトウェア開発の工程において「情報の複製性」は、主にコードの再利用や環境の再現を
促進する側面と、機密データの拡散を抑制する側面があります。
促進するプロダクト・ツールは開発効率を高めるために情報の「コピー＆ペースト」や
「共有」を意図的に容易にし、抑制するものはセキュリティリスクを避けるために
情報の「拡散」を意図的に難しくします。
複製性を促進するプロダクト・ツール
-
バージョン管理 (Git/GitHubの
fork・clone機能)公式リポジトリの内容を、自分のアカウントまたはローカルPCに完全に複製（コピー）し、オリジナルのリポジトリに影響を与えることなく自由に複製物を編集できる
-
コード生成/補完 (GitHub Copilot/Code LlamaなどのAIコード生成ツール)
既存の大量のコードパターンから学習し、開発者の入力に対して最適なコードブロックを提案・複製して挿入これにより、定型的なコードの複製・記述を大幅に短縮する
-
仮想化・コンテナ (Docker/Vagrant)
開発環境、実行環境全体を定義したイメージとして複製し、
どのPCやサーバーでも完全に同じ環境を再現できるようにする
このほかにも身近なものとして
「フレームワークのテンプレート機能」「ライブラリ管理(パッケージマネージャー)」
などが挙げられます。
複製性を抑制するプロダクト・ツール
-
データ漏洩防止 (DLPソリューション)
ソースコードや機密情報（顧客データ、APIキーなど）が、外部メディア（USBメモリ）、メール、ネットワーク、クリップボードなどを経由して外部に複製される操作を
リアルタイムで監視し、ブロックする
-
認証情報管理 (シークレット管理ツール)
パスワードやAPIキーなどの機密情報を、コードや設定ファイルに直接書き込む
（＝複製して残す）ことを回避し、動的なアクセス制御によって
情報への恒久的な複製を抑制する
-
DRM/IRL (情報権限管理（IRM）ソフトウェア)
設計書や仕様書などのドキュメントに対し、閲覧・編集・印刷・コピーといった
操作の権限を詳細に設定し、許可されていないユーザーによる情報の複製や拡散を
技術的に抑制します。
これらは、開発における効率とセキュリティという
相反する要件のバランスをとる上で不可欠なものです。
特に、Dockerのように環境の複製性を促進するツールと、
DLPのようにデータの複製性を抑制するツールが、開発現場では両立して使われています。
伝播性
1. 伝播性とは
情報における伝播性とは「情報が人々の間を容易に、速く広まっていく特性」のことです。
それこそ、www(World Wide Web)などの普及によって、
情報が瞬時に世界中へと拡散されるようになりました。
インターネット上の拡散力は他のメディアに比べて圧倒的ですよね。
2. プロダクト開発時の情報の伝播性
ソフトウェア開発における「情報の伝播性」は、情報が拡散したり、
共有されたりする度合いを指します。
促進プロダクト・ツールは「知識や変更をチーム全体に効率的かつ迅速な共有」、
抑制は「機密情報や未承認の変更が不適切に拡散の防止」を目的とします。
伝播性を促進するプロダクト・ツール
-
モニタリング・ログ管理 (Datadog/Prometheus)
サーバーやアプリケーションから発生するログ、メトリクス、トレースなどの情報を
集約し、ダッシュボードやアラート機能を通じて全体へ可視化して伝播させる
-
開発者ポータル (Backstageなどの内部ポータル)
チーム内のサービス一覧、API仕様、担当者、ドキュメントなど、散在しがちな情報を
一箇所に集約し、検索を通じて必要な情報が素早く開発者に伝播させる
-
APIゲートウェイ (Amazon API Gateway)
バックエンドサービスの機能や仕様変更を、APIゲートウェイを通じて
外部の利用者に一元的に公開し、情報の消費と伝播を管理する
伝播性を抑制するプロダクト・ツール
-
アクセス制御 (IAM (Identity and Access Management) )
誰がどのリソース（コード、設計書、サーバー）にアクセスできるかを細かく制限し、
機密情報や設定情報が権限のないユーザーに伝播することを抑制する
-
データマスキング/匿名化ツール (個人情報保護ツール)
本番環境のデータ（個人情報など）を開発環境やテスト環境に伝播させる際、
マスキング（仮データ化）を施すことで、機密性の高い情報の伝播を抑制する
-
ネットワーク分離 (VPC (Virtual Private Cloud) やファイアウォール)
開発環境や本番環境などのネットワークセグメントを分離し、
ある環境の情報や障害が意図せずに他の環境へ伝播することを防ぐ
まとめ
今回は情報の特性に関わるプロダクトやツールについて学習してきました！！
自分たちが作成したプロダクトのFBをユーザから受けることで、
必要と感じる考え方や仕組みが存在すると感じる場面がありました。
プロダクト作成の途中では必要と感じないものでも、
世の中の人に提供するには「何か」が欠けている。
今回記事を書いてみて「情報の特性」の知識をつけることで、
そんな部分に少し気づきやすくなるのかなと思いました。ちょっと言い過ぎかも...
この特性を理解することで、開発者が単に機能を作るだけでなく、
ユーザーのデータに対する『責任』と『信頼』を設計し、
ユーザ体験の向上を図れるのではないでしょうか。
あとがき
「調べればわかるよ」って内容が多かったと思いますが..
そこのところは申し訳ないです。
今回の記事を書く経験を活かして、学んだことをこれからもっとアウトプットしていきます。ちなみに、年末に個人開発として人に使ってもらえるプロダクトを作成しようと計画しています。結構本格的に(クオリティは妥協しつつ...)
自分としては、この記事を書く中で知らなかった分野の知識を知れたり、
これから身につけるべき知識を知れたりいいことづくめでした！
この記事の内容自体も全てを消化しきれているわけではないので、しっかり反芻します！
みなさんがこの記事を読むことでプラスの影響を受けられたらいいなと思っています。
最後まで読んでくださりありがとうございました！！！！