diff --git a/content/ja/cluster.md b/content/ja/cluster.md
index 4d3e73051f..7673d7f283 100644
--- a/content/ja/cluster.md
+++ b/content/ja/cluster.md
@@ -2,13 +2,12 @@
 title: クラスター
 status: Completed
 category: コンセプト
-tags: ["インフラストラクチャ", "基礎", ""]
+tags: ["インフラストラクチャ", "基礎", "アーキテクチャ"]
 ---
 
-クラスターは、共通の目的に向けて連携して働くコンピューターやアプリケーションのグループです。
-クラウドネイティブコンピューティングの文脈では、この用語は通常[Kubernetes](/ja/kubernetes/)に適用されます。
-Kubernetesクラスターは、通常異なるマシン上でそれぞれのコンテナ内で実行される一連のサービス（あるいはワークロード）です。
-これらすべての[コンテナ化](/ja/containerization/)されたサービスの集合がネットワーク上で接続され、クラスターを形成しています。
+クラスターは、共通の目的に向けて連携して働く[ノード](/ja/nodes/)と呼ばれるコンピューターやアプリケーションのグループです。
+クラウドネイティブコンピューティングでは、この用語は通常[Kubernetes](/ja/kubernetes/)に適用されます。
+これは、ノードがより密結合している特定の種類の[分散システム](/ja/distributed-systems/)として捉えることができます。
 
 ## 解決すべき問題はなんですか
 
diff --git a/content/ja/digital-certificate.md b/content/ja/digital-certificate.md
new file mode 100644
index 0000000000..bf23ea546c
--- /dev/null
+++ b/content/ja/digital-certificate.md
@@ -0,0 +1,23 @@
+---
+title: デジタル証明書
+status: Completed
+category: テクノロジー
+tags: ["セキュリティ", "", ""]
+---
+
+(デジタル)証明書、しばしば公開鍵証明書やSSL証明書とも呼ばれるものは、ネットワーク上の通信を保護するために使われるデジタル文書です。
+証明書により、通信相手が本当にその主張どおりの存在であることを知ることができます。
+また送受信するデータを暗号化することで、通信が第三者に覗かれないようにし、プライバシーを保つことも可能にします。
+
+## 解決すべき問題はなんですか
+
+デバイスがネットワーク上で通信するとき、特定のデバイスがその名乗っている通りの存在であるという保証は、本質的には存在しないです。
+さらに、任意の2つのデバイス間のトラフィックが第三者に傍受されないという保証もないです。
+したがって、あらゆる通信は傍受される可能性があり、ユーザー名やパスワードのような機密情報が漏洩するリスクがあります。
+
+## どのように役に立つのでしょうか
+
+証明書を利用する現代のメールクライアントは、送信者の身元が正しいかどうかを通知することができます。
+ウェブブラウザも同様であり(アドレスバーの前に表示される小さな鍵アイコンを見てください)、送信者の正当性を示します。
+一方で、証明書はインターネット上のエンティティ間の通信を暗号化するためにも用いられます。
+証明書は、通信を傍受した者が実際にデータを読み取ることをほぼ不可能にする暗号化手法を提供します。
diff --git a/content/ja/nodes.md b/content/ja/nodes.md
index 0db4e3e783..3360ad3d81 100644
--- a/content/ja/nodes.md
+++ b/content/ja/nodes.md
@@ -2,7 +2,7 @@
 title: ノード
 status: Completed
 category: コンセプト
-tags: ["インフラストラクチャ", "基礎", ""]
+tags: ["インフラストラクチャ", "基礎", "アーキテクチャ"]
 ---
 
 ノードとは、他のコンピューター、つまり他のノードと協力して共通のタスクを達成するコンピューターのことです。
