diff --git a/config.toml b/config.toml
index 147a46f848..7f159d9b3f 100644
--- a/config.toml
+++ b/config.toml
@@ -33,16 +33,16 @@ blog = "/:section/:year/:month/:day/:slug/"
 
 ## Configuration for BlackFriday markdown parser: https://github.com/russross/blackfriday
 [blackfriday]
-plainIDAnchors = true
-hrefTargetBlank = true
 angledQuotes = false
+hrefTargetBlank = true
 latexDashes = true
+plainIDAnchors = true
 
 # Image processing configuration.
 [imaging]
-resampleFilter = "CatmullRom"
-quality = 75
 anchor = "smart"
+quality = 75
+resampleFilter = "CatmullRom"
 
 [services]
 [services.googleAnalytics]
@@ -53,8 +53,8 @@ anchor = "smart"
 
 [languages]
 [languages.en]
+languageName = "English"
 title = "Cloud Native Glossary"
-languageName ="English"
 # Weight used for sorting.
 weight = 1
 [languages.en.params]
@@ -68,104 +68,111 @@ description = "The CNCF Cloud Native Glossary Project is intended to be used as
 #time_format_default = "02.01.2006"
 #time_format_blog = "02.01.2006"
 
-
 [languages.hi]
-title = "क्लाउड नेटिव शब्दावली"
-languageName ="हिन्दी (Hindi)"
 contentDir = "content/hi"
+languageName = "हिन्दी (Hindi)"
+title = "क्लाउड नेटिव शब्दावली"
 weight = 2
 [languages.hi.params]
 description = "CNCF क्लाउड नेटिव शब्दावली परियोजना का उद्देश्य क्लाउड नेटिव एप्लिकेशन के बारे में बात करते समय प्रयोग किए जाने वाले सामान्य शब्दों के संदर्भ के रूप में उपयोग किया जाना है।"
 
 [languages.pt-br]
-title = "Glossário Cloud Native"
+contentDir = "content/pt-br"
 languageName = "Português"
-contentDir =  "content/pt-br"
+title = "Glossário Cloud Native"
 weight = 3
 [languages.pt-br.params]
 description = "O Projeto CNCF Glossário Cloud Native se destina a ser usado como uma referência para termos comuns usados ao falar sobre aplicações nativas de nuvem."
 
 [languages.it]
-title = "Glossario Cloud Native"
-languageName = "Italiano"
 contentDir = "content/it"
+languageName = "Italiano"
+title = "Glossario Cloud Native"
 weight = 4
 [languages.it.params]
 description = "Il progetto del Glossario CNCF Cloud Native è pensato per essere un riferimento per i termini comuni, usati nell'ambito delle applicazioni cloud native."
 
 [languages.ko]
-title = "클라우드 네이티브(Cloud Native) 용어집"
-languageName ="한국어 (Korean)"
 contentDir = "content/ko"
+languageName = "한국어 (Korean)"
+title = "클라우드 네이티브(Cloud Native) 용어집"
 weight = 5
 [languages.ko.params]
 description = "CNCF 클라우드 네이티브 용어집 프로젝트는 클라우드 네이티브 애플리케이션을 주제로 대화를 나눌 때 참조할 수 있는 공통의 용어 제공을 목표로 한다."
 
 [languages.es]
-title = "Cloud Native Glosario"
-languageName ="Español (Spanish)"
 contentDir = "content/es"
+languageName = "Español (Spanish)"
+title = "Cloud Native Glosario"
 weight = 6
 [languages.es.params]
 description = "El proyecto de CNCF Cloud Native Glosario pretende ser usado como una referencia para los terminos comunes usados cuando se habla acerca de las aplicaciones nativas para la nube."
 
 [languages.zh-cn]
-title = "Cloud Native(云原生) Glossary"
-languageName ="简体中文 (Simplified Chinese)"
 contentDir = "content/zh-cn"
+languageName = "简体中文 (Simplified Chinese)"
+title = "Cloud Native(云原生) Glossary"
 weight = 7
 [languages.zh-cn.params]
 description = "CNCF 云原生 Glossary 项目旨在用作讨论云原生应用程序时常用术语的参考"
 
 [languages.bn]
-title = "ক্লাউড নেটিভ শব্দকোষ"
-languageName = "বাংলা (Bengali)"
 contentDir = "content/bn"
+languageName = "বাংলা (Bengali)"
+title = "ক্লাউড নেটিভ শব্দকোষ"
 weight = 8
 [languages.bn.params]
 description = "CNCF ক্লাউড নেটিভ শব্দকোষ প্রকল্পটি ক্লাউড নেটিভ অ্যাপ্লিকেশন সম্পর্কে কথা বলার সময় ব্যবহৃত সাধারণ পদগুলির জন্য একটি রেফারেন্স হিসাবে ব্যবহার করার উদ্দেশ্যে।"
 
 [languages.de]
-title = "Cloud Native Glossar"
-languageName ="Deutsch"
 contentDir = "content/de"
+languageName = "Deutsch"
+title = "Cloud Native Glossar"
 weight = 9
 [languages.de.params]
 description = "Das CNCF Cloud Native Glossar soll als Referenz für gängige Begriffe dienen, die im Zusammenhang mit Cloud Native Anwendungen verwendet werden."
 
 [languages.ur]
-title = "کلاؤڈ کی مقامی لغت"
-languageName ="اردو (Urdu)"
 contentDir = "content/ur"
+languageName = "اردو (Urdu)"
+title = "کلاؤڈ کی مقامی لغت"
 weight = 10
 [languages.ur.params]
 description = "CNCF کلاؤڈ کی مقامی لغت کا مقصد کلاؤڈ مقامی ایپلی کیشنز کے بارے میں بات کرتے وقت استعمال ہونے والی عام اصطلاحات کے حوالے کے طور پر استعمال کرنا ہے۔"
 
 [languages.fr]
-title = "Glossaire Cloud Native"
-languageName ="Français (French)"
 contentDir = "content/fr"
+languageName = "Français (French)"
+title = "Glossaire Cloud Native"
 weight = 11
 [languages.fr.params]
 description = "Le projet de Glossaire CNCF Cloud Native a pour objectif de référencer les termes courants utilisés dans les différentes applications Cloud Natives."
 
 [languages.zh-tw]
-title = "Cloud Native(雲端原生) Glossary"
-languageName ="繁體中文 (Traditional Chinese)"
 contentDir = "content/zh-tw"
+languageName = "繁體中文 (Traditional Chinese)"
+title = "Cloud Native(雲端原生) Glossary"
 weight = 12
 [languages.zh-tw.params]
 description = "CNCF 雲端原生 Glossary 專案旨在用作討論雲端原生應用程式時常用術語的參考"
 
+[languages.ja]
+contentDir = "content/ja"
+languageName = "日本語 (Japanese)"
+title = "クラウドネイティブ用語集"
+weight = 13
+[languages.ja.params]
+description = "CNCF クラウドネイティブ用語集プロジェクトは、クラウドネイティブアプリケーションについて話すときに使われる一般的な用語のリファレンスとして使用することを目的としています。"
+
 [markup]
-  [markup.goldmark]
-    [markup.goldmark.renderer]
-      unsafe = true
-  [markup.highlight]
-      # See a complete list of available styles at https://xyproto.github.io/splash/docs/all.html
-      style = "tango"
-      # Uncomment if you want your chosen highlight style used for code blocks without a specified language
-      # guessSyntax = "true"
+[markup.goldmark]
+[markup.goldmark.renderer]
+unsafe = true
+[markup.highlight]
+# See a complete list of available styles at https://xyproto.github.io/splash/docs/all.html
+style = "tango"
+# Uncomment if you want your chosen highlight style used for code blocks without a specified language
+# guessSyntax = "true"
 
 # Everything below this are Site Params
 
@@ -184,13 +191,13 @@ images = ["images/cncf-glossary-social.jpg"]
 # This menu appears only if you have at least one [params.versions] set.
 version_menu = "Releases"
 
-# Flag used in the "version-banner" partial to decide whether to display a 
+# Flag used in the "version-banner" partial to decide whether to display a
 # banner on every page indicating that this is an archived version of the docs.
 # Set this flag to "true" if you want to display the banner.
 archived_version = false
 
 # The version number for the version of the docs represented in this doc set.
-# Used in the "version-banner" partial to display a version number for the 
+# Used in the "version-banner" partial to display a version number for the
 # current doc set.
 version = "0.0"
 
@@ -208,7 +215,7 @@ github_repo = "https://github.com/cncf/glossary"
 
 # Uncomment this if you have a newer GitHub repo with "main" as the default branch,
 # or specify a new value if you want to reference another branch in your GitHub links
-github_branch= "main"
+github_branch = "main"
 
 # Google Custom Search Engine ID. Remove or comment out to disable search.
 gcs_engine_id = "eda0239a7d3fd0d90"
@@ -242,15 +249,15 @@ footer_about_disable = true
 [params.ui.feedback]
 enable = true
 # The responses that the user sees after clicking "yes" (the page was helpful) or "no" (the page was not helpful).
-yes = 'Thank you! Please <a href="https://github.com/cncf/glossary/issues/new">let us know if you have any suggestions</a>.'
 no = 'Thanks for your feedback. Please <a href="https://github.com/cncf/glossary/issues/new">tell us how we can improve</a>.'
+yes = 'Thank you! Please <a href="https://github.com/cncf/glossary/issues/new">let us know if you have any suggestions</a>.'
 
 # Adds a reading time to the top of each doc.
-# If you want this feature, but occasionally need to remove the Reading time from a single page, 
+# If you want this feature, but occasionally need to remove the Reading time from a single page,
 # add "hide_readingtime: true" to the page's front matter
 [params.ui.readingtime]
 enable = false
 
 [taxonomies]
-tag = "tags"
 category = "categories"
