Merge branch 'doc/issue-45521' of https://github.com/b1gb4by/website into doc/issue-45521

Author: b1gb4by

content/ja/blog/_posts/2024-03-07-cri-o-seccomp-oci-artifacts.md

@@ -175,7 +175,7 @@ allowed_annotations = [
 これは、ソースからビルドするか、[静的バイナリバンドル](https://github.com/cri-o/packaging?tab=readme-ov-file#using-the-static-binary-bundles-directly)を使用するか、[プレリリースパッケージ](https://github.com/cri-o/packaging?tab=readme-ov-file#usage)を使用することで行うことができます。
 
 これを実証するために、[`local-up-cluster.sh`](https://github.com/cri-o/cri-o?tab=readme-ov-file#running-kubernetes-with-cri-o)を使って単一ノードのKubernetesクラスターをセットアップし、コマンドラインから`crio`バイナリを実行しました。
-クラスターが起動して実行されているので、seccomp `Unconfined`として実行されているアノテーションのないポッドを試してみましょう:
+クラスターが起動して実行されているので、seccomp `Unconfined`として実行されているアノテーションのないPodを試してみましょう:
 
 ```shell
 cat pod.yaml
@@ -286,7 +286,7 @@ sudo crictl inspect $CONTAINER_ID | jq .info.runtimeSpec.linux.seccomp | head
     {
 ```
 
-ユーザーが接尾辞`/container`を予約名`/POD`に置き換えると、ポッド内のすべてのコンテナに対して同じことが機能します。
+ユーザーが接尾辞`/container`を予約名`/POD`に置き換えると、Pod内のすべてのコンテナに対して同じことが機能します。
 たとえば:
 
 ```yaml
@@ -425,7 +425,7 @@ CRI-OはOCIアーティファクトを通常のファイルと同様に内部で
 これにより、それらを移動したり、使用されなくなった場合に削除したり、seccompプロファイル以外のデータを利用したりする利点が得られます。
 これにより、OCIアーティファクトをベースにしたCRI-Oの将来の拡張が可能になります。
 また、OCIアーティファクトの中に複数のレイヤーを持つことを考える上で、seccompプロファイルの積層も可能になります。
-v1.30.xリリースでは`Unconfined`ワークロードのみがサポートされている制限は、将来CRI-Oが解決したい課題です。
+v1.30.xリリースでは`Unconfined`ワークロードのみがサポートされているという制限は、将来CRI-Oが解決したい課題です。
 セキュリティを損なうことなく、全体的なユーザーエクスペリエンスを簡素化することが、コンテナワークロードにおけるseccompの成功の鍵となるようです。
 
 CRI-Oのメンテナーは、新機能に関するフィードバックや提案を歓迎します！