--- title: "ゼロから始めるGitOps：Argo CD、Image Updater、Rolloutsの検証 | grasys blog" url: "https://blog.grasys.io/post/mr-binelias/starting-gitops/" description: "どうも、ライアンでございます。 この記事では、以下のツールを用いてローカルマシンに「GitOpsワークフロー」を構築する方法を解説します。 1. Argo CDサーバーとArgo CD Image Updaterの連携 - 新しいイメージがリポジトリにプッシュされる → Docker Hub → ArgoCD Ima…" --- ゼロから始めるGitOps：Argo CD、Image Updater、Rolloutsの検証 | grasys blog[本文へスキップ](#main-content) # ゼロから始めるGitOps：Argo CD、Image Updater、Rolloutsの検証 - ![](/_astro/noicon.CTHOhNiB_1HMs6A.webp)[mr.binelias](/authors/mr-binelias/) - 公開日：2025年10月2日 - カテゴリー：[Tech](/categories/tech/) - タグ：[#Argo CD](/tags/argo-cd/)[#Docker Hub](/tags/docker-hub/)[#GitHub](/tags/github/)[#GitOps](/tags/gitops/)[#Kubernetes](/tags/kubernetes/) ![ゼロから始めるGitOps：Argo CD、Image Updater、Rolloutsの検証](/_astro/hero.VJu31s4C_Z16TlCo.webp) どうも、ライアンでございます。 この記事では、以下のツールを用いてローカルマシンに「GitOpsワークフロー」を構築する方法を解説します。 1. Argo CDサーバーとArgo CD Image Updaterの連携 - 新しいイメージがリポジトリにプッシュされる **→** Docker Hub **→** ArgoCD Image Updater **→** Github **→** ArgoCD **→** k8sリソースへ自動デプロイ - リポジトリに新バージョンのイメージがアップロードされると、Argo CD Image Updaterが自動的にGitブランチのタグを更新し、その変更をトリガーとしてArgo CDがKubernetesリソースの同期・デプロイを自動実行します。 2. Argo Rollout - Argo RolloutsによるBlue/Greenデプロイメントの容易さを実際に検証します。 ## 技術単語 GitOps - Gitリポジトリをアプリケーションの理想状態の唯一のソースとして利用することで、従来の継続的デプロイメント戦略を短縮する手法。 ArgoCD - GitリポジトリとKubernetesクラスター間の状態の同期を自動化する、Kubernetes向けのGitOpsツール。 ArgoCD Image updater - Docker Hubなどのコンテナイメージレジストリから最新のイメージタグを自動的に検知し、Gitリポジトリを更新するツール。 ArgoCD rollout - デフォルトのRolling Updateよりも安全で制御されたデプロイメント（例：Blue/Green、Canary）を提供する、Kubernetesのコントローラー。 minikube - ローカルマシン上に単一ノードのKubernetesクラスターを素早く構築・実行するためのツール。 kustomize - テンプレートを使わずに、ベースとなるYAMLファイルを維持したまま、デプロイされるリソースを環境ごとにカスタマイズできるツール。 ## 前提条件 - ローカル環境構築：[Docker](https://docs.docker.com/desktop/setup/install/mac-install/), [kubectl](https://minikube.sigs.k8s.io/docs/start/?arch=%2Fmacos%2Farm64%2Fstable%2Fhomebrew), [minikube](https://minikube.sigs.k8s.io/docs/start/?arch=%2Fmacos%2Farm64%2Fstable%2Fhomebrew)は導入済みです。 - Gitリポジトリ：プライベートなGitHubリポジトリの作成が完了しています。 - コンテナイメージ：Docker Hubリポジトリへのイメージバージョンのアップロードも済んでいます。 ## ワークフローの概要 ### Stagingワークフロー Argo CD Image Updaterは、イメージレジストリ内のタグの変更を常時監視しており、新しいタグが発見されると、その変更を自動的にGitブランチにコミットします。 その後、そのブランチを監視しているArgo CDが、コミットされた変更を検知し、Kubernetesリソースを自動で更新・デプロイします。 ![Stagingワークフローの写真](/_astro/01-Screenshot-2025-09-25-at-8.01.20-PM-1024x792-b341682b.hmQTaNdr_2eAwFy.webp) ### Productionワークフロー これから、Argo Rolloutsの機能を利用して、新しいバージョンへのデプロイを手動Blue/Greenデプロイメントの形式で進めます。 ![Argo Rolloutsを使ったProductionワークフロー](/_astro/02-Screenshot-2025-09-26-at-6.21.09-AM-1024x769-16fba5e8.ClKP5jI5_Z124WxD.webp) ## Stagingワークフローの設定 ### Argo CDサーバーの起動 Minikubeを起動します。（Dockerエンジンが動作している） Plain textcontent\_copy ``` minikube start --insecure-registry="registry-1.docker.io" ``` Argo CDリソースをargocd名前空間にインストールします。 Plain textcontent\_copy ``` kubectl create namespace argocd kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml ``` Argo CD CLIをインストールします。 Plain textcontent\_copy ``` brew install argocd ``` ポートフォワードを設定し、Argo CDのUIにアクセス可能にします。 Plain textcontent\_copy ``` kubectl port-forward svc/argocd-server -n argocd 8080:443 ``` 自動生成された初期パスワードを取得します。 Plain textcontent\_copy ``` argocd admin initial-password -n argocd ``` ユーザー名 adminと取得したパスワードを使って、CLIからArgo CDサーバーにログインします。 Plain textcontent\_copy ``` argocd login localhost:8080 ``` パスワードを変更します。 Plain textcontent\_copy ``` argocd account update-password ``` これで、先ほど設定した新しい認証情報を使ってArgo CDサーバーのUIにログインできるようになりました。 しかし、その前に、GitHubリポジトリをArgo CDサーバーに接続する必要があります。 ### UIを使ってGitHubをArgo CDサーバーに接続する 今回はSSH接続を利用するため、まずSSHキーペアを作成します。 Plain textcontent\_copy ``` ssh-keygen -t ed25519 -C "your_email@example.com" ``` 作成したGitHubのプライベートリポジトリに、作成済みの公開鍵を[デプロイキーとして登録します](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/managing-deploy-keys#set-up-deploy-keys)。設定は以下の図の通りにしてください。 ![UIを使ってGitHubをArgo CDサーバーに接続する画面（1）](/_astro/03-Screenshot-2025-09-25-at-12.55.44-PM-1-1024x407-f959e77d.2kRcxkxj_Z2mSEMG.webp) 次に、[作成した秘密鍵](https://argo-cd.readthedocs.io/en/stable/user-guide/private-repositories/#ssh-private-key-credential)をArgo CDサーバーのUI上で認証情報（Credentials）としてGitHubリポジトリに追加します。 ![UIを使ってGitHubをArgo CDサーバーに接続する画面（2）](/_astro/04-Screenshot-2025-09-23-at-1.09.13-PM-2-1024x185-41581df9.tNHuQl4S_EAvxG.webp) ### アプリケーションのデプロイ準備 Application CRDをデプロイする前に、まず、隔離（アイソレーション）のベストプラクティスに基づき、base、stg、prd環境それぞれに独立した名前空間を作成します。 Plain textcontent\_copy ``` kubectl create namespace base kubectl create namespace stg kubectl create namespace prd ``` フォルダ構成は以下の通りです。コード全体を確認するには、[こちらを押して](https://github.com/binelias/argocd.git)ください。 Plain textcontent\_copy ``` > tree . ├── argocd │ ├── applications │ │ ├── app_base.yaml │ │ ├── app_prd.yaml │ │ └── app_stg.yaml ├── base │ ├── deployment.yaml │ ├── kustomization.yaml │ ├── service.yaml ├── configmap │ └── docker-access │ └── argocd-img-updater-credentials.yaml └── env ├── prd │ ├── rollout.yaml │ └── service.yaml └── stg ├── kustomization.yaml └── replica_count.yaml ``` ベースとなるリソースなしにオーバーレイをデプロイすることはできないため、まずKustomizeのベースとなるアプリケーションマニフェストを展開します。 Argo CDは「stg」ブランチの変更を監視し、このKubernetesリソースをbase名前空間へ自動的にデプロイします。 Plain textcontent\_copy ``` app_base.yaml apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: myapp namespace: argocd spec: project: default source: repoURL: git@github.com: targetRevision: stg path: base destination: server: https://kubernetes.default.svc namespace: base syncPolicy: syncOptions: - CreateNamespace=true - Validate=true - PrunePropagationPolicy=foreground - PruneLast=true automated: selfHeal: true prune: true allowEmpty: false ``` アプリケーションマニフェストを適用します。 Plain textcontent\_copy ``` kubectl apply -f app_base.yaml ``` ご覧のように、Argo CDは最新のGitブランチへのコミット変更を検知し、Kubernetesリソースへ自動的に同期します。 ![アプリケーションのデプロイ準備の写真](/_astro/05-Screenshot-2025-09-23-at-6.44.18-PM-1-1024x273-9e9ed8c2.DmV3FsS9_ZKLlVh.webp) ### ArgoCD Image Updaterの設定 Argo CD Image Updaterをインストールします。 Plain textcontent\_copy ``` kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj-labs/argocd-image-updater/stable/manifests/install.yaml ``` Argo CD Image UpdaterにDockerレジストリへのアクセス権を付与します。認証情報はSecretに安全に保存し、ConfigMapを経由して参照するように設定します。 Plain textcontent\_copy ``` argocd-img-updater-credentials.yaml apiVersion: v1 kind: ConfigMap metadata: name: argocd-image-updater-config namespace: argocd data: registries.conf: | registries: - name: Docker Hub api_url: https://registry-1.docker.io prefix: docker.io credentials: secret:argocd/dockerhub-credentials ``` Docker Hubにログインするための認証情報をKubernetesのSecretとして作成します。 Plain textcontent\_copy ``` kubectl create secret docker-registry dockerhub-credentials --namespace argocd --docker-server=docker.io --docker-username= --docker-password= ``` Image Updaterのアノテーションはまだ適用せず、まずはステージング環境にアプリケーションをデプロイします。 これにより、アプリがNginxアプリケーション（イメージ：/nginx-demo:1.0.0）として確実に起動することを確認します。 Plain textcontent\_copy ``` app_stg.yaml apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: myapp-stg namespace: argocd spec: project: default source: repoURL: git@github.com: targetRevision: stg path: env/stg destination: server: https://kubernetes.default.svc namespace: stg syncPolicy: syncOptions: - CreateNamespace=true - Validate=true - PrunePropagationPolicy=foreground - PruneLast=true automated: selfHeal: true prune: true allowEmpty: false ``` マニフェストを適用します。 Plain textcontent\_copy ``` kubectl apply -f app_stg.yaml ``` ![Argo CDでHealthyかつSyncedになったステージングアプリケーションのリソース構成](/_astro/06-Screenshot-2025-09-23-at-6.43.31-PM-1024x290-14797660.50sUDj0F_Z1Uoniz.webp) ### デモ：最新イメージへの自動デプロイを検証 ここからは、実際に最新イメージへの自動デプロイを検証します。 まずは、現在デプロイされているステージングサービスへアクセスできるよう、ポートフォワーディングを使って公開します。 Plain textcontent\_copy ``` kubectl port-forward svc/myapp-service-stg -n stg 8086:80 ``` 初期バージョンである 1.0.0 は、Nginxのイメージです。 Plain textcontent\_copy ``` ❯ kubectl describe deployment myapp-stg -n stg | grep Image Image: /nginx-demo:1.0.0 ``` ![Argo CDに初期バージョンとしてデプロイされたNginx 1.0.0の画面](/_astro/07-Screenshot-2025-09-23-at-8.08.08-PM-8eceaf2a.DfSqFLGf_10Ef1g.webp) Argo CD Image Updaterは、デプロイするイメージタグを決定する際、デフォルトで[セマンティックバージョニング（SemVer](https://argocd-image-updater.readthedocs.io/en/stable/install/testing/#testing-for-semver-constraints)）戦略を使用します。 ここで、ステージングアプリケーションに以下のアノテーションを追加します。 この設定により、Image Updaterは利用可能なタグの中から数値的に最も新しい（高い）バージョンを選択します。 例えば、現在の1.0.0から、タグ2.0.0に自動的に更新されます。 Plain textcontent\_copy ``` app_stg.yaml .... namespace: argocd annotations: # image-list: The tag X means the image updater will update the image to the latest version. argocd-image-updater.argoproj.io/image-list: /nginx-demo:X argocd-image-updater.argoproj.io/write-back-method: git argocd-image-updater.argoproj.io/pull-secret: argocd:dockerhub-credentials .... ``` 更新したマニフェストを再適用します。 Plain textcontent\_copy ``` kubectl apply -f app_stg.yaml ``` イメージの更新が成功したかどうかは、主に以下の３つの方法で検証できます。 まず、Image Updater podのログを確認します。 Plain textcontent\_copy ``` > kubectl get pods -n argocd > kubectl logs -n argocd argocd-image-updater-57878df448-bxgc8 time="2025-09-23T11:23:22Z" level=info msg="Setting new image to /nginx-demo:2.0.0" alias= application=myapp-stg image_name=/nginx-demo image_tag=1.0.0 registry= time="2025-09-23T11:23:22Z" level=info msg="Successfully updated image '/nginx-demo:1.0.0' to '/nginx-demo:2.0.0', but pending spec update (dry run=false)" alias= application=myapp-stg image_name= /nginx-demo image_tag=1.0.0 registry= ``` 次は、GitHubリポジトリのコミット履歴を確認します。イメージの更新は自動的にコミットされており、通常、そのファイル名は .argocd-source-<アプリケーション名>.yaml といった形式になっています。 ![Argo CD Image Updaterがイメージタグを1.0.0から2.0.0へ自動更新したGitHubコミット](/_astro/08-Screenshot-2025-09-29-at-5.59.22-PM-1-1024x328-1c5f9d91.CM4BKkZv_1zH9Xt.webp) 最後に、ブラウザでアクセスして確認します。 以前のNginxのホーム画面が、ご覧の通りApacheのホーム画面に切り替わっていることを確認できます。 ![イメージの自動更新後に表示されたApacheのIt worksページ](/_astro/09-Screenshot-2025-09-29-at-6.22.53-PM-71871faa.DhbJqg1d_Z155ewd.webp) ### 以前のコミットへのロールバック手順 Argo CDのUI上では、以下の手順で簡単に前のコミットへロールバックできます。 1. 対象のApplication CRDを選択します。 2. 画面上部の History and Rollback タブをクリックします。 3. ロールバックしたいコミット履歴の右側にある三点リーダー（︙）ボタンを押します。 4. 最後に Rollback ボタンを押して実行します。 ![以前のコミットへのロールバック手順の画面](/_astro/10-Screenshot-2025-09-23-at-8.56.40-PM-1-1024x291-cb7657b0.7ZuZjILb_1UVuut.webp) メモ：以前のコミットにロールバックを実行した場合、自動同期（Auto Sync）は自動的に無効になります。 ## Productionワークフローの設定 Argo RolloutsではカナリアデプロイやBlue/Greenデプロイなど多様な戦略が提供されていますが、本記事ではBlue/Greenデプロイのみを実行します。 ### Argo Rolloutsの設定 まず、argo-rollout名前空間にargo-rolloutsコントローラーをインストールします。 Plain textcontent\_copy ``` kubectl create namespace argo-rollouts kubectl apply -n argo-rollouts -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml ``` kubectlのArgo RolloutsプラグインCLIをインストールします。 Plain textcontent\_copy ``` brew install argoproj/tap/kubectl-argo-rollouts ``` ### Rolloutマニフェストの手動デプロイ ここでは、Argo CDの管理外で、Rolloutマニフェストを手動でデプロイします。 これは、Blue/Green戦略の動作確認のための一時的なデプロイ手順となります。 Plain textcontent\_copy ``` env/prd/rollout.yaml apiVersion: argoproj.io/v1alpha1 kind: Rollout metadata: name: my-app-rollout namespace: prd spec: replicas: 2 revisionHistoryLimit: 2 selector: matchLabels: app: my-app-rollout template: metadata: labels: app: my-app-rollout spec: containers: - name: my-app-rollout image: argoproj/rollouts-demo:blue imagePullPolicy: Always ports: - containerPort: 8080 strategy: blueGreen: activeService: my-app-active previewService: my-app-preview autoPromotionEnabled: false ``` Rolloutマニフェストを適用します。 Plain textcontent\_copy ``` kubectl apply -f env/prd/rollout.yaml ``` ### Serviceマニフェストのデプロイ RolloutのBlue/Green戦略に必須となる、preview用とactive用、両方のServiceマニフェストも同様に適用します。 これらのserviceが、デプロイ時にトラフィックの振り分けを担います。 Plain textcontent\_copy ``` env/prd/service.yaml apiVersion: v1 kind: Service metadata: name: my-app-active namespace: prd spec: selector: app: my-app-rollout ports: - protocol: TCP port: 8080 targetPort: 8080 --- apiVersion: v1 kind: Service metadata: name: my-app-preview namespace: prd spec: selector: app: my-app-rollout ports: - protocol: TCP port: 8080 targetPort: 8080 ``` Serviceマニフェストを適用します。 Plain textcontent\_copy ``` > kubectl apply -f env/prd/service.yaml service/my-app-active created service/my-app-preview created ``` デプロイされたServiceリソースが正しく作成されているか確認します。 Plain textcontent\_copy ``` ❯ kubectl get svc -n prd NAME TYPE CLUSTER-IP EXTERNAL -IP PORT(S) AGE my-app-active ClusterIP 10.109.32.210 8080/TCP 143m my-app-preview ClusterIP 10.105.20.40 8080/TCP 142m ``` 現在のデプロイ状況を可視化するために、ターミナルで以下のコマンドを実行します。 初期状態では、イメージタグは 「blue」 と表示されます。 Plain textcontent\_copy ``` > kubectl argo rollouts get rollout my-app-rollout -n prd --watch Name: my-app-rollout Namespace: prd Status: ✔ Healthy Strategy: BlueGreen Images: argoproj/rollouts-demo:blue (stable, active) Replicas: Desired: 2 Current: 2 Updated: 2 Ready: 2 Available: 2 NAME KIND STATUS AGE INFO ⟳ my-app-rollout Rollout ✔ Healthy 21m └──# revision:1 └──⧉ my-app-rollout-57bf9c5889 ReplicaSet ✔ Healthy 19m stable,active ├──□ my-app-rollout-57bf9c5889-487gx Pod ✔ Running 19m ready:1/1 └──□ my-app-rollout-57bf9c5889-bzlxs Pod ✔ Running 19m ready:1/1 ``` ### Rolloutのプレビュー開始 ここから、新しい 「green」 イメージバージョンへのロールアウトを開始し、my-app-previewサービスにルーティングします。 Plain textcontent\_copy ``` kubectl argo rollouts set image my-app-rollout -n p rd my-app-rollout=argoproj/rollouts-demo:green ``` 現在、新しい「green」イメージバージョンは一時停止（Pause）状態にあり、previewサービスにのみルーティングされており、`active`サービスでは提供されていません。 Plain textcontent\_copy ``` Name: my-app-rollout Namespace: prd Status: ॥ Paused Message: BlueGreenPause Strategy: BlueGreen Images: argoproj/rollouts-demo:blue (stable, active) argoproj/rollouts-demo:green (preview) Replicas: Desired: 2 Current: 4 Updated: 2 Ready: 2 Available: 2 NAME KIND STATUS AGE INFO ⟳ my-app-rollout Rollout ॥ Paused 104m ├──# revision:2 │ └──⧉ my-app-rollout-f75f67d6d ReplicaSet ✔ Healthy 64m preview │ ├──□ my-app-rollout-f75f67d6d-552dc Pod ✔ Running 64m ready:1/1 │ └──□ my-app-rollout-f75f67d6d-zggsf Pod ✔ Running 64m ready:1/1 └──# revision:1 └──⧉ my-app-rollout-57bf9c5889 ReplicaSet ✔ Healthy 102m stable,active ├──□ my-app-rollout-57bf9c5889-487gx Pod ✔ Running 102m ready:1/1 └──□ my-app-rollout-57bf9c5889-bzlxs Pod ✔ Running 102m ready:1/1 ``` 以下のコマンドを使ってポートフォワーディングを行い、previewサービス経由で新しい「green」イメージバージョンにアクセスできるようにします。 Plain textcontent\_copy ``` kubectl port-forward svc/my-app-preview -n prd 8082:8080 ``` ![Rolloutのプレビュー開始の画面（1）](/_astro/11-Screenshot-2025-09-24-at-8.36.54-PM-1024x438-b0fc56a2.Cl8PqNv6_Z24bhdc.webp) こちらが、現在デプロイされているアクティブサービスです。初期の 「blue」イメージバージョンがトラフィックを処理している状態を確認できます。 Plain textcontent\_copy ``` kubectl port-forward svc/my-app-active -n prd 8081:8080 ``` ![Rolloutのプレビュー開始の画面（2）](/_astro/12-Screenshot-2025-09-24-at-8.37.12-PM-1024x483-c77223d1.CXjcbD3P_2hjM0G.webp) ### Preview中のRolloutをActiveへ昇格（プロモート） 新しいイメージバージョンを本番環境へ切り替える（プロモート）には、そのトラフィックをmy-app-activeサービスが受け持つようにする必要があります。 この切り替えは、以下のpromoteコマンドで実行できます。 Plain textcontent\_copy ``` > kubectl argo rollouts promote my-app-rollout -n prd rollout 'my-app-rollout' promoted ``` このコマンドの実行により、以前の 「blue」 イメージバージョンのPodリソースも削除されます\*\*。\*\* Plain textcontent\_copy ``` Name: my-app-rollout Namespace: prd Status: ✔ Healthy Strategy: BlueGreen Images: argoproj/rollouts-demo:green (stable, active) Replicas: Desired: 2 Current: 2 Updated: 2 Ready: 2 Available: 2 NAME KIND STATUS AGE INFO ⟳ my-app-rollout Rollout ✔ Healthy 159m ├──# revision:2 │ └──⧉ my-app-rollout-f75f67d6d ReplicaSet ✔ Healthy 119m stable,active │ ├──□ my-app-rollout-f75f67d6d-552dc Pod ✔ Running 119m ready:1/1 │ └──□ my-app-rollout-f75f67d6d-zggsf Pod ✔ Running 119m ready:1/1 └──# revision:1 └──⧉ my-app-rollout-57bf9c5889 ReplicaSet • ScaledDown 157m ``` ポートフォワーディングを使って、my-app-activeサービスが更新されたことを確認できます。 Plain textcontent\_copy ``` kubectl port-forward svc/my-app-active -n prd 8081:8080 ``` ![Preview中のRolloutをActiveへ昇格（プロモート）の画面](/_astro/13-Screenshot-2025-09-24-at-8.46.22-PM-1024x467-8eb2792f.fPPoED5O_Z1VN3Ru.webp) ## 学びの要点 このチュートリアルを通して得られた学びの要点は以下の通りです。 - Minikubeの動作環境について： Minikubeを起動するには、DockerやOrbStackといったコンテナドライバーが必須である。 - Argo CDのApplication CRD (カスタムリソース定義)こそが、Gitブランチのディレクトリと、Kubernetesリソースのライブ状態を同期させるための設定そのものである。 - Image Updaterの前提条件： コンテナイメージの自動更新対象とするアプリケーションは、必ずArgo CDによって管理されている必要がある。 - Image Updaterの対応フォーマット： Argo CD Image Updaterがコンテナイメージを更新できるのは、アプリケーションマニフェストがKustomizeまたはHelmによってレンダリングされている場合に限られる。 ## まとめ この記事では、Argo CDを使ったGitOpsの基本的な構成について、しっかりとした基礎を固めることができました。 特にArgo CDとImage Updaterは、リソースデプロイを効率化してくれる非常に便利なツールだと実感しています。 ただし、Argo Rollouts自体は強力な高度なデプロイ機能を提供してくれるものの、コアとなるArgo CDのワークフローと統合し、シームレスな更新を実現する点では、少々課題に直面しました。 統合時のつまずきはありましたが、このデバッグの過程こそが最高の学習機会でした。一つ一つ問題を解決していく中で、Argo CDがどのように動作しているのかを深く、実践的に理解できたからです。 GitOpsを体感したい方には、ぜひこのハンズオンでのアプローチを強くお勧めします! ## この記事を書いた人 [![](/_astro/noicon.CTHOhNiB_Z24aAgM.webp)](/authors/mr-binelias/) ### [mr.binelias](/authors/mr-binelias/) mr.bineliasのプロフィールと執筆記事をご覧いただけます。 [プロフィールと記事一覧](/authors/mr-binelias/)