+tag = "tags"
diff --git a/content/ja/_TEMPLATE.md b/content/ja/_TEMPLATE.md
new file mode 100644
index 0000000000..f830c85c2f
--- /dev/null
+++ b/content/ja/_TEMPLATE.md
@@ -0,0 +1,19 @@
+---
+title: デフォルトテンプレート
+status: Feedback Appreciated
+category: コンセプト
+---
+
+コンセプトとその内容を簡単にまとめます。
+
+## 解決すべき問題はなんですか
+
+解決すべき問題を定義します。理想的には、定義している用語に触れないことです。
+
+## どのように役に立つのでしょうか
+
+その用語が上記の問題にどのように対処しているかを記述します。
+
+## 関連する用語はありますか
+
+関連する用語の追加します（該当する場合）
diff --git a/content/ja/_index.md b/content/ja/_index.md
new file mode 100755
index 0000000000..5f04fa6118
--- /dev/null
+++ b/content/ja/_index.md
@@ -0,0 +1,49 @@
+---
+title: "クラウドネイティブ用語集"
+status: Completed
+---
+
+# クラウドネイティブ用語集
+
+クラウドネイティブ用語集は、技術者だけでなくビジネスサイドの人々にもわかりやすく伝えることで、複雑なことで有名なクラウドネイティブの領域を、人々にとってよりシンプルにすることを目指しています。そのために、シンプルであること（例：バズワードを使わないシンプルな言葉、テクノロジーを使う人なら誰でも共感できる例、不必要な詳細は省くなど）に重点を置いています。この用語集は、CNCFビジネスバリュー分科会（BVS, Business Value Subcommittee）が主導するプロジェクトです。
+
+<p><img class="mt-3" src="/images/homepage/kubecon.jpg" alt="People watching a Kubecon presentation"></p>
+
+## 貢献
+
+クラウドネイティブ用語集の変更、追加、改良を提案することを歓迎します。
+私たちは、共有語彙目録を開発・改良するために、CNCFが管理するコミュニティ主導のプロセスを採用しています。
+この用語集は、クラウドネイティブテクノロジーに関する共有語彙を整理するために、ベンダーニュートラルなプラットフォームを提供します。
+プロジェクトの目的と憲章を遵守するすべての参加者からの投稿を歓迎します。
+
+
+貢献したい人は、GitHubのissueを提出するか、プルリクエストを作成することができます。
+[スタイルガイド](/ja/style-guide/)に従うことを確認し、[貢献の方法](/ja/contribute/)ドキュメントを読み, CNCF Slackの[#glossary](https://cloud-native.slack.com/archives/C02TX20MQBB) チャンネルに参加してください。
+また、用語集を母国語に翻訳する手伝いをしたい人のために、[#glossary-localizations](https://cloud-native.slack.com/archives/C02N2RGFXDF) チャンネルがあります。
+
+## 謝辞
+
+クラウドネイティブ用語集は、CNCFマーケティング委員会（ビジネスバリュー分科会）によって始められ、
+[Catherine Paganini](https://www.linkedin.com/in/catherinepaganini/en/), 
+[Chris Aniszczyk](https://www.linkedin.com/in/caniszczyk/), 
+[Daniel Jones](https://www.linkedin.com/in/danieljoneseb/?originalSubdomain=uk), 
+[Jason Morgan](https://www.linkedin.com/in/jasonmorgan2/), 
+[Katelin Ramer](https://www.linkedin.com/in/katelinramer/), 
+[Mike Foster](https://www.linkedin.com/in/mfosterche/?originalSubdomain=ca), 
+その他多くの貢献者による貢献が含まれています。
+全ての貢献者リストについては、[GitHub page](https://github.com/cncf/glossary/graphs/contributors) を参照してください。
+
+用語集は 
+[Catherine Paganini](https://www.linkedin.com/in/catherinepaganini/en/)、
+[Jason Morgan](https://www.linkedin.com/in/jasonmorgan2/)、
+[Jihoon Seo](https://www.linkedin.com/in/jihoon-seo/)、
+[Noah Ispas](https://www.linkedin.com/in/noah-ispas-0665b42a/)、
+そして [Seokho Son](https://www.linkedin.com/in/seokho-son/)によってメンテナンスされています.
+
+クラウドネイティブ用語集の日本語化は、[Kaito Ii](https://github.com/kaitoii11)、[Kohei Ota](https://github.com/inductor)、[Yuishi Nakamura](https://github.com/yuichi-nakamura)、[MItabashi](https://github.com/bashi8128)、[HANABE926](https://github.com/HANABE926)、[Junya Okabe](https://github.com/Okabe-Junya)、[Akira Aiura](https://github.com/A-aiura)、[shizhenhu](https://github.com/shizhenhu)、[Nao Nishijima](https://github.com/naonishijima)の貢献を通じて開始されました。
+クラウドネイティブ用語集の日本語への翻訳とローカライゼーションに興味のある方は、[#glossary-localization-japanese](https://app.slack.com/client/T08PSQ7BQ/C057F81GFUG) チャンネルにご参加ください。
+
+## ライセンス
+
+すべてのコードの貢献はApache 2.0ライセンスに基づいています。
+ドキュメントはCC BY 4.0に基づいて配布されます。
\ No newline at end of file
diff --git a/content/ja/api-gateway.md b/content/ja/api-gateway.md
new file mode 100644
index 0000000000..8efe5d6abd
--- /dev/null
+++ b/content/ja/api-gateway.md
@@ -0,0 +1,29 @@
+---
+title: APIゲートウェイ
+status: Completed
+category: テクノロジー
+tags: ["ネットワーキング", "", ""]
+---
+
+[API](/ja/application-programming-interface/)ゲートウェイは、いくつかのアプリケーションAPIを集約し、
+それらを一か所で利用可能にするツールです。
+これにより認証や認可、
+またはアプリケーション間のリクエスト数を制限するなどの重要な機能を中央管理された場所に集約することができます。
+APIゲートウェイは、(しばしば外部の)APIの利用者に対する共通のインターフェースとして機能します。
+
+## 解決すべき問題はなんですか
+
+外部の利用者にAPIを提供する場合、
+すべてのアクセスを管理・制御するための一つのエントリーポイントが必要になります。
+さらに、それらのやり取りに機能を適用する必要がある場合、
+APIゲートウェイを使用するとアプリのコードを変更することなく、すべてのトラフィックに対して一様にそれを適用することができます。
+
+## どのように役に立つのでしょうか
+
+アプリケーション内のさまざまなAPIに対して単一のアクセスポイントを提供するAPIゲートウェイは、
+組織の横断的なビジネスロジックやセキュリティロジックを一箇所に集中して適用するのを容易にします。
+また、アプリケーションの利用者がすべてのニーズに対して単一のアドレスを通じてアクセスできるようにもします。
+APIゲートウェイは、システム内のすべてのウェブサービスへのリクエストに対して単一のアクセスポイントを提供することで、
+セキュリティや[可観測性](/ja/observability/)などの運用上の懸念を簡素化することができます。
+すべてのリクエストがAPIゲートウェイを通過するため、
+メトリクス収集、レート制限、認証などの機能を追加するための単一の場所となります。
diff --git a/content/ja/application-programming-interface.md b/content/ja/application-programming-interface.md
new file mode 100644
index 0000000000..aaa4fdb074
--- /dev/null
+++ b/content/ja/application-programming-interface.md
@@ -0,0 +1,24 @@
+---
+title: アプリケーションプログラミングインタフェース(API)
+status: Completed
+category: テクノロジー
+tags: ["アーキテクチャ", "基礎", ""]
+---
+
+APIは、コンピュータープログラム同士が互いにやり取りする方法です。
+人間がウェブページを介してウェブサイトとやり取りするように、APIはコンピュータープログラムが相互に通信するための手段を提供します。
+人間のやり取りとは異なり、APIには何が要求できるか、あるいはできないかについての制限があります。
+この制限によって、プログラム間で安定的で機能的なコミュニケーションが実現されます。
+
+## 解決すべき問題はなんですか
+
+アプリケーションが複雑になるにつれて、小さなコードの変更が他の機能に大きな影響を及ぼす可能性があります。
+アプリケーションが成長しながらも安定性を維持するために、機能にモジュラーなアプローチを採用する必要があります。
+APIがなければ、アプリケーション同士が相互に通信するための枠組みが不足します。
+共有された枠組みがないと、アプリケーションが[スケール](/ja/scalability/)し、統合することが困難になります。
+
+## どのように役に立つのでしょうか
+
+APIは、コンピュータープログラムやアプリケーションが定義された理解しやすい方法で相互に通信し、情報を共有することを可能にします。
+これは現代のアプリケーションの構成要素であり、開発者にアプリケーションを統合するための方法を提供します。
+[マイクロサービス](/ja/microservices-architecture/)が連携して動作しているのであれば、それはAPIを用いて相互に通信していると推測できます。
diff --git a/content/ja/bare-metal-machine.md b/content/ja/bare-metal-machine.md
new file mode 100644
index 0000000000..bfe14ff754
--- /dev/null
+++ b/content/ja/bare-metal-machine.md
@@ -0,0 +1,18 @@
+---
+title: ベアメタルマシン
+status: Completed
+category: テクノロジー
+tags: ["インフラストラクチャー", "", ""]
+---
+
+ベアメタルとは物理コンピューターを意味し、具体的にはサーバーのことでありオペレーティングシステムが1つしかないものです。最近のコンピューティングでは、サーバーの多くが[仮想マシン](/ja/virtual-machine/)であるため、この区別は重要です。物理サーバーは、一般的に強力なハードウェアを内蔵したかなり大型のコンピューターです。[仮想化](/ja/virtualization/)せずに、物理ハードウェア上にオペレーティングシステムをインストールし直接アプリケーションを実行することを"ベアメタル"上で実行すると呼ばれます。
+
+## 解決すべき問題はなんですか
+
+1つのオペレーティングシステムと1台の物理コンピューターの組み合わせはコンピューティングの原型です。物理コンピューターのすべてのリソースがオペレーティングシステムで直接利用可能であり、仮想化レイヤーが存在しないため、オペレーティングシステムの命令をハードウェアに変換する際に人工的な遅延が発生しません。
+
+## どのように役に立つのでしょうか
+
+コンピューターのすべての計算リソースを単一のオペレーティングシステムに割り当てることで、オペレーティングシステムに最高のパフォーマンスを提供できる可能性があります。ハードウェアリソースに極めて高速にアクセスしなければならないワークロードを実行する必要がある場合、ベアメタルが適切なソリューションかもしれません。
+
+[クラウドネイティブアプリケーション](/ja/cloud-native-apps/)のコンテキストでは、私たちは一般的にパフォーマンスを、[水平スケーリング](/ja/horizontal-scaling/)（リソースプールにマシンを追加する）で処理できる多数の並行イベントへの[スケーリング](/ja/scalability/)という観点から考えます。しかし、ワークロードによっては[垂直スケーリング](/ja/vertical-scaling/)（既存の物理マシンにさらにパワーを追加する）が必要な場合や、極めて高速な物理ハードウェアのレスポンスが必要になる場合はベアメタルが適しています。また、ベアメタルにおいては、タスクを達成するために、物理ハードウェアや場合によってはハードウェアドライバをチューニングすることもできます。
diff --git a/content/ja/client-server-architecture.md b/content/ja/client-server-architecture.md
new file mode 100644
index 0000000000..bab2dc42f7
--- /dev/null
+++ b/content/ja/client-server-architecture.md
@@ -0,0 +1,29 @@
+---
+title: クライアントサーバーアーキテクチャ
+status: Completed
+category: コンセプト
+tags: ["アーキテクチャ", "基礎", ""]
+---
+
+クライアントサーバーアーキテクチャでは、アプリケーションを構築するロジック(あるいはコード)が2つ以上のコンポーネントに分割されます。
+それは作業の実行を要求するクライアント(例えばウェブブラウザで実行されるGmailのウェブアプリケーション)と、その要求を満たす1つ以上のサーバー(例えばクラウド内のGoogleのコンピューターで実行されるメール送信サービス)です。
+この例では、あなたが書いた送信メールは、クライアント(ウェブブラウザで実行されるウェブアプリケーション)によってサーバー(あなたの送信メールを受信者に転送するGmailのコンピューター)へ送られます。
+
+これは、(例えばデスクトップアプリケーションのような)すべての作業を一つの場所で行う自己完結型のアプリケーションとは対照的です。
+例えば、Microsoft Wordのようなワードプロセッサープログラムは、あなたのコンピューター上にインストールされ完全にあなたのコンピューター上で実行されます。
+
+## 解決すべき問題はなんですか
+
+クライアントサーバーアーキテクチャは、自己完結型のアプリケーションが抱える、定期的な更新という大きな課題を解決します。
+自己完結型アプリでは、更新のたびにユーザーは最新バージョンをダウンロードしてインストールする必要があります。
+Amazonの商品カタログ全体を、ブラウジングする前に自分のコンピュータにダウンロードすることを想像してみてください！
+
+## どのように役に立つのでしょうか
+
+リモートサーバーやサービスでアプリケーションロジックを実装することにより、
+オペレーターはクライアント側のロジックを変更することなく、それを更新できます。
+これによって更新をより頻繁に行うことができます。
+データをサーバー上に保存することで、多くのクライアントが同じデータを見て共有することができます。
+オンラインのワードプロセッサーを使用することと、従来のオフラインのワードプロセッサーを使用することの違いを考えてみてください。
+前者ではファイルはサーバー側に存在し、他のユーザーがサーバーからダウンロードするだけで共有することができます。
+従来の世界では、ファイルはリムーバブルメディア(フロッピーディスク！)にコピーされ、個別に共有される必要がありました。
diff --git a/content/ja/cloud-computing.md b/content/ja/cloud-computing.md
new file mode 100644
index 0000000000..1681b4dc0a
--- /dev/null
+++ b/content/ja/cloud-computing.md
@@ -0,0 +1,16 @@
+---
+title: クラウドコンピューティング
+status: Completed
+category: コンセプト
+tags: ["インフラストラクチャー", "基礎", ""]
+---
+
+クラウドコンピューティングは、CPU、ネットワーク、ディスクなどの計算資源をインターネット上でオンデマンドで提供し、ユーザーは物理的に離れた場所にある計算能力にアクセスし、使用することができるようにします。一般に、クラウド基盤が組織専用のものか、オープンな公共サービスのために共有されているかによって、プライベートクラウドとパブリッククラウドに区別されます。
+
+## 解決すべき問題はなんですか
+
+組織は従来、コンピューティングパワーを拡大しようとする際、主に2つの課題に直面していました。物理的なサーバーとネットワークをホストするための（新しい）設備を取得、サポート、設計するか、既存の設備を拡張、維持するかです。クラウドコンピューティングは、企業がコンピューティングニーズの一部をアウトソースできるようにすることで、この課題を解決しています。
+
+## どのように役に立つのでしょうか
+
+クラウドプロバイダーは、企業がオンデマンドでコンピューティングリソースを借り、使用量に応じて料金を支払うことを可能にし、2つの重要な利点をもたらします。第一に、企業は新しい物理的なインフラストラクチャーを待つことなく、計画し、リソースを費やすことなく、製品やサービスに集中することができます。そして2つ目は、必要に応じてオンデマンドで[拡張](/ja/scalability/)できることです。クラウドコンピューティングでは、必要な分だけインフラを導入することができます。
diff --git a/content/ja/cloud-native-apps.md b/content/ja/cloud-native-apps.md
new file mode 100644
index 0000000000..8aff40a688
--- /dev/null
+++ b/content/ja/cloud-native-apps.md
@@ -0,0 +1,16 @@
+---
+title: クラウドネイティブアプリケーション
+status: Completed
+category: コンセプト
+tags: ["アプリケーション", "基礎", ""]
+---
+
+クラウドネイティブアプリケーションは、[クラウドコンピューティング](/ja/cloud-computing/)の技術革新を活用するため特別に設計されています。これらのアプリケーションは、それぞれのクラウドアーキテクチャと容易に統合でき、クラウドのリソースと[スケーリング](/ja/scalability/)機能を活用できます。また、クラウドコンピューティングによるインフラストラクチャーの技術革新を活用するアプリケーションのことも指します。今日のクラウドネイティブアプリケーションには、クラウドプロバイダーのデータセンターで実行されるアプリケーションと、オンプレミスのクラウドネイティブプラットフォームで実行されるアプリケーションがあります。
+
+## 解決すべき問題はなんですか
+
+従来、オンプレミス環境では、コンピューティングリソースをかなり特化した方法で提供していました。各データセンターは、アプリケーションを特定の環境に[密結合](/ja/tightly-coupled-architectures/)するサービスを持っており、多くの場合、[仮想マシン](/ja/virtual-machine/)やサービスのようなインフラストラクチャーの提供は手作業に大きく依存していました。その結果、開発者とそのアプリケーションは、特定のデータセンターに制約されることになりました。クラウド用に設計されていないアプリケーションは、クラウド環境の耐障害性やスケーリング機能を活用することができません。例えば、正しく起動するために手作業が必要なアプリケーションは、自動的にスケーリングすることができず、障害発生時に自動的に再起動することもできません。
+
+## どのように役に立つのでしょうか
+
+クラウドネイティブアプリケーションへの万能な道はありませんが、いくつかの共通点はあります。クラウドネイティブアプリケーションは弾力性があり、管理しやすく、それに付随する一連のクラウドサービスによって支援されます。さまざまなクラウドサービスによって、高度な[可観測性](/ja/observability/)が有効になり、ユーザーは問題が深刻化する前に発見して対処することができます。堅牢な自動化と組み合わせることで、エンジニアは最小限の労力で、インパクトの大きい変更を頻繁にかつ予想通りに行うことができます。
diff --git a/content/ja/cloud-native-security.md b/content/ja/cloud-native-security.md
new file mode 100644
index 0000000000..ab3eaa3a02
--- /dev/null
+++ b/content/ja/cloud-native-security.md
@@ -0,0 +1,19 @@
+---
+title: クラウドネイティブセキュリティ
+status: Completed
+category: コンセプト
+tags: ["セキュリティ", "", ""]
+---
+
+クラウドネイティブセキュリティは、セキュリティを[クラウドネイティブアプリケーション](/ja/cloud-native-apps/)に組み込むアプローチです。開発から本番に至るまで、アプリケーションのライフサイクル全体にセキュリティが組み込まれていることを保証します。クラウドネイティブセキュリティは、従来のセキュリティモデルと同じ基準を保証しつつ、クラウドネイティブ環境の特性、すなわち迅速なコード変更や非常に短命な[^1]インフラストラクチャーに適応することを目指します。クラウドネイティブセキュリティは、[DevSecOps](/ja/devsecops/)と呼ばれるプラクティスと非常に関係があります。
+
+[^1]: 訳注：必要に応じてリソースを動的に拡張したり縮小したりするといった性質を持つ
+
+## 解決すべき問題はなんですか
+
+従来のセキュリティモデルは、もはや有効でない多くの前提のもとに構築されていました。クラウドネイティブアプリケーションは頻繁に変わり、多数のオープンソースツールやライブラリを使用し、多くの場合ベンダーが管理するインフラストラクチャーで実行され、急速なインフラストラクチャーの変更に影響を受けることがあります。コードレビューや長い品質保証サイクル、ホストベースの脆弱性スキャン、直前のセキュリティレビューは、クラウドネイティブアプリケーションに対応することはできません。
+
+## どのように役に立つのでしょうか
+
+クラウドネイティブセキュリティは、従来のセキュリティモデルから、リリースサイクルのすべての段階でセキュリティが関与するモデルへと移行することにより、アプリケーションを保護する新しい方法を導入します。手作業による監査と監視は、大部分が自動スキャンに取って代わられます。迅速なコードリリースパイプラインは、コンパイル前にコードの脆弱性をスキャンするツールと統合されます。オープンソースライブラリは、信頼できるソースから取得され脆弱性がないか監視されています。
+クラウドネイティブセキュリティモデルは、緩やかな変化ではなく、脆弱性のあるコンポーネントを頻繁に更新したり、インフラストラクチャーを定期的に交換したりすることを受け入れます。
diff --git a/content/ja/cloud-native-tech.md b/content/ja/cloud-native-tech.md
new file mode 100644
index 0000000000..51117e1d53
--- /dev/null
+++ b/content/ja/cloud-native-tech.md
@@ -0,0 +1,18 @@
+---
+title: クラウドネイティブテクノロジー
+status: Completed
+category: コンセプト
+tags: ["基礎", "", ""]
+---
+
+クラウドネイティブテクノロジーは、クラウドネイティブスタックとも呼ばれ、[クラウドネイティブアプリケーション](/ja/cloud-native-apps/)を構築するために使用される技術です。これらの技術により、組織がスケーラブルなアプリケーションを、パブリックやプライベート、ハイブリッドクラウドのようなモダンでダイナミックな環境で、[クラウドコンピューティング](/ja/cloud-computing/)の利点を最大限に活用しながら、構築や実行することができます。コンテナ、サービスメッシュ、マイクロサービス、イミュータブルインフラストラクチャーなど、クラウドコンピューティングの機能を活用するために1から設計されたアプローチです。
+
+## 解決すべき問題はなんですか
+
+クラウドネイティブスタックには多くの異なる技術カテゴリーがあり、様々な課題に対応しています。
+[CNCFクラウドネイティブランドスケープ](https://landscape.cncf.io/)を見ると、いかに多くの異なる領域に触れているかわかると思います。
+しかし高いレベルでは、主に従来のIT運用モデルのマイナス面に取り組んでいます。含まれる課題としては、拡張性がありフォールトトレラントな自己修復型アプリケーションの実現が困難であること、リソースの活用が非効率であることなどが挙げられます。
+
+## どのように役に立つのでしょうか
+
+それぞれの技術は特定の問題に対応していますが、全体として、クラウドネイティブテクノロジーは弾力性があり管理可能で観測可能な疎結合のシステムを実現します。堅牢な自動化と組み合わせることで、エンジニアは最小限の労力で影響力の大きい変更を頻繁にかつ予測通りに行うことができます。クラウドネイティブシステムの望ましい特性は、クラウドネイティブスタックで実現することが容易になりました。
diff --git a/content/ja/cluster.md b/content/ja/cluster.md
new file mode 100644
index 0000000000..c29169cc34
--- /dev/null
+++ b/content/ja/cluster.md
@@ -0,0 +1,26 @@
+---
+title: クラスター
+status: Completed
+category: コンセプト
+tags: ["インフラストラクチャー", "基礎", ""]
+---
+
+クラスターは、共通の目的に向けて連携して働くコンピューターやアプリケーションのグループです。
+クラウドネイティブコンピューティングの文脈では、この用語は通常[Kubernetes](/ja/kubernetes/)に適用されます。
+Kubernetesクラスターは、通常異なるマシン上でそれぞれのコンテナ内で実行される一連のサービス（あるいはワークロード）です。
+これらすべての[コンテナ化](/ja/containerization/)されたサービスの集合がネットワーク上で接続され、クラスターを形成しています。
+
+## 解決すべき問題はなんですか
+
+単一のコンピューター上で動作するソフトウェアには、単一障害点があります。
+もしそのコンピューターがクラッシュしたり、誰かが誤って電源ケーブルを抜いたりした場合、
+ビジネス上重要なシステムが利用できなくなる可能性があります。
+そのため、モダンなソフトウェアは一般的に[分散アプリケーション](/ja/distributed-apps/)として構築され、クラスターとしてまとめられます。
+
+## どのように役に立つのでしょうか
+
+クラスター化された分散アプリケーションは複数のマシン上で実行され、単一障害点がなくなります。
+しかし、分散システムを構築することは非常に難しいです。
+実際、分散システムはコンピューターサイエンスの中で一つの分野として扱われています。
+グローバルなシステムの必要性と長い年月をかけた試行錯誤が、[クラウドネイティブ技術](/ja/cloud-native-tech/)と呼ばれる新たなタイプの技術スタックの開発につながりました。
+これらの新しい技術は、分散システムの運用と作成を容易にするための構成要素となります。
diff --git a/content/ja/container-orchestration.md b/content/ja/container-orchestration.md
new file mode 100644
index 0000000000..ee479c1f47
--- /dev/null
+++ b/content/ja/container-orchestration.md
@@ -0,0 +1,23 @@
+---
+title: コンテナオーケストレーション
+status: Completed
+category: コンセプト
+---
+
+[コンテナ](/ja/container/)オーケストレーションとは、流動的な環境において、コンテナ化されたアプリケーションのライフサイクルを管理し自動化することを指します。
+これはコンテナオーケストレータ(ほとんどの場合は[Kubernetes](/ja/kubernetes))を通じて実行され、デプロイメント、(自動)スケーリング、自動ヒーリング、モニタリングが可能になります。
+オーケストレーションという言葉は比喩です。
+オーケストレーションツールは、音楽指揮者のようにコンテナを指揮し、すべてのコンテナ(または音楽家)が適切に機能するようにします。
+
+## 解決すべき問題は何ですか
+
+スケールに応じて[マイクロサービス](/ja/microservices-architecture)、セキュリティ、ネットワーク通信や一般的な[分散システム](/ja/distributed-systems)を管理することは、
+手動で行うには難しく、場合によっては不可能です。
+コンテナオーケストレーションにより、これらすべての管理タスクを自動化することができます。
+
+## どのように役に立つのでしょうか
+
+コンテナオーケストレーションツールは、ユーザーがシステムの状態を決定することを可能にします。
+まず、システムがどのようにあるべきかを宣言します(例えばx個のコンテナ、y個のPodなど)。
+その後、オーケストレーションツールは自動的にインフラを監視し、現状が宣言した状態から逸脱した場合には修正します(例えばコンテナがクラッシュした場合に新しいコンテナを立ち上げるなど)。
+この自動化により、プロビジョニング、デプロイメント、スケーリング（増減）、ネットワーキング、ロードバランシングといった、エンジニアリングチームが手作業で行う複雑な運用タスクが大幅に簡素化されます。
diff --git a/content/ja/container.md b/content/ja/container.md
new file mode 100644
index 0000000000..3944bd392e
--- /dev/null
+++ b/content/ja/container.md
@@ -0,0 +1,30 @@
+---
+title: コンテナ
+status: Completed
+category: テクノロジー
+tags: ["アプリケーション", "基礎", ""]
+---
+
+コンテナは、コンピューターのオペレーティングシステムがリソースと機能面での制限を管理する、実行中のプロセスです。
+コンテナプロセスで利用可能なファイルは、コンテナイメージとしてパッケージ化されています。
+コンテナは一つのマシン上で同時に実行されますが、
+通常オペレーティングシステムは別々のコンテナプロセスが互いに干渉するのを防ぎます。
+
+## 解決すべき問題は何ですか
+
+コンテナが利用可能になる前は、アプリケーションを実行するためには別々のマシンが必要でした。
+各マシンはそれぞれのオペレーティングシステムを必要とし、CPU、メモリ、ディスクスペースを消費します。
+これらは全て個々のアプリケーションが動作するために必要なものです。
+さらに、オペレーティングシステムのメンテナンス、アップグレード、起動は大きな手間のかかる作業です。
+
+## どのように役に立つのでしょうか
+
+コンテナはオペレーティングシステムとそのマシンリソースを共有し、
+オペレーティングシステムのリソースオーバーヘッドを分散させ、物理マシンを効率的に使用します。
+これは通常コンテナが互いに干渉することが制限されているため、実現できます。
+これにより、同じ物理マシン上で多くのアプリケーションを実行することができます。
+
+しかし、いくつかの制限もあります。
+コンテナは同じオペレーティングシステムを共有するため、プロセスは代替手段と比べて安全性が低いと考えられます。
+またコンテナは、共有されるリソースへの制限を必要とします。
+リソースを保証するために、管理者はメモリやCPUの使用を制限し、他のアプリケーションのパフォーマンスが低下しないようにする必要があります。
diff --git a/content/ja/containerization.md b/content/ja/containerization.md
new file mode 100644
index 0000000000..041cd24d5b
--- /dev/null
+++ b/content/ja/containerization.md
@@ -0,0 +1,29 @@
+---
+title: コンテナ化
+status: Completed
+category: テクノロジー
+tags: ["アプリケーション", "", ""]
+---
+
+コンテナ化は、アプリケーションとその依存関係をコンテナイメージにまとめるプロセスです。
+コンテナのビルドプロセスでは、[Open Container Initiative](https://opencontainers.org)(OCI)標準への準拠が必要です。
+出力がこの標準に準拠したコンテナイメージであれば、どのコンテナ化ツールを使用しても問題ありません。
+
+## 解決すべき問題は何ですか
+
+コンテナが普及する前は、組織は仮想マシン(VM)に依存して、
+単一の[ベアメタルマシン](/ja/bare-metal-machine/)上で複数のアプリケーションをオーケストレーションしていました。
+VMはコンテナよりも非常に大きく、実行にはハイパーバイザーが必要です。
+これらの大きなVMテンプレートのストレージ、バックアップ、転送により、VMテンプレートの作成もより遅くなります。
+さらに、VMは[不変性](/ja/immutable-infrastructure/)の原則に反する構成ドリフトに悩まされることがあります。
+
+## どのように役に立つのでしょうか
+
+コンテナイメージは(従来のVMとは異なり)軽量です。
+またコンテナ化のプロセスには依存関係のリストが記載されたファイルが必要です。
+このファイルはバージョン管理が可能で、ビルドプロセスを自動化できます。
+これにより組織は他の優先事項に集中でき、
+自動化されたプロセスがビルドを担当します。
+コンテナイメージは、その厳密な内容と設定に関連付けられた一意の識別子によって保存されます。
+コンテナがスケジュールされ再スケジュールされると、
+常に初期状態にリセットされるため、構成ドリフトが解消されます。
diff --git a/content/ja/continuous-delivery.md b/content/ja/continuous-delivery.md
new file mode 100644
index 0000000000..907599e3d2
--- /dev/null
+++ b/content/ja/continuous-delivery.md
@@ -0,0 +1,34 @@
+---
+title: 継続的デリバリー(CD)
+status: Completed
+category: コンセプト
+tags: ["方法論", "アプリケーション", ""]
+---
+
+継続的デリバリー(しばしばCDと略される)は、
+コードの変更が自動的に受け入れ環境にデプロイされる
+(または継続的デプロイメントの場合、本番環境にデプロイされる)一連の実践を指します。
+CDは、ソフトウェアがデプロイメント前に適切にテストされていることを保証する手順を重要視し、
+必要と判断された場合に変更をロールバックする方法を提供します。
+継続的インテグレーション(CI)は継続的デリバリーに向けた最初のステップです
+(つまり、テストやデプロイがされる前に、変更がうまく統合されなければなりません。)
+
+## 解決すべき問題は何ですか
+
+大規模な環境では、[信頼性](/ja/reliability/)の高いアップデートのデプロイが問題となります。
+理想的には、エンドユーザーにより良い価値を提供するために、頻繁にデプロイを行いたいところです。
+しかし、それを手動で行うと変更ごとに高いトランザクションコストが発生します。
+歴史的に、これらのコストを避けるために、組織は頻繁にリリースを行わず、
+一度に多くの変更をデプロイしてきましたが、これにより何かが間違ってしまうリスクが高まります。
+
+## どのように役に立つのでしょうか
+
+CD戦略は、完全に自動化された本番環境へのパスを作成し、
+[カナリア](/ja/canary-deployment/)や[ブルーグリーン](/ja/blue-green-deployment/)リリースなどの様々なデプロイメント戦略を使用してソフトウェアをテストしデプロイします。
+これにより、開発者は頻繁にコードをデプロイすることができ、新しいリビジョンがテストされていることを安心して受け入れることができます。
+通常CD戦略では、フィーチャーブランチやプルリクエストとは対照的に、トランクベースの開発を行います。
+
+## 関連する用語はありますか
+
+* [継続的インテグレーション](/ja/continuous-integration/)
+* [継続的デプロイメント](/ja/continuous-deployment/)
diff --git a/content/ja/continuous-deployment.md b/content/ja/continuous-deployment.md
new file mode 100644
index 0000000000..59847ba78a
--- /dev/null
+++ b/content/ja/continuous-deployment.md
@@ -0,0 +1,32 @@
+---
+title: 継続的デプロイメント(CD)
+status: Completed
+category: コンセプト
+tags: ["アプリケーション", "方法論", ""]
+---
+
+継続的デプロイメント(しばしばCDと略される)は、
+完成したソフトウェアを直接本番環境にデプロイするという点で[継続的デリバリー](/ja/continuous-delivery/)より一歩進んでいます。
+継続的デプロイメント(CD)は[継続的インテグレーション](/ja/continuous-integration/)(CI)と密接に関連しており、しばしばCI/CDと呼ばれます。
+CIプロセスは特定のアプリケーションへの変更が有効であるかどうかをテストし、
+CDプロセスはコードの変更を自動的に組織のテスト環境や本番環境にデプロイします。
+
+## 解決すべき問題はなんですか
+
+新しいソフトウェアバージョンのリリースは、労力がかかりエラーが発生しやすいプロセスです。
+また本番環境でのインシデントを避け、エンジニアが通常の業務時間外に対応する時間を減らすため、
+組織が頻繁に行わないことも多いです
+伝統的なソフトウェアデプロイメントモデルでは、
+ソフトウェアのリリースプロセスが組織の安定性と機能の速度の両方に関するニーズを満たせず、組織を悪循環に陥らせます。
+
+## どのように役に立つのでしょうか
+
+リリースサイクルを自動化し、組織が頻繁に本番環境へのリリースを強制することにより、
+CDは運用チームに対して、CIが開発チームにもたらした効果を実現します。
+具体的には、運用チームが本番へのデプロイメントの際に煩雑でエラーが発生しやすい部分を自動化するように促し、全体的なリスクを減少させます。
+また組織が本番環境の変更を受け入れ、適応する能力を向上させ、より高い安定性につながります。
+
+## 関連する用語はありますか
+
+* [継続的インテグレーション](/ja/continuous-integration/)
+* [継続的デリバリー](/ja/continuous-delivery/)
diff --git a/content/ja/continuous-integration.md b/content/ja/continuous-integration.md
new file mode 100644
index 0000000000..c4c048d74a
--- /dev/null
+++ b/content/ja/continuous-integration.md
@@ -0,0 +1,31 @@
+---
+title: 継続的インテグレーション(CI)
+status: Completed
+category: コンセプト
+tags: ["アプリケーション", "方法論", ""]
+---
+
+継続的インテグレーション(CI)とは、コードの変更を可能な限り定期的に統合することを指します。
+CIは[継続的デリバリー](/ja/continuous-delivery/)(CD)の前提条件です。
+伝統的に、CIのプロセスはバージョンコントロールシステム(GitやMercurial、あるいはSubversion)にコードの変更がコミットされることで開始し、
+CDシステムで利用できるようになったテスト済みの成果物で終了します。
+
+## 解決すべき問題はなんですか
+
+ソフトウェアシステムはしばしば大規模で複雑であり、多くの開発者が維持や更新をしています。
+システムの異なる部分で並行して作業を行う開発者たちは、
+意図せずに互いの作業を壊すような矛盾した変更を加えることがあります。
+さらに、同じプロジェクトに複数の開発者が取り組む場合、
+テストやコード品質の計測といった日常的なタスクは、各開発者によって繰り返される必要があり、時間の無駄になります。
+
+## どのように役に立つのでしょうか
+
+CIソフトウェアは、開発者が変更をコミットするたびに、コードの変更がスムーズにマージできることを自動的に確認します。
+CIサーバーを使用してコードの品質チェック、テスト、さらにはデプロイメントを行うことは、広範囲にわたって一般的に行われる実践です。
+そのため、CIはチーム内の品質管理を具体的に実行する方法となります。
+CIを利用することで、ソフトウェアチームはすべてのコードのコミットを、具体的な失敗か実用的なリリース候補のいずれかにすることができます。
+
+## 関連する用語はありますか
+
+* [継続的デリバリー](/ja/continuous-delivery/)
+* [継続的デプロイメント](/ja/continuous-deployment/)
diff --git a/content/ja/contribute/_index.md b/content/ja/contribute/_index.md
new file mode 100644
index 0000000000..1a7a3a5a5c
--- /dev/null
+++ b/content/ja/contribute/_index.md
@@ -0,0 +1,220 @@
+---
+title: 貢献の方法
+toc_hide: true
+status: Completed
+menu:
+  main:
+    weight: 10
+---
+
+## ようこそ
+ 
+クラウドネイティブ用語集の貢献ガイドへようこそ。
+このプロジェクトに貢献できる方法はいくつかありますが、ここではその詳細を説明します：
+
+1) [既存の課題に取り組む](#work-on-an-existing-issue)
+2) [新しい用語の提案](#propose-new-terms)
+3) [既存の用語を更新する](#update-an-existing-term)
+4) [用語集を翻訳する](#help-localize-the-glossary)
+
+## CNCF用語集レビュー 
+
+この用語集のゴールは、複雑なことで有名なクラウドネイティブの空間をシンプルにすることで、より多くの人に親しんでもらうことです。
+
+クラウドネイティブ用語集のコンテンツは[GitHub repo](https://github.com/cncf/glossary) に保存されています。
+ここには、用語集に関する[issues](https://github.com/cncf/glossary/issues), pull request ([PRs](https://github.com/cncf/glossary/pulls)), そして[discussions](https://github.com/cncf/glossary/discussions) のリストがあります。
+
+## 誰が貢献できるのか？
+
+このプロジェクトにどのように参加できるかは、クラウドネイティブの専門知識のレベルによって異なります。
+複雑な概念を簡略化するには、そのトピックに関する深い知識が必要です。
+したがって、新しい用語を寄稿するには、その用語に精通している必要があります。
+貢献者は通常、これらの技術にしばらく携わってきたエンジニアや、クラウドネイティブに焦点を当てたアカデミックの経験者です。
+
+複雑な概念を簡単な言葉で説明するのは _本当_ に難しいので、そのノウハウが必要です。そして、消化しやすく、ユーザーフレンドリーな結果は簡単に見えるかもしれませんが、望ましいシンプルさを実現するためには、クラウドネイティブの専門家たちの努力と協力が必要です。
+
+もしあなたがまだクラウドネイティブの専門家ではないが、それでも貢献したいのであれば、専門家とチームを組むことをお勧めします。
+その専門家が、その用語がコンセプトを正確に表現していると確信したら、最初の用語集への投稿の準備ができました。
+
+翻訳は、他言語に精通した初心者が用語集に貢献できる貴重な場です。
+英語での定義がしっかりしていれば、経験の浅い貢献者でも、用語を目標の言語に翻訳することができます。既存の翻訳チームに参加することも、新しいチームを作ることもできます。このガイドの[用語集の翻訳を支援する](#help-localize-the-glossary)のセクションを読んで、開始方法を学んでください。
+
+## 始める前に
+
+用語集へ貢献する旅を始める前に、必ず以下のステップを完了してください：
+
+1. [GitHub アカウント](https://docs.github.com/en/get-started/signing-up-for-github/signing-up-for-a-new-github-account)を持っていなければ作成する。
+2. [貢献者ライセンス契約書](https://docs.linuxfoundation.org/lfx/easycla/v2-current/contributors) (CLA)にサインする。
+3. [コミット署名を確認する](https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification)
+4. GitHubアカウントで[警戒モード](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode)を有効にすると、コミット時に検証ステータスが表示されます。
+
+## ベストプラクティス {#best-practices}
+
+レビューを容易にするため、[セマンティック改行](https://sembr.org/)を使用してください（例：1文につき1行など）。
+私たちは、GitHubでマークダウンテキストを正しくフォーマットするために、この[マークダウンのチートシート](https://www.markdownguide.org/cheat-sheet/)を確認することをお勧めします（例：ハイパーリンク、ボールド、イタリック）。
+また、.md ファイルに名前をつけるときは、単語を区切るために小文字とスペースではなくハイフンを使い括弧は避けてください。
+
+## スタイルガイド
+
+[スタイルガイド](/ja/style-guide/)を読んで、文書のフォーマットや書き方に関するガイドラインを理解し、投稿プロセスをより効率的にしてください。
+
+## 用語集コミュニティに参加する！ {#join-the-glossary-community}
+
+定期的に貢献したい場合は、毎月開催されるGlossary Working Groupのミーティングに参加することを検討してください。
+ミーティングの詳細は、[CNCFカレンダー](https://www.cncf.io/calendar/)で確認できます。
+また、CNCF Slackの[#glossary](https://cloud-native.slack.com/archives/C02TX20MQBB)チャンネルで、メンテナや他の貢献者とつながることもできます。あなたにお会いできるのを楽しみにしています！
+
+## 既存の課題に取り組む {#work-on-an-existing-issue}
+
+[用語集のGitHub issues](https://github.com/cncf/glossary/issues)に行くと、利用可能なissueのリストが見つかります。
+ラベル（例：English language、help needed、good first issue）を使って、課題をフィルタリングすることができます。
+
+![Issueとラベル](/images/how-to/issue-and-labels.png)
+
+選択した用語がすでに誰かに割り当てられていないことを確認してください。
+例えば、ここでは、最初の3つの用語は利用可能ですが、4番目の用語はすでに割り当てられていることがわかります。
+
+![用語を担当する](/images/how-to/howto-04.png)
+
+取り組むべき用語を選択したら、そのissueに対してコメントする。
+
+![issueを主張する](/images/how-to/claiming-an-issue.png)
+
+さらに、CNCF Slackの[#glossary](https://cloud-native.slack.com/archives/C02TX20MQBB)チャンネルでメンテナに通知してください、そして
+_@Catherine Paganini_, _@Seokho Son_, _@Jihoon Seo_, および/または _@iamnoah_ をタグ付けして、メンテナが見逃さないようにします。
+
+次のステップについては、新しい用語の提案（PRの作成）(#submitting-a-new-term)のセクションを参照してください。
+
+**備考**: メンテナがissueをあなたに割り当てた後、そのissueに取り組み始めることができます。
+一度に要求できるのは1つの用語のみです。
+複数の用語に対する作業は順次行われ、次の用語を要求する前に用語を完了させる必要があります。
+
+## 新しい用語の提案 {#propose-new-terms}
+
+新しい用語を提案して他の人に取り組んでもらうことも、自分で新しい定義を作ることもできます。
+いずれにせよ、まずは[issueの作成](#creating-an-issue)から始めることになります。
+用語集に追加するには、すべての新しい用語が[CNCFのクラウドネイティブ定義](https://github.com/cncf/toc/blob/main/DEFINITION.md)を満たしている必要があります。
+ただし、クラウドネイティブの概念を理解するために必要な基礎的な用語だけは例外です。
+
+以下は、GitHubに不慣れな人のためのステップバイステップガイドです。
+**GitHub Pro**の方は、このガイドに _目を通して_ 、以下のトピックについて十分な情報を集めてください：
+
+1. issueおよび新しい用語のテンプレートを探す
+2. issueを要求する
+3. [スペルチェック](#spell-check)の失敗を解決する
+
+### issueを作成する {#creating-an-issue}
+
+[用語集のGitHub repo](https://github.com/cncf/glossary/issues)issuesにアクセスして"New issue"をクリックしてください。
+
+![issues](/images/how-to/howto-01.png)
+
+テンプレート一覧から「Request to add a new term (English)」を選択します。
+
+![templates](/images/how-to/english-issue-template.jpg)
+
+提案する単語を追加し、質問に答え、チェックボックスにチェックを入れて、「Submit new issue」を押してください。
+新しい用語を提案するだけなら、これで完了です！定義に取り組みたい場合は、このまま読み進めてください。
+
+### issueの優先順位 {#triaging-your-issue}
+
+次に、メンテナンス担当者はその問題の優先度を決めます。
+つまり、その用語が用語集に含まれるべきかどうかを評価するのです。
+すべての用語が認められるわけではありません。用語集に含めるには、確立された、広く使われているクラウドネイティブコンセプトである必要があります
+。
+Slackでメンテナに新しい用語を提案したことを知らせてください。そして _@Catherine Paganini_, _@Seokho Son_, _@Jihoon Seo_, および/また _@iamnoah_ のタグを付けることを忘れないでください。
+もし、あなたがその定義に取り組みたいのであればメンテナに知らせてください。メンテナがあなたをアサインします。
+
+### 新しい用語を登録する（PRを作成する） {#submitting-a-new-term}
+
+[スタイルガイド](/ja/style-guide/)にあるように、GoogleやWordのドキュメントで始めることを強くお勧めします。
+
+用語の提出準備が整ったら、「content」へ...
+
+![content](/images/how-to/howto-05.png)
+
+...次に、「en（英語の場合）」または貢献する言語の最初の2文字..
+
+![language folder](/images/how-to/howto-06.png)
+
+...そして `_TEMPLATE.md` を選択します。
+
+![template](/images/how-to/howto-07.png)
+
+内容をコピーする...
+
+![copy content](/images/how-to/howto-08.png)
+
+...「en」フォルダーに戻ります。「Add file」をクリックし、「Create new file」を選択します。
+
+![create new file](/images/how-to/howto-09.png)
+
+[ベストプラクティス](#best-practices)セクションで説明したURLに、用語の名前を追加します。
+名前の最後に拡張子.mdを追加します（この拡張子がないとファイルをプレビューすることができません）。
+次に、下のセクションにテンプレートの内容を貼り付けます。定義のテキストをコピーして、ファイルに貼り付けてください。
+[ベストプラクティス](#best-practices)のセクションで説明したように、マークダウンを使用したことを確認するために、「Preview」をクリックします。
+
+![finalize term](/images/how-to/howto-10.png)
+
+下にスクロールして、新しいコミットファイルに名前をつけます。提出する準備ができたら、「Commit new file」を押してください。
+そして...
+
+![commit new file](/images/how-to/howto-11.png)
+
+...これで新しいPRを作成する準備ができました
+
+![create a pr](/images/how-to/howto-12.png)
+
+「Create pull request」ボタンを押すと、「Pull requests」タブにPRが表示されます。
+
+![prs](/images/how-to/howto-13.png)
+
+## 既存の用語を更新する {#update-an-existing-term}
+
+既存の用語を更新するには、issueを作成して変更を依頼するか、自分で変更を行ってPRを提出します。
+
+### issueから変更を依頼する {#request-a-change-via-an-issue}
+
+用語に関する問題にフラグを立てたい場合は、CNCF用語集ウェブページの「問題を報告する」オプションを使用することができます。
+フラグを立てたいコンセプトのCNCFページで自分の位置を確認し、「Report issue」をクリックします。
+これにより、自動的にあなたのためのissueが開かれます。
+
+![report issue](/images/how-to/howto-14.png)
+
+あなたの提案と、それがなぜ必要なのかを説明してください。送信を押してください、それで終わりです。
+
+![submit issue](/images/how-to/howto-15.png)
+
+### 用語を直接更新する {#update-a-term-directly}
+
+用語を修正したり、提案を提出したりするには、「Edit this page」をクリックします。
+
+![edit this page](/images/how-to/howto-16.png)
+
+これにより、その用語のGitHubページが開きます。変更を加え、PRを作成してください。
+上記の[ベストプラクティス](#best-practices)セクションを参照し、私たちの[スタイルガイド](/ja/style-guide/)を読んで、私たちのガイドラインに従っていることを確認してください。
+
+## 用語集のローカライズを支援する {#help-localize-the-glossary}
+
+用語集を目的の言語にローカライズするのを手伝うには、CNCF Slackワークスペースの [#glossary-localizations](https://cloud-native.slack.com/archives/C02N2RGFXDF) チャンネルに参加し、私たちにメッセージを送ってください。
+既存のチームに参加することも、新しいチームを作ることもできます。
+(何が必要かは、[ローカリゼーションガイド](https://github.com/cncf/glossary/blob/main/LOCALIZATION.md)を読んでください)。
+チームの貢献プロセスの詳細を収集するために、目的の言語の **How to contribute** ガイドをお読みください。
+
+## スペルチェック {#spell-check}
+
+スペルチェックが失敗する理由は、主に2つあります：
+
+- PRにスペルミスが含まれている。
+- PRには、単語リストに登録されていない単語が含まれています。
+
+新しい単語をリストに追加するには、次の手順に従います：
+
+1. PRの中に「wordlist.txt」というファイルを見つけます。
+2. 「このファイルを編集する」をクリックし、不足している単語をアルファベット順に追加します。
+3. コミットメッセージを追加し、「サインオフして変更を提案する」を選択します。
+
+**注意**：スペルチェックは大文字と小文字を区別しません。
+
+
+**[The Good Docs Project](https://thegooddocsproject.dev/)のテンプレートに基づき、このガイドを更新しました。**
\ No newline at end of file
diff --git a/content/ja/contributor-ladder/_index.md b/content/ja/contributor-ladder/_index.md
new file mode 100644
index 0000000000..e82a636d9a
--- /dev/null
+++ b/content/ja/contributor-ladder/_index.md
@@ -0,0 +1,101 @@
+---
+title: 貢献者のラダー
+toc_hide: true
+status: Completed
+menu:
+  main:
+    weight: 10
+---
+
+こんにちは！👋 CNCFクラウドネイティブ用語集プロジェクトへの貢献に関心をお寄せいただきありがとうございます。新しい用語を投稿する、用語集を母国語にローカライズするのを手伝う、または他の人が用語集を始めるのを手助けするなど、このコミュニティのアクティブメンバーになる方法はたくさんあります。このドキュメントでは、プロジェクト内におけるそれぞれの貢献者の役割と、それに伴う責任と権限の概要を説明します。
+
+## 1. 貢献者
+
+用語集はすべての人のためのものです。このプロジェクトに貢献するだけで、誰でも用語集の貢献者になることができます。すべての貢献者は、[CNCF行動規範](https://github.com/cncf/foundation/blob/main/code-of-conduct.md)に従うことが期待されています。
+
+プロジェクトに貢献するには、以下のようなさまざまな方法があります：
+
+- **コンテンツの貢献者**: 既存の用語を改良したり、新しい用語を投稿する方々
+- **ローカライゼーションの貢献者**: 用語集を他の言語に翻訳するのを手伝ってくれる方
+- **ヘルパー**：GitHubやSlackなど、コミュニティメンバーがサポートを必要としている場所で助ける方
+- **アンバサダー**：多くの人にメッセージを伝え、コミュニティに貢献の仕方やその理由について教えてくれる方
+
+貢献者は、複数の役割を持つことも、1つの分野のみに集中することもできます。***これらの貢献はすべて等しく重要であり***、活気あるコミュニティの育成に貢献します。コンテンツとローカライゼーションへの貢献については、[貢献方法](/ja/contribute/)と[スタイルガイド](/ja/style-guide/)を参照してください。
+
+## 2. 承認者
+
+承認者は、PRに対するフィードバックを提供しPRを承認します。アクティブな投稿者なら誰でも承認者になれます（[承認者になる](#承認者になる)を参照）。用語集では、(1)英語用語集の承認者と(2)ローカライズチームの承認者の2つの承認者を区別しています。
+
+用語集の承認者には次のことが期待されます：
+
+- PRが技術的に正確かどうかを確認します
+- 貢献者に課題を割り当て、適切なラベルを付けます
+- 貢献者にフィードバックを提供し、必要に応じて指導します
+- 提出物の校正と編集します
+
+承認者が上記の職務に興味がなくなったり、遂行できなくなった場合は、メンテナにその旨を伝え辞任すべきです。
+
+### 英語用語集の承認者
+
+承認者には3つのタイプがあります：
+
+1) 強力な技術的背景を持つ承認者
+2) 確かな文章力を持つ承認者
+3) 両方に精通した承認者
+
+**技術承認者**：しっかりとした英文のライティングスキルがなくても、技術的なバックグラウンドが強力な人なら承認者になれます。ただし、技術的な利点に基づいてPRを承認する場合は、必ず（編集）承認者によるレビューをしなければなりません。
+
+**編集者**：編集者は用語を校正し、スタイルガイドに従って簡単な言葉で説明されていることを確認します。用語が大幅に編集されている場合、編集者は意味が変更されていないことを確認するため、技術承認者に再度校閲を依頼しなければなりません。
+
+### ローカライゼーションの承認者
+
+用語集にはローカライゼーション承認者もいます。この承認者は、ローカライゼーションチーム (用語集を翻訳するチーム) の承認者です。ローカライゼーションの承認者は、自分のチームの承認者の職務のみを行うことができ、PRを専用の開発ブランチにマージすることができます。ローカライゼーションの承認者は、要件を満たせば英語用語集の承認者になることもできます。
+
+### 承認者になる
+
+承認者候補は、高品質のPRを提出し、他の人がPRをマージ可能な状態にするのを支援してきた実績があるべきです。また、タイムゾーンが許せば[用語集ワーキンググループのミーティング](https://www.cncf.io/calendar/)に定期的に出席してください。
+
+承認者になるには、興味があることを既存のメンテナーに伝えることから始めましょう。既存のメンテナーはあなたに、彼らの指導のもとでPRを投稿したり、レビューをしたり、その他の仕事をしたり上記の資格を証明するよう求めます。しばらく一緒に仕事をした後、メンテナーはあなたに承認者の資格を与えるかどうかを決定します。この決定は、あなたが示した熟練度と対応能力に基づいて行われます。
+
+## 3. メンテナー
+
+メンテナーもPRをマージすることができます。誰でも用語集のメンテナーになることができます（[メンテナーになる](#メンテナーになる)を参照）。メンテナーには、以下のような期待があります：
+
+- 積極的かつ迅速な承認者であること（上記参照）
+- サイトの設定、パーミッション、Issueテンプレート、GitHubワークフローなど、リポジトリのメンテナンスをサポートします
+- 用語集のSlackチャンネルを監視し可能な限り協力します
+- [用語集ワーキンググループミーティング](https://www.cncf.io/calendar/)に定期的に出席します（タイムゾーンが許せば）
+
+もしメンテナーが上記の職務に興味がなくなったり、遂行できなくなったりした場合は、名誉メンテナーに移行する必要があります。
+
+### メンテナーになる
+
+メンテナーは、承認者として成功し、質の高いPRを提出してきた実績があるべきです。また、タイムゾーンが許せば用語集ワーキンググループのミーティングに定期的に出席する必要があります。
+
+メンテナーになるには、興味があることを既存のメンテナーに伝えることから始めましょう。既存のメンテナーはあなたに、彼らの指導のもとでPRを投稿したり、レビューをしたり、その他の仕事をしたり上記の資格を証明するよう求めます。しばらく一緒に仕事をした後、メンテナーはあなたにメンテナーの地位を与えるかどうかを決定します。この決定は、あなたが示した熟練度と対応能力に基づいて行われます。
+
+## 4. コミュニティマネージャー
+
+コミュニティマネージャーは、有効的で魅力的なコミュニティの育成を支援します。コミュニティメンバーは誰でもコミュニティマネージャーになることができます。コミュニティマネージャーには次のことが求められます：
+
+- 新しいメンバーを歓迎し、必要な情報が得られるようにします
+- コミュニティからの質問に答えたり、手助けできる人を探すのを手伝います
+- Slackでの会話をモデレートします
+
+### コミュニティマネージャーになる
+
+用語集のコミュニティマネージャーは誰でもなることができます。コミュニティマネージャーは、貢献とローカライゼーションのプロセスをしっかりと理解し、他者との交流や手助けを楽しむことが求められます。コミュニティマネージャーになるには、興味があることを既存のメンテナーに伝えることから始めましょう。オンボード/トライアル期間を経て、メンテナーは実績に基づいてコミュニティマネージャーのステータスを付与するかどうかを決定します。
+
+## 非自主的な解任
+
+貢献者の非自主的な解任は、責任と要求が満たされない場合に行われます。これには、度重なる活動停止、長期の活動停止、および/または行動規範違反などが含まれます。このプロセスは、コミュニティとその成果物を保護すると同時に、新しい貢献者が参入する機会を開くという意味で重要です。
+
+## 退任/名誉職のプロセス
+
+貢献者のコミットメントレベルが変化した場合、貢献者は退任（貢献者のラダーを下げること[^1]）か名誉職（プロジェクトから完全に離れる）かを検討することができます。
+
+[^1]: 訳注：例えば、メンテナ―から承認者に貢献レベルを落とす
+
+## 役職への復帰
+
+以前の貢献者の役割に戻ることができる人材がいれば、プロジェクトリーダーはそれを手配し、検討することができます。
diff --git a/content/ja/devops.md b/content/ja/devops.md
new file mode 100644
index 0000000000..e497556f50
--- /dev/null
+++ b/content/ja/devops.md
@@ -0,0 +1,31 @@
+---
+title: DevOps
+status: Completed
+category: コンセプト
+tags: ["方法論", "", ""]
+---
+
+DevOpsは、アプリケーション開発から本番運用までの全過程をチームが所有する方法論で、それゆえDevOpsと呼ばれます。
+これは一連の技術を実装することを超えて、文化やプロセスの完全な変革を必要とします。
+DevOpsは、(全体の機能ではなく)小さなコンポーネントに取り組むエンジニアのグループを求め、エラーの一般的な原因である引き渡しの回数を減らします。
+
+## 解決すべき問題はなんですか
+
+従来、[密結合な](/ja/tightly-coupled-architectures/)[モノリシックアプリ](/ja/monolithic-apps/)を持つ複雑な組織では、
+通常、作業は複数のグループ間で断片化されていました。
+これにより多くの引き渡しと長いリードタイムが発生しました。
+コンポーネントやアップデートが準備できるたびに、それは次のチームのキューに置かれました。
+個々の担当者はプロジェクトの一部分のみを扱うため、このアプローチは所有権の欠如につながりました。
+彼らの目標は、作業を次のグループに渡すことであり、顧客に適切な機能を提供することではありませんでした。
+これは明らかな優先順位のずれです。
+
+コードが最終的に本番環境に入る頃には、多くの開発者を経由し、多くのキューで待機していたため、
+コードが動作しない場合の問題の原因を追跡するのが難しくなりました。
+DevOpsはこのアプローチを根本から覆します。
+
+## どのように役に立つのでしょうか
+
+アプリケーションの全ライフサイクルを一つのチームが担当することで、
+引き渡しを最小限に抑え、本番環境へデプロイする際のリスクを減少させ、
+チームが本番環境でのコードのパフォーマンスにも責任を持つことでコード品質が向上し、
+より多くの自律性と所有権により従業員の満足度も高まります。
diff --git a/content/ja/function-as-a-service.md b/content/ja/function-as-a-service.md
new file mode 100644
index 0000000000..57f2b664b7
--- /dev/null
+++ b/content/ja/function-as-a-service.md
@@ -0,0 +1,34 @@
+---
+title: Function as a Service (FaaS)
+status: Completed
+category: テクノロジー
+tags: ["インフラストラクチャー", "", ""]
+---
+
+Function as a Service (FaaS)は、
+[サーバーレス](/ja/serverless/)、[クラウドコンピューティング](/ja/cloud-computing/)、[サービス](/ja/service/)の一種であり、
+イベントによってコードを実行することを可能にします。
+これは通常、[マイクロサービス](/ja/microservices-architecture/)アプリケーションの構築や立ち上げに関連する、
+複雑なインフラストラクチャーのメンテナンスを必要としません。
+FaaSを使用すると、ユーザーは関数とデータのみを管理し、クラウドプロバイダーがアプリケーションを管理します。
+これにより、開発者はコードが実行されていないときにサービスの費用を支払うことなく、必要な機能を得ることができます。
+
+## 解決すべき問題はなんですか
+
+従来のオンプレミスシナリオでは、企業は自社のデータセンターの管理や維持をします。
+企業はサーバー、ストレージ、ソフトウェア、その他の技術に投資し、ITスタッフや請負業者を雇ってすべての機器やライセンスの購入、管理、更新を行う必要があります。
+データセンターは、作業負荷が減少しリソースがアイドリング状態の時期があるにも関わらず、ピーク需要に対応できるように建設されなければなりません。
+逆にビジネスが急速に成長する場合、IT部門は追いつくのに苦労するかもしれません。
+標準的な[Infrastructure-as-a-Service (IaaS)](/ja/infrastructure-as-a-service/)クラウドコンピューティングモデルでは、
+ユーザーは事前に容量ユニットを購入します。
+つまりアプリを実行するために、サーバーコンポーネントを常時起動させ、それに対する支払いをパブリッククラウドプロバイダーに行います。
+需要が高まる時にサーバー容量を増やし、その容量が不要になった時に減らすのはユーザーの責任です。
+アプリが使用されていないときでも、そのアプリを実行するためのクラウドインフラは稼働しています。
+
+## どのように役に立つのでしょうか
+
+FaaSはサーバーを管理することなく、イベントに応じてウェブアプリケーションを実行するための[抽象化](/ja/abstraction/)を開発者に提供します。
+例えば、ファイルのアップロードがそのファイルを様々な形式にトランスコードするカスタムコードのトリガーとなるかもしれません。
+FaaSのインフラストラクチャーは、頻繁に使用するコードを自動的にスケールアップし、
+開発者は[スケーラビリティ](/ja/scalability/)のためのコード構築に時間やリソースを費やす必要がありません。
+課金は計算時間のみに基づいているため、機能が使用されていない時には企業は支払いをする必要がありません。
diff --git a/content/ja/idempotence.md b/content/ja/idempotence.md
new file mode 100644
index 0000000000..5702efafc9
--- /dev/null
+++ b/content/ja/idempotence.md
@@ -0,0 +1,9 @@
+---
+title: 冪等性
+status: Completed
+category: プロパティ
+tags: ["プロパティ", "", ""]
+---
+
+数学やコンピュータサイエンスにおいて、冪等性とは、何度実行しても常に同じ結果になる操作を指します。
+パラメーターが同じであれば、冪等な操作を複数回実行しても、追加の効果はありません。
diff --git a/content/ja/kubernetes.md b/content/ja/kubernetes.md
new file mode 100644
index 0000000000..429f523c31
--- /dev/null
+++ b/content/ja/kubernetes.md
@@ -0,0 +1,33 @@
+---
+title: Kubernetes
+status: Completed
+category: テクノロジー
+tags: ["インフラストラクチャー", "基礎", ""]
+---
+
+Kubernetesは、しばしばK8sと略される、オープンソースのコンテナオーケストレーターです。
+Kubernetesは、モダンなインフラストラクチャー上でコンテナ化されたアプリケーションのライフサイクルを自動化し、[分散システム](/ja/distributed-systems/)全体でアプリケーションを管理するデータセンターのオペレーティングシステムとして機能します。
+
+Kubernetesは、[クラスター](/ja/cluster/)内の[ノード](/ja/nodes/)にまたがって[コンテナ](/ja/container/)をスケジュールし、ロードバランサーや永続ストレージなど、いくつかのインフラストラクチャーリソースを束ねてコンテナ化されたアプリケーションを実行します。
+
+Kubernetesは自動化と拡張性を実現し、ユーザーが宣言的に（以下参照）かつ再現可能な方法でアプリケーションをデプロイできるようにします。
+Kubernetesは[API](/ja/application-programming-interface/)を介して拡張可能であり、経験豊富なKubernetesの専門家が自分たちのニーズに応じて拡張することができます。
+
+## 解決すべき問題はなんですか
+
+インフラストラクチャーの自動化と宣言的な設定の管理は長い間重要な概念でしたが、[クラウドコンピューティング](/ja/cloud-computing/)が人気になるにつれて、その重要性がさらに増していきました。
+計算機リソースへの需要が増加し、組織がより少ないエンジニアでより多くの運用機能を提供する必要が生じる中、その需要に応えるためには新しい技術や作業方法が求められています。
+
+## どのように役に立つのでしょうか
+
+従来の[Infrastracture as Code](/ja/infrastructure-as-code/)ツールと同様にKubernetesは自動化を支援しますが、コンテナを用いて動作するという利点があります。
+コンテナは[仮想マシン](/ja/virtual-machine/)や物理マシンよりも設定のずれに対する耐性があります。
+
+さらにKubernetesは宣言的に動作します。つまり、オペレータがマシンに何かを行う方法を指示するのではなく、インフラストラクチャーがどのようにあるべきかを記述します。これは通常、マニフェストファイル（例えばYAML）として記述されます。
+その後、Kubernetesが実行方法の詳細を管理します。
+これにより、KubernetesはInfrastracture as Codeと非常に互換性が高くなっています。
+
+またKubernetesは[セルフヒーリング](/ja/self-healing/)を行います。
+セルフヒーリングによって、クラスターの実際の状態は、常にオペレータの望む状態と一致します。
+Kubernetesがマニフェストファイルで記述された内容と異なる点を検出した場合、Kubernetesコントローラーがそれを修正します。
+Kubernetesが使用するインフラストラクチャーは絶えず変化しているかもしれませんが、Kubernetesは常に自動的に変化に適応し、望ましい状態と一致するように保証します。
diff --git a/content/ja/loosely-coupled-architecture.md b/content/ja/loosely-coupled-architecture.md
new file mode 100644
index 0000000000..8712a34dd1
--- /dev/null
+++ b/content/ja/loosely-coupled-architecture.md
@@ -0,0 +1,15 @@
+---
+title: 疎結合アーキテクチャ
+status: Completed
+category: プロパティ
+tags: ["基礎", "アーキテクチャ", "プロパティ"]
+---
+
+疎結合アーキテクチャは、アプリケーションの構成要素それぞれが互いに独立して構築されるようなアーキテクチャです
+(その逆は[密結合アーキテクチャ](/ja/tightly-coupled-architectures/)と呼ばれます)。
+[マイクロサービス](/ja/microservice/)とよく呼ばれる個々の構成要素は、その他多くのサービスから利用できるような方法で、特定の機能を果たすよう構築されます。
+疎結合アーキテクチャは密結合アーキテクチャより一般的に実装が遅くなりますが、特にアプリケーションがスケールする際に多くの利点があります。
+
+アプリケーションが疎結合だと、チームは独立して機能開発、デプロイ、スケールすることが可能です。
+よって組織は個々の構成要素における開発サイクルを素早く反復することができます。
+アプリケーション開発はより速くなり、チームは能力に基づいて構成され、特定のアプリケーションに注力することができます。
diff --git a/content/ja/microservices-architecture.md b/content/ja/microservices-architecture.md
new file mode 100644
index 0000000000..df6aee24fd
--- /dev/null
+++ b/content/ja/microservices-architecture.md
@@ -0,0 +1,21 @@
+---
+title: マイクロサービスアーキテクチャ
+status: Completed
+tags: ["インフラストラクチャー", "基礎", ""]
+---
+
+マイクロサービスアーキテクチャは、アプリケーションを個々の独立した（マイクロ）[サービス](/ja/service/)に分割するアーキテクチャ手法で、各サービスは特定の機能に焦点を当てています。これらのサービスは密接に連携して動作し、エンドユーザーには単一のエンティティとして見えます。例として、Netflix を考えてみます。そのインターフェイスは、ビデオへのアクセス、検索、プレビューが可能です。これらの機能は、ブラウザでの認証、検索、プレビューの実行など、それぞれ一つの機能を扱う小さなサービスによって実現されている可能性が高いです。
+
+このアーキテクチャ手法により、[モノリシックアプリケーション](/ja/monolithic-apps/)（以下に詳細あり）のようにすべてが密接に結合している場合よりも、開発者は新機能を迅速に導入したり機能を更新したりすることができます。
+
+## 解決すべき問題はなんですか
+
+アプリケーションは、さまざまなパーツで構成され、それぞれが特定の能力を担当します。特定の機能に対する需要は、アプリケーションの他のパーツに対する需要と連動して必ず増減するわけではありません。Netflix の例に戻りましょう。例えば、大規模なマーケティングキャンペーンの後で、Netflix の契約者数が急増したが、その日の早い時間帯におけるストリーミングは概ね安定しているとします。
+契約者数の急増は、平常時より多くのキャパシティを要求します。伝統的な手法（モノリシックアプローチ）の場合では、増加に対応するためにアプリ全体を[スケールアップ](/ja/scalability/)する必要がありました。これは非常に非効率的なリソースの使い方です。
+
+また、モノリシックアーキテクチャは、開発者が設計の落とし穴に陥りやすくするものです。すべてのコードが一か所にあるため、そのコードが[密結合](/ja/tightly-coupled-architectures/)になりやすく、関心の分離の原則を適用することが難しくなります。さらに、多くの場合、モノリスはデプロイする前にコードベース全体を理解する必要性を生じさせます。マイクロサービスアーキテクチャは、こうした課題への対応策です。
+
+## どのように役に立つのでしょうか
+
+機能を異なるマイクロサービスに分離することにより、それらを独立してデプロイ、アップデート、スケールすることが容易になります。また、意図せずアプリケーションの他のパーツに悪影響を与えることなく、大きなアプリケーションの一部に対して複数のチームが同時に作業することを可能にします。
+マイクロサービスアーキテクチャは多くの問題を解決しますが、デプロイして追跡する必要があるものが桁違いに増えるため、運用上のオーバーヘッドも発生させます。多くの[クラウドネイティブテクノロジー](/ja/cloud-native-tech/)は、マイクロサービスのデプロイと管理を容易にすることを目指しています。
diff --git a/content/ja/monolithic-apps.md b/content/ja/monolithic-apps.md
new file mode 100644
index 0000000000..b670a7287c
--- /dev/null
+++ b/content/ja/monolithic-apps.md
@@ -0,0 +1,22 @@
+---
+title: モノリシックアプリケーション
+status: Completed
+category: コンセプト
+tags: ["アーキテクチャ", "基礎"]
+---
+
+モノリシックアプリケーションは単独で配置できるプログラムにすべての機能を格納しており、アプリケーションを開発する時に最も簡単かつ手軽な出発点とされています。
+しかし、アプリケーションが複雑になると、モノリスのメンテナンスが難しくなることがあります。 
+また、同じコードベースで作業する開発者が増えるため、変更が競合したり、開発者の間で直接コミュニケーションを取る必要性が高まります。
+
+## 解決すべき問題はなんですか
+
+アプリケーションを[マイクロサービス](/ja/microservices-architecture/)に移行するとテスト、デプロイ、実行などの運用オーバーヘッドが増加します。
+そのため、製品ライフサイクルの初期段階には製品を複雑化させる物は先送り、製品が成功したと判断されるまでモノリシックアプリーケーションで設計することが有利な場合もあります。
+
+## どのように役に立つのでしょうか
+
+適切に設計されたモノリスはアプリケーションを起動して実行する最も簡単な方法であるため、簡潔さを維持できます。
+モノリシックアプリーケーションがビジネス的に価値があると証明されれば、アプリケーションを分割し、マイクロサービス化させる事も可能です。
+価値が証明される前に技術的努力を費やし、マイクロサービス基盤でアプリケーションを開発することは早計である可能性があります。
+アプリケーションが価値を生まなければ、その努力も無駄になるためです。
\ No newline at end of file
diff --git a/content/ja/nodes.md b/content/ja/nodes.md
new file mode 100644
index 0000000000..14bf72b188
--- /dev/null
+++ b/content/ja/nodes.md
@@ -0,0 +1,25 @@
+---
+title: ノード
+status: Completed
+category: コンセプト
+tags: ["インフラストラクチャー", "基礎", ""]
+---
+
+ノードとは、他のコンピューター、つまり他のノードと協力して共通のタスクを達成するコンピューターのことです。
+例えばあなたのラップトップ、モデム、プリンターを考えてみてください。
+これらはすべてあなたのWi-Fiネットワークを介して接続されており、通信し協力しており、それぞれが一つのノードを表しています。
+[クラウドコンピューティング](/ja/cloud-computing/)において、ノードは物理的なコンピューターであったり、仮想コンピューター、つまり[VM](/ja/virtual-machine/)（バーチャルマシン）であったり、または[コンテナ](/ja/container/)であることもあります。
+
+## 解決すべき問題はなんですか
+
+アプリケーションは1台のマシン上で動作させることができます(そして実際に多くのアプリケーションがそうしています)が、それにはいくつかのリスクが伴います。
+具体的には、基盤となるシステムの故障がアプリケーションの中断を引き起こすことです。
+これに対処するために、開発者たちは[分散アプリケーション](/ja/distributed-apps/)を作り始めました。
+これは、各プロセスがそれぞれのノード上で動作します。
+それゆえ、ノードはアプリやプロセスを実行し、共通の目標を達成するために協力するノードの[クラスター](/ja/cluster/)、またはグループの一部として機能します。
+
+## どのように役に立つのでしょうか
+
+ノードはクラスタに割り当てることができる計算上の明確な違いがある単位(メモリ、CPU、ネットワーク)を提供します。
+[クラウドネイティブ](/ja/cloud-native-tech/)プラットフォームやアプリでは、ノードは作業を行うことができる単一のユニットを表します。
+理想的には個々のノードには区別がなく、特定のタイプのあるノードは、同じタイプの他のノードと区別がつかないものとされます。
diff --git a/content/ja/observability.md b/content/ja/observability.md
new file mode 100644
index 0000000000..45691feaaf
--- /dev/null
+++ b/content/ja/observability.md
@@ -0,0 +1,16 @@
+---
+title: 可観測性
+status: Completed
+category: コンセプト
+tags: ["プロパティ", "", ""]
+---
+
+可観測性とは、システムが実用的な洞察をどの程度出力できるかを決める性質のことを指します。
+可観測性により、ユーザーはシステム外部への出力を元にそのシステムの状態を理解し、(是正)措置を取ることが可能になります。
+
+コンピューターシステムは、CPU時間・メモリ・ディスク容量といった低水準のシグナルや、APIの応答時間・エラー数・秒間トランザクション数などを含む高水準でビジネスに直結するシグナルを観測することで評価されます。
+可観測なシステムは、いわゆる可観測性ツールと言われる専門のツールで**観測**(もしくは監視)されます。可観測性ツールの一覧は[クラウドネイティブ ランドスケープの可観測性セクション](https://landscape.cncf.io/card-mode?category=observability-and-analysis&grouping=category)で見られます。
+
+可観測なシステムは、有意義かつ実用的なデータを運用者に提供し、運用者が(インシデントへのより素早い対応や開発者の生産性向上といった)好ましい結果を出すことを可能にします。システムのダウンタイムとともに、手間のかかる手作業での仕事も少なくなります。
+
+結果として、システムの運用コストと開発コストは、そのシステムがどれだけ可観測なのかに大きく影響を受けるでしょう。
diff --git a/content/ja/pod.md b/content/ja/pod.md
new file mode 100644
index 0000000000..28102d6e15
--- /dev/null
+++ b/content/ja/pod.md
@@ -0,0 +1,31 @@
+---
+title: Pod
+status: Completed
+category: コンセプト
+tags: ["インフラストラクチャー", "基礎", ""]
+---
+
+[Kubernetes](/ja/kubernetes/)環境の中では、Podは最も基本的なデプロイ可能ユニットとして機能します。
+これはコンテナ化されたアプリケーションをデプロイし、管理するための基本的な構成要素を表しています。
+各Podには単一のアプリケーションインスタンスが含まれ、一つ以上の[コンテナ](/ja/container/)を保持することができます。
+Kubernetesは、より大規模なDeploymentの一部としてPodを管理し、必要に応じてPodを[垂直スケーリング](/ja/vertical-scaling/)または[水平スケーリング](/ja/horizontal-scaling/)することができます。
+
+## 解決すべき問題はなんですか
+
+コンテナは一般的に、特定のワークロードを実行し制御する独立した単位として機能しますが、
+コンテナが密接に相互作用し、適切に連携して制御される必要がある場合もあります。
+
+これらの密接に関連するコンテナがそれぞれ個別に管理される場合、冗長な管理作業が発生します。
+たとえば、オペレーターは関連するコンテナの配置を繰り返し判断し、それらが一緒に保たれるようにしなければなりません。
+また、これらの関連するコンテナのライフサイクルは同期される必要がありますが、個別にしか管理できません。
+
+## どのように役に立つのでしょうか
+
+Podは密接に関連するコンテナを単一のユニットにまとめることで、
+コンテナ操作を大幅に簡素化します。
+たとえば、補助的なコンテナは、追加機能を提供したり、グローバルな設定を行うために主コンテナと一緒に使用されることがよくあります。
+これには、基本設定を主コンテナに注入して適用するコンテナ、
+_sidecar_(コンテナ)であり、主コンテナのためのネットワークトラフィックルーティングを処理する([サービスメッシュ](/ja/service-mesh/)を参照)、
+あるいは各コンテナと連動してログを収集するコンテナなどが含まれます。
+
+メモリとCPUの割り当ては、Podレベルで定義することも、コンテナごとに定義することもできます。Podレベルで定義すると、内部のコンテナがリソースを柔軟に共有できます。
diff --git a/content/ja/reliability.md b/content/ja/reliability.md
new file mode 100644
index 0000000000..fb2febb94a
--- /dev/null
+++ b/content/ja/reliability.md
@@ -0,0 +1,11 @@
+---
+title: 信頼性
+status: Completed
+category: プロパティ
+tags: ["基礎", "プロパティ", ""]
+---
+
+クラウドネイティブの観点から見ると、信頼性とはシステムが障害にどれだけうまく対応するかを指します。
+インフラストラクチャーが変化し、個々のコンポーネントが故障しても動作し続ける[分散システム](/ja/distributed-systems/)があれば、それは信頼性があります。
+一方で、容易に故障し、運用者が手動で介入して動作を維持する必要がある場合、それは信頼性がないです。
+[クラウドネイティブアプリケーション](/ja/cloud-native-apps/)の目標は、本質的に信頼性の高いシステムを構築することです。
diff --git a/content/ja/role-based-access-control.md b/content/ja/role-based-access-control.md
new file mode 100644
index 0000000000..914c94f30e
--- /dev/null
+++ b/content/ja/role-based-access-control.md
@@ -0,0 +1,25 @@
+---
+title: ロールベースアクセス制御(RBAC)
+status: Completed
+category: コンセプト
+tags: ["セキュリティ", "", ""]
+---
+
+ロールベースアクセス制御(RBAC)は、チームあるいはより大きな組織内での個々のロールに基づいてシステムやネットワーク、リソースへのアクセスを管理するセキュリティ方法です。
+RBACは、管理者に特定の職務を持つすべてのユーザーに必要なアクセスレベルを割り当て、
+事前に定義された一連の権限を持つ役割をそれらのユーザーに割り当てる権限を与えます。
+組織はRBACを利用して、従業員ごとの役割と責任に合わせた、さまざまなレベルのアクセスを提供します。
+
+## 解決すべき問題はなんですか
+
+RBACは、特にアプリケーションとチームメンバーの数が増えるにつれて、
+チームメンバーやアプリケーションがアクセスできるリソース、
+および彼らが実行できる操作を制御するという課題に対処します。
+管理者は、各ユーザーがアクセスする必要があるリソースに対して正しい権限を持っていることを確認する必要がありますが、
+これは構造化されたアクセス制御メカニズムがなければ煩雑で間違いが生じやすい作業になります。
+
+## どのように役に立つのでしょうか
+
+RBACは、ITチームにグループ内のすべてのユーザーの権限を同時に簡単に管理したり、役割を割り当てたり削除することで、個々のユーザーのアクセスレベルをすばやく調整する能力を提供します。
+これにより、機密データを保護し従業員が職務に必要な情報のみにアクセスし、行動できるようにします。
+結果として、RBACはアクセス管理やセキュリティを強化し、組織内の運用効率を向上させます。
diff --git a/content/ja/scalability.md b/content/ja/scalability.md
new file mode 100644
index 0000000000..655d120645
--- /dev/null
+++ b/content/ja/scalability.md
@@ -0,0 +1,18 @@
+---
+title: スケーラビリティ
+status: Completed
+category: コンセプト
+tags: ["基礎","プロパティ" , ""]
+---
+
+スケーラビリティは、システムがどれだけ拡張できるのかを示す特性を指します。
+
+この特性により、システムが行うべき任意の処理に対して、その処理能力を増強することが可能となります。
+
+例として、[Kubernetes](/ja/kubernetes/)[クラスタ](/ja/cluster/)は、[コンテナ化](/ja/containerization/)されたアプリの数を増減することでスケールしますが、そのスケーラビリティはいくつかの要素に依存します。[ノード](/ja/nodes/)の数、各ノードが処理できる[コンテナ](/ja/container/)の数、コントロールプレーンがサポート可能なレコードとオペレーションの規模と関係しています。
+
+スケーラブルなシステムは、キャパシティの追加を容易に行えます。
+
+私たちはスケーリングアプローチを2種類に分類します。[水平スケーリング](/ja/horizontal-scaling/)では、増加した負荷を処理するためにより多くのノードを追加します。一方で、[垂直スケーリング](/ja/vertical-scaling/)では、個々のノードがより多くのトランザクションを実行するために性能向上します（例えば、個別のマシンにより多くのメモリやCPUを追加すること）。
+
+スケーラブルなシステムは、容易に変更することができ、ユーザーのニーズに応えることができます。
diff --git a/content/ja/service.md b/content/ja/service.md
new file mode 100644
index 0000000000..268a7f4fc3
--- /dev/null
+++ b/content/ja/service.md
@@ -0,0 +1,12 @@
+---
+title: サービス
+status: Completed
+category: コンセプト
+tags: ["アプリケーション", "基礎", ""]
+---
+
+ITの分野において、サービスという言葉には複数の意味があります。
+この定義では、より伝統的な意味でのサービス、つまりマイクロサービスとしてのサービスに焦点を当てます。
+サービスがマイクロサービスとどのように異なるのかは微妙であり、人によって異なる意見を持つかもしれません。
+高レベルの定義としては、これらを同じものとして扱います。
+[マイクロサービス](/ja/microservices-architecture/)の定義を参照してください。
diff --git a/content/ja/site-reliability-engineering.md b/content/ja/site-reliability-engineering.md
new file mode 100644
index 0000000000..897d6f8edb
--- /dev/null
+++ b/content/ja/site-reliability-engineering.md
@@ -0,0 +1,27 @@
+---
+title: Site Reliability Engineering
+status: Completed
+category: コンセプト
+tags: ["方法論", "", ""]
+---
+
+SRE(Site Reliability Engineering)は、オペレーションとソフトウェアエンジニアリングを組み合わせた分野です。
+後者では、特にインフラストラクチャーとオペレーションの問題に応用されます。
+つまり製品機能を構築する代わりに、SREエンジニアは、アプリケーションを実行するためのシステムを構築します。
+[DevOps](/ja/devops/)との類似点がありますが、DevOpsがコードを本番環境に導入することに焦点を当てているのに対し、
+SREは本番環境で実行中のコードが適切に機能することを保証します。
+
+## 解決すべき問題はなんですか
+
+アプリケーションを[高い信頼性](/ja/reliability/)で実行するためには、
+パフォーマンスモニタリング、アラート、デバッグ、トラブルシューティングなど、複数の機能が必要です。
+これらがなければ、システムオペレーターは問題に対応するだけで、積極的にそれらを回避しようとすることはできません。
+— ダウンタイムは時間の問題となるだけです。
+
+## どのように役に立つのでしょうか
+
+SREのアプローチは、基盤となるシステムを継続的に改善することで、ソフトウェア開発プロセスのコスト、時間、労力を最小限に抑えます。
+システムは、インフラストラクチャーとアプリケーションコンポーネントを継続的に測定し監視します。
+何か問題が発生した場合、システムはSREエンジニアにいつ、どこで、どのように修正するかを指摘します。
+このアプローチを用いて運用タスクを自動化することで、
+高度に[スケーラブル](/ja/scalability/)で信頼性の高いソフトウェアシステムを作成するのに役立ちます。
diff --git a/content/ja/stateful-apps.md b/content/ja/stateful-apps.md
new file mode 100644
index 0000000000..7368e4db24
--- /dev/null
+++ b/content/ja/stateful-apps.md
@@ -0,0 +1,16 @@
+---
+title: ステートフルアプリケーション
+status: Completed
+category: プロパティ
+tags: ["基礎", "アプリケーション", "プロパティ"]
+---
+
+ステートフル(および[ステートレス](/ja/stateless-apps/))アプリについて話すとき、ステートとは、アプリが設計通りに機能するために必要なあらゆるデータを指します。
+例えば、カートの情報を保存しているオンラインショップなどはステートフルアプリです。
+
+今日、私たちが使用するほとんどのアプリケーションは少なくとも部分的にステートフルです。
+しかし、クラウドネイティブ環境では、ステートフルアプリは難しいです。
+これは、[クラウドネイティブアプリ](/ja/cloud-native-apps)が非常に動的だからです。
+これらはスケーリング、再起動、別の場所への移動が可能ですが、それでもそのステートにアクセスできる必要があります。
+
+そのため、ステートフルアプリには、データベースのようにどこからでもアクセス可能な何らかのストレージが必要です。
diff --git a/content/ja/style-guide/_index.md b/content/ja/style-guide/_index.md
new file mode 100644
index 0000000000..bd6082bba1
--- /dev/null
+++ b/content/ja/style-guide/_index.md
@@ -0,0 +1,184 @@
+---
+title: スタイルガイド
+toc_hide: true
+status: Completed
+menu:
+  main:
+    weight: 10
+---
+
+このスタイルガイドは、用語集の読者、定義の構造、必要な詳細度、一貫したスタイルを維持する方法について理解するのに役立ちます。
+
+クラウドネイティブ用語集は、CNCFリポジトリの[デフォルトスタイルガイド](https://github.com/cncf/foundation/blob/master/style-guide.md)に従っています。
+さらに、以下のルールにも従っています：
+
+1. 専門用語や流行語は避け、シンプルでわかりやすい言葉を使う。
+2. [口語を避ける](https://en.wikipedia.org/wiki/Colloquialism)
+3. [書き言葉や具体的な言葉を使う](https://guidetogrammar.org/grammar/composition/abstract.htm)
+4. [前置詞と冠詞の縮約を含めない](https://en.wikipedia.org/wiki/Contraction_(grammar))
+5. [受動態は慎重に使う](https://www.ef.com/ca/english-resources/english-grammar/passive-voice/)
+6. [肯定形でのフレーズを目指す](https://examples.yourdictionary.com/positive-sentence-examples.html) 
+7. [引用符以外の感嘆符を使用しない](https://www.grammarly.com/blog/exclamation-mark/)
+8. 誇張しないこと
+9. 繰り返しを避ける
+10. 簡潔であること
+
+## 読者
+
+用語集は、技術者および技術者以外の読者を対象として書かれています。
+技術的な知識を前提とせず、定義が簡単な言葉で説明されていることを確認してください。詳しくは、以下の定義をご覧ください。
+
+## 最小限の定義
+
+私たちの目標は、クラウドネイティブの用語を誰でも本当に簡単に理解できるようにすることです。
+そのため、シンプルであることに重点を置いています。
+つまり、テクノロジーを使っている人なら誰でも共感できるような例を用いて、明確でシンプルな言葉を使うということです（詳しくは後述します）。また、少なくとも技術的な観点からは、最小限の定義を提供します。
+文脈や例を節約するつもりはありません。結局のところ、それらは読者がコンセプトを理解するのに役立ちますが、技術的な詳細が理解に必要でない場合は、それを省略します。
+目標は、物事を複雑にし過ぎないことです。読者が基本的なコンセプトを理解したら、他のリソースでより深く掘り下げることができるようにします。その部分はこの用語集の範囲外です。
+
+## 定義のテンプレート
+
+各用語はマークダウンファイルに格納され、このテンプレートに従います：
+
+```md
+---
+title: 
+status: 
+category: 
+---
+
+技術やコンセプトの簡単な要約。
+
+## 解決すべき問題はなんですか
+
+取り組んでいる問題について数行。
+
+## どのように役に立つのでしょうか
+
+それがどのように問題を解決するのか数行。
+```
+
+### タイトル
+
+**タイトル** ラベルは、常に定義レイアウトの先頭に位置し、その値はタイトルケースであるべきです。
+
+```md
+---
+title: Definition Template
+```
+
+### 状態
+
+**状態** ラベルは、タイトルラベルの後に表示されます。状態ラベルは、定義が十分に吟味されているか、より多くの努力を必要とするかを示します。
+
+有効な値は以下の通りです： 
+
+- Completed（完了）
+- Feedback Appreciated（フィードバックが必要です）
+- Not Started（未着手）
+
+完了した定義に対して、いつでもissueを開くことができます。定義が流動的な場合、そのステータスは*Feedback Appreciated*に変更されます。
+
+```md
+---
+title: Definition Template
+status: Feedback Appreciated
+```
+
+### タグ
+
+ステータスラベルの後に、**タグ** ラベルが続きます。
+タグが意味を持ち、結果としてユーザーの役に立つためには、タグを厳密な意味で使うことになります。
+多くのタグを付けると、その意味が薄れるだけです。
+他のクラウドネイティブの概念を理解するために必要な用語であることを示すfundamental（基礎）を除き、ほとんどの用語のタグは1つだけとなる可能性があります。
+
+**注意**： 管理者の承認がない限り、新しいタグを導入しないでください。エントリにタグを追加する場合は、以下のリストにあるように正確に綴るようにしてください（単数形、タイプミスなし）。
+
+現在のタグは以下の通りです：
+
+- application（アプリケーション）
+- architecture（アーキテクチャ）
+- fundamental（基礎）
+- infrastructure（インフラストラクチャー）
+- methodology（方法論）
+- networking（ネットワーキング）
+- property（プロパティ）
+- security（セキュリティ）
+
+```md
+---
+title: Definition Template
+status: Feedback Appreciated
+tags: ["tag 1"], ["tag 2"]
+---
+```
+
+### 定義
+
+#### 2つの副題
+
+**テクノロジー** と **コンセプト** のカテゴリの定義には、簡単な概要と2つの副題があります： 
+
+- (簡単な概要) : 私たちが話していることについて、短く明確な概要を提供します。
+- **解決すべき問題はなんですか** : 問題に焦点を当て、解決策（それは次のセクションで出てきます）には触れないようにします。
+  実際、定義されている用語に言及するのは避けましょう。問題は、私たちがそのモノを必要とするようになった **きっかけ** に焦点を当てます。
+- **どのように役に立つのでしょうか** : さて、その用語に戻りましょう。その用語は、上記の問題にどのように対処するのでしょうか？
+
+なお、**プロパティ**は別項目を必要としません。定義で十分です。
+
+レビューを容易にするために、**セマンティック改行**（1行に1文）を使ってください。
+
+#### 品質を最優先する
+
+マージされると、あなたの投稿がその用語の公式なCNCF定義となります（他の誰かが改良するまで）。
+CNCFの高い基準を満たす用語の作成は、急ぐことはできません - 品質には時間と努力が必要です。
+
+**よく調べてください**：その用語を知っていると自信があっても、正しく理解できているかどうか確認してください。
+私たちはしばしば、組織の中で用語を特定の方法で使用しますが、それは全体像を反映していないかもしれません。
+特に、その用語に100％精通しているわけではない場合、複数のリソースを使用して調査してください。
+特にベンダーが提供する場合、多くの定義が一方的なものである。
+用語集には、ベンダーニュートラルで、世界的に認められた定義が含まれていなければなりません。
+
+**盗作はしないこと**：用語集には、他の真面目な出版物と同じルールが適用されます。
+引用して寄稿している場合を除き、他人の著作物をコピー＆ペーストしてはいけません。
+定義の特定の部分が気に入った場合は、自分の言葉で言い換えてください。
+
+**権威あるリソースを参照する**：可能であれば、プロジェクトのドキュメントなどの権威あるリソースにリンクしてください。
+ベンダーが開発したコンテンツへのリンクはできませんのでご注意ください。
+
+#### シンプルであること
+
+用語集は、**複雑な概念を簡単な言葉で説明する**ことを目的としていますが、これは意外と難しい作業で、何度も改訂が必要になります。
+定義を作成する際には、常に読者を念頭に置いてください。
+業界用語や流行語の使用は避けてください。きっと、つい見返してしまい、自動修正が必要になるかもしれません。
+
+適切な場合は、読者（特に非技術者）が、説明しているコンセプトが *いつ*、*なぜ* 関連しているのかをより理解しやすくするために、**実例** を使用します。 
+
+定義で使用する場合は、必ず **既存の用語集にリンクしてください** （最初の言及のみハイパーリンクする必要があります）。
+
+**例**：[サービスメッシュの定義](/ja/service-mesh/)の概要セクションを見てみましょう。
+マイクロサービス、サービス、信頼性、観測可能性の定義とリンクしています。
+さらに、マイクロサービス環境におけるネットワークの課題（非技術者が共感できないもの）と無線LANの問題（ノートパソコンを使っている人なら理解できるもの）を比較した実例を用いています。可能な限り、そのつながりを作るようにしてください。
+
+#### Google や Word のドキュメントから始める
+
+GoogleやWordのドキュメントから始めて、数日置いてから、もう一度見直してみることをお勧めします。
+そうすることで、よりシンプルでわかりやすい表現ができるフレーズや表現をキャッチすることができます。
+また、PRを提出する前に、必ずスペルチェックを行いましょう。
+
+ある用語に取り組んでいるときに、他の人がPRを提出しないようにするには、issueを要求し（または作成し）、そのissueが自分に割り当てられるようにする必要があります。
+詳しくは、[貢献の仕方](/ja/contribute/) ドキュメントをご覧ください。
+
+始める前に、詳細や難易度、例文が適切に感じるか公開されている用語集をいくつか読んでください。
+
+## レビュープロセス：期待されること
+
+現在、私たちは3人のメンテナンス担当者だけが、余暇を利用してこの作業を行っていることにご注意ください。
+時には、すぐに用語の見直しができることもありますが、時間がかかることもあります。
+ご不明な点がございましたら、Slackの#glossaryチャンネルでお問い合わせください。
+(チャンネルがある場所と方法については、[貢献の仕方](/ja/contribute/) ドキュメントを参照してください)。
+
+私たちの目標は、用語集が可能な限り最高のリソースとなるようにすることです。
+あなたがPRを提出すると、私たちは1つまたは複数の修正をお願いすることがあります。
+挫折しないでください、多くのPRでそうなっています。
+このようなやり取りと私たちの協力によって、あなたの投稿が、世界中の読者に読まれ、参照される、本当に役立つ定義になることを保証します。
diff --git a/content/ja/tightly-coupled-architectures.md b/content/ja/tightly-coupled-architectures.md
new file mode 100644
index 0000000000..69e15388c3
--- /dev/null
+++ b/content/ja/tightly-coupled-architectures.md
@@ -0,0 +1,18 @@
+---
+title: 密結合アーキテクチャ
+status: Completed
+category: プロパティ
+tags: ["基礎", "アーキテクチャ", "プロパティ"]
+---
+
+密結合アーキテクチャは、アプリケーション構成要素の多くが互いに依存しているようなアーキテクチャを指します
+(その逆は[疎結合アーキテクチャ](/ja/loosely-coupled-architecture/)と呼ばれます)。
+密結合であることは、ある構成要素に対する変更がその他の構成要素に影響を与えうることを意味します。
+一般的に、密結合アーキテクチャはより疎結合なアーキテクチャと比較して簡単に実装できますが、カスケード障害と呼ばれる連鎖的な障害に対してシステムがより弱くなる可能性があります。
+また、しばしば構成要素を協調してロールアウトする必要が生じるため、開発者の生産性に対する足かせとなる可能性があります。
+
+密結合なアプリケーションアーキテクチャはかなり古典的なアプリケーション構築方法です。
+[マイクロサービス](/ja/microservices/)開発のベストプラクティス全てには必ずしも整合しませんが、
+密結合アーキテクチャは特定の場合に有用です。
+密結合アーキテクチャでの開発は、実装がより簡潔で早くなる傾向があり、
+[モノリシックアプリケーション](/ja/monolithic-apps/)とよく似て初期開発サイクルを加速させる可能性があります。
diff --git a/content/ja/virtual-machine.md b/content/ja/virtual-machine.md
new file mode 100644
index 0000000000..134c8cd9f9
--- /dev/null
+++ b/content/ja/virtual-machine.md
@@ -0,0 +1,18 @@
+---
+title: 仮想マシン
+status: Completed
+category: テクノロジー
+tags: ["基礎", "インフラストラクチャー", ""]
+---
+
+仮想マシン（VM）とは、特定のハードウェアに縛られないコンピューターとそのオペレーティングシステムのことです。VMは、1台の物理コンピューターを複数の仮想コンピューターに分割する[仮想化](/ja/virtualization/)に依存しています。この分割は、組織やインフラプロバイダーに、下層のハードウェアに影響を与えることなく、VMを簡単に作成、破棄することを可能にします。
+
+## 解決すべき問題はなんですか
+
+仮想マシンは仮想化を利用しています。[ベアメタル](/ja/bare-metal-machine/)マシンは単一のオペレーティングシステムに縛られているので、マシンのリソースをどれだけ使えるかはある程度制限されます。また、オペレーティングシステムも単一の物理マシンに縛られているので、その可用性はハードウェアに直結します。物理マシンがメンテナンスやハードウェア故障によりオフラインになると、オペレーティングシステムもオフラインになります。
+
+## どのように役に立つのでしょうか
+
+オペレーティングシステムと物理マシンとの直接的な関係を取り除くことで、プロビジョニングの時間やハードウェア利用率、弾力性といったベアメタルマシンが抱えるいくつかの問題を解決することができます。
+
+新しいハードウェアの購入やインストール、あるいはそれをサポートするための設定が必要ないため、新しいコンピューターのプロビジョニングの時間が劇的に短縮されます。VMは、1台の物理マシン上に複数の仮想マシンを配置することで、既存の物理ハードウェアリソースをより有効に活用できます。特定の物理マシンに縛られないため、VMは物理マシンよりも耐障害性に優れています。物理マシンがオフラインになる必要がある場合、その上で稼働しているVMを、ほとんどない、あるいは全く停止時間なしで別のマシンに移動させることができます。
diff --git a/content/ja/virtualization.md b/content/ja/virtualization.md
new file mode 100644
index 0000000000..e4a6af4c1a
--- /dev/null
+++ b/content/ja/virtualization.md
@@ -0,0 +1,27 @@
+---
+title: 仮想化
+status: completed
+category: テクノロジー
+tags: ["基礎", "インフラストラクチャー", "方法論"]
+---
+
+クラウドネイティブコンピューティングにおける仮想化とは、
+サーバーとも呼ばれる物理コンピューターを確保し、その上で複数の隔離されたオペレーティングシステムを動かせるようにするプロセスを指します。
+そういった隔離されたオペレーティングシステムとそれらに割り当てられた計算資源(CPU、メモリ、ネットワーク)は、仮想マシンやVMと呼ばれます。
+[仮想マシン](/ja/virtual-machine/)はソフトウェア的に作り出されたコンピューターを意味します。
+仮想マシンは実際のコンピューターのように見えたり動作したりしますが、他の仮想マシンとハードウェアを共有しています。
+[クラウドコンピューティング](/ja/cloud-computing/)は主に仮想化技術の恩恵を受け提供されています。
+例えば、AWSで作成し使用できる「コンピューター」は実際のところはVMです。
+
+
+## 解決すべき問題はなんですか
+
+仮想化によって、我々は多くの課題に対処することができます。
+例えば、仮想化によって同じ物理的なハードウェア上により多くのアプリケーションを互いに隔離しつつ動かすことができるので、
+セキュリティを保ったまま物理マシンの使用率を改善することができます。
+
+## どのように役に立つのでしょうか
+
+仮想マシン上で動作しているアプリケーションは、お互いが物理的なコンピューターを共有していることを意識しません。
+また、データセンター利用者は仮想化によって新たなコンピューター(すなわちVM)を数分以内に起動できるようになります。
+その際に新しいコンピューターをデータセンターに追加する際の物理的な制約を気にする必要はありません。
diff --git a/content/ja/zero-trust-architecture.md b/content/ja/zero-trust-architecture.md
new file mode 100644
index 0000000000..03eaebbda5
--- /dev/null
+++ b/content/ja/zero-trust-architecture.md
@@ -0,0 +1,28 @@
+---
+title: ゼロトラストアーキテクチャ
+status: Completed
+category: コンセプト
+tags: ["セキュリティ", "", ""]
+---
+
+ゼロトラストアーキテクチャは、ITシステムの設計と実装において信頼を完全に取り除くアプローチを推奨します。
+その核心の原則は「決して信頼せず、常に検証する」であり、
+デバイスやシステムは、システムの他のコンポーネントと通信する際に常に事前に自分自身を検証します。
+今日の多くのネットワークは、企業ネットワークの信頼された境界内にあるため、システムやデバイスは互いに自由に通信することができます。
+ゼロトラストアーキテクチャは、ネットワークの境界内にあっても、
+システム内のコンポーネントは通信する前に検証しなければならないという正反対のアプローチを取ります。
+
+## 解決すべき問題はなんですか
+
+伝統的な信頼ベースのアプローチでは、企業ネットワークの境界内に存在するシステムやデバイスに対して、
+信頼があるため問題がないという前提があります。
+しかし、ゼロトラストアーキテクチャは、その信頼が脆弱性になると認識しています。
+攻撃者が信頼されたデバイスへのアクセスを獲得した場合、
+そのデバイスに与えられている信頼のレベルとアクセスに依存してシステムは攻撃に対して脆弱になります。
+なぜなら、攻撃者は信頼されたネットワークの境界内におり、システム内を横断的に移動することができるからです。
+ゼロトラストアーキテクチャでは、信頼が取り除かれるため攻撃者はシステム内をさらに横断する前に検証を強いられ、結果としてアタックサーフェスが縮小します。
+
+## どのように役に立つのでしょうか
+
+ゼロトラストアーキテクチャを採用することで、主な利点としてセキュリティが向上し、アタックサーフェスが縮小します。
+企業システムから信頼を取り除くことで、攻撃者がシステムの他の領域へアクセスするために通過しなければならないセキュリティゲートの数と強度が増加します。
diff --git a/i18n/ja.toml b/i18n/ja.toml
new file mode 100644
index 0000000000..ed7e51c80b
--- /dev/null
+++ b/i18n/ja.toml
@@ -0,0 +1,87 @@
+
+
+# UI strings. Buttons and similar.
+
+[ui_pager_prev]
+other = "前へ"
+
+[ui_pager_next]
+other = "次へ"
+
+[ui_read_more]
+other = "続きを読みます"
+
+[ui_search]
+other = "サイト検索…"
+
+# Used in sentences such as "Posted in News"
+[ui_in]
+other = "に"
+
+# Phrases for tags
+[ui_see_all_tags]
+other = "全てのタグを見ます"
+[ui_tag]
+other = "Tag"
+[ui_tags]
+other = "Tags"
+[ui_search_by_tags]
+other = "タグで閲覧します"
+[ui_tags_intro]
+other = "用語集の用語を分類しています。フィルターを使って、タグごとに用語を閲覧することができます。"
+[ui_or_search_by_tags]
+other = "...またはタグで閲覧します"
+[ui_select_all]
+other = "全てを選択します"
+[ui_deselect_all]
+other = "全ての選択を解除します"
+
+# Footer text
+[footer_all_rights_reserved]
+other = "All Rights Reserved"
+
+[footer_privacy_policy]
+other = "プライバシーポリシー"
+
+[footer_hub_button_text]
+other = "全てのCNCFサイト"
+
+# Post (blog, articles etc.)
+[post_byline_by]
+other = "によって"
+[post_created]
+other = "作成されました"
+[post_last_mod]
+other = "最終更新日"
+[post_edit_this]
+other = "このページを編集します"
+[post_create_child_page]
+other = "子ページを作成します"
+[post_create_issue]
+other = "issueを報告します"
+[post_create_project_issue]
+other = "プロジェクトissueを作成します"
+[post_posts_in]
+other = "内の投稿"
+[post_reading_time]
+other = "読んだ時間(分)"
+
+# Print support
+[print_printable_section]
+other = "このセクションの複数ページ印刷用ビューです"
+[print_click_to_print]
+other = "印刷する場合はこちらをクリックしてください"
+[print_show_regular]
+other = "このページの通常の表示に戻ります"
+[print_entire_section]
+other = "セクション全体をプリントします"
+
+# Feedback section
+[feedback_title]
+other = "フィードバック"
+[feedback_question]
+other = "このページは役に立ちましたか？"
+[feedback_answer_yes]
+other = "はい"
+[feedback_answer_no]
+other = "いいえ"