diff --git a/content/ja/platform-engineering.md b/content/ja/platform-engineering.md
new file mode 100644
index 0000000000..d765b89f19
--- /dev/null
+++ b/content/ja/platform-engineering.md
@@ -0,0 +1,21 @@
+---
+title: プラットフォームエンジニアリング
+status: Completed
+category: ["方法論", "プラットフォーム"]
+---
+
+プラットフォームエンジニアリングとは、ソフトウェア開発者を支援するツールとプロセスを構築する技術です。
+開発者がソフトウェアを作る過程全体で必要とするものを満たすように設計されたセルフサービスステーションを作るようなものです。
+これらのツールとワークフローを提供することで、プラットフォームエンジニアリングは開発者がより速く、より効率的に作業できるようにします。
+
+## 解決すべき問題はなんですか
+
+プラットフォームエンジニアリングは、遅く非効率なソフトウェア開発という課題に取り組みます。
+かつて開発者は、環境構築やツール設定のような反復的な作業に多くの時間を費やしていました。
+プラットフォームエンジニアリングはこれらのプロセスを合理化し、開発者が革新的なコードを書くという本質的な作業に集中できるようにします。
+
+## どのように役に立つのでしょうか
+
+プラットフォームエンジニアリングは、あらかじめ構築されたツールキットを開発者に提供することでソフトウェア開発の非効率性に対処します。
+このツールキットは、しばしばInfrastructure as a Service ([IaaS](/ja/infrastructure-as-a-service/))や[ベアメタル](/ja/bare-metal-machine/)上に構築されており、共通の作業を効率化するツールと自動化されたプロセスを含みます。
+インフラ管理の複雑さを抽象化することで、プラットフォームエンジニアリングは開発者が革新的なコードを書くことに専念できるようにします。
diff --git a/content/ja/service-mesh.md b/content/ja/service-mesh.md
index 3bfb41fd4a..fc653c522b 100644
--- a/content/ja/service-mesh.md
+++ b/content/ja/service-mesh.md
@@ -22,3 +22,11 @@ tags: ["ネットワーキング", "", ""]
 
 サービスメッシュは、コードの変更を必要とせずに、クラスタ全体のすべてのサービスに対して、信頼性、オブザーバビリティ、およびセキュリティ機能を均一に追加します。
 サービスメッシュが登場する前は、その機能をすべての個々のサービスに組み込む必要があり、バグや技術的負債の潜在的な原因となっていました。
+
+[サイドカーコンテナ](/ja/sidecar-container/)モデルは、各[Pod](/ja/pod/)ごとにプロキシをペアにします。
+このPodごとのプロキシがネットワークトラフィックを傍受・管理し、セキュリティポリシーを適用し、ワークロードの負荷分散を行い、各サービスのパフォーマンスデータを収集します。
+このアプローチは優れた制御性とサービスごとのトラフィック管理を提供しますが、計算リソースを多く消費し、システムが大きくなるにつれて管理がより複雑になります。
+
+一方で **サイドカーレス** な設計は、前述のメッシュの機能を[eBPF](/ja/ebpf/)のようなカーネル機能を使ってオペレーティングシステムレベルに移します。
+Podごとのプロキシを撤廃することで、この方法はリソース使用量を大幅に削減し、不要なネットワークホップをなくすためレイテンシーが下がりパフォーマンスが向上します。
+Pod数にかかわらずオーバーヘッドが一定で、デプロイすべきエージェントも少ないため、チームは運用の簡素化とワークロード増加に対する線形のスケーラビリティの恩恵を受けられます。
diff --git a/content/ja/sidecar-container.md b/content/ja/sidecar-container.md
new file mode 100644
index 0000000000..d3f0e2497a
--- /dev/null
+++ b/content/ja/sidecar-container.md
@@ -0,0 +1,24 @@
+---
+title: サイドカーコンテナ
+status: Completed
+category: コンセプト
+---
+
+サイドカーコンテナはサイドカーパターンの実装です。
+別のコンテナ上にデプロイされたアプリケーションが並行して動作し、メインコンテナ上で動いている主要なアプリケーションとライフサイクルを共有します。
+
+## 解決すべき問題はなんですか
+
+ログ、モニタリング、トレースだけでなくセキュリティやネットワーキングのようなシナリオに対処するために、複数の[コンテナ](/ja/container/)とそれらのライフサイクルをまとめて扱うのが都合の良いクロスプラットフォームの状況があります。
+このアプローチ以前は、ログは通常、コンテナ内のアプリケーションコードの中で実装されていました。
+これにより、開発者やアプリケーションによってロジックの実装方法が異なり、結果として保守や運用がより複雑なシステムになることが多かったです。
+たとえば、ログロジックの更新が実行時のアプリケーションに影響を与え、運用リスクが増大する可能性があります。
+
+## どのように役に立つのでしょうか
+
+関心の分離の原則を強制し、主要なアプリケーションのコードを変更することなく、別のコンテナ上で動作する分離されたプロセスを使って機能を拡張できます。
+
+サイドカーコンテナはメインコンテナと同じリソース(ストレージやネットワーキングを含む)を共有します。
+その間に、メインコンテナは機能的なタスクやビジネス機能の公開に集中できるようになります。
+
+たとえば、複数のマイクロサービスが同じディレクトリから読み取るログエージェントとして機能するサイドカーコンテナを持っていて、メインアプリケーションがそのディレクトリにログを書き込んでいる場合などです。