はじめに 昨今の開発環境においては、オンプレミスであってもコンテナアプリケーションを稼働させたいというニーズが高まっています。 その様なオンプレミスかつ外部インターネットに接続できない閉域環境などでも、効率的かつセキュアな開発基盤の整備は欠かせません。 こうした環境では、GitHubのようなパブリックサービスは利用が難しいため、自社内で完結できるソースリポジトリおよびCI/CDプラットフォームとしてGitLabが有力な選択肢として挙げられます。 閉域環境において、CI/CDとKubernetesやOpenShiftといったコンテナプラットフォームを統合したい企業にとっては、GitLabを中核とした構成が現実的かつ強力な選択肢となります。 本シリーズでは、そのようなユースケースを想定し、閉域網におけるGitLabとコンテナプラットフォーム（本記事ではOpenShift）とのCI/CD構築や連携方法を解説します。 今回はシリーズの第一回として、GitLabの構築手順と、閉域環境のOpenShiftクラスターとの連携方法を中心に解説します。 検証環境構成 本記事では、GitLabと閉域環境のOpenShiftクラスターを連携させたCI/CD基盤の構築手順を紹介します。今回構築した検証環境の構成は以下の通りです。 外部インターネットに接続可能なサーバー上にGitLabを構築 閉域環境下のOpenShiftクラスターにGitLab Runnerをデプロイし、GitLabと連携 踏み台サーバー が以下の機能を兼任： GitLabとOpenShift間の名前解決を行う内部DNSサーバー コンテナの永続ストレージや、GitLabのコンテナレジストリ格納領域を提供する NFSサーバー 必要なトラフィックのルーティングを担う ロードバランサー ※本記事では GitLab の構築に焦点を当てており、踏み台サーバーや OpenShift クラスターの構築手順については割愛しています。 ※「コンテナプラットフォーム」は一般的なKubernetes基盤を指し、本記事で使用する「OpenShiftクラスター」はその具体的な構築済み環境を意味します。 目標 本記事での検証構成では、以下の実現を目標とします。 GitLabのインストールと初期設定 OpenShiftクラスターへのGitLab Runnerのデプロイ GitLabとGitLab Runner間の連携の確立 構築手順についても上記の順に沿って解説します。 用語説明 GitLab：ソースコード管理（Git）、コンテナレジストリ、CI/CD など、開発に必要な機能を統合したオールインワンのプラットフォーム。 GitLab Runner：GitLabのCI/CDジョブを実行するためのエージェント。様々な実行環境（Kubernetes、Docker、Shellなど）で動作可能。 Kubernetes Executor：GitLab Runner が Kubernetes クラスター上で Pod を動的に起動し、ジョブを実行するモード。Kubernetes 環境でのCI/CDに最適。 構築情報 本記事では、以下の構成と前提条件に基づいてGitLabを構築しています。 前提条件 以下の環境はあらかじめ構築済みであることを前提としています。 外部インターネットに接続できない OpenShift クラスター OpenShift用のミラーレジストリーサーバー 踏み台サーバー兼作業用端末 OpenShiftクラスターにアクセス可能であり、以下の役割を兼任： 内部DNSサーバー GitLab、GitLab Container Registry、OpenShift クラスター間の名前解決を提供 NFSストレージサーバー OpenShift内のコンテナで使用される永続ストレージ（PersistentVolume）を提供 ロードバランサー OpenShiftクラスターへの HTTPS 通信（APIや Webコンソール）を中継 GitLabの内部公開用ドメインを取得済み 取得したドメインは踏み台サーバーの内部DNSに登録済み ※ 本記事では OpenShiftクラスターおよび踏み台サーバーの構築手順は割愛しています。 GitLabサーバー構成 OS: RHEL9.4 CPU: 8コア メモリ: 16GB ストレージ: 200GB ※ GitLab公式ドキュメント：Reference Architecture のうち、最小構成に準拠。実際に必要なリソースは利用規模（秒間リクエスト数やユーザー数）により変動します。 バージョン情報 GitLab: 18.2.1 GitLab Runner: 18.2.0 GitLab エディション: Community Edition ※ GitLab本体はバージョン 18.2.1、GitLab Runnerはバージョン 18.2.0を使用しています。  なお、 公式ドキュメント によれば、同一マイナーバージョン内でのパッチバージョン差は互換性に影響せず、連携にも問題がないため、本構成でも正常に動作することを確認済みです。 ※本記事のOpenShiftクラスターはOpenShift 4.x系で構築されていますが、Kubernetes標準に準拠したクラスターであれば同様の構成が可能です。 GitLabの構築 GitLabは、Linuxパッケージを用いた手動インストールや、HelmチャートやOperatorによるKubernetes上へのデプロイなど、複数の構築手段が提供されています。 本記事では、RHELサーバー上にLinuxパッケージを用いてGitLab Community Editionを構築する方法を紹介します。 必要なツールのインストール GitLabをインストールするRHELサーバーにログインし、rootユーザーに切り替えます。 $ sudo su - 作業用ディレクトリを作成します。 # mkdir -p /data/work # cd /data/work GitLabの構築に必要なパッケージをインストールします。 # dnf install curl nfs-utils openssl postfix -y ※ツールの説明： curl: GitLabのリポジトリ追加で使用 nfs-utils: 踏み台サーバー内のNFS共有ディレクトリを利用するために使用 openssl: 自己署名証明書の作成に使用 postfix: メール通知機能に使用（今回はローカル送信のみ） GitLabのインストール GitLabのリポジトリを追加し、外部公開URLを指定してGitLabパッケージをインストールします。 # curl "https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.rpm.sh" | bash # EXTERNAL_URL=https://gitlab.local.example.com \ dnf install gitlab-ce 自己署名証明書の作成と配置 今回は内部DNSを使用する閉域環境のため、自己署名証明書を利用します。まずは、GitLabサーバーのドメインとGitLabコンテナレジストリのドメインの自己署名証明書を作成します。 自己署名証明書を作成するための秘密鍵を作成します。 # openssl genpkey -algorithm RSA -out gitlab.local.example.com.key -pkeyopt rsa_keygen_bits:2048 証明書の情報を記載した設定ファイルを作成します。 alt_namesにGitLabサーバーのドメインとGitLabコンテナレジストリのドメインを設定します。 # vi san.cf [ req ] distinguished_name = req_distinguished_name req_extensions = v3_req prompt = no [ req_distinguished_name ] C = JP ST = Tokyo L = Minato-city O = My Local Environment OU = My Team CN = gitlab.local.example.com [ v3_req ] keyUsage = critical, digitalSignature, keyEncipherment extendedKeyUsage = serverAuth subjectAltName = @alt_names [ alt_names ] DNS.1 = gitlab.local.example.com DNS.2 = registry.gitlab.local.example.com 作成した秘密鍵と設定ファイルを利用して、自己署名証明書を作成します。 # openssl req -new -key gitlab.local.example.com.key \ -out gitlab.local.example.com.csr -config san.cnf # openssl x509 -req -days 3650 -in gitlab.local.example.com.csr \ -signkey gitlab.local.example.com.key \ -out gitlab.local.example.com.crt \ -extfile san.cnf -extensions v3_req # 作成結果の確認 # openssl x509 -in gitlab.local.example.com.crt -noout -text # 出力例（一部省略） -----BEGIN CERTIFICATE----- MIIElDCCA3ygAwIBAgIULJoazWr+hErKovG2ZiUSZ5qtHxswDQYJKoZIhvcNAQEL ... -----END CERTIFICATE----- 作成した自己署名証明書と秘密鍵をGitLabのSSLディレクトリにコピーします。 # cp gitlab.local.example.com.jp.crt /etc/gitlab/ssl # cp gitlab.local.example.com.key /etc/gitlab/ssl ファイルのパーミッション設定を以下のように行います。 証明書ファイル（.crt）は読み取り専用（644）にします。 秘密鍵（.key）は機密性が高いため、所有者のみ読み書き可能（600）にします。 # chmod 644 /etc/gitlab/ssl/gitlab.local.example.com.crt # chmod 600 /etc/gitlab/ssl/gitlab.local.example.com.key GitLab設定ファイルの編集 GitLabの設定ファイル /etc/gitlab/gitlab.rb を編集します。 # vi /etc/gitlab/gitlab.rb 下記に示す内容を設定ファイル/etc/gitlab/gitlab.rbに記載します。 基本設定（外部公開URL） 参考： https://docs.gitlab.com/omnibus/settings/ssl/#configure-https-manually これらの設定はGitLabにアクセスするためのURLを設定します。今回は自己署名証明書を利用するので、Let’s Encrypt設定を無効化します。また、ドメイン名が長すぎるとエラーが起きるので、nginx[‘server_names_hash_bucket_size’] = 128と設定します。 external_url "https://gitlab.local.example.com" letsencrypt['enable'] = false nginx['server_names_hash_bucket_size'] = 128  # ドメイン名が長い場合のエラー対策 コンテナレジストリ設定（プライベートレジストリとして使用） 参考： https://docs.gitlab.com/administration/packages/container_registry/#container-registry-domain-configuration これらの設定はGitLabコンテナレジストリの設定をします。アクセスするためのURLやその証明証書ファイルを指定します。今回はコンテナレジストリのディレクトリを踏み台サーバーにマウントするので、gitlab_rails[‘registry_path’]にはマウントするディレクトリを設定します。 registry_external_url "https://registry.gitlab.local.example.com" registry_nginx['ssl_certificate'] = "/etc/gitlab/ssl/gitlab.local.example.com.crt" registry_nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/gitlab.local.example.com.key" gitlab_rails['registry_path'] = "/mnt/gitlab-registry" メール通知設定（Postfixによるローカル配送） 参考： https://docs.gitlab.com/omnibus/settings/smtp/ これらの設定はGitLabのメール通知設定を行います。GitLabサーバー上のPostfixのSMTPサーバーにメール通知する設定をします。 gitlab_rails['gitlab_email_from'] = 'gitlab@example.com' gitlab_rails['gitlab_email_display_name'] = 'GitLab' gitlab_rails['smtp_enable'] = true gitlab_rails['smtp_address'] = "127.0.0.1" gitlab_rails['smtp_port'] = 25 gitlab_rails['smtp_domain'] = "localhost" gitlab_rails['smtp_authentication'] = "none" gitlab_rails['smtp_enable_starttls_auto'] = false gitlab_rails['smtp_tls'] = false gitlab_rails['smtp_ssl'] = false 設定の適用と動作確認 GitLabの設定適用 上記の /etc/gitlab/gitlab.rbを記載したら以下のコマンドでGitLabの設定を適用します。 # gitlab-ctl reconfigure サービスの状態確認 GitLabのサービスの状態を確認します。 # gitlab-ctl status 全てのサービスがrun:と表示されていれば正常です。 （例） run: alertmanager: (pid 1319) 3117s; run: log: (pid 1317) 3117s run: crond: (pid 1309) 3117s; run: log: (pid 1305) 3117s run: gitaly: (pid 1284) 3117s; run: log: (pid 1282) 3117s run: gitlab-exporter: (pid 1316) 3117s; run: log: (pid 1308) 3117s run: gitlab-kas: (pid 1310) 3117s; run: log: (pid 1296) 3117s run: gitlab-workhorse: (pid 1307) 3117s; run: log: (pid 1306) 3117s …（省略） 以上でGitLabのインストールと初期構成は完了です。続いて、WebブラウザからGitLabにアクセスし、初期設定を行います。 GitLabの初期設定 初期パスワードの確認 GitLabの初回ログイン用パスワードは、インストール時に自動生成され/etc/gitlab/initial_root_password に保存されています。 以下のコマンドで確認します。 # cat /etc/gitlab/initial_root_password Webコンソールへのアクセス ブラウザからexternal_url に設定したドメインにアクセスします。 初回アクセス時には、次のようなログイン画面が表示されます。 ユーザー名：root パスワード：上記で確認した初期パスワード ※本検証では、閉域環境の内部DNSドメインを使用しているため、外部接続可能なサーバーからVNCコンソール経由でアクセスしています。オフライン環境でもGUIでログイン・操作ができるよう、ネットワーク経路の確保またはポートフォワーディングなどの工夫が必要です。 ユーザーインターフェースの言語を日本語に変更 GitLabインストール直後のUIは英語表記になっています。日本語に切り替えるには、以下の手順で設定します。 サイドメニューから[User settings] > [Preferences] > [Localization]と選択し、ローカライズ設定画面に移動 ローカライズ設定画面の[Language]欄でJapaneseを選択すると、言語環境を日本語に変更 これで、GitLabの管理者アカウントでのログインと基本的なUI設定が完了しました。 次のステップでは、GitLab Runner の登録および CI/CD 環境の構築へと進みます。 GitLab Runnerの構築 本セクションでは、閉域環境の OpenShift クラスターに GitLab Runner をデプロイし、GitLab 本体と連携させる手順を解説します。 GitLab Runnerは Kubernetes Executor を利用し、OpenShift上でCI/CDジョブ用のPodを動的に起動します。 ※Kubernetes Executorとは： GitLab Runnerの実行方式の一つで、CI/CDジョブごとに Kubernetes上に一時的なPodを生成してジョブを実行するモードです。本記事では、このKubernetes Executorを用いてRunnerを構成します。 構築フロー概要 以下の手順で GitLab Runner を構築・連携します： コンテナイメージを配置するプロジェクトを作成 GitLab用のプライベートレジストリに必要なコンテナイメージを事前格納 GitLab管理コンソールで Runnerを登録し、トークンを取得 Helmチャートを用いて OpenShiftにRunnerをデプロイ 証明書・認証情報をOpenShift側に連携 Runnerの稼働確認 プロジェクトの作成 GitLabのコンソールから[+]を選択し、新規プロジェクトを作成します。 GitLabコンテナレジストリにイメージを格納 プロジェクトを作成したら、踏み台サーバーにログインし、ターミナルからRunnerが必要とする資材を取得します。 利用イメージ（例） 用途 イメージ名 GitLab Runner 本体 gitlab-org/gitlab-runner:alpine-v18.2.0 ジョブPodベースイメージ alpine:latest 操作手順（RHEL + Podman 利用例） ※Docker 利用環境ではpodman → dockerに置き換えてください。 # podman login registry.gitlab.local.example.com # podman pull registry.gitlab.com/gitlab-org/gitlab-runner:alpine-v18.2.0 # podman pull docker.io/library/alpine:latest # podman tag registry.gitlab.com/gitlab-org/gitlab-runner:alpine-v18.2.0 registry.gitlab.local.example.com/<ユーザー名>/<プロジェクト名>/gitlab-runner:alpine-v18.2.0 # podman tag docker.io/library/alpine:latest registry.gitlab.local.example.com/<ユーザー名>/<プロジェクト名>/alpine:latest # podman push registry.gitlab.local.example.com/<ユーザー名>/<プロジェクト名>/gitlab-runner:alpine-v18.2.0 # podman push registry.gitlab.local.example.com/<ユーザー名>/<プロジェクト名>/alpine:latest GitLab上で Runner を登録 続いて、GitLab上でRunnerを登録します。本手順はGitLabのコンソール画面にログインして実施します。 GitLab管理コンソールにログイン サイドメニューから[管理者メニュー] → [CI/CD] → [Runner]と移動 [Create instance runner] を選択 任意のタグを入力し、[Runnerを作成] 表示された認証トークン（例: glrt-xxxxxxx）を控えておく ※本記事では、インスタンスRunner（全プロジェクトで利用可能なRunner）を採用しています。 Helmチャートの取得と展開準備 OpenShiftではOperatorを利用してGitLab Runnerをインストールすることも可能ですが、本環境は閉域構成のためOperatorの自動更新によるメリットを十分に活かせません。そこで今回は、Helm チャートを使用してGitLab Runner をインストールします。 本手順は踏み台サーバー内で実施します。 GitLabから提供されているRunnerのHelmチャートを取得 # helm repo add gitlab https://charts.gitlab.io # helm repo update # helm pull gitlab/gitlab-runner --version 0.79.0 OpenShift上の事前設定 OpenShiftにRunnerをデプロイするための準備を行います。 本手順は踏み台サーバー内で実施します。 Namespace 作成 GitLab Runnerのリソースを管理するNamespaceを作成します。 # oc create namespace gitlab-runner-test ServiceAccount & SCC（anyuid）設定 OpenShiftでJobを実行するServiceAccountを作成します。 # oc create sa gitlab-runner-sa -n gitlab-runner-test ServiceAccountの権限設定するgitlab-runner-sa-role.yaml を作成し、以下を適用します。 # vi gitlab-runner-sa-role.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata:   name: scc-anyuid   namespace: gitlab-runner-test rules: - apiGroups:   - security.openshift.io   resourceNames:   - anyuid   resources:   - securitycontextconstraints   verbs:   - use --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata:   name: sa-to-scc-anyuid   namespace: gitlab-runner-test subjects: - kind: ServiceAccount   name: gitlab-runner-sa roleRef:   kind: Role   name: scc-anyuid   apiGroup: rbac.authorization.k8s.io # oc apply -f gitlab-runner-sa-role.yaml OpenShiftに証明書と認証情報を登録 レジストリCAの登録（自己署名証明書対応） 証明書を踏み台サーバーのコンテナ証明書ストアに保存します。 $ mkdir -p /etc/containers/certs.d/registry.gitlab.local.example.com $ openssl s_client -showcerts -connect registry.gitlab.local.example.com:443 < /dev/null | sudo tee /etc/containers/certs.d/registry.gitlab.local.example.com/ca.crt > /dev/null GitLabコンテナレジストリの証明書をOpenShiftのCAストアに登録します。 # oc create configmap gitlab-runner-ca -n openshift-config \ --from-file=registry.gitlab.local.example.com=/etc/containers/certs.d/registry.gitlab.local.example.com/ca.crt # oc patch image.config.openshift.io/cluster --patch '{"spec":{"additionalTrustedCA":{"name":"gitlab-runner-ca"}}}' --type=merge プライベートレジストリのPull認証設定 GitLab RunnerのJobを実行するServiceAccountがコンテナレジストリにアクセスできるようにするために、証明書の認証情報をServiceAccountに紐づけます。 # oc create secret docker-registry gitlab-registry-secret \ --docker-server="registry.gitlab.local.example.com" \ --docker-username="<ユーザー名>" \ --docker-password="***" \ -n gitlab-runner-test # oc secrets link gitlab-runner-sa gitlab-registry-secret --for=pull -n gitlab-runner-test GitLab証明書のシークレット化 GitLab RunnerがGitLab サーバーにアクセスできるようにするためにシークレットを登録します。 # scp <GitLabサーバーのユーザー名>@<GitLabサーバーのIPアドレス>:/data/work/gitlab.local.example.com.crt . # oc create secret generic gitlab-runner-secret \ --namespace gitlab-runner-test \ --from-file=gitlab.local.example.com.crt HelmによるGitLab Runnerのデプロイ values.yaml 設定例 gitlabUrlにはGitLabのURLを設定します。runnerTokenにはGitLab上でGitLab Runnerを作成した際に、確認した認証トークンの値を入力します。imageにはGitLab Runnerのイメージを指定します。runnersにはGitLab RunnerのJob Podのベースイメージを指定します。certsSecretNameにはGitLabサーバーの証明書情報が保存されているシークレットを指定します。 gitlabUrl: https://gitlab.local.example.com/ runnerToken: "glrt-xxxxxxxxxxxxxxxxx" rbac:   create: true serviceAccount:   create: false   name: gitlab-runner-sa image:   registry: "registry.gitlab.local.example.com"   image: <ユーザー名>/<プロジェクト名>/gitlab-runner   tag: <タグ名> runners:   config: |     [[runners]]       [runners.kubernetes]         namespace = "{{ default .Release.Namespace .Values.runners.jobNamespace }}"         image = "registry.gitlab.local.example.com/<ユーザー名>/<プロジェクト名>/alpine:latest" certsSecretName: gitlab-runner-secret インストール実行 GitLab RunnerをHelmインストールします。 # helm install gitlab-runner ./gitlab-runner-0.79.0.tgz -f values.yaml -n gitlab-runner-test 動作確認 Podの起動確認 # oc get pod -n gitlab-runner-test # Running 状態で起動していることを確認 NAME                             READY   STATUS    RESTARTS   AGE gitlab-runner-7658bb5fdc-rb95v   1/1     Running   1          13h GitLab側でRunnerステータス確認 GitLab管理コンソールの [Runner管理画面] にて、登録したRunnerが「オンライン」表示になっていることを確認します。 これでGitLabとOpenShiftクラスター上の GitLab Runnerの連携が完了しました。 このRunnerを利用して、GitLab CI/CDパイプラインからジョブを実行できるようになります。 まとめ 本記事では、Linuxサーバー上に GitLabを構築し、閉域環境にあるKubernetes（OpenShift クラスター）と連携してCI/CD環境を実現する手順を紹介しました。 特に、以下のような環境において、今回の検証内容は実用的なモデルケースとなります。 インターネット接続が制限されたオンプレミス環境 セキュリティ要件上、外部クラウドサービスの利用が難しい開発現場 閉域環境下で Kubernetesを活用しているものの、CI/CD基盤の整備や統合に課題を抱えている開発現場 本シリーズでは今後も今回構築した環境を基に閉域環境でのリポジトリ管理やCI/CDパイプラインとコンテナプラットフォームの連携について解説する予定です。 「閉域環境でのDevSecOps」を本格展開するための一歩として、本記事の構成をぜひ活用してみてください。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post GitLabとコンテナプラットフォームの連携 first appeared on SIOS Tech. Lab .

はじめに こんにちは！重要な機能開発を任されて最近まで業務で手一杯だったなーがです。今回はBicepで作成したAzure FunctionsとApplication Insightsをリンクする方法について解説します。 Azure Functionsをデプロイした際、Azure PortalのFunctionsの画面から直接ログを確認したいというニーズは多いかと思います。しかし、Bicepでそれぞれを個別にデプロイしただけでは、Azure FunctionsのポータルからApplication Insightsのログを直接参照することができず、一手間かかってしまいます。 今回の設定を行うことで、Azure Functionsの管理画面からシームレスにログの確認ができるようになります。 課題：Azure FunctionsからApplication Insightsのログを直接確認できない BicepでAzure FunctionsとApplication Insightsをデプロイしただけでは、Portal上のFunctionsのメニューからログを確認しようとしても、関連付けがされていないため、以下のように表示されてしまいます。この状態では、Application Insightsのリソースを直接開いてログを確認する必要があり、少し不便です。 解決方法 この問題は、Azure Functionsのアプリケーション設定に、Application Insightsの接続文字列を追加することで解決します。 具体的には、Azure Functionsリソースの siteConfig.appSettings に APPLICATIONINSIGHTS_CONNECTION_STRING という名前のプロパティを追加し、その値としてApplication Insightsリソースの properties.ConnectionString を指定します。 公式ドキュメントによると、 APPINSIGHTS_INSTRUMENTATIONKEY または APPLICATIONINSIGHTS_CONNECTION_STRING のいずれかを設定することで連携できます。しかし、 APPINSIGHTS_INSTRUMENTATIONKEY は2025年3月31日にサポートが終了しているため、今後は APPLICATIONINSIGHTS_CONNECTION_STRING の使用が推奨されます。 参照 Azure Functions のアプリケーション設定のリファレンス Connection strings in Application Insights resource applicationInsights 'Microsoft.Insights/components@2020-02-02' = { name: 'application-insights' location: location kind: 'web' ~~ 省略 ~~ } } resource funcApp 'Microsoft.Web/sites@2023-12-01' = { name: 'func-app' ~~ 省略 ~~ properties: { siteConfig: { appSettings: [ { name: 'APPLICATIONINSIGHTS_CONNECTION_STRING' value: applicationInsights.properties.ConnectionString } ] } } } この設定をデプロイ後、Azure Portalで確認すると、Azure FunctionsがApplication Insightsに正しく接続されていることが分かります。 これにより、Azure Functionsの「ログ」メニューから直接クエリを実行して、Application Insightsに送信されたログを確認できるようになります。 補足： hidden-link タグについて Function AppとApplication Insightsを関連付けると、Azureの内部では tags プロパティに hidden-link という特殊なタグが作成されます。これは、Azure PortalなどのUI上でリソース間の関連付けを表現するために使用されるものです。 APPLICATIONINSIGHTS_CONNECTION_STRING をアプリケーション設定に追加するだけで、通常はこの hidden-link タグがAzureによって自動的に作成・管理されます。そのため、Bicepテンプレートで明示的に hidden-link タグを記述する必要は基本的にありません。 このタグを手動で管理することは、サブスクリプションIDやリソースグループ名などをBicepファイルに含める必要があり、テンプレートの複雑性を増す要因にもなります。 そのため、推奨される方法は APPLICATIONINSIGHTS_CONNECTION_STRING の設定に任せて、 hidden-link の自動作成を利用することです。 参照： In bicep, how to property and securly set `hidden-link` in tags? 応用：複数のAzure Functionsを1つのApplication Insightsに紐付ける 複数のAzure Functionsのログを、1つのApplication Insightsでまとめて管理することも可能です。その場合も設定は同様で、各Azure Functionsの appSettings に、共通のApplication Insightsの接続文字列を追加するだけです。 resource applicationInsights 'Microsoft.Insights/components@2020-02-02' = { name: 'application-insights' location: location kind: 'web' ~~ 省略 ~~ } } resource funcApp1 'Microsoft.Web/sites@2023-12-01' = { name: 'func-app-1' ~~ 省略 ~~ properties: { siteConfig: { appSettings: [ { name: 'APPLICATIONINSIGHTS_CONNECTION_STRING' value: applicationInsights.properties.ConnectionString } ] } } } resource funcApp2 'Microsoft.Web/sites@2023-12-01' = { name: 'func-app-2' ~~ 省略 ~~ properties: { siteConfig: { appSettings: [ { name: 'APPLICATIONINSIGHTS_CONNECTION_STRING' value: applicationInsights.properties.ConnectionString } ] } } } ログの識別性を高める 複数のFunctionsからログを集約すると、どのログがどのFunction Appから出力されたものか区別がつきにくくなる場合があります。 その際は、環境変数 WEBSITE_CLOUD_ROLENAME を設定することで、Application Insights上のログに表示されるクラウドロール名（ cloud_RoleName ）を任意の名前に変更できます。これにより、ログの発生源を容易に特定できるようになります。 参照： クラウド ロール名を設定する resource applicationInsights 'Microsoft.Insights/components@2020-02-02' = { name: 'application-insights' location: location kind: 'web' ~~ 省略 ~~ } } resource funcApp1 'Microsoft.Web/sites@2023-12-01' = { name: 'func-app-1' ~~ 省略 ~~ properties: { siteConfig: { appSettings: [ { name: 'APPLICATIONINSIGHTS_CONNECTION_STRING' value: applicationInsights.properties.ConnectionString } { name: 'WEBSITE_CLOUD_ROLENAME' value: 'function-application-1' } ] } } } resource funcApp2 'Microsoft.Web/sites@2023-12-01' = { name: 'func-app-2' ~~ 省略 ~~ properties: { siteConfig: { appSettings: [ { name: 'APPLICATIONINSIGHTS_CONNECTION_STRING' value: applicationInsights.properties.ConnectionString } { name: 'WEBSITE_CLOUD_ROLENAME' value: 'function-application-2' } ] } } } WEBSITE_CLOUD_ROLENAME を指定しない場合、 cloud_RoleName にはAzure Functionsのリソース名（この例では func-app-1 , func-app-2 ）が自動的に使用されます。 おわりに 今回は、Bicepを利用してAzure FunctionsとApplication Insightsを連携させる方法についてご紹介しました。 APPLICATIONINSIGHTS_CONNECTION_STRING を設定するという簡単な手順で、開発や運用の効率を大きく向上させることができます。Bicepを利用してAzure FunctionsとApplication Insightsでリソースを管理する際には、ぜひこの設定を活用してみてください。 今回作成したリソースは こちら ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Bicepで作成したAzure FunctionsとApplication Insightsをリンクする方法 first appeared on SIOS Tech. Lab .

はじめに 前回 は、GitLab上のリモートリポジトリとの連携やプロジェクトの作成・管理、ローカル環境でのクローン、ローカルリポジトリでの変更内容をリモートリポジトリに反映してみました。これで、複数の開発者で同じ変更履歴を共有することができるため、円滑にチーム開発を進められます。 Gitを使った開発では、コードの変更履歴を管理するだけでなく、複数の開発者が同時に作業を進めるための仕組みが必要です。その中心となるのが「ブランチ」という概念です。 今回は、Gitのブランチとは何かという基本から、チーム開発でよく使われるブランチ戦略、そしてGitLabでのマージリクエストを通じた具体的な開発フロー、さらにはコンフリクト（競合）の解消方法まで、実践的に解説していきます。 ブランチ説明と利用ケース ブランチとは、 第1回 でも軽く触れましたが、現在の作業から派生して新しい開発ラインを作成する機能です。新しい機能開発やバグ修正を行う際に、メインの開発ラインに影響を与えずに作業を進めることができます。作業が完了したら、上位のブランチに統合（マージ）します。 ブランチを作成することで、複数の開発者がそれぞれ異なる機能やバグ修正に同時に取り組んだり、メインの安定した状態を壊すことなく、新しい機能を追加したり、大きな変更を加えたりすることができます。 ブランチ戦略について Gitのブランチを効果的に使うためには、チーム全体で共通のルールが必要です。これが「ブランチ戦略」と呼ばれるものです。ここで大切なことは、必ずしも絶対的なブランチ戦略はなく、プロジェクトの性質に応じて適切なブランチ戦略を選択することです。 ここでは、代表的な4つの戦略の概要を見ていきましょう。 Git Flow Git Flowは、最も歴史が長く複雑なブランチ戦略です。 main、developブランチを中心としてそれぞれの修正用ブランチとリリース用ブランチを運用します。 特に大規模なプロジェクトや、頻繁なリリースよりも安定性と厳密なバージョン管理が求められるプロジェクトに適しています。 Webアプリのような継続的デリバリーを想定したプロジェクトには適していません。 バージョン管理と安定したリリースが可能ですが、5種類 (main, hotfix, release, develop, feature) のブランチを運用するため、ブランチ管理が複雑で運用コストが高い点が特徴です。 main: 本番環境にデプロイされている、常に安定したコードを保持するブランチです。ここに直接コミットすることは通常ありません。 develop: 次期リリースに向けた開発の中心となるブランチです。featureブランチでの作業が完了すると、ここにマージされます。 feature: 新機能開発のためのブランチです。developから分岐し、開発が完了するとdevelopにマージされます。 release: リリース準備のためのブランチです。developから分岐し、最終的なバグ修正やリリースバージョン情報の更新が行われます。完了後、mainとdevelopの両方にマージされます。 hotfix: 本番環境で発見された緊急のバグ修正のためのブランチです。mainから分岐し、修正が完了するとmainとdevelopの両方にマージされます。 Image Source: https://nvie.com/posts/a-successful-git-branching-model/ GitHub Flow GitHub Flowは、非常にシンプルで軽量なブランチ戦略です。継続的デリバリーを重視し、頻繁なデプロイが行われるWebサービスやSaaS開発に広く採用されています。 main, featureの2種類のブランチで運用します。基本的に main ブランチのみをメインとし、このブランチは「常にデプロイ可能」な状態を保ちます。すべての開発はmainから派生した新しいfeatureブランチで行われ、プルリクエスト（GitLabでのマージリクエスト）を通じてmainに統合されます。 シンプルで理解しやすく、運用が容易で、CI/CDとも相性が良いですが、複数のリリースを管理する場合には適していない点が特徴です。 GitLab Flow GitLab Flowは、Git Flowの厳密さとGitHub Flowのシンプルさを組み合わせたブランチ戦略です。GitHub Flowをベースにしつつ、環境ごとのデプロイや長期安定版の管理を考慮しており、特にGitLabのCI/CDやDevOps機能との統合を前提としています。 main, featureの2種類のブランチ運用を基本としつつ環境用のブランチを適宜導入して運用します。main ブランチを常にデプロイ可能にするのはGitHub Flowと同じですが、必要に応じて pre-production や production といった環境ブランチを導入し、段階的なデプロイを管理できます。これにより、ステージング環境でのテストを経て本番にデプロイするといったワークフローをブランチレベルで表現できます。 比較的シンプルな構造のまま複数のリリースを管理できますが、Git Flowほどの厳密なリリース管理には向いていない点が特徴です。 トランクベース開発 トランクベース開発は、チーム全員が1つのメインブランチ（trunkやmain）を中心に開発を進め、各自の変更を小さな単位で頻繁にメインブランチへマージするGitのブランチ戦略です。 この手法では、長期間存在する開発用ブランチや大規模なマージ作業を避け、「短命なブランチ」または直接のコミットを用い、1日1回〜数日に1回のペースでメインブランチに変更を統合します。これにより、コンフリクト（競合）の発生を抑止しやすく、常にリリース可能な安定したmainブランチ状態を保つことができます。 常に安定したメインブランチを維持でき、マージコンフリクトやリリース遅延のリスクが低いですが、長期ブランチや大規模リリースの運用には向いていない点が特徴です。 Trunk-Based Development For Smaller Teams: Scaled Trunk-Based Development: Image Source: https://trunkbaseddevelopment.com/ 一般に大規模かつ安定性を重視する場合は、運用するブランチを増やして対応する戦略が推奨され、小規模や頻繁なデプロイが行われる場合は、運用するブランチを少なくシンプルに対応する戦略が推奨されます。 チーム開発での課題 チーム開発では、複数の開発者が同じファイルを同時に変更することが頻繁にあります。その際に発生するのが「コンフリクト（競合）」です。Gitは賢いツールですが、同じファイルの同じ行を異なる方法で変更した場合など、どちらの変更を採用すべきか自動で判断できない場合にコンフリクトが発生します。 コンフリクトの例 図は、同じ起点から分岐したブランチAとブランチBで、同じファイル（index.html）をそれぞれ変更していることを示しています。この2つのブランチをmainブランチ（青い線）にマージしようとすると、Gitはどの変更を最終的に採用すべきか判断できず、コンフリクトが発生します。 チーム開発の実例 それでは、具体的なシナリオでGitHub Flowを使ったチーム開発を見ていきましょう。コンフリクトの実例と解決も行っていきます。 第4回のブログの手順を実施後、すでにgit cloneでローカルにリポジトリを取得していることを前提とします。 複数メンバーによる競合発生 GitHub Flowでは、mainブランチは常に安定しており、デプロイ可能な状態を保ちます。そのため、機能開発やバグ修正は必ずmainから新しいブランチを切って行います。 コンフリクトを起こすための2つのブランチを作成します。 ブランチA (feature/add-comment)での作業 mainブランチから新しいブランチfeature/add-commentを作成し、README.mdファイルにコメントを追加します。ブランチを作成する際は、git checkoutコマンドを実行します。-bオプションをつけることで、作成したブランチにそのまま移動します。 $ git checkout -b feature/add-comment Switched to a new branch 'feature/add-comment' README.mdを開き、以下の内容を追記します。 # プロジェクト概要 このプロジェクトはGitLabの学習用です。 // Aさんが追加したコメント コミットとプッシュを行います。 $ git add README.md $ git commit -m "feat: Add a comment in README" $ git push -u origin feature/add-comment ブランチB (feature/update-description)での作業 次に、mainブランチに戻り、別の新しいブランチfeature/update-descriptionを作成します。こちらも同じREADME.mdファイルの同じ箇所に別の変更を加えます。 mainブランチに戻ります。 $ git checkout main Switched to branch 'main' Your branch is up to date with 'origin/main'. ブランチの作成と切り替えを行います。 $ git checkout -b feature/update-description Switched to a new branch 'feature/update-description' README.mdを開き、以下の内容に追記します。 # プロジェクト概要 このプロジェクトはGitLabの学習用です。 // Bさんが追加したコメント コミットとプッシュを行います。 $ git add README.md $ git commit -m "feat: Update project description" $ git push -u origin feature/update-description これで、mainブランチを起点に、同じファイルの同じ行を異なる内容で変更した2つのブランチができました。 マージリクエスト（プルリクエスト）作成 GitLabのWeb UI上で、feature/add-commentブランチの変更をmainに統合するためのマージリクエスト (MR) を作成します。 GitLabでMRを作成します。 メニューの「マージリクエスト」から「新しいマージリクエスト」をクリックします。 ソースブランチとターゲットブランチを選択し、「ブランチを比較して続行する」をクリックして、feature/add-commentからmainへのMRを作成します。 「作成 merge request」をクリックしてMRを作成します。 GitLabでは、マージが完了したfeatureブランチを自動的に削除するオプションがあります。基本的にマージ後は不要になるブランチなので、積極的に削除してブランチリストをきれいに保ちましょう。ローカルブランチも git branch -d <ブランチ名> で削除できます。 mainにマージします。 この時点ではまだコンフリクトは起きていません。問題なくマージできるので、「マージ」をクリックしてマージを完了させます。 マージできたことを確認します。 次に、feature/update-descriptionブランチの変更をmainに統合するためのMRを作成します。 ソースブランチとターゲットブランチを選択し、「ブランチを比較して続行する」をクリックして、feature/update-descriptionからmainへのMRを作成します。 「作成 merge request」をクリックしてMRを作成します。 コンフリクトの発生を確認します。 MR作成後、GitLabの画面に「マージがブロックされました」というメッセージが表示されます。これは、feature/update-descriptionの変更と、すでにmainにマージされたfeature/add-commentの変更が同じ箇所を編集しているため、GitLabが自動でマージできないことを示しています。 コンフリクト解消 コンフリクトが発生したら、開発者が手動で解決する必要があります。 ローカルブランチに最新の変更を取り込みます。 feature/update-descriptionブランチにmainブランチの最新の変更を取り込みます。 自分の作業ブランチにいることを確認します。 $ git checkout feature/update-description Already on 'feature/update-description' Your branch is up to date with 'origin/feature/update-description'. mainブランチの最新を取り込みます。 git pullを実行すると、コンフリクトが発生したことがコマンドラインに表示されます。 $ git pull origin main Auto-merging README.md CONFLICT (content): Merge conflict in README.md Automatic merge failed; fix conflicts and then commit the result. 手動でファイルを修正します。 README.mdをエディタで開き、Gitが挿入した競合マーカーを確認します。 # プロジェクト概要 このプロジェクトはGitLabの学習用です。 <<<<<<< HEAD // Bさんが追加したコメント ======= // Aさんが追加したコメント >>>>>>> main <<<<<<< HEADから=======までが現在のブランチ(feature/update-description)での変更、=======から>>>>>>> mainまでがmainブランチでの変更です。今回は両方のコメントを残すことにしましょう。マーカーを削除し、以下のように修正します。 # プロジェクト概要 このプロジェクトはGitLabの学習用です。 // Bさんが追加したコメント // Aさんが追加したコメント コンフリクト解消のコミットとプッシュを行います。 修正が完了したら、変更をコミットし、リモートにプッシュします。 $ git add README.md $ git commit -m "Fix: Resolve conflict in README.md" $ git push origin feature/update-description マージ ローカルでコンフリクトが解決され、リモートにプッシュされると、GitLabのMR画面の「マージがブロックされました」というメッセージが消えます。レビューが完了したら、安心して「マージ」をクリックできます。 このように、コンフリクトは複数のブランチが同じ箇所を同時に変更した際に発生しますが、 git pull で最新の変更を取り込み、競合マーカーを参考に手動で修正することで、簡単に解決できます。 今回はシンプルなテキストにおけるコメントの重複でしたが、チーム開発の現場においてはソースコード内での処理など複雑なコンフリクトが発生する場合があります。 そのような場合、コンフリクトは発生してから解決するよりも、事前に避けることの方が重要です。コンフリクトを未然に防ぐために大切なことは、作業を始める前や、ブランチをプッシュする前に、必ず最新の変更をメインブランチから取り込むことです。 たとえば、 git pull --rebase というコマンドを使うと、リモートの最新コミットを基に自分のコミットを再適用し、履歴をきれいに保ちながらコンフリクトを最小限に抑えられます。こうした習慣を身につけることで、チーム開発はよりスムーズになり、余計なトラブルを減らすことができます。 コンフリクト解消の基本 プロセスを習得することで、チーム開発でのトラブルを恐れず、安心して開発を進められるようになりますが、 解決にかかる時間を減らすためにも、日頃からこまめに最新の変更を取り込むことを心がけましょう。 まとめ 今回の記事では、Gitを使ったチーム開発の要である「ブランチ」について深く掘り下げました。GitHub Flowを前提としたチーム開発の流れを実践し、さらにはコンフリクト（競合）の解消方法まで解説しました。 次回は、GitLabの主な利用機能とGitHubとの違いを解説していきます。 参考文献 https://nvie.com/posts/a-successful-git-branching-model/ https://docs.github.com/ja/get-started/using-github/github-flow https://about.gitlab.com/ja-jp/topics/version-control/what-is-gitlab-flow/ https://trunkbaseddevelopment.com/   ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Git & GitLab 入門 (5) ～Git マスターへの道～「Git のブランチについて」 first appeared on SIOS Tech. Lab .

はじめに Git & GitLab入門ブログ Gitマスターへの道の第4回です。前回のGit & GitLab入門ブログ3Gitマスターへの道「Git操作チーム利用コマンドやロールバック」では、チーム開発で使うコマンド、コミットを戻す際に使用するコマンドについて紹介しました。 今回は、 リモートリポジトリの解説とリモートリポジトリへのsshキーの登録、リモートリポジトリ(プロジェクト)の作成、リモートリポジトリのクローンなどの操作、その他のリモートリポジトリへの変更を加える操作を実践的に解説していきます。 今回は、Gitのブランチとは何かという基本から、チーム開発でよく使われるブランチ戦略、そしてGitLabでのマージリクエストを通じた具体的な開発フロー、さらにはコンフリクト（競合）の解消方法まで、実践的に解説していきます。 実行環境 OS : WSL2 – Ubuntu 22.04.2 LTS リモートリポジトリとは? 共同開発においてリモートリポジトリはコードの共有やバックアップなどの役割を担っています。 リモートリポジトリはネットワーク上に存在し、チームメンバーで共有して使うリポジトリです。一方ローカルリポジトリは開発者のパソコン上に存在しており、個人で使用します。 リモートリポジトリとローカルリポジトリはClone, Pull, PushなどのGit操作によってやり取りを行っています。 そこで、チーム開発の現場でこのリモートリポジトリを提供している代表的なサービス、ソリューションについて再度説明します。 GitLab GitLabはGitの仕組みを利用したDevSecOpsプラットフォームです。DevSecOpsとは開発(Dev)・運用(Ops)のプロセスにセキュリティを組み込み、早期から継続的に安全性を確保する取り組みのことを差します。 GitLabの特徴はこのDevSecOpsとの一体化と組織内で運用できるセルフホスト型であることで、統合型のDevOpsプラットフォームとして優れています。 GitHub GitHubはGitの仕組みを利用してオンラインでソースコードなどの共有、管理などを行うことができるウェブサービスです。 GitHubは世界中のオープンソースプロジェクトが利用しておりコミュニティが活発であり、個人や企業などで使用されており、オープンソースコミュニティやシンプルなコード管理に優れています。 リモートリポジトリのクローン GitLabでのリモートリポジトリのクローンの手順を解説します。 ※今回はGitLabの手順を解説しますが、「ローカルにSSH鍵を作成して、公開鍵をリモートリポジトリ側に登録し、SSH経由で操作できるようにする」という流れはGitHub等の他サービスにおいても同様です。 ssh設定 まずGitLabに対してssh設定を行います。 自身のターミナルでsshキーを作成します。 Linux準拠のホームディレクトリの指定方法の場合は以下のコマンドで作成できます。 ssh-keygen -t ed25519 -f ~/.ssh/GitLab_key Windowsの標準ターミナルで実行する場合パスの指定方法が異なり以下のようになります。 ssh-keygen -t ed25519 -f %USERPROFILE%\.ssh\GitLab_key このコマンドは以下の構成でできています。 ssh-keygen  sshキーを生成するためのユーティリティ -t ed25519 鍵のタイプを指定するオプション -f ~/.ssh/GitLab_key 鍵の保存先と名前を指定 以下の画像はsshキー作成時の実行結果です。 ~/.sshディレクトリへ移動後コマンドを実行し、その際入力を求められますが何も入力せずにエンターを押して大丈夫です。 sshキーの作成 次にGitLabでこのsshキーを登録していきます。 GitLabへログイン後TOPページから、以下の画像のように自分のユーザーのアイコンから設定を開きます。 GitLabのTOPページ 画面左のサイドバーにユーザー設定があるので、ユーザー設定項目からSSHキーの箇所をクリックします。 ユーザー設定内のSSHキー 次に画面右中央の新しいキーを追加をクリックします。 SSHキー追加 先ほど作成したSSHキー(.pubがついているほう)の中身をcatコマンドなどで確認してコピーします。 公開鍵のコピー キーのセクションに先ほどコピーしたキーの中身を貼り付けます。その他の設定もお好みで入力しキーを作成をクリックします。 SSHキー登録時の設定画面 今回はキーの名前をカスタムしているのでconfigファイルにSSH設定を書き込んでおきます。 vi ~/.ssh/config viコマンドでconfigファイルを開き Host (GitLabのホスト名)     HostName (GitLabのホスト名)     User git     IdentityFile ~/.ssh/GitLab_key このテキストを貼り付けて保存します。 これでsshキーの設定ができました。 リモートリポジトリ(プロジェクト)の作成 次にリモートリポジトリ(プロジェクト)の作成です。 ユーザーアイコンの隣の＋マークから新規プロジェクト/リポジトリをクリックします。 GitLabのTOPページから新規プロジェクト作成 プロジェクト作成方法の選択画面です。今回は空のプロジェクトの作成をクリックします。 プロジェクト作成補法の選択画面 プロジェクトの設定画面です。プロジェクト名などを入力してプロジェクトを作成をクリックします。 プロジェクト作成設定画面 これでリモートリポジトリ(プロジェクト)の作成ができました。 GitLabからのGit clone 次に先ほど作ったリモートリポジトリ(プロジェクト)をローカルにcloneします。 プロジェクトのホーム画面で画面右側の上のほうにある「コード」という箇所をクリックします。そうすると以下のようなボックスが出てくるので「SSHでクローン」のURLをコピーします。 プロジェクトのTOPページ リモートリポジトリ(プロジェクト)をローカルリポジトリとして配置したいディレクトリでgit cloneを行います。 git clone (先ほどコピーしたSSHクローンの内容) を実行します。 以下のような実行結果が出れば成功です。 git cloneの実行結果 リモートリポジトリに変更を反映させる 次にadd,commit,pushを行いローカルリポジトリの変更をリモートリポジトリに反映させていきます。 尚、今回はブランチを切らずにすべてmainブランチで実施します。ブランチに関しては次回の Git & GitLab 入門 (5) ～Git マスターへの道～「Git のブランチについて」 で詳しく取り上げますのでそちらをご覧ください。 今回はmain.pyをローカルリポジトリに追加しました。こちらをリモートリポジトリに反映させていきます。 作成したmain.py まず、コマンドラインから実行する場合の手順です。 最初にadd を行います。これにより指定されたファイルはステージングエリアに追加されます。 git add (ファイル名) 次にcommitを行います。これによりステージングエリアの変更をローカルリポジトリに保存します。 git commit -m "コメント" 最後にpushを行います。これによりローカルリポジトリの変更がリモートリポジトリに送信されます。今回はmainブランチに直接変更を加えるのでオプションなどは付けずにコマンドを実行します。 git push 以下の画像はコマンドラインで一連の流れを実施した際の実行結果です。 コマンドラインでのadd, commit, pushの実行結果 VScodeから実行する場合以下のようになります。 add ソース管理のファイル名の右端にある＋ボタンを押すとファイルをステージングエリアに追加できる。 VScodeでのgit addの実行例 commit メッセージのテキストボックスにコメントを書き込みコミットボタンを押すとステージングエリアの変更をローカルリポジトリに保存することができる。 VScodeでのgit commitの実行例 push 変更の同期を押すとローカルリポジトリの変更がリモートリポジトリに送信される。 VScodeでのgit pushの実行例 まとめ 今回はリモートリポジトリの解説とリモートリポジトリへのsshキーの登録、リモートリポジトリ(プロジェクト)の作成、リモートリポジトリのクローンなどの操作、その他のリモートリポジトリへの変更を加える操作を実施しました。 これにより、Gitを活用してリモートリポジトリとの連携やプロジェクトの作成・管理、ローカル環境でのクローン、ローカルリポジトリでの変更内容をリモートリポジトリに反映できるようになりました 。 次回は、Gitのブランチについての説明とチーム開発でのブランチの実例を紹介します。 参考文献 https://wa3.i-3-i.info/diff811repository.html ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Git & GitLab 入門 (4) ～Git マスターへの道～「リモートリポジトリとローカルリポジトリ」 first appeared on SIOS Tech. Lab .

こんにちは、PS-SL新卒1年目のひろです。 8/3にOSC京都2025に参加させていただきました。参加した中で特に印象に残った展示、セミナーについて紹介させていただきます。 さくらインターネット株式会社 さくらインターネット さんが行っていた「高火力シリーズ」についてのセミナーに参加させていただきました。私は、さくらインターネットさんと聞いてまず思い浮かんだのはレンタルサーバ事業で、高火力シリーズときいてどのようなサービスなんだろうと気になっていました。 今回ご紹介いただいた 「高火力シリーズ」 では、3つのGPUクラウドサービスが展開されています。今回のセミナーでは実際に生成AIを使用し、画像を生成するデモを見せていただきました。 生成AIにとってGPUはとても重要な要素です。GPUは小さなコアをたくさん持っており、大量の計算を同時にこなすような並列処理に特化しています。生成AIの学習や推論には膨大な計算が不可欠なため、GPUが活用されています。さくらインターネットさんの高火力シリーズはこのGPUを提供するサービスで、生成AIや機械学習の分野に持って来いなサービスです。 今回紹介されていた3つのサービスについてまとめます。 まず 高火力PHY 。こちらはGPUを8基搭載したベアメタルサーバーです。NVIDIA H100やH200といった超高性能なGPUを搭載したモデルが用意されています。高火力も高火力といった具合で、大規模なサービス開発に特化している印象を受けました。 次に 高火力VRT 。こちらはVM（仮想マシン）型のGPUクラウドで、NVIDIA H100、NVIDIA V100といったGPUのプランを選ぶことができます。チャットボットサービスなどの即応答性が求められるサービスに最適です。また、時間単位での課金制で 、柔軟に利用することができます。 最後に 高火力DOK 。こちらはコンテナー型GPUクラウドサービスで、作成したDockerイメージをpullし、イメージを実行することができます。こちらはバッチ処理のような終わりのある処理に適していると紹介いただきました。高火力DOKは秒単位での従量課金制で、実行時間のみコストが発生する仕組みとなっており、高火力なGPUを最小限のコストで利用できる点が大きな魅力です。AI関連のサービス開発や研究の敷居を下げてくれる素晴らしいサービスだと思いました。 今回のセミナーを通じて、「高火力シリーズ」が大規模処理、リアルタイム処理、バッチ処理といった多様なニーズをカバーしていることがよく分かりました。日本の生成AIサービスや研究を支える、土台のような存在だと感じました。 osdev-jp osdev-jp さんはOS開発に役立つ情報を収集、公開されているコミュニティで、今回は自作OSを展示されていました。 私はOS開発をしたことはなく、OSが何を行っているか大まかな知識しか持っていなかったのですが、お話していただいた内容から興味を持つことができました。特に魅力的に感じたのは、自分だけのGUIデザインやコマンドを作ることができる点と、普段何気なく使用しているPCの裏側でOSがどのような役割を果たしているのか実践的に深く学べるという点です。OS開発に関する書籍も紹介していただいたので折に触れて挑戦したいと思いました。 osdev-jpさんの展示内容。自作OSの展示です Japanese Raspberry Pi Users Group Japanese Raspberry Pi Users Group さんはRaspberry Piを用いた様々な製品、作品の展示をされていました。印象に残った展示についてまとめます。 まず、Raspberry Pi 500というRaspberry Piとキーボードが一体になっている製品です。モニターとマウスさえあればPCとして使用することが可能という、手軽で優れた製品です。自分はRaspberry Piをほとんど使用したことがなかったこともあり、キーボードと一体になっていることに驚きました。小型のモニタモジュールと一緒に使用できる様子を見せていただきました。 次にRaspberry Pi 5 + AI Cameraの展示です。AI CameraはカメラモジュールにAIが内蔵されており、モジュール側で物体検知を行えるという優れものです。小型カメラ側で検知してくれるという点に驚きました。 自分は電子工作を通ってきておりませんが、モジュールを組み合わせてアイデア次第で様々なものを作れるというのがとても魅力的で、自分でも何か作ってみたいと思いました。まずはRaspberry Piを購入するところから始めたいと思います！ Japanese Raspberry Pi Users Groupさんの展示内容。Raspberry Pi 500の展示です Japanese Raspberry Pi Users Groupさんの展示内容。Raspberry Pi 5 + AI Cameraの展示です 最後に 今回OSC京都2025に参加し、これまでよく知らなかった技術のお話をたくさん聞くことができ、とても有意義な時間を過ごすことができました。もっと技術的に深い議論ができるよう精進していきたいと思います。 素敵な展示、セミナーを開催してくださった皆様、本当にありがとうございました。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 1人がこの投稿は役に立ったと言っています。 The post OSC京都2025 セミナー＆展示紹介と感想 first appeared on SIOS Tech. Lab .

デザインに潜む「魔法の数字」 この記事では、なぜ現代のUIデザインにおいて「8の倍数ルール」と「12カラムシステム」が最適解として広く採用されているのか、その謎を紐解いていきます。この二つのルールを理解することは、デザインの品質を向上させるだけでなく、その背後にある「なぜ」を知ることで、より本質的なデザイン思考を身につける助けとなるでしょう。 すべての土台にある「2のべき乗」という考え方 UIデザインの話をする前に、まずそのUIが表示される媒体、すなわちコンピューターの根本的な仕組みに触れる必要があります。なぜなら、「8」という数字が選ばれる背景には、コンピューターの動作原理が深く関わっているからです。 コンピューターの言語「2進数」 ご存知の通り、コンピューターは内部ですべての情報を「0」と「1」の組み合わせで処理しています。これは、電気回路のスイッチが「オン」か「オフ」かという、2つの状態しか物理的に表現できないことに由来します。この「0」と「1」だけで数を表現する方法が「2進数」です。 しかし、2進数は人間にとって扱いにくいという問題があります。例えば、私たちが日常的に使う10進数の「255」は、2進数で表現すると「11111111」という8桁の長い文字列になってしまいます。これでは、人間が読んで理解したり、間違いなく入力したりするのは困難です。 2進数の最適な通訳「16進数」と「8ビット」 この問題を解決するために登場するのが「16進数」です。16進数がなぜ「通訳」として最適なのか。それは、2⁴=16 という数学的な関係があるためです。これにより、 2進数の4桁を、過不足なくピッタリ16進数の1桁に置き換えることができます。 例： 2進数「1111 1111」 → 16進数「FF」 4桁ずつ区切って機械的に変換できるため、2進数の情報を短く、人間が格段に扱いやすい形で表現できるのです。 そして、ここで重要になるのが「8」という数字です。コンピューターの世界では、伝統的に 8つのビット（2進数の桁）をひとまとめにした「1バイト」という単位 で情報を扱います。 これは、初期のコンピューターが8ビット単位でデータを処理していたことに由来する、いわばデジタル世界の基本単位です。 この「8ビット＝1バイト」という概念や、2³=8、2⁴=16 という関係性から、コンピューターの世界では「8」や「16」といった 2のべき乗の数字が「キリが良く、処理しやすい、基本的な数」 として扱われてきました。この技術的な背景が、UIデザインのルールにも影響を与えているのです。 ミクロのデザインを支配する「8の倍数ルール」 コンピューターが「8」という数字と親和性が高いことを理解した上で、次はいよいよUIデザインにおける「8の倍数ルール」について見ていきましょう。これは「8pt Grid System」とも呼ばれ、現代UIデザインの基礎となっています。 「8の倍数ルール」とは何か これは非常にシンプルなルールです。UIを構成するあらゆる要素のサイズや、要素間の余白（マージンやパディング）を、すべて8の倍数（8px, 16px, 24px, 32px, 40px…）で設計するというものです。アイコンのサイズ、ボタンの高さ、テキストと画像の間の距離など、あらゆる箇所にこのルールを適用します。 なぜ「8」の倍数が良いのか では、なぜこのルールがこれほどまでに支持されているのでしょうか。理由は大きく3つあります。 理由1：視覚的な一貫性と調和 最大の理由は、デザインに視覚的な秩序が生まれることです。8の倍数という共通の尺度を用いることで、各要素が数学的に整然と配置され、レイアウト全体に安定したリズム感が生まれます。ユーザーは無意識にその規則性を感じ取り、「きれいに整っている」「心地よい」という印象を受けます。逆に、7px, 13px, 19pxといったバラバラな数値で余白が設定されていると、どこか落ち着きのない、まとまりのないデザインに見えてしまいます。 理由2：意思決定の効率化 このルールは、デザイナーとエンジニア双方の作業効率を劇的に向上させます。「ここの余白はどれくらいにしよう？」という曖昧な感覚的な判断が不要になり、「8の倍数の中から選ぶ」という明確な指針が生まれます。これにより、デザインの意思決定が迅速化し、デザイナーとエンジニア間での「この余白は16pxでお願いします」といったコミュニケーションも円滑になります。デザインシステムを構築する上でも、このルールは不可欠な基盤となります。 理由3：レスポンシブデザインとの圧倒的な相性 これが、他の数字（例えば6や10）ではなく「8」が選ばれる決定的な理由です。現代のWebサイトやアプリは、PC、タブレット、スマートフォンなど多種多様な画面サイズや画素密度に対応する「レスポンシブデザイン」「高解像度対応」が必須です。このとき、画面サイズに応じてレイアウトや余白を調整する必要があり、「要素を半分にする」という操作が頻繁に発生します。 8は2³であるため、どこまでも2で割り続けることができます。 64px → 32px → 16px → 8px → 4px → 2px → 1px すべて整数であり、ピクセル単位で描画されるデジタルの世界と完璧に調和します。 一方で、もし12の尺度をスペースに採用するとどうなるでしょうか。 24px → 12px → 6px → 3px → 1.5px 1.5pxという小数点、いわゆる「サブピクセル」が発生してしまいます。これは、画面上で表示がぼやける原因となり、デザインの品質を損ないます。この「半分にし続けられる」という特性が、様々な画面サイズにクリーンに対応しなければならないUIデザインにおいて、8の倍数ルールを絶対的なものにしているのです。 マクロな骨格を司る「12カラムシステム」 「8の倍数ルール」が要素のサイズというミクロなデザインを司るのに対し、ページ全体の骨格というマクロなデザインを司るのが「12カラムシステム」です。ここで多くの人が「なぜここでは12なの？」と疑問に思います。Bootstrapのような有名なフレームワークも、この12カラムシステムを採用しています。 「12カラムシステム」とは何か これは、画面の表示領域の横幅を、目には見えない12個の均等な「カラム（柱）」に分割して考えるシステムです。デザイナーは、コンテンツをこの12本の柱のうち何本分を使って配置するか、という考え方でレイアウトを組んでいきます。 なぜレイアウトは「12」なのか その理由は、 12という数字が持つ「約数の多さ」 にあります。12の約数は「1, 2, 3, 4, 6, 12」と非常に多く、これがレイアウト設計に圧倒的な柔軟性をもたらします。 12カラムシステムを使えば、以下のような多様なレイアウトを簡単に、そして均等に作ることができます。 2分割レイアウト： 6カラム + 6カラム 3分割レイアウト： 4カラム + 4カラム + 4カラム 4分割レイアウト： 3カラム + 3カラム + 3カラム 非対称レイアウト： 8カラム（メイン）+ 4カラム（サイドバー） 非対称レイアウト： 9カラム（メイン）+ 3カラム（サイドバー） 非対称レイアウト： 10カラム（メイン）+ 2カラム（サイドバー） もしこれを8カラムシステムでやろうとすると、柔軟性が損なわれます。レイアウトの骨格を作る上では、2のべき乗であることよりも、多様な分割比に対応できることのほうが重要度が高いのです。 なお、このようなグリッドによるレイアウト方法は、紙媒体の誌面デザインでも基本となっています。 二つのルールの美しい共存 ここまで読んで、「8」と「12」という異なるルールが同時に存在することに、まだ少し混乱しているかもしれません。しかし、重要なのは、この 二つのルールは対立するものではなく、それぞれが担当する役割と階層が違う、完璧なパートナーである ということです。 12カラムシステム → ページの骨格（マクロレイアウト） 8の倍数ルール → 要素間の距離やサイズ（ミクロレイアウト） これを家に例えるなら、 「12カラムシステム」は家全体の間取りを決める設計図 です。「リビングはこの広さで、寝室を2つここに配置して…」と、大きな空間の分割を担います。 一方、 「8の倍数ルール」は、その部屋の中に置く家具のサイズや、家具と壁の間の距離、窓の高さなどを決める詳細なルール です。 Webサイトに置き換えると、まず12カラムシステムを使って「ヘッダー」「メインコンテンツ（8カラム分）」「サイドバー（4カラム分）」といったページの大きな骨格を決めます。次に、8の倍数ルールを使い、メインコンテンツとサイドバーの間の隙間を「24px」に設定し、記事タイトルとその下の本文の間の余白を「16px」に、本文のフォントサイズを「16px」に…と、詳細なデザインを詰めていくのです。この二つのルールを組み合わせることで、 「柔軟な骨格」と「整然としたディテール」を両立した、高品質なUIデザインが実現 します。 まとめ 本記事では、UIデザインにおける「8の倍数ルール」と「12カラムシステム」がなぜ最適と考えられているのかを解説しました。 8の倍数ルール は、コンピューターの基本単位である「8ビット」との歴史的な親和性を持ち、特にレスポンシブデザインにおける「半分にし続けられる」という特性から、要素のサイズや余白といった ミクロなデザイン に最適です。 12カラムシステム は、その圧倒的な約数の多さから、多様な分割パターンを可能にし、ページの骨格となる マクロなレイアウト設計 に最適です。 これらのルールは、単なる見た目の美しさのためだけでなく、コンピューターの仕組み、人間の認知、そして開発の効率性までを考慮した、合理的で洗練されたデザイン手法です。 もちろん、デザインに絶対の正解はありません。他の方法が適しているケースもあるかと思います。また、ディスプレイの画素密度が上がり、コンピューターの計算や通信速度が向上することで割り切りやすさへの考慮は低くなるかもしれません。しかし、このような手法の原理は、さまざまな開発のヒントになるでしょう。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post UIデザインはなぜ「8の倍数ルール」と「12カラムシステム」が最適と考えられているのか first appeared on SIOS Tech. Lab .

なぜ今、コンテナ環境導入は“スモールスタート”が重要なのか？ DevOps・CI/CDにより高速デリバリーを実現する環境やオンプレミス・クラウドなど様々な環境を意識した開発・運用が主流となった現在、コンテナ技術はインフラ環境の新しい標準構成として多くのサービスや企業へ導入されています。 しかし実際の現場では、 「まず何から始めればいいかわからない」 「KubernetesやOpenShift、Rancherといった技術の学習コストが大きい」 「いきなり本番運用レベルの環境構築は躊躇してしまう」 といった悩みを抱える企業も少なくありません。 これらの課題を解決するのがコンテナ環境のスモールスタートです。 スモールスタートによる重要なポイントでは、 「短期間・低コストの投資で効果的な結果を確認できる」 「小規模環境から明瞭な運用を実施し学習できる」 「PoC環境から円滑に本番環境へ移行できる」 などが挙げられます。 このようなコンテナ導入の課題をサイオステクノロジーがサポートし、スモールスタートでの強みを活かして、短納期・低額での環境の提供を実現するのが「 コンテナ導入スモールスタートパック 」です。 サービスの特徴：コンテナ導入スモールスタートパックの3つのポイント コンテナ導入スモールスタートパックの大きな特徴として3点ご紹介します。 短納期による環境提供 最短2か月で要件のヒアリングから構築、引き渡しを行いPoCなどに迅速に取り組む事が可能となります。 低額で始められるコンテナ環境 導入費用を抑えたミニマムな環境から構築可能となります。 パッケージ化されたシンプルな導入プロセス Kubernetes自体のコマンド操作手順だけでなく、GUI上での管理コンソールの操作手順書等も提供し、シンプルながら分かりやすい導入後の学習面もサポートいたします。 これらの3つのポイントはコンテナ環境の構築・運用では非常に重要となります。 サービス紹介：最短2ヶ月〜導入可能なサービスパッケージ 本サービスは、OpenShiftまたはRancherを用いた本格的なコンテナプラットフォーム環境を、最小構成から構築するスモールスタート導入支援サービスです。 オンプレミスでもクラウドでも対応可能で、導入後の運用まで見据えた設計・構築サービスをご提供します。 導入プラットフォーム：OpenShift / Rancher 提供環境：オンプレミスまたはクラウド（AWS / Azure / GCP） 工期：2ヶ月～ ※ご要件に応じて調整可能 価格：500万円～ ※構成・規模によりご相談 提供ドキュメント： 環境概要設計書 パラメーターシート プラットフォーム標準運用手順書 対応パターン例：様々なニーズに応じて柔軟に対応します コンテナ導入スモールスタートパックでは様々なニーズに向けたパターンへ対応可能です。 パターン1：まずは最低限の環境からスモールスタート OpenShiftまたはRancherによるスモールスタート構成を構築！ オンプレミス環境だけではなく、クラウド（AWS/Azure/GCP）環境でも同等の構成で導入可能 初めてのコンテナ環境導入でも概要設計書や操作手順書付きで操作・学習も安心 パターン2：閉域網環境（Air Gap環境）でのスモールスタート 閉域網環境（Air Gap環境）にもサービス導入が可能！ 通常の環境と同様にOpenshiftまたはRancherによる構成から選んで構築可能 閉域網環境（Air Gap環境）用の構成周りのドキュメントも充実し、効果的なスモールスタートが可能 上記に限らず、オンプレミスやクラウド、コンテナオーケストレーターに応じた様々なケースへ対応可能となっています。 まとめ コンテナ環境の導入は「小さく始めて、大きく育てる」のが成功の鍵です。 本サービスは、スモールスタートによる技術検証や技術習得と将来的な本番環境への展開の双方を視野に入れた “実践的スモールスタート” を実現します。 まずはお気軽にご相談ください。 https://sios.jp/products/it/container-consulting/smallstartpack/ ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post コンテナ環境導入の第一歩を支援！ 「コンテナ導入スモールスタートパック」サービスのご紹介 first appeared on SIOS Tech. Lab .

挨拶 ども！7月は 技術ブログ×生成AIというニッチなジャンルでブログを執筆 していた龍ちゃんです。Claude Maxプランで本当はコード生成をゴリゴリやらせるべきだけど、7月は登壇資料作成もあったのでブログ×生成AIテーマの執筆が多めでブログが出ちゃいましたね。8月はコード生成のほうもちょこちょこ出す予定です。おかげで投稿開始から3年で200本に届きそうです。 皆さんは技術ブログを書く時、いきなり本文から書き始めていませんか？私も以前はそうだったのですが、書いているうちに「あれ、これも書いたほうがいいかな？」「この構成で大丈夫かな？」と迷いが生じて、気がつくと手が止まってしまうことが多々ありました。 そこで今回は、技術ブログ執筆を効率化する「アウトライン作成術」について詳しく見ていきます。実際に私が検証してきた2つのアプローチ「対話型」と「抽出型」を比較しながら、どちらがあなたに合うかを一緒に考えていきましょう！ なぜアウトラインが技術ブログ執筆の要なのか まず、そもそもなぜアウトラインを作るといいのでしょうか？ 私の経験上、一番大きなメリットは 執筆時に迷うことが少なくなる 点です。文章を書くのと技術検証するのは、それぞれ使う脳の機能が違うんですよね。執筆中に「これも検証したほうがいいかな？」と考え始めると、思考のスイッチングコストが発生して効率が落ちてしまいます。 さらに、アウトラインを事前に作っておくことで以下のような構造の検証もできます： ブログ全体の構成がおかしくないか 長すぎるから分割したほうがいいか 読者にとって情報に過不足がないか SEO観点からブログが長すぎないか 実際、私もアウトラインの段階で「これは長いので内容を削りたいが、SEO的に残すべき内容や分割すべき内容はないか」をClaudeに相談し、必要に応じてシリーズ化することもあります。こうすることで執筆時間だけに注力でき、非常に効率的なんです。 2つのアプローチ：あなたはどっちタイプ？ アウトラインを生成する方法として、私が実践しているのは主に2つのアプローチです。 対話型アプローチ：計画重視で体系的に 適用場面： 構想段階・計画重視 向いている人： 論理的思考タイプ これは書く内容があまり決まっていない状態や検証前の段階で有効な方法です。「こんな感じのブログを書きたい」「こういうことを検証しようと思っている」ということをClaudeに伝えて、一緒にアウトラインを作っていきます。 この方法のいいところは、 対話しながら自分の考えを整理できる 点ですね。ブログ制作の初期段階、特に検証前であれば、構想の整理ができるというメリットがあります。 プロンプトサンプル： 技術記事のテーマ：React Hooks入門 想定読者：React初心者（JavaScript基礎は理解済み） 記事の目的：useStateとuseEffectを実際に使えるようになってもらう 読者が理解しやすい論理的な流れで大項目を5個程度生成してください。 各項目では何を説明すべきかも含めて提案してください。 龍ちゃん ※実際のプロンプトはもっとざっくりとした投げかけから始まることが多いです。詳細なやり取りは こちら で確認できます。 抽出型アプローチ：実体験ベースで独自性重視 適用場面： 検証済み内容のブログ化・直感重視 向いている人： アイデア発散タイプ もう一つの方法は、まずざっと書いてしまって、そこからアウトラインを抽出する方法です。これは既に検証した内容をブログにアウトプットするのに適しています。 「こういうことを検証しました」「こんなことをやったんですが、ブログにするならどう構成すればいいですか？」といった感じで、ざっと書いた内容をそのまま入力として与え、そこからアウトラインを抽出してもらいます。 この方法のメリットは、検証内容を全部書いた状態からアウトラインを生成するので、 自分の意図した内容と書きたいことが直接検証結果に基づいている 点です。 プロンプトサンプル： 以下の自由執筆からアウトラインを抽出してください： [検証内容や体験談をそのまま入力] 1. 主要ポイントの抽出 2. 論理的な順序での並び替え 3. 技術ブログ用の見出し構成案 4. 各章の想定文字数 読者が理解しやすい構成になるよう調整もお願いします。 龍ちゃん ※実際のプロンプトはもっと雑な感じです。詳細なやり取りは こちら で確認できます。 最近は音声でブログを書く方法も試しています。音声入力は考えていることを直接文章に反映できるので、おすすめの方法としては、まずざっと話してしまって、検証内容や書こうと思った理由など脳内の情報を全部一旦文章化し、そこからアウトラインを抽出してもらいます。 話した内容には不要な情報や体験談が含まれて冗長になることもありますが、アウトラインでそれらを取捨選択できます。また、「このエピソードは入れたい」といった判断もできるので、話すのが得意な方にとっては、ざっと話した内容からアウトラインを作ってもらう方法が効果的だと思います。 実践例で見る2つの手法の違い 実際に同じテーマで両方の手法を試してみたので、その違いを比較してみましょう。 対話型で作成したアウトライン例 テーマ： Claude×技術ブログ構成編 ## 導入：なぜアウトライン設計が技術ブログの成否を分けるのか - 技術記事でよくある3つの失敗パターン - アウトライン設計で解決できること - 本記事で学べる2つのアプローチ ## 2つのアウトライン生成手法 ### 【手法1】対話型アプローチ - 特徴：Claudeと段階的に構造を組み立て - 向いている人：計画重視、論理的思考タイプ ### 【手法2】執筆先行アプローチ - 特徴：先に自由執筆→後からアウトライン抽出 - 向いている人：直感重視、アイデア発散タイプ ## 読者レベル別の調整ポイント ### 初心者向けの場合 - 前提知識の明示：何を知っていることを前提にするか - 用語解説の配置：どのタイミングで説明するか ### それ以外（中級者以上）の場合 - 前提知識は省略：基本的な説明は最小限に - 応用例・実践例重視：より実務的な内容を 特徴： 体系的で教育的、読者視点重視、チェック機能付き 抽出型で作成したアウトライン例 元素材： 音声入力による自由執筆（今回提供いただいた内容ベース） ## はじめに - 技術ブログ執筆でアウトライン作成が重要な理由 - 執筆時の迷いを削減し、構造検証を可能にするメリット - 2つのアプローチの概要紹介 ## アウトライン作成の2つのアプローチ ### 対話型アプローチ - 適用場面：構想段階・計画重視 - 向いている人：論理的思考タイプ - 手順：Claudeと段階的に構造を組み立て ### 抽出型アプローチ - 適用場面：検証済み内容のブログ化・直感重視 - 向いている人：アイデア発散タイプ - 手順：自由執筆 → アウトライン抽出 → 再構成 ## 実践例による2つの手法の比較 - 対話型で作成したアウトライン例 - 抽出型で作成したアウトライン例 - 2つの手法の違い（比較表付き） ## アウトライン活用のコツ - 手法の使い分け指針 - 品質向上のチェックポイント 特徴： 実体験ベース、具体的で実践的、独自性が高い どちらを選ぶべき？手法の比較 項目 対話型 抽出型 構造 体系的・教育的 実践的・比較重視 向いている人 計画重視・初心者 効率重視・経験者 作成時間 計画長・執筆短 計画短・修正長 文字数目安 3000-4000字 2500-3000字 独自性 汎用性高い 体験談豊富 実際のプロジェクトでどちらを選ぶべきか、迷うところですよね。私の経験では以下のような使い分けをしています： 対話型を選ぶべき場面： 新しい分野について書く時 体系的な解説記事を作りたい時 初心者向けの記事を作る時 抽出型を選ぶべき場面： 実験結果をまとめたい時 体験談を中心とした記事を作る時 音声入力を活用したい時 より効率的なワークフローへの発展 さらに、アウトラインを作ることで、追加で必要な検証内容が見えてきたり、不足部分を早期に発見できたりします。また、今後どういったことを検証すべきかという判断もしやすくなるのも大きなメリットです。 現在私が検証的に取り組んでいるのは、文体抽出も組み合わせた方法です。自分の文体を模倣してもらい、それとアウトライン生成方法を組み合わせています。つまり、話した内容からアウトラインを作り、そのアウトラインと話した内容と文体統一を掛け合わせて、ブログのラフ版を書いてもらうのです。 今後はNotion上で音声入力をして、MCPを使ってClaudeに問い合わせるという方法も考えています。Notionだけで執筆し、その後の修正内容をClaudeから呼び出すことで、執筆時間を大幅に短縮できる予定です。 この辺りの詳細な workflow については、「 Notion×MCP×音声認識でブログを3倍速執筆！完全自動化ガイド 」で詳しく解説していますので、ぜひそちらもご覧ください。 まとめ 今回は技術ブログのアウトライン作成について、2つのアプローチを詳しく見てきました。 対話型 ：計画重視で体系的なアウトライン作成に向いている 抽出型 ：実体験ベースで独自性の高いアウトライン作成に向いている どちらの手法も、最終的には読者視点での精査が必須ですが、自分のタイプと記事の性質に応じた使い分けが重要ということがわかりました。 実際にブログを書く手間や作成時間を大幅に削減でき、より多くのブログを公開したり検証時間を確保したりできるのがアウトライン作成の大きなメリットです。 皆さんも、ぜひ自分に合った手法でアウトライン作成にチャレンジしてみてください！そのほかにもClaude×技術ブログで情報発信をしています、お楽しみに。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Claude活用アウトライン作成術：対話型vs抽出型の実践比較【2025最新】 first appeared on SIOS Tech. Lab .

はじめに Git & GitLab入門ブログ Gitマスターへの道の第3回です。前回の Git & GitLab入門ブログ2 Gitマスターへの道「Git操作入門」 では、ローカルPCにGit、VSCodeを導入し、最初のコミットを行うまでの手順を解説しました。 今回は、チーム開発で使うコマンド、コミットを戻す際に使用するコマンドについて紹介します。 チーム開発で行うことがある操作 まずは前回説明したGit操作を踏まえて、実際のチーム開発でよく使うコマンド（操作）について活用例を交えて紹介していきます。 git log Gitリポジトリのコミット履歴を表示するコマンドです。履歴を見るだけでなくオプションによってプロジェクトの過去の分析や問題の原因究明に役立てることができます。 チーム開発での活用例 バグ特定：特定の機能がいつ、誰によって導入されたか、どのコミットが原因でバグが発生したかを追跡 マージコンフリクトの原因究明：複雑なマージの前に履歴を確認することで、コンフリクトの発生源究明に役立つ オプション git log –oneline : 各コミットを1行で簡潔に表示します。 git log –graph –oneline –all : ブランチの分岐・結合をグラフィカルに表示し、全てのブランチの履歴を1行で表示します。 git log -p <ファイル名> : 特定のファイルの変更履歴と差分を表示します。 git log –author=”<著者名>” : 特定の著者が行ったコミットのみを表示します。 git log –grep=”<キーワード>” : コミットメッセージに特定のキーワードを含むコミットを検索します。 以下はGitリポジトリのコミット履歴を表示するgit logの使用例です。 git logの使用例 今回の例ではコミット履歴を新しい順に表示しています。 commit から始まる複数のブロックが、それぞれ過去に行われた変更（コミット）を表しています。mainブランチへのコミット日時やコメント、設定している場合は誰が行ったかなどが表示され、チーム全体での変更履歴の確認が可能です。 git diff gitの差分を表示するためのコマンドです。 インデックスとワークツリーの差分(addしていない手元の変更点)やコミットとワークツリーの差分などを確認することができます。 チーム開発での活用例 コミット前の最終確認：コミットする前に、意図しない変更が含まれていないかを確認します。 コードレビュー：他のメンバーの変更内容をレビューする際に、差分を確認します。 以下の画像はまだステージングされていない、ワーキングツリー（作業ディレクトリ）での変更内容を表示するgit diffコマンドの使用例です。 git diffの使用例   git diff の出力を見ることで、コミットしようとしている変更が、どのファイルに、どの行が、どういった内容で追加・削除されたかを明確に把握することができます。 git tag 特定のコミットにタグをつけたり、タグの確認をするコマンドです。 タグを使用することでコミットを分かりやすく保管することができます。 チーム開発での活用例 重要なポイントの記録： v1.0.0 , v2.1.0 のように、ソフトウェアのリリースバージョンにタグを付け、後からその時点のコードを簡単に参照できるようにします。 リリースバージョンの管理：特定の重要なマイルストーンや、大きな変更があったコミットにタグを付けて、履歴を分かりやすくします。 以下の画像は最新のコミットに対してタグを作成するgit tagの使用例です。 git tagの使用例 最新のコミットへ `v1.0-beta`というタグを作成することで、その後はgit show (タグ名) などのコマンドを使用することでコミット内容を簡単に確認出来るようになります。 .gitignore .gitignore はコマンドではなく、Gitリポジトリに配置されるファイルです。 .gitignoreにファイル名やディレクトリ名を記載することで、Gitの追跡対象からそれらを無視させることができます。ルートだけでなくサブディレクトリにも配置することができ、その場合、そのファイルが置かれたディレクトリとそのサブディレクトリにルールが適用されます。 チーム開発での活用例 リポジトリをきれいに保つ： 不要なファイルやバージョン管理の対象にしたくないファイルやディレクトリがコミットされるのを防ぎ、リポジトリのサイズを小さく保ちます。 バージョン管理の対象にしたくないファイルとはコンパイル時やエディタが自動生成するファイル( dist/ , build/ )やライブラリ依存のファイル(node_modules/)、キャッシュファイル( __pycache__/ , .pytest_cache/ )などがあります。 環境変数、機密情報などGitから除外：公開リポジトリや誤って共有してしまった場合のセキュリティリスクを減らします。 以下画像は.gitignoreファイルの例です .gitignoreの作成例 主にPythonでの開発時の不要ファイルを定義しています。 コミットの戻し方 チーム開発時では意図しない内容をコミットへ含めてしまったり、前の状態へ戻したいなどの状況が発生します。 そのような状況でもgitではコミットをコマンドで取り消すことができます。 状況によりコマンドの使い分けが必要です。 git revert すでにリモートにpushしている場合 git revertを使います。 git revertは間違ったコミットを打ち消す新しいコミットを追加して取り消します。元のコミットは残ったままです。 以下画像はgit revertの使用例です。 コミットハッシュを使用してgit revertを使用する例 ↑コミットをpushしたのちgit revertコマンド実行 git revert実行後の編集画面 ↑git revertコマンド実行後のコミット内容編集画面 編集後再度pushする際の例 ↑git revert後コミットを再度push これによりgit revertを使用して打ち消したいコミットの内容を打ち消す内容のコミットがpushされます。 VScodeから実行する場合以下のようになります git revertをVScodeから実行する例 git reset コミット履歴自体を操作する強力なコマンドです。いくつかオプションがありますが、ここではよく使うものを簡単に紹介します。 git reset –soft [コミットID]: 指定したコミットの状態に戻しますが、ファイルの変更内容はそのまま残し、ステージングされた状態にします。 git reset –mixed [コミットID] (デフォルト): 指定したコミットの状態に戻し、ファイルの変更内容も残しますが、ステージングは解除されます。 git reset –hard [コミットID]: 指定したコミットの状態に戻し、指定したコミットIDの状態にプロジェクト全体を完全に巻き戻します。普段作業しているPC上のプロジェクトフォルダやステージングエリアもすべて破棄します。 この操作は非常に危険で、元に戻すことができないため、使用には細心の注意が必要です。 git resetは履歴そのものを書き換えて取り消しします。git resetでpush後のコミットを操作すると他のチームメンバーにも影響が有るため、非常に危険な操作だと意識しましょう。 以下の画像は 直前のコミットを取り消しつつ、変更内容は残すgit reset –soft HEAD~1の使用例です git reset –soft HEAD~1の使用例 VScodeから実行する場合以下のようなります git resetをVScodeから実行する例 git restore git restore は、コミットされた履歴ではなく、ワークツリー（手元のファイル）やステージングエリア（ git add した変更）の変更を元に戻すために使用するコマンドです。 git reset よりも粒度が細かく、安全です。 以下はコマンドでのステージングエリアの変更取り消しの実行例です。 git restoreの使用例 VScodeで実行する場合以下のようになります git restoreをVScodeで実行する例 まとめ 今回はチーム開発で使うコマンド、コミットを戻す際に使用するコマンドを紹介しました。これでGitを使ったチーム開発において、コードの変更管理と履歴の追跡をよりスムーズに行うことが出来るようになります。 次回は、Gitを使った共同開発の基本として、リモートリポジトリの役割やクローン、SSH設定、そして変更を反映する一連の流れを詳しく解説します。 参考文献 https://qiita.com/shibukk/items/8c9362a5bd399b9c56be https://qiita.com/growsic/items/ed67e03fda5ab7ef9d08 https://qiita.com/anqooqie/items/110957797b3d5280c44f https://envader.plus/article/244 https://envader.plus/article/448 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Git & GitLab 入門 (3) ～Git マスターへの道～「Git操作チーム利用コマンドや ロールバック」 first appeared on SIOS Tech. Lab .

はじめに ども！Claude関連のブログを週に5本も投稿してしまって燃え尽きている龍ちゃんです。登壇資料完成までもう少しなので、今週の残りを走り切ろうと思います。 Claude×技術ブログというテーマ でハイペースでブログを執筆しています。 そんな中、今回の登壇資料作成にClaudeが大活躍して、なんと 爆速で登壇資料作成が終わった んです！ 衝撃の効率化実績 従来：40時間/本 × 2本 = 80時間 新手法：11時間で2本完成（3時間生成 + 5時間修正 × 2本） 結果：約7倍の効率化を実現 45分の登壇資料を3時間で作る、これって革命的じゃないですか？ この記事で得られること ブログ記事を登壇資料に変換する実用的な方法 Claude×Marpによるエンジニア最適化ワークフロー 実際に使えるプロンプト例とコード 現実的な課題と対処法（包み隠さず全部話します！） 実際の成果物 今回作成したコンテンツはすべて、GitHubとGitHub Pagesに公開しています。ぜひ見てみてください。 参考 Claude AI活用技術セミナー – 登壇資料ハブ 参考 GitHub – Ryunosuke-Tanaka-sti/claude_and_blog_seminar GitHub 基本ワークフロー（シンプルな3ステップ） Claude×Marpによる登壇資料作成は、以下の3ステップで完了します。Claude Codeの実行環境を準備することで、Marp形式のMarkdownをスムーズに編集・更新できます。 ステップ1：ブログ記事をClaudeに読み込ませる 最初に、既に執筆済みのブログ記事をClaudeに読み込ませ、ドキュメントとして参照できる状態にします。 一次情報の活用 ：すでに執筆済みの内容なので、信頼性が担保されています 複数ブログの参照 ：関連する複数のブログを参照させることで、より充実した登壇資料を短時間で作成できます ステップ2：登壇情報を明確化してMarp形式で生成 高品質な登壇資料を作成するためには、 登壇に関する基本情報を整理 することが重要です。 対象者 ：どのようなレベル・バックグラウンドの人か 時間 ：登壇時間はどれくらいか 目的 ：何を伝えたいのか これらの情報とブログの内容を組み合わせて、ClaudeにMarp形式で登壇資料を生成してもらいます。 メリット ： MarpはMarkdown形式での記述のため、エンジニアにとって操作しやすく、バージョン管理も容易です。 ステップ3：VSCodeで微調整とプレビュー Claudeが生成した初期草案をベースに、VSCode上でリアルタイムプレビューを確認しながら編集を行います。 主な調整作業 ： 内容の追加・修正 ：特定の部分を詳しく追記、関連情報の補強 スライド構成の最適化 ：情報量の調整、ページ分割の精練 ビジュアル調整 ：フォントサイズ、レイアウトの微調整 効率的な作業環境 ： VSCodeのMarp拡張機能を使用することで、コード編集とプレゼンテーションのプレビューを同時に行えるため、作業効率が大幅に向上します。 実際の手順（今すぐ試せる具体的方法） 環境準備（5分で完了） # VSCode拡張機能のインストール - Marp for VS Code - Markdown Preview Enhanced（推奨） Claude用プロンプト例（コピペOK） 以下のブログ記事を基に、45分の技術登壇用資料をMarp形式で作成してください。 【対象者】：エンジニア（経験年数3-5年） 【時間】：45分 【目的】：実践的な知識共有 【ブログ記事】： [ここにブログ記事をペースト] or [MCP経由で取得] 【要件】： - スライド数：25-30枚程度 - 実装例やコード例を含める - 質疑応答用のスライドも追加 - Marp形式で出力 Marpの基本設定 --- marp: true theme: default paginate: true header: '登壇タイトル' footer: 'あなたの名前 | 日付' --- 生成から完成までの流れ Claude出力をコピー （約30秒） VSCodeで新規.mdファイル作成 （約1分） プレビュー確認 （Ctrl+K → V） 内容調整 （30分-2時間） エクスポート （約2分） 制約と現実的な対処法 Marpが苦手なこと Claudeと実際に試してみたところ、いくつか苦手な部分がわかりました： 複雑なレイアウト 対処法：シンプルなデザインに徹する 個人的に「デザインよりもコンテンツの方が重要」と考えるようになりました 凝った図表作成 対処法：図にしたい部分はHTMLで出力してもらい、そのHTMLをベースに図表を作成してSVGで埋め込む これは現実的な手法だと思います 情報の詰め込みすぎ 一枚のスライドに収まりきらない情報を書いてしまったり 図で表現すべき内容を文章で表現してしまうことがあります 対処法：何を図にするかという判断には、やはり人間の目が必要 人間による最終調整が必要な部分 現状、Marpで出力した資料をそのまま使えるケースはそれほど多くないと思います。 図 vs 文章の判断 ：AIは文章で説明しがち スライド分割 ：1枚に情報を詰め込む傾向 フォントサイズ調整 ：読みやすさの最終確認 ただし、ブログをもとに生成された文章自体は使えるので、図の配置などに関して人間が確認しながら修正すれば十分実用的です。 PowerPointとの使い分け Marp向き ： コンテンツ重視 情報密度高め エンジニア向け技術発表 PowerPoint向き ： デザイン重視 営業資料 視覚効果重要な場面 レイアウトにこだわらなければMarpで登壇資料を作るのはすごく効率的です。Marpで資料を作り、それをベースにパワーポイントなどで編集するというのも現実的なアプローチだと個人的に感じています。 実際の成果と品質評価 生成品質 文章品質 ： そのまま使用可能レベル 構成力 ： 論理的で分かりやすい流れ 技術精度 ： ブログベースなので一次情報で正確 デザイン ： シンプルだが実用的 時間短縮の内訳 .work-time-comparison-container { font-family: 'Segoe UI', Tahoma, Geneva, Verdana, sans-serif; margin: 20px auto; padding: 0; background: #f5f6fa; border-radius: 8px; max-width: 800px; box-sizing: border-box; width: 100%; } .work-time-comparison-container * { box-sizing: border-box; } .work-time-comparison-wrapper { background: white; border-radius: 8px; box-shadow: 0 4px 12px rgba(0,0,0,0.1); overflow: hidden; } .work-time-comparison-header { background: #2f3542; color: white; text-align: center; padding: 20px; } .work-time-comparison-header h1 { margin: 0; font-size: 1.8em; font-weight: 300; } .work-time-comparison-subtitle { margin-top: 8px; font-size: 1em; opacity: 0.9; } .work-time-comparison-content { padding: 20px; } .work-time-comparison-section { display: flex; gap: 20px; margin-bottom: 30px; align-items: flex-start; } .work-time-comparison-before-after { flex: 1; } .work-time-comparison-section-title { font-size: 1.4em; margin-bottom: 20px; text-align: center; padding: 12px; border-radius: 6px; font-weight: bold; } .work-time-comparison-before .work-time-comparison-section-title { background: #ff4757; color: white; } .work-time-comparison-after .work-time-comparison-section-title { background: #3742fa; color: white; } .work-time-comparison-task-item { display: flex; align-items: center; margin-bottom: 15px; padding: 15px; background: #f8f9fa; border-radius: 6px; transition: transform 0.3s ease; position: relative; width: 100%; } .work-time-comparison-task-item:hover { transform: translateY(-2px); box-shadow: 0 5px 15px rgba(0,0,0,0.1); } .work-time-comparison-task-name { flex: 1; font-weight: 600; font-size: 0.95em; color: #2d3748; margin-right: 10px; } .work-time-comparison-task-time { font-weight: bold; font-size: 1.1em; padding: 8px 12px; border-radius: 4px; min-width: 70px; text-align: center; } .work-time-comparison-before .work-time-comparison-task-time { background: #ffcccc; color: #d63031; } .work-time-comparison-after .work-time-comparison-task-time { background: #cce5ff; color: #0984e3; } .work-time-comparison-time-bar { height: 8px; background: #e9ecef; border-radius: 4px; margin: 10px 0; overflow: hidden; } .work-time-comparison-time-fill { height: 100%; transition: width 1s ease; border-radius: 4px; } .work-time-comparison-before .work-time-comparison-time-fill { background: #ff4757; } .work-time-comparison-after .work-time-comparison-time-fill { background: #3742fa; } .work-time-comparison-total-section { background: #5352ed; color: white; padding: 20px; border-radius: 6px; text-align: center; margin-top: 30px; } .work-time-comparison-total-comparison { display: flex; justify-content: space-around; align-items: center; margin-top: 15px; } .work-time-comparison-total-item { text-align: center; } .work-time-comparison-total-number { font-size: 2.2em; font-weight: bold; margin-bottom: 5px; } .work-time-comparison-total-label { font-size: 1em; opacity: 0.9; } .work-time-comparison-arrow { font-size: 2em; opacity: 0.7; animation: work-time-comparison-pulse 2s infinite; } @keyframes work-time-comparison-pulse { 0%, 100% { opacity: 0.7; } 50% { opacity: 1; } } .work-time-comparison-efficiency-badge { position: absolute; top: -8px; right: -8px; background: #2ed573; color: white; padding: 4px 8px; border-radius: 4px; font-size: 0.8em; font-weight: bold; box-shadow: 0 2px 6px rgba(46,213,115,0.3); } .work-time-comparison-savings { background: #ff6348; color: white; padding: 15px; border-radius: 6px; margin-top: 15px; text-align: center; } .work-time-comparison-savings-title { font-size: 1.2em; font-weight: bold; margin-bottom: 8px; } .work-time-comparison-savings-amount { font-size: 2em; font-weight: bold; } @media (max-width: 768px) { .work-time-comparison-container { margin: 5px; padding: 0; max-width: none; width: calc(100vw - 10px); } .work-time-comparison-content { padding: 10px; } .work-time-comparison-section { flex-direction: column; gap: 20px; width: 100%; } .work-time-comparison-before-after { width: 100%; flex: 1; } .work-time-comparison-task-item { display: flex; flex-direction: row; align-items: center; justify-content: space-between; padding: 10px 12px; width: 100%; box-sizing: border-box; } .work-time-comparison-task-name { flex: 1; margin-right: 10px; margin-bottom: 0; font-size: 0.9em; min-width: 0; } .work-time-comparison-task-time { min-width: 50px; font-size: 0.9em; padding: 4px 8px; flex-shrink: 0; } .work-time-comparison-time-bar { display: none; } .work-time-comparison-total-comparison { flex-direction: row; gap: 10px; justify-content: space-evenly; width: 100%; } .work-time-comparison-arrow { font-size: 1.2em; transform: none; } .work-time-comparison-section-title { font-size: 1.1em; padding: 8px; margin-bottom: 15px; width: 100%; box-sizing: border-box; } .work-time-comparison-header { padding: 15px 10px; width: 100%; } .work-time-comparison-header h1 { font-size: 1.3em; } .work-time-comparison-subtitle { font-size: 0.85em; } .work-time-comparison-efficiency-badge { position: absolute; top: -6px; right: -6px; padding: 2px 5px; font-size: 0.7em; } .work-time-comparison-total-number { font-size: 1.6em; } .work-time-comparison-total-label { font-size: 0.9em; } .work-time-comparison-total-section { padding: 15px 10px; width: 100%; box-sizing: border-box; } .work-time-comparison-total-item { flex: 1; text-align: center; } } @media (max-width: 480px) { .work-time-comparison-container { margin: 2px; width: calc(100vw - 4px); } .work-time-comparison-content { padding: 8px; width: 100%; } .work-time-comparison-task-item { padding: 8px 10px; margin-bottom: 10px; width: 100%; } .work-time-comparison-task-name { font-size: 0.85em; flex: 1; min-width: 0; overflow: hidden; text-overflow: ellipsis; white-space: nowrap; } .work-time-comparison-task-time { font-size: 0.85em; padding: 3px 6px; min-width: 45px; flex-shrink: 0; } .work-time-comparison-total-section { padding: 12px 8px; width: 100%; } .work-time-comparison-savings { padding: 10px 8px; width: 100%; box-sizing: border-box; } .work-time-comparison-savings-title { font-size: 1em; } .work-time-comparison-savings-amount { font-size: 1.4em; } .work-time-comparison-header { padding: 12px 8px; width: 100%; } .work-time-comparison-header h1 { font-size: 1.2em; } .work-time-comparison-subtitle { font-size: 0.8em; } .work-time-comparison-section-title { font-size: 1em; padding: 6px; width: 100%; } .work-time-comparison-efficiency-badge { font-size: 0.65em; padding: 1px 4px; } .work-time-comparison-total-number { font-size: 1.4em; } .work-time-comparison-total-label { font-size: 0.8em; } .work-time-comparison-total-item { flex: 1; min-width: 0; } } 作業時間効率化比較 従来の手法 vs Claude + Marp活用 従来の手法 構成検討 8時間 内容執筆 20時間 デザイン調整 10時間 微調整 2時間 Claude + Marp活用 構成検討 (Claude) 5分 96倍効率化 内容執筆 (Claude) 5分 240倍効率化 デザイン調整 (Marp) 1時間 10倍効率化 微調整 (人間) 2-5時間 // WordPress環境でのアニメーション効果 (function() { function initWorkTimeComparisonAnimation() { const timeFills = document.querySelectorAll('.work-time-comparison-time-fill'); timeFills.forEach(fill => { const width = fill.style.width; fill.style.width = '0%'; setTimeout(() => { fill.style.width = width; }, 500); }); } // ページ読み込み完了後またはDOMContentLoaded後に実行 if (document.readyState === 'loading') { document.addEventListener('DOMContentLoaded', initWorkTimeComparisonAnimation); } else { initWorkTimeComparisonAnimation(); } })(); 管理面でのメリット Marpで資料を管理しておくと、通常登壇資料はドライブに保存するだけで参照情報をすべて記録することは少ないものですが、この方法では参照した情報がすべて保存された状態になり、管理の面でも優れています。 また、MarpでVSCodeのデザインファイルを作成できるので、CSSでプロパティを編集して自分の登壇資料のベースデザインを作成できます。CSSを書くのが苦手な人も多いと思いますが、AI入力に適した形式になっていると個人的に感じています。 まとめ この手法が向いている人 既にブログを書いているエンジニア コンテンツ重視の登壇をする人 効率化を重視する人 マークダウンに慣れている人 この手法が向いていない場面 デザイン性を重視する営業資料 複雑な図表が多数必要な資料 ブランディング重視のプレゼン 今日から始められるアクション VSCodeにMarp拡張機能をインストール 過去のブログ記事を1つ選ぶ 上記のプロンプトをClaudeに投入 5分で最初のスライドを生成体験 将来的な展望 これは将来的な展望になりますが、Marpで第一段階の資料を作成し、その構造化情報をもとに別のAIに入力してデザインを整えてもらうという方法も検討しています。 次回予告 具体的な応用例 ：技術勉強会での実際の使用例 高度なカスタマイズ ：CSSでのデザイン調整 チーム運用 ：複数人でのMarp資料管理 皆さんも、ぜひこの方法で登壇資料作成の効率化にチャレンジしてみてください！ 補足情報 参考リンク Marp公式サイト VS Code Marp拡張機能 動作環境 VSCode（最新版推奨） Node.js（Marp CLI使用時のみ） Claude Code ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 【ブログ→登壇資料】Claude×Marpで80時間を11時間に短縮した方法 first appeared on SIOS Tech. Lab .

はじめに データベースとWebアプリケーションの連携について学ぶため、PostgreSQLとNode.js、Expressを使って従業員管理システムのREST APIを構築してみました。本記事では、環境構築から実際のAPI作成まで、初心者の視点で学んだことをまとめます。 今回作成したもの PostgreSQL 17 を使ったデータベース Node.js + Express によるREST APIサーバー Sequelize を使ったORM実装 CRUD操作 (Create, Read, Update, Delete) の完全実装 環境構築 PostgreSQLのインストール Windows環境では、wingetを使って簡単にインストールできました winget install PostgreSQL.PostgreSQL.17 winget install PostgreSQL.pgAdmin ポイント： PostgreSQLはWindowsサービスとして自動起動 pgAdminでGUI管理が可能 初期設定でパスワードの設定が必要 Node.js環境の準備 プロジェクトの依存関係： { "name": "intro-sq", "dependencies": { "express": "^4.18.2", "pg": "^8.16.3", "sequelize": "^6.37.7" } } 学んだこと： npmパッケージ名は小文字とハイフンのみ使用可能 introSQ → intro-sq への変更が必要だった データベース設計 employeeテーブル CREATE TABLE employee ( id SERIAL PRIMARY KEY, name TEXT NOT NULL UNIQUE, tel TEXT ); 特徴： id ：自動採番の主キー name ：一意制約付きの必須項目 tel ：NULL許可の電話番号 アプリケーション構成 ディレクトリ構造 introSQ/ ├── app.js # メインアプリケーション ├── routes/ │ └── index.js # APIルーティング ├── app/ │ ├── db/ │ │ ├── db-config.js # DB接続設定 │ │ └── db-client.js # CRUD操作 │ └── model/ │ └── employee.js # Sequelizeモデル └── package.json API エンドポイント Method URL 機能 GET /employee/find 全従業員取得 POST /employee/register 新規登録 PUT /employee/update 情報更新 DELETE /employee/remove 削除 実装のポイント 1. Express アプリケーションの基本構造 var express = require('express'); var app = express(); // JSONパーサーミドルウェア app.use(express.json()); app.use(express.urlencoded({ extended: false })); // ルーティング設定 app.use('/', indexRouter); // サーバー起動 app.listen(3000, function() { console.log('Server is running on port 3000'); }); 2. Sequelizeモデル定義 const employee = dbConfig.define('employee', { id: { type: Sequelize.INTEGER, primaryKey: true, autoIncrement: true }, name: { type: Sequelize.STRING }, tel: { type: Sequelize.STRING } }, { timestamps: false, freezeTableName: true }); 3. REST APIの実装 // GET - データ取得 router.get('/employee/find', function(req, res, next) { const query = req.query; dbClient.find(query, function(result) { res.json(result); }); }); // POST - データ登録 router.post('/employee/register', function(req, res, next) { const addData = req.body; dbClient.register(addData, function(result) { res.json(result); }); }); フレームワーク vs ライブラリの理解 フレームワークとライブラリの違いについては、理解があやふやな部分がありましたが、開発を通して両者の違いを理解することができました。 また、ランタイム環境についても理解を深めることができたので、3者の違いをまとめておきます。 フレームワーク Express : アプリケーションの構造を提供 フレームワークが主導権を握る 決められたルールに従ってコードを配置 ライブラリ Sequelize : 特定機能を提供 開発者が必要時に呼び出す 使用方法の自由度が高い ランタイム環境 Node.js : JavaScript実行環境 ブラウザ外でのJavaScript実行を可能に 学習成果 技術的な理解 PostgreSQL : オープンソースのリレーショナルデータベース管理システム Node.js : JavaScriptでサーバーを構築するための実行環境 Express : Node.jsのための軽量なWebアプリケーションフレームワーク Sequelize : Node.js用のORM（DBを簡単に操作するためのライブラリ） 開発スキル 環境構築 : wingetを活用したツール導入 設定管理 : 認証設定とセキュリティ API設計 : RESTful な設計原則 テスト : Postmanによる動作確認 まとめ 今回の学習を通して、モダンなWeb アプリケーション開発の基礎を体験できました。 上述した技術の組み合わせにより、効率的で保守性の高いアプリケーション開発が可能であることを実感しました。 参考リンク PostgreSQL公式ドキュメント Express.js公式サイト Sequelize公式ドキュメント Node.js公式サイト この記事が、同じように学習を始める方の参考になれば幸いです。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 【初心者向け】PostgreSQL & Node.js をまとめてキャッチアップ first appeared on SIOS Tech. Lab .

はじめに ども！今週は大量のブログを執筆しており、このペースだと執筆開始から3年で200本達成ができそうな龍ちゃんです。いや～大量のブログを書きましたね。そんなブログ執筆をさらに早くするためのお話です。 長時間のタイピングで肩が凝る、キーボードから離れた場所では作業できない、文章を書くのに時間がかかりすぎて図作成やサムネイル制作に時間を割けない…そんな課題を抱えている方も多いのではないでしょうか。 今回は、そんな悩みを一気に解決する新しいブログ執筆法をご紹介します。使用するツールは Notion 、 MCP（Model Context Protocol） 、そして Claude の組み合わせです。この方法を使えば、従来のタイピング中心の執筆から脱却し、音声認識を活用した効率的なワークフローを構築できます。 私自身、この方法を導入してから執筆効率が約3倍向上し、しかも疲労感は大幅に軽減されました。特に技術ブログのような専門的な内容でも、人間らしい「生の声」を保ちながら高品質なコンテンツを短時間で制作できるようになったんです。 それでは、具体的なワークフローを詳しく見ていきましょう。 前提環境の構築 まず最初に、この方法を実践するための環境構築について触れておきます。今回のワークフローを実現するためには、 Notion 、 Notion MCP（Model Context Protocol） 、そして Claude Desktop を連携させた環境が必要です。 具体的には以下の構成になります： Notion : ブログの下書きとアウトライン管理 Notion MCP : NotionとClaude間のデータ連携 Claude Desktop : 最終的な文章修正と品質向上 MCPを導入することで、Notionのページやデータベースに直接Claude Desktopからアクセスできるようになり、従来のコピー&ペースト作業が不要になります。この環境構築により、音声入力から最終仕上げまでの一連の流れが非常にスムーズになるんです。 Notion MCPとClaude Desktopの接続方法に関しては、「 Claude×Notion MCP実装術｜コネクタ版とIntegration版の選び方解説 」で解説しています。 環境構築の詳細については別の記事で解説予定ですが、一度セットアップしてしまえば劇的に作業効率が向上しますので、ぜひ挑戦してみてください。 4段階のワークフロー 第一段階：アウトライン作成 まず最初に行うのは、Claudeとの会話を通じたアウトライン作成です。これは従来の執筆方法でも重要な工程でしたが、音声入力を前提とするとより一層重要になってきます。 Claudeには「こんなトピックでブログを書きたい」「この技術について解説したい」といった大まかな方向性を伝え、詳細なアウトラインを一緒に作り上げていきます。この段階では、章立てだけでなく、各章で話したい内容を箇条書きレベルまで具体化します。 例えば、今回の記事でも最初に「音声認識を活用したブログ執筆法」というテーマから始まり、「4段階のワークフロー」「メリット」「実践的なコツ」といった大枠を決めた後、それぞれの章で何を話すかを詳細に決めていきました。 従来の方法では「なんとなく」で始めることもありましたが、音声入力では話す内容が事前に整理されていないと、「えーと」「あー」が多くなってしまい、後の修正工程が大変になってしまうんですね。 第二段階：音声入力による執筆 アウトラインが完成したら、いよいよ音声認識での執筆に入ります。ここが今回の方法の最大のポイントです。 作成したアウトラインに沿って、頭の中にある情報をそのままダイレクトに話していきます。この時のコツは、 完璧を求めないこと です。「えーと」「あー」といった思考整理のための言葉も気にせずそのまま話します。言い間違いがあってもそのまま言い直せばOKです。 私の場合、技術的な検証結果や実装時に苦労したポイントなど、リアルタイムで体験したことをそのまま話すようにしています。例えば「この設定でハマったんですよね」「最初はこう思ったんですけど、実際やってみると違って」といった、人間ならではの試行錯誤のプロセスも含めて話します。 音声認識の精度は現在かなり向上しているので、普通に話していれば大体は適切に変換してくれます。私はiPhoneの音声認識を主に使用していますが、Notionアプリでも直接音声入力ができるので非常に便利です。 Before（従来の方法） ： キーボードに向かう → 文章を考える → タイピング → 疲れる → 休憩 → また考える… After（音声入力） ： アウトライン確認 → 話し始める → 思考がそのまま文字になる → 疲労感なし → 継続して話せる この変化は本当に劇的でした。特に長時間の執筆でも集中力が続きやすくなったのは大きなメリットです。 第三段階：Notion AIでの一次修正 音声入力が完了したら、次はNotion AIを使った一次修正です。ここでの主な目的は、思考の滞留時間に出てくる「えーと」「あー」といった言葉の削除と、基本的な文章の改善です。 Notion AIは非常に優秀で、文脈を理解した上で自然な文章に修正してくれます。音声認識特有の問題として、句読点が適切に入らないことがありますが、Notion AIがかなりの精度で補完してくれるんです。 修正時の具体的な指示例： 「音声入力による不自然な表現を修正して」 「『えーと』『あー』などの間投詞を削除して」 「文章の流れを自然にして」 ただし、この段階では 完璧を求めません 。あくまで一次修正として、明らかに不自然な部分だけを直す程度に留めています。内容の大幅な変更や追加は次の段階で行います。 第四段階：Claudeでの最終修正 最後の仕上げは、MCPを介してNotionからコンテンツを取得し、Claudeで最終的な修正を行います。この段階が、今回のワークフローの真骨頂と言えるでしょう。 ClaudeにはSIOSテックブログの文体やトーンを学習させているので、一次修正された音声入力の内容を、ブログに適した文章に変換してくれます。具体的には： 技術的な正確性の確認 読者にとってわかりやすい表現への変更 情報の整理と補完 ブログ特有の親しみやすい文体への調整 MCPの導入により、NotionとClaudeの連携が非常にスムーズになりました。従来はコピー&ペーストで内容を移す必要がありましたが、今では直接Notionの内容を参照できるため、作業効率が格段に向上しています。 最終チェックポイントとしては： 技術用語の正確性 読者の技術レベルに応じた説明の詳細度 文章の論理的な流れ SIOSテックブログらしい親しみやすさの維持 具体的な方法に関しては、「 Claude技術ブログ品質向上の試行錯誤｜3段階チェックで安定【プロンプト実践】 」でまとめています。 この方法のメリット 効率性の向上 まず何といっても、 執筆速度の劇的な向上 が最大のメリットです。私の場合、タイピング速度と比較すると音声入力は約3倍の効率を実現できています。 具体的な時間比較を見てみましょう： 従来の方法（5000文字のブログ） ： アウトライン作成：30分 執筆（タイピング）：3時間 見直し・修正：1時間 合計：4時間30分 音声認識活用法（同じ5000文字） ： アウトライン作成：45分（より詳細に） 音声入力：1時間 Notion AI修正：15分 Claude最終修正：30分 合計：2時間30分 つまり、 約45%の時間短縮 を実現できているんです。しかも、タイピングによる疲労がないため、長時間の継続性も格段に向上しました。 環境の柔軟性 この方法のもう一つの大きなメリットは、 場所を選ばないこと です。キーボードが使える環境でなくても、スマートフォンがあればブログを書けるようになりました。 実際の活用例： 電車での移動中にアウトライン確認→音声入力 カフェでリラックスしながら修正 散歩中にふと思いついたアイデアをその場で録音 外出先での空き時間を有効活用 特にiPhoneの音声認識機能は本当に優秀で、多少の雑音があっても正確に認識してくれます。従来は「パソコンの前に座って集中して」という制約がありましたが、今では思考がまとまったタイミングでいつでもどこでも執筆できるようになりました。 品質向上への時間配分 文字起こし時間が削減されることで、 ブログの品質向上により多くの時間を割けるようになりました 。これは予想以上に大きな変化でした。 時間配分の変化： 従来の配分 ： 文章執筆：70% 図作成：20% サムネイル制作：10% 現在の配分 ： 音声入力＋修正：40% 図作成：35% サムネイル制作：15% 追加調査・検証：10% 結果として、より視覚的でわかりやすいブログを制作できるようになり、社内からの反応も良くなっています（書きすぎちゃって見るのが重いって苦情が来ましたけど…w）。図を作りながら話し続けるというマルチタスクも可能になったため、理想的には同時並行での作業も実現できそうです。 人間らしいコンテンツの維持 AIに一から生成してもらうのではなく、人間の話した内容を基盤とすることで、 生の情報発信 を維持できているのも重要なポイントです。 技術ブログにおいて、人間の葛藤や苦労、試行錯誤のプロセスは非常に価値があります。AIは「詰まる」ことがなく、間違っていても「動きます」と言ってきたりしますが、実際のエンジニアは様々な課題に直面しながら解決策を見つけていくものです。 音声入力により、そうした「生の声」を自然にコンテンツに反映できるようになりました。「ここで実際にハマったんですよね」「最初はうまくいかなくて」といった、リアルな体験談が自然に含まれるため、読者にとってより価値のあるコンテンツになっているはずです。きっと… 実践上の変化と工夫 アウトライン作成の重要性 音声入力を導入してから、 アウトライン作成により丁寧に取り組むようになりました 。これは話す内容を事前に整理しておいた方が圧倒的に話しやすいからです。 具体的な変化： 章立てだけでなく、各章の要点まで箇条書きで整理 話したい順序を明確に決定 技術用語や固有名詞を事前にリストアップ 想定される読者の疑問点も事前に洗い出し 例えば今回の記事では： ## 第二段階：音声入力による執筆 - アウトラインに沿って話す - 完璧を求めない - 「えーと」「あー」も気にしない - 実体験を交える - Before/After例を示す このレベルまで決めておくと、頭の中での思考スピードも向上し、話している最中に「これも追加しよう」という気づきも生まれやすくなります。 AIの活用方針 重要なのは、 AIに一から生成してもらうのではなく、人間の話した内容を補正してもらう という使い方です。これにより、以下の効果を得られています： 情報源は自分の頭から出たものなので信頼性が高い 人間ならではの体験談や失敗談が含まれる 技術的な詰まりポイントや試行錯誤が自然に表現される AIでは表現できない「葛藤」が記事に含まれる AIと人間の役割分担を明確にすることで、効率性と人間らしさの両方を実現できているのが、この方法の大きな特徴だと思います。 音声入力のコツと注意点 精度向上のポイント 音声認識の精度を上げるためのコツをいくつかご紹介します。まず何といっても 滑舌 が重要です。現在の音声認識技術はかなり向上していますが、やはり明瞭な発音の方が精度が高くなります。 実践的なコツ： 言い間違いは音声認識を止めずにそのまま言い直す 一文が長くなりすぎないよう適度に区切る 専門用語はゆっくりめに発音する 環境音が多い場所では少し大きめの声で話す おすすめの音声認識アプリとしては、iPhoneの標準機能が最も優秀だと感じています。Notionアプリでも直接音声入力ができますし、GoogleドキュメントやMicrosoft Wordでも音声入力機能が充実しています。 修正が必要な要素 音声認識で特に注意が必要なのは、 技術用語や固有名詞の認識精度 です。ここは現在でも課題が残っている部分ですね。 よくある誤変換パターン： 「Claude」→ 「黒田」「クラウド」 「GitHub」→ 「ギットハブ」「Git Hub」 「API」→ 「エーピーアイ」「a P I」 「AWS」→ 「あws」「アマゾン」 製品名などは特に変換ミスが起きやすく、文脈から見て明らかにおかしな変換になることがあります。例えば技術ブログで急に「黒田さん」が登場したら、それはおそらく「Claude」の誤変換だと推測できますよね。 こうした部分は 後から手動で修正する ことを前提として、音声入力時はあまり気にせずに話し続けることが効率的です。 AIへの事前情報提供 ClaudeやNotion AIに修正を依頼する際は、 適切な固有名詞を事前に提供する と、かなり優秀に補正してくれるようになります。 例えば： 以下の音声入力文章を修正してください。 技術用語は正確に表記してください。 使用している技術はClaude・GitHub・Notionなどです。 このように事前情報を提供することで、AIの文脈理解が向上し、より自然で正確な修正結果を得られるようになります。 まとめ 今回は、音声認識を活用したブログ執筆法について詳しくご紹介しました。Notion、MCP、Claudeを組み合わせた4段階のワークフローにより、従来のタイピング中心の執筆から大幅な効率向上を実現できています。 重要なポイントをまとめると： 音声入力により執筆効率が約3倍向上 場所を選ばない柔軟な執筆環境を実現 品質向上により多くの時間を配分可能 人間らしい「生の声」を維持したコンテンツ制作 特に技術ブログにおいては、エンジニアの実体験や試行錯誤のプロセスが読者にとって非常に価値があります。AIだけでは表現できない「人間の葛藤」を自然に含めながら、効率的にコンテンツを制作できるこの方法は、多くの技術ブロガーにとって有効だと思います。 現在はこのワークフローをさらに発展させ、 タイトル作成やメタディスクリプション生成 なども含めた包括的なブログ制作システムを構築しています。そちらについても、また別のブログで詳しく紹介しますね。 皆さんも、ぜひ音声認識を活用したブログ執筆にチャレンジしてみてください！最初は慣れないかもしれませんが、一度コツを掴めば手放せなくなるはずです。何か質問があれば、コメントでお気軽にお声がけくださいね。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Notion×MCP×音声認識でブログを3倍速執筆！技術者向け効率化ワークフロー解説 first appeared on SIOS Tech. Lab .

  こんにちは、サイオステクノロジーの佐藤 陽です。 本日は、最近話題が尽きることのない「AIエージェント」についてご紹介したいと思います！ とは言いつつ、最新のトピックに関する内容ではなく そもそも「AIエージェント」とは何か？といった、根本に立ち返った内容となっています。 RAGは分かった！次はAIエージェントだ！ AIエージェントって最近よく聞くけどよく分かんない AIエージェントについてざっくり知りたい といった方は是非、最後までご覧ください！ はじめに 本記事は、 こちら の記事を非常に参考にしており、元記事に対して、 理解を容易にするための追記 自分なりの解釈の加筆 をおこなったものです。 そのため、元記事と内容が重複していかと思いますがこの点、了承いただければと思います。 そして本記事を読んで興味を持った方がいたら、是非元の記事も読んでいただければと思います。 ちなみに元記事は、オライリーの AI Engineering という書籍の筆者が、書籍の内容を一部抜粋したものということです。 まだ日本語版が発売していないようなので、今後の発売に期待です。 AIエージェントとは AIエージェントの定義については様々な場面で、様々な定義がされております。 これはまだまだAIエージェントが新興分野であることが要因です。 今回ご紹介する内容についても、あくまで複数ある定義のうちの1つであることを踏まえて読んでいただければと思います。 それではAIエージェントの定義について考えていきます。 まずはAIエージェントを 「AI」 と 「エージェント」 の要素に分解し、それぞれを定義を見ていきたいと思います。 AIとは まずは「AI」とは何かについてですが、NTTデータさんの ページ に以下のように定義されていました。 いま最も注目されているテクノロジーの1つに人工知能（AI：Artificial Intelligence）があります。AIは、一般的には「人が実現するさまざまな知覚や知性を人工的に再現するもの」という意味合いで理解されています。 しかし実際には、AIに対して一意に決まった定義がなされているわけではありません。コンピューター・サイエンスや認知科学、医学、心理学、さらには哲学にいたるまで、今もさまざまな立場で論じられ続けている領域です。 これは最近の様々なAIサービスの登場により、実感できている部分かと思います。 例えば、ChatGPTは人間のように考え質問に対して答えることができます。 他にも人間のように絵を描いたり、作曲するサービスなど、知覚や知性を再現するサービスが多く存在しています。 エージェントとは 次に、「エージェント」についてです。 エージェントとは、 環境 を認識し、その環境に応じて 行動 できるもののことです。 『Artificial Intelligence: A Modern Approach』 (1995) では、エージェントを、センサーを通じて環境を認識し、アクチュエータを通じてその環境に応じて行動できるものとして定義しています。 これにより、エージェントは「環境」と「実行出来るアクションのセット」によって構成されることが分かります。 環境 ではまず環境とは何を示すのでしょうか？ これは、ユースケースによって異なります。 例えば、自動運転を行うエージェントであれば「道路状況」が環境となります。 一方で、株の売買を行うエージェントであれば「社会情勢」や「株価指数」などが環境となります。 アクションセット 次にアクションとは何を示すのでしょうか？ こちらも環境と同様、ユースケースによって異なります。 自動運転エージェントであれば、車の操作、例えば「アクセルを踏む」や「ハンドルをきる」といった操作がアクションに該当します。 一方で、株の売買を行うエージェントであれば、「社会情勢を調査する」、「株を売る」といった内容がアクションに該当します。 AIエージェントにおけるAIの役割 ここまででAIエージェントとは何かについて、なんとなく分かっていただけたのではないかと思います。 ではAIエージェントを実現するにあたって、AIはどういった役割をしているのでしょうか。 そもそもAIエージェントの目的は、 ユーザーから与えられたタスクを実行し、完遂すること です。 もう少し具体的に述べると、 AI自身が「環境」と「アクションセット」を認識し、特定の環境下でどのツールを使えばタスクを完遂することができるかを考え、行動します。 この時のAIの役割としては以下2点です ユーザーから与えられたタスクを完遂するために計画を立てる その計画通りにタスクを実行し、完了したかどうかを判断する これらを見ると、生成AI単体や、RAGで利用される場合よりも、生成AIに対してより複雑な処理が要求されることが分かります。 こういったことから、AIエージェントを構築するためには強力なAIモデルが必要であると一般的に言われています。 より具体的な理由としては以下のようなものがあげられます。 エージェントにおいて強力なモデルが求められる理由1 1つのタスクを完遂するためには、複数のステップが行われます。 そしてステップが積み重なるごとに全体の成功率も下がってしまいます。 例えば1つのステップの成功率が98%であっても、そのステップが20個連なった場合、全体の成功率としては約67%まで下がります。 この対策としては 強力なモデルを採用して、ステップ単体の成功率を上げる ステップ数を減らす といった内容が考えられます。 この1.の対策が、賢く強力なAIモデルを利用する理由となります。 エージェントにおいて強力なモデルが求められる理由2 AIエージェントはアクションを行うことで、外部にも影響を及ぼします。 例えばデータベースへのアクセスや、外部へのメール送信などを行うことができます。 想定通りの処理を行ってくれればいいのですが、想定しない処理を行われる可能性もあります。 例えば意図しないデータの書き換えや、誤った情報の外部へのメール送信などが該当します。 こういった誤った操作を行わないためにも、より賢い強力なモデルが必要となります。 AIエージェントの性能を決定づける要因 次に「良いAIエージェント」とは、どういったものを指すかについて考えてみたいと思います。 AIエージェントの性能を決定づける主な要因が以下2つです。 ツール プランニング ツール ツールはAIエージェントが利用できる道具です。 そしてこのツールは以下の3つの種類に大別できます。 知識の拡張ツール 機能拡張ツール エージェントが環境に応じて動作できるようにするツール これらのツールが豊富されている場合、生成AIが計画を行う際の選択肢が広がります。 知識の拡張ツール 1つ目が知識の拡張ツールです。 これは生成AIの知識を拡張するためのもので、本来生成AIのモデルが知りえない情報などを補完する際に利用されます。 具体的には以下のようなツールが該当します。 インターネットでの検索 データベースの検索 お気づきかもしれませんが、知識の拡張ツールを利用する点ではRAGと類似しています。 ただし、AIエージェントは取得した情報を基に自律的に行動計画を立て、複数のアクションを実行できる点でRAGとは異なります。 非常に簡素な形で実装してあるAIエージェントを、RAGとみなすことができる…とはいえるかもしれないです。 機能拡張ツール 2つ目が拡張機能ツールです。 以下のようなツールが該当します。 計算 単位変換 「計算などは生成AI単体でもできるのでは？」と思われるかもしれません。 生成AIは基本的な算数計算は可能ですが、複雑な数値計算や高精度な計算においては限界があります。 これは、生成AIが学習データのパターンから推論を行うため、計算専用ツールのような正確性は保証されないためです。 特に大きな数値や複雑な数式、統計計算などでは外部の計算ツールを使用する必要があります。 動作ツール 3つ目が動作ツールです。 以下のようなツールが該当します。 データベースの更新 電子メールの送信 これが一番のAIエージェントの醍醐味である一方で、リスクも伴うツールになります。 先ほども少し言及しましたが、外部に影響を与えることで得られる恩恵が多い一方で、誤動作などによるリスクは見逃すことができません。 プランニング 次に、性能を決定づける要素の2つ目である「プランニング」についてご紹介します。 プランニング とは、AIエージェントが与えられたタスクに対して、どのような処理を行えばタスクを完遂できるかを検討し、計画を立てることを指します。 例えば 「大手ECサイトで、人気スポーツブランド『サイオス』のTシャツのうち、現在セール価格になっているものを探してください」 というタスクが与えられたとします。 この時、AIエージェントは少なくとも2つの計画を立てることが考えられます。 計画1 ECサイトで開催中のセール対象商品をすべてリストアップする。 その膨大なリストの中から、ブランドが「サイオス」のものを絞り込む。 さらにその中から、商品カテゴリが「Tシャツ」であるものを探す。 計画2 ECサイトで、ブランドが「サイオス」のTシャツをすべてリストアップする。 そのリストアップした商品それぞれが、現在セール価格になっているかを確認する。 この2つの計画を比較してみましょう。 ECサイト全体のセール対象商品は、キャンペーンの規模によっては数十万〜数百万点にも及ぶ可能性があります。 計画1では、まずこの膨大なデータを取得してから絞り込むため、非常に多くの情報を処理する必要があり、時間もかかってしまいます。 一方で計画2は、最初に比較的母数の少ない「『サイオス』のTシャツ」という条件で商品を絞り込みます。 これなら対象は多くても数百点程度でしょう。 その上で、各商品がセール対象かどうかをチェックする方が、はるかに効率的にタスクを完了できそうです。 このように、同じゴールにたどり着く場合でも、より効率の良い計画を立てられるかどうかで、処理時間やコストが大きく変わってきます。 そして、どうしたらより良い計画が立てられるかについては、先ほども少し言及しましたが、状況を的確に判断できる性能の良いLLMモデルを利用することが一番の近道かと思います。 上記で説明したように、どのようなツールが用意されており、どのような計画が立てられるかで、与えられたタスクが正しく完遂されるかが決定されます。 ツールを豊富に用意したところで、正しく計画できなければタスクは完遂できません 正しい計画が行えたとしても、ツールが不足していればタスクが完遂できません そのため、AIエージェントに対して、 適切なツールを与え、適切な計画を立てさせること が良いAIエージェントを構築する上で重要となります。 フィードバック これまでご紹介したように、AIエージェントは与えられた「ツール」を利用して、「プランニング」を実行し、タスクを完遂しようとします。 ただ、ここでさらに注目するべきポイントが、AIエージェントが単に計画を立てて、実行するだけにとどまらない点です。 AIエージェントは自ら立てたプランを評価し、問題なければそれに従いタスクを実行していきます。 この時、もし計画に問題がある(タスクを完遂できなさそう)場合は、再度計画を練り直します。 更に、そのプランの実行中および実行後に実行結果を評価し、問題があるようであれば再度プランニングから行います。 具体的な流れは以下のようになります。 ユーザーからの要求を分解して、解決するための一連のタスク(=プラン)に分解する 生成したプランを評価する プランが適切でない場合は再生成する 生成されたプランを実行する 実行された結果を判定し、完了していない場合は再度計画し直す このフィードバックループにより、AIエージェントは失敗から学習し、より効果的な解決策を見つけることができます。 以下に参考にした記事の、非常に分かりやすい図を掲載しておきます。 (引用:https://huyenchip.com/2025/01/07/agents.html) まとめ 今回はAIエージェントについて初心に帰り、基礎的な部分のご紹介をしました。 近年、様々なAIエージェント開発ツールや、MCP(Model Context Protocol)などの登場によりAIエージェントの開発が非常に容易なものとなってきています。 その一方で、今回ご紹介したようなAIエージェントの基礎的な部分も抑えておく必要はあるかと思うので、是非参考にしていただければと思います。 ではまた！ 参考 https://huyenchip.com/2025/01/07/agents.html ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post AIエージェントとは？~基礎から理解する流行りのAIエージェント~ first appeared on SIOS Tech. Lab .

挨拶 ども！登壇資料の準備が佳境を迎えています、龍ちゃんです。資料の前段でブログを書こうと思ったら、執筆済みのブログが5件ほど積み上がっているという魔境のような現状があります。 さて今回は、その中の1つシリーズである「タイトルとメタディスクリプションをAIに丸投げしてみた」というブログの内容になります。 SEOわからん勢のリアルな悩み ブログを書き終わった後に悩む要素って、サムネイルとタイトルとメタディスクリプションですよね。正直、タイトルとメタディスクリプションだけで考えるのは非常に疲れてしまいます。というか嫌ですね。 だってメタディスクリプションって何なんですか？知らないですよね。でもやっぱりタイトルの引きってあると思うんですよね。「検索されやすいタイトルを…」って言われても困っちゃいますよね。 というわけで、そういうめんどくさい作業をAIに丸投げしちゃおうぜ！という話になります。 こんなことで悩んでませんか？ タイトル考えるのに30分かかる問題 メタディスクリプションって何？状態 キーワードとか意味不明 「検索されやすいタイトルを…」とか言われても困る 結論：もうAIに丸投げしよう 実際にやってるタイトル生成の流れ もう今では、タイトルやメタディスクリプションを自分で考えることなんて1個もなくなりました。AIが出してきたものに対して文句を言ってるだけで完成するんですね。 具体的な流れとしては、まずブログを執筆します。これは避けることのできない工程です。ブログを執筆して、そのブログを入力として与えます。 ステップ1：記事の要素を整理 使った技術スタック 想定読者（初心者？上級者？） 記事で解決する問題 他の記事との違い ステップ2：Claudeに投げるプロンプト あなたは、SEOに精通したライターです。 Goal：ブログ用タイトル・メタディスクリプションの作成 Plan： - 添付ファイルからコンテンツの把握 - タイトルを55~60文字以内で考案 - メタディスクリプションを85文字以内で作成 - SEO的に優れているという観点で順位付け - 複数案を提案 Tips： - 誇大広告は避けてください - 技術名を明確に含める - 実践的な価値を伝える ステップ3：複数案もらって選ぶ だいたい3-5個案をもらう 自分が「あ、これ読みたい」と思うやつを選ぶ 技術名が入ってるかチェック メタディスクリプション生成の流れ メタディスクリプションも同様の方法で作成することができます。ですが、メタディスクリプションはプロジェクトナレッジの追加を行い、条件付けを行っています。 SEOなんもわからんから調査してみた メタディスクリプションって何なんですか？正直全然わからなかったんですよね。 「120文字以内で書け」とか「160文字がベスト」とか、色んな情報が飛び交ってて何が正解かわからない状態でした。タイトルはなんとなく「キャッチーに書けばいいんでしょ？」って感じでしたが、メタディスクリプションは本当に謎。 そこで、SEOなんもわからん勢の僕が取った行動は「AIに調査してもらう」でした。調査はClaude リサーチとGemini DeepReserchを利用して調査しました。 調査結果をプロジェクトナレッジに登録 この調査結果を「メタディスクリプションガイド」としてプロジェクトナレッジに登録しました。 登録した重要な発見 ： 文字数の現実 ：60-85文字が2025年の実際の表示限界 表示確率の現実 ：Googleが設定内容を使うのは28%だけ スマホファースト ：検索の75%がスマホなので、スマホ基準で考える 前半50文字ルール ：重要情報は絶対に前半に配置 この調査をやってみて「やっぱりSEOって奥が深いんだな」って思いました。でも同時に「AIに調査してもらえば、素人でもプロレベルの知識が手に入る」っていうことも分かりました。 ナレッジベースを活用したプロンプト完成版 プロジェクトナレッジに調査結果を登録したので、今度はそれを活用したプロンプトを作成しました： あなたは、SEOに精通したライターです。 Goal：ブログ用メタディスクリプションの作成 制約条件（プロジェクトナレッジより）： - 文字数：60-85文字以内（2025年現在の実際の表示限界） - プライマリキーワード：最初の50文字以内に必ず配置 - 技術名を2-3個まで（キーワード詰め込み禁止） - 誇大表現禁止（「完全ガイド」「決定版」など） - スマホ表示を最優先に考える Plan： 1. 添付ファイルからコンテンツとタイトルの把握 2. プロジェクトナレッジのメタディスクリプション評価指標を参照 3. 前半50文字に最重要情報を配置したメタディスクリプションを複数考案 4. SEO的に最適かどうかの観点で順位付け 5. 最終的に一つに絞って推奨案を提示 Tips： - プロジェクトナレッジの制限事項を厳守 - 価値提案を明確にする（読者のメリット明示） - 技術レベルを表示する（初心者向け/上級者向け） - 問題解決フォーカスで書く ポイント ：「プロジェクトナレッジより」「プロジェクトナレッジの制限事項を厳守」って入れることで、Claudeが調査結果を参照してくれるんです。これがめちゃくちゃ便利！ 実例：劇的ビフォーアフター Claude暴走制御記事の場合 元々考えてたタイトル ：「Claudeの暴走制御を行う3つのパターン」 Claudeが作ったタイトル ：「 Claude調教術｜暴走パターンを制御する3つのプロンプトテクニック 」 メタディスクリプション ：「Claude制御の実践ガイド。過剰Artifact生成・スレッド肥大化・人間主導学習の3テクニックをプロンプトエンジニアリング視点で解説。Goal設定や成果物否定、段階的学習法で効率的AI活用を実現」 結果 ：技術名が明確で検索されやすそう！ 2025-07-04 Claude調教術｜暴走パターンを制御する3つのプロンプトテクニック Azure + Next.js記事の場合 元々考えてたタイトル ：「Azure SWA×Managed Fucntions：Next.jsでBicepから作成してGitHub Actionsでデプロイする」 Claudeが作ったタイトル ：「 Azure SWA×Next.js認証API統合を実践解説【DevContainer〜本番まで】 」 メタディスクリプション ：「Azure SWAでNext.js×Azure Functions認証API統合を実践解説。DevContainer開発環境からBicep IaC、GitHub Actions並列ビルドまで完全対応。Standard プラン対応でセキュアな認証フロー構築」 結果 ：具体的で差別化されたタイトルに変身！ 2025-07-07 Azure SWA×Next.js認証API統合を実践解説【DevContainer〜本番まで】 やってみてわかったコツと注意点 誇大表現問題への対処法 実際に僕がぶち当たった問題なんですけど、Claudeって「完全ガイド」とか「決定版」とか誇大表現が好きなんですよね。 そんな自信持ってブログ書いてるわけないじゃないですか！なので、そういった時は「ブログは完全版に耐えることができる内容ですか？」って聞いちゃうんです。すると反省して「完全じゃないです」って言って「実践編」とかに変えてくれます。 プロンプトで指定すべきこと 技術レベル（初心者向けとか） 記事の種類（チュートリアル、解説、比較など） 使ってる技術名 文字数制限 人間が最終チェックすべきポイント 内容と合ってるか 誇大広告になってないか 技術名が正確に記載されているか 自然な日本語になってるか SEO効果は実際どうなった？ SEO効果ってところは、これ測ってないんで知らないんですよね（笑） ただ、なんとなく昔のブログのタイトルと今のブログのタイトルを比較して、なんかいい感じです。なんか技術ブログっぽくなってるんですよ。てか昔のタイトルがゴミすぎるって説はあるんですけど。 時間的な効果は確実 ：タイトル考えるのに1時間かかってたのが、プロンプト入力だけなので5分になりました。めっちゃ早い！ 主観的な変化 タイトル考える時間が激減（1時間→5分） 記事を書くこと自体に集中できるように なんとなく「それっぽい」技術ブログタイトルになった ストレスが大幅に軽減された まとめ：SEOわからなくてもなんとかなる 今回は、SEOなんもわからん勢の僕が「タイトルとメタディスクリプションをAIに丸投げしてみた」という話をしてきました。 やったこと ： Claudeに調査してもらってプロジェクトナレッジに蓄積 プロンプトを作ってタイトル・メタディスクリプション生成を自動化 人間は最終チェックだけ 得られた成果 ： タイトル考える時間が1時間→5分に激減 なんとなく技術ブログっぽいタイトルになった ストレス大幅軽減でブログ執筆に集中できるように 正直、SEO効果のほどは測ってないので分からないんですが、少なくとも「タイトル考えるのめんどくさい問題」は完全に解決しました。 皆さんも、ブログのタイトルやメタディスクリプションで悩んでる時間があったら、その時間をブログの内容充実に使った方が絶対いいですよね。AIにできることはAIに任せて、人間は創造的な部分に集中しましょう！ それでは、また次回の記事でお会いしましょう〜！ ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post SEOなんもわからんけんClaudeに丸投げしたらストレスフリーになった話 first appeared on SIOS Tech. Lab .

挨拶 ども！Claudeでブログを書きまくっている龍ちゃんです。最近はClaudeのおかげでブログ執筆のスピードがメキメキと上がってきましたが、一方で作業時間の捻出に苦労している今日この頃です。 今回はClaudeでMermaidの図をサクッと作ってもらう方法について解説していきます。皆さんも技術ブログで「図があったらもっと分かりやすいのに…」と思ったことはありませんか？ なぜMermaidなのか？ 技術ブログにおける図解の重要性 技術ブログで図解が重要な理由は明確です。図があるかないかで読者の理解度や説得力が大きく変わります。ビジュアル的な要素があると、コンテンツの分かりやすさが飛躍的に向上するからです。 しかし、図を作るのがとにかく大変です。私もブログを書いた後にFigmaで図を作ることがありますが、2時間くらいかかってしまいます。作るのは楽しいのですが、やはり時間がかかるのがネックです。特にシーケンス図やフローチャートを説明する時は、図があった方が確実に分かりやすいのですが、作成の手間を考えると躊躇してしまいがちです。 Mermaidが解決する課題 そこで登場するのがMermaidです。Mermaidを使うと、以下のようなメリットがあります： コードベースで図を作成 ：テキストで書けるのでClaudeが得意 短時間で完成 ：5-10分程度で作成可能 一定の品質を保証 ：自由度が限定されているため、意図しない結果になりにくい メンテナンスが容易 ：コードなので後から修正しやすい この記事で身につくスキル この記事を読むことで、以下のスキルが身につきます： Claudeで効率的にMermaidコードを生成する方法 作成したMermaidを保存・管理するワークフロー Live Editorを活用した細かい調整テクニック 従来のツールでは2時間かかっていた図作成が、この方法なら5-10分で完了します。シリーズの一環として、ぜひ最後まで読んでみてください。 基本的な作業フロー 全体の流れ Claude × Mermaid × Live Editorを使った図作成の基本フローは以下の通りです： 要求定義（作りたい図の整理） Claudeにプロンプト入力 Mermaidコード生成 Live Editorで確認・調整 PNG/SVGで保存・活用 Live Editorとは Mermaid Live Editor は、ブラウザ上でMermaidコードをリアルタイムに編集・プレビューできる公式ツールです。コードを入力すると即座に図が表示され、エラーチェックも自動で行ってくれます。 効果的なプロンプトの構成要素 Claudeに良いMermaid図を作ってもらうためのプロンプトには、以下の要素を含めましょう： 図の種類 ：フローチャート、シーケンス図、パイチャートなど 目的 ：何を説明したいのか 要素 ：含めたい項目やステップ 制約条件 ：文字数制限や特別な要求があれば 実践①：フローチャート作成術 フローチャートが適している場面 フローチャートは以下のような場面で威力を発揮します： 業務プロセスの可視化 ：人間の判断や作業手順 システムの処理流れ ：API処理やデータ変換の流れ 意思決定プロセス ：条件分岐を含む判断フロー 重要なのは、複雑すぎる分岐は避けることです。2-3分岐程度に収めると見やすい図になります。 実際のプロンプト例 Mermaid形式のフローチャートで以下のブログ執筆プロセスを表現してください： 1. 執筆：人間による初稿作成 2. AI校閲：Claudeによる文体・技術的チェック 3. 評価：E-E-A-T観点での点数化 4. 改善判定：70点以上なら公開、未満なら修正 5. 修正：評価結果に基づく改善作業 6. 再評価：改善効果の測定 7. 公開：最終版の公開 見やすさを重視し、判定部分を分岐で表現してください。 よく使うパターン集 API処理フロー リクエスト受信 → 認証チェック → 処理実行 → レスポンス返却 デプロイフロー コード更新 → テスト実行 → ビルド → デプロイ → 監視開始 バグ修正プロセス バグ報告 → 現象調査 → 原因特定 → 修正実装 → テスト → リリース 実践②：シーケンス図でAPI解説 シーケンス図の特徴 シーケンス図は時系列での処理を表現するのに最適です。特に以下のような場面で効果的： システム間通信 ：API呼び出しやデータのやり取り 認証フロー ：OAuth2.0やJWT認証の流れ マイクロサービス連携 ：複数サービス間の協調処理 実際のプロンプト例 以下の要件でMermaidのシーケンス図を作成してください： 【参加者】 - ユーザー - フロントエンド - 認証層 - バックエンド - Google Sheets - Azure OpenAI 【処理フロー】 1. ユーザーがフロントエンドにデータ分析を要求 2. フロントエンドが認証層で認証確認 3. 認証OKでバックエンドにAPI呼び出し 4. バックエンドがGoogle Sheetsからデータ取得 5. バックエンドがAzure OpenAIにAI処理要求 6. Azure OpenAIで「Agent Systemとして処理」（注釈追加） 7. 分析結果をバックエンド経由でフロントエンドに返却 8. ユーザーに結果表示 エラーケースも含めて表現してください。 プロンプトのコツ 参加者を明確に定義する ：Claudeに推測させると意図と異なる結果になりがちです。関連するシステムやユーザーを明確に列挙しましょう。 処理順序を番号付きで説明 ：時系列が重要なので、ステップを明確に番号付けすると精度が上がります。 実践③：パイチャートで割合を可視化 パイチャートの活用場面 パイチャートは割合や構成比を表現する際に効果的です： リソース使用量 ：メモリ、CPU、ストレージの使用率 コスト内訳 ：プロジェクト予算の配分 技術スタック構成 ：使用技術の割合 特にこちらは、SVGで出力してFigmaで活用したりしています！ 実際のプロンプト例 MermaidでPieチャートを作成してください。 【タイトル】 ブログ記事のトークン使用量内訳 【データ】 HTMLタグ：6000 記事本文：12000 プロンプト：2200 その他：1600 各要素の割合を%で表示してください。 注意点 パイチャートは要素が多すぎると見にくくなります。5-7要素程度に収めて、小さな項目は「その他」でまとめるのが効果的です。 トラブルシューティング よくある問題と解決法 構文エラーが発生する場合 Claude側での確認 ：まずClaude上で図が表示されるかチェック Live Editorでの検証 ：エラー箇所を具体的に特定 Claudeに修正依頼 ：エラーコードをそのまま貼り付けて「修正してください」と依頼 日本語表示がうまくいかない場合 英語で作成 ：最初は英語で図を作成 後から翻訳 ：完成後に日本語に変換 エンコーディング確認 ：文字化けの場合はUTF-8で保存 図が複雑になりすぎる場合 階層化 ：大きな図を複数の小さな図に分割 抽象度調整 ：詳細すぎる部分を簡略化 別の図形式 ：フローチャートではなくシーケンス図に変更 すぐ使えるプロンプトテンプレート集 Claudeに図形式を確認する Mermaidで作成可能な図の種類を、簡単なサンプルコード付きで教えてください。 基本テンプレート フローチャート用 [システム名/プロセス名]をMermaidフローチャートで作成してください： 【処理ステップ】 - ステップ1：[具体的内容] - ステップ2：[具体的内容] - 判定：[条件分岐の内容] 見やすさを重視し、エラーハンドリングを含めてください。 シーケンス図用 [システム名]の処理をMermaidシーケンス図で表現してください： 【参加者】 [A、B、C...] 【処理フロー】 1. [A→Bの処理内容] 2. [B→Cの処理内容] ... エラーケースも含めて表現してください。 パイチャート用 以下のデータでMermaidパイチャートを作成してください： 【タイトル】 [グラフのタイトル] 【データ】 項目1：[数値] 項目2：[数値] ... 割合を%表示で含めてください。 修正依頼用テンプレート 先ほどのMermaid図を以下の点で修正してください： 【修正内容】 - [修正点1] - [修正点2] - [修正点3] より分かりやすく調整してください。 Live Mermaid Editorの活用術 Live Editorの優位性 Live Mermaid Editorが他のツールより優れている点： リアルタイム編集 ：コードを書くと即座に図が更新される 構文エラーの即座検出 ：エラー箇所をリアルタイムで表示 フル機能対応 ：GitHubやNotionで制限される機能も利用可能 ブラウザ完結 ：インストール不要で、どこでも利用可能 URL共有 ：作成した図をURLで簡単に共有できる テーマ選択 ：GitHub、Dark、Neutralなど複数のテーマ 他のプラットフォームとの違い NotionやGitHub上でもMermaidは表示されますが、以下の制約があります： Notion ： コードブロックのサイズ制限により大きな図が見にくい コードまたは図のみの表示選択は可能だが、同時編集・確認は困難 GitHub ： 一部のMermaid機能に制限（ハイパーリンク、ツールチップ、特定シンボル等） 保存後に図が表示されるため、試行錯誤に時間がかかる 構文エラーの詳細が分かりにくい Live Editor ： 複雑な図を作成する際の微調整が効率的 全Mermaid機能を制限なく利用可能 リアルタイムでエラー確認・修正が可能 ファイル管理・履歴機能 Live Editorの保存・管理機能： 自動履歴保存 ： 編集内容を1分間隔で自動保存 最大30編集まで履歴を保持 ブラウザストレージに依存（データクリア時は消失） 外部保存機能 ： GitHub Gistとの連携による長期保存 URL共有によるチーム間でのやり取り 手動保存による重要バージョンの固定 制限事項 ： 履歴はブラウザローカルに保存されるため、他デバイスでは参照不可 ブラウザデータをクリアすると履歴が失われる 長期保管にはGist連携の活用を推奨 まとめ 今回は、ClaudeとMermaidを組み合わせた効率的な図作成方法について詳しく解説しました。 この記事のポイント 時短効果 ：2時間の作業が5-10分に短縮 品質確保 ：一定レベルの見やすい図を安定して作成 学習コスト低 ：複雑なツールの習得が不要 メンテナンス性 ：コードベースなので修正が容易 Live Mermaid Editorとの組み合わせにより、リアルタイムでの編集・確認も可能になります。技術ブログの図解作成で時間を短縮したい方は、ぜひこの方法を試してみてください。 図があるだけで記事の分かりやすさが劇的に向上します。皆さんも、ぜひMermaidを使った図解作成にチャレンジしてみてください！ ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post ClaudeでMermaid図作成を自動化！2時間→5分の劇的時短術【Live Editor活用】 first appeared on SIOS Tech. Lab .

はじめに ども！最近、Claude Proになってより一層Claudeを使い倒している龍ちゃんです。新しい技術ということもあり、書くことがいっぱいあって楽しいですね。あと、書き手があと3人ほどいたら嬉しいところです。弊社でも徐々にClaude関連の記事が増えていて、僕的にはウハウハな状況です。 さて、今回は以前書いた「 Claude×技術ブログで執筆環境が激変！次世代AI協働ワークフロー解説 」で取り扱っていなかった 詳細なプロンプト技術 について、深掘りして解説していきたいと思います。 最終的には登壇資料としてまとめなきゃいけないので、これから頑張ってブログを書いていくしかないですね。それでは、始めていきましょう！ シリーズ全体構想 まだ第1回を読んでいない方は、ぜひ第1回を読んでいただけると幸いです。シリーズの全体構想は以下のとおりです： 第1回： Claude×技術ブログで執筆環境が激変！次世代AI協働ワークフロー解説 第2回：Claude技術ブログ品質を10倍向上させる3段階チェック術【プロンプト実践】　←　今回はここ！ 第3回：構成・アウトライン編 第4回：SEO最適化編 第5回：ビジュアル制作編 第6回：サムネイル・デザイン編 AIを活用した3段階品質チェック戦略 品質チェックという部分に注目して、Claudeをどう使っているのかについて解説していきます。ここで取り扱う内容は主に以下の3つになります： 文体統一 技術的正確性の検証 アウトライン評価 文体統一の実践手法 自分の文体を抽出してシステムプロンプト化 文体統一では、まず自分の文体の癖を抽出するところから始めます。具体的には過去に書いたブログ記事をClaudeに入力として与え、共通する文体の特徴や全体感を抽出しています。 出力されたシステムプロンプトの一部をご紹介します： # SIOSテックブログ風文体・テイスト再現プロンプト 以下の文体・テイストでテクニカルブログを執筆してください： ## 基本的な文体・トーン - **親しみやすくカジュアルな表現**: 「ども！」「〜ですね」などの親近感ある表現 - **個人的な体験談を交える**: 執筆者の個人的な近況や体験を自然に織り込む - **軽快でカジュアルながら技術的**: 難しい技術内容も親しみやすく説明 ## 記事構成のテンプレート 1. **はじめに** - 個人的な近況（AI課金額、技術動向など） - 今回のトピック紹介 - 読者へのメリット提示 2. **技術解説部** - **段階的な説明**: 基礎から応用まで順序立てて解説 - **豊富なコード例**: 実際のコードを多用し、コメントで詳細に説明 [...]（詳細なプロンプトは省略） 自分のブログから抽出された内容なので、「あ、自分って意外とこういう書き方の癖があるんだな」と気づくことができて結構面白いですね。出力されたシステムプロンプトは、間違っている部分を修正してClaudeのプロジェクトナレッジとして登録しています。 Claude暴走防止のプロンプト設計 実際に起きた問題として、ブログのアウトラインと部分的な章構成を与えた場合、Claudeが勝手にブログ全体を書いてしまうということが発生しました。 今回のターゲットは、ブログをAIに生成してもらうことではなく、 人間が書いたブログをClaudeに修正してもらう という使い方です。そのため、追加でプロジェクトナレッジのシステムプロンプトとして以下のようなプロンプトを入力しています： プロジェクトナレッジを検索して使えそうな情報がある場合は、使用してください。 情報を作成をする前に具体的なプランを明示して許可を取ってから実行をしてください。 明確な指示がない場合は、文章の校閲をしてほしいと解釈してください。 ブログ全文の生成は「ブログの全部を書いてほしい」という明確な指示があった時だけです。 この辺のテクニックに関しては、「 Claude調教術｜暴走パターンを制御する3つのプロンプトテクニック 」で詳しく取り扱っています。 入力方法と注意点 与える入力は、アウトラインと執筆した章単位で分割しています。こうすることで、部分的にアウトプットを作成しながら章を追加したい場合、アーティファクトを追加するという形で出力されます。 トラブルシューティング として気をつけているポイント： PDFでの入力 : 読み込みに失敗する可能性があるため避ける 画像URL含有 : 文章中に画像のURLが含まれている場合、参照できずに出力が失敗することがある アウトライン共有 : 全体像を把握させるため、必ずアウトラインを共有する これらの問題を避けるため、入力は極力 テキストベース で行っています。 技術的正確性の検証アプローチ 公式リファレンスとの照合手法 技術的正確性の検証では、すでに執筆したブログの正確性を確認する作業を行っています。こちらのブログ「 【実践解説】技術ブログ品質チェック術｜Gemini Deep Researchで5分検証 」では、執筆済みのブログを入力として与え、ブログの評価を行うという手法で検証しています。 このアプローチは、 ブログの執筆完了後ではなく、執筆中に検証を行う ものです。 大前提として、AIに聞いたところで、必ずしも正確な情報が返ってくるわけではありません。ただ、入力として公式リファレンスのURLと書いてある内容の精度という観点においては優秀な精度を誇っています。 具体的な検証プロセス 一次情報として人間が書いたブログと、参照した公式リファレンスを合わせて与えることによって、「ブログで書かれているコンテンツと公式情報に矛盾がないか？」という確認を主に行っています。 また、入力として追加で執筆したブログのコンテンツに関する言及があるかどうかを聞くことによって、自分が見落としていた問題などを発見することができます。 着眼点としては ： 公式が推奨するベストプラクティスに則っているか 最新の仕様変更に対応できているか 誤解を招きやすい表現がないか リアルタイム検証の実践手法 このアプローチは、ブログの執筆完了後ではなく、執筆中に検証を行うものです。章を書き終えるたびに即座に検証することで、後から大幅な修正が必要になるリスクを回避できます。 実際に使用しているプロンプト ブログの章を執筆しました。引用されているURLの内容と執筆されている内容に齟齬がないか確認をお願いします。引用されている情報をもとに判断して、推測などを含めないでください。 ~~ブログコンテンツ~~ アウトライン評価の実践 対話的なアウトライン構築 アウトライン評価は、執筆前の段階の整備作業となります。アウトラインについては、AIと対話的に作成することもあります。主にClaudeとの対話を通じて構築することもあれば、人間がベースを作成してAIに入力して評価してもらうこともあります。 使い方の流れ ： ざっくりと章だけを書く そのアウトラインを特定のプロンプトで評価してもらう 評価の返答を参考にして、章立ての追加やアウトラインの拡充を行う 再評価を繰り返すことによって、ブログの品質を向上させる 私の体感ですが、この方法でブログを書く順序として非常に効果的です。 トラブルシューティングと改善ポイント よくある問題 ： アウトラインで章タイトルのみを記載している場合、AIが想像する内容の方向性が自分の考えている方向性と異なることがある 解決方法 ： アウトライン内に内容の概要を箇条書きで追加する 「10段階評価でお願いします」というリクエストを加えて、明確な数値化を実現する 「計画を出力してください」というリクエストを加えて、一度出力形式の確認をする アウトライン評価のサンプルプロンプト あなたはSEOが得意な技術ライターです。 最新リソースからブログのアウトラインをEEAT・トレンド性の観点から評価をしてください。 検索などを駆使して再帰的に反復して時間をかけて結論を出してください。 アウトラインは以下です 【Claude実践】技術ブログ品質を10倍向上させる対話型チェック術 1. はじめに * AIによる技術ブログ執筆支援の現状 * 品質向上における課題 * この記事で得られるもの [...]（詳細なアウトラインは省略） この評価手法には、GeminiのDeep ResearchやClaude Searchなども活用できますが、ClaudeのWeb検索機能でも問題なく動作すると考えています。 実際の評価結果と改善プロセス 実際にこのプロンプトを使用した結果、以下のような評価を得ることができました： E-E-A-T評価スコア例 ： Experience : 8.2/10（具体的な体験談が豊富） Expertise : 8.7/10（技術的深度と最新動向への言及） Authoritativeness : 8.0/10（シリーズとしての一貫性） Trustworthiness : 8.6/10（限界や課題の率直な共有） トレンド性評価 : 9.0/10（2025年のAI活用トレンドに合致） この評価を基に、Experience部分により具体的な失敗例を追加し、Trustworthiness向上のために検証中の内容を明示するなど、継続的な改善を行っています。 効率化の実測と品質管理手法 データ駆動型の品質向上アプローチ 体感値だけでなく、より客観的な品質管理を実現するため、以下の指標で継続的に測定を行っています： 執筆効率の定量化 ： 従来手法 : 2時間（体感値） AI協働手法 : 30分（体感値） 効率化率 : 約75%向上 品質指標の数値化 ： E-E-A-T総合スコア : 8.5/10（第三者評価による） 反復改善のフィードバックループ 実際の運用では、以下のサイクルで品質向上を図っています： 執筆 : 人間による初稿作成 AI校閲 : Claude による文体・技術的チェック 評価 : E-E-A-T観点での点数化 改善 : 評価結果に基づく修正 再評価 : 改善効果の測定 このプロセスを繰り返すことで、継続的な品質向上を実現しています。 トラブルシューティングのポイント 図表関連の対応 技術ブログでは図表が重要な要素となりますが、以下の点に注意が必要です： PNG/JPEG/SVG : それぞれの特性を理解した使い分け Mermaidの活用 : システム構成図やフローチャートの効率的な作成 図のクラッシュ対応 : ファイルサイズや解像度の最適化 想定される技術的課題 入力データの制限 ： ファイルサイズの上限 対応フォーマットの制限 処理時間の制約 出力品質の安定化 ： プロンプトの一貫性確保 期待する出力形式の明確化 エラーハンドリングの仕組み作り 実践的な課題解決事例 実際の運用で直面した課題と解決策をご紹介します： 課題1: AI暴走の制御 問題 : アウトライン提示時にブログ全体を勝手に生成 解決策 : システムプロンプトでの明確な役割制限 課題2: 文体の一貫性維持 問題 : 章ごとに文体が変化してしまう 解決策 : 過去記事からの文体抽出とナレッジ化 課題3: 技術情報の正確性確保 問題 : AI による誤った技術情報の生成 解決策 : 公式リファレンスとの照合プロセス導入 課題4: 図が含まれることによりクラッシュ 問題 : 入力に図が含まれる場合にクラッシュする 解決策 : 図を無視するようにプロンプトで無視（マスクする） Notion MCP連携の実装成果 期待から実現へ ClaudeとNotionの連携について検討していた Notion MCP ですが、実際に実装に成功しました！当初は「絶賛検証中」としていましたが、想定以上にスムーズな統合を実現できています。 「 Claude×Notion MCP実装術｜コネクタ版とIntegration版の選び方解説 」で解説しています。 実装により実現できたこと ： 自然言語でのページ操作 : Claude経由でのNotionページの作成・更新・検索 校閲済みコンテンツの直接保存 : ブログ校閲結果のワンクリック保存 過去記事からの文体抽出自動化 : 蓄積された記事データの効率的活用 実装で得られた知見 詳細な実装手順については別記事「 Claude Notion MCP実装ガイド 」で解説していますが、ここでは品質向上ワークフローへの統合効果をご紹介します。 効果測定結果 ： 校閲結果の保存時間 : 手動2分 → 自動10秒（92%短縮） 過去記事参照 : 手動検索5分 → AI検索30秒（90%短縮） 文体抽出の精度 : 手動選別 → 全記事自動解析による包括性向上 実際の活用事例 1. リアルタイム品質チェック結果の蓄積 校閲結果をNotionのデータベースに自動保存 → 品質向上のパターン分析が可能に → よくある間違いの事前防止 2. 文体統一プロセスの自動化 過去160本の記事から文体特徴を自動抽出 → より精密なシステムプロンプト生成 → 文体一貫性の向上 3. 技術検証の効率化 Notion内の技術ナレッジベースと連携 → 過去の検証結果の瞬時参照 → 重複検証の回避 次なる挑戦：音声認識ワークフロー Notion MCP連携が実現できたことで、次のステップとして 音声認識機能 を活用したNotion直接入力の検証を進めています。 想定ワークフロー ： 音声入力 : Notionに話した内容を直接テキスト化 AI校正 : Notion AI×Claudeによる文章整理と構成最適化 品質チェック : 今回紹介した3段階チェックの自動実行 最終出力 : 投稿済み品質のブログ記事の完成 期待される効果 ： 執筆時間 : 現在30分 → 10分程度（70%さらなる短縮） アイデアキャプチャ : 思いついたタイミングでの即座記録 ハンズフリー執筆 : 移動中や休憩時間の有効活用 効率化の実測データと検証 ただし、ブログ執筆にかかる時間については具体的な数字を測定していなかったので、これはあくまで体感値です。より正確な効果測定のために、以下の指標で検証を進めています： 執筆時間 : 初稿完成までの時間 校閲回数 : AI支援による修正回数 品質スコア : E-E-A-T観点での評価値 読者エンゲージメント : 実際の記事への反応 まとめ 今回は「Claude×技術ブログ品質向上編」として、AIを活用した3段階品質チェック手法について詳しく見てきました。 3つの実践手法 ： 文体統一 : 過去記事からの文体抽出とシステムプロンプト化によるClaude暴走防止 技術的正確性 : 公式リファレンスとの照合による執筆中のリアルタイム検証 アウトライン評価 : E-E-A-T観点での対話的評価と継続的改善 また、将来的な展望として、Notion MCP連携や音声認識を活用した執筆フローの可能性についても触れました。実際の運用では、効率化だけでなく品質管理の数値化や反復改善のフィードバックループが重要であることも確認できました。 次回の「構成・アウトライン編」では、より詳細な企画段階でのClaude活用術をお届けする予定です。お楽しみに！ ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Claude技術ブログ品質向上の試行錯誤｜3段階チェックで安定【プロンプト実践】 first appeared on SIOS Tech. Lab .

はじめに ども！最近Claude ProでAI開発にどっぷりハマっている龍ちゃんです。先日、Claudeにブログ記事を評価してもらったら「2025年としてはこのブログ普通っすね！むしろ遅れてるぐらいっす」って辛辣なコメントをもらっちゃいました。一方で、Gemini Deep Researchで同じ記事を評価したらべた褒めだったので、AIによる評価の違いって面白いですよね。 今回は、いよいよClaude DesktopとNotion MCPを接続して、AIによるドキュメント自動操作環境を構築していきます。 予測される効果として、「 Claude×技術ブログで執筆環境が激変！次世代AI協働ワークフロー解説 」こちらのブログで解説している内容がよりグレードアップされると期待しています。 事前準備：Node.js環境のセットアップ まずは、Notion MCPサーバーを動作させるためのNode.js環境を準備しましょう。既にNode.jsが入っている方は、バージョン確認から始めてください。 Node.js未インストールの場合：Voltaで管理 Node.jsが入っていない方には、 Volta での管理をおすすめします（完全に個人的な趣味ですが…）。お好きな管理ツールを使っていただいて構いません。 Voltaのインストール（Windows） # 管理者権限で実行 curl https://get.volta.sh | bash Node.jsのインストール # LTS版をインストール volta install node # バージョン確認 node --version npm --version 既存環境の確認 Node.js v18以上が必要です。以下のコマンドで確認してください： # Command PromptまたはPowerShellで実行 node --version npm --version Notion MCPサーバーの動作確認 以下のコマンドで、Notion MCPサーバーがインストールできるかテストします： # 動作確認テスト npx -y @notionhq/notion-mcp-server --help 正常に動作すればヘルプが表示されます。Ctrl+Cでプロセスを終了してください。 接続方法の比較と選択 補足：Notion公式のHosted MCP Serverについて 2025年7月より、Notion公式がHosted MCP Serverも提供開始しました！ Hosted MCP Server（リモート版）の特徴 OAuth認証でワンクリック接続 AI向けに最適化されたMarkdown形式でのデータ提供 サーバー管理不要 Notionがクラウドでホスト ワークスペース全体への完全アクセス ただし、 現在報告されている課題 ： Gemini CLI等のMCPクライアントとの互換性問題 細かいアクセス制御ができない（ワークスペース全体のみ） なぜローカル実装（npx経由）を推奨するのか Notion公式のHosted MCP Serverも魅力的ですが、現在以下の理由でローカル実装をおすすめします： 方法 設定難易度 プラン制限 アクセス制御 安定性 推奨ユーザー コネクタ版（Remote） 公式未明記 ワークスペース全体 簡単設定重視 Integration版（Local） なし ページ単位 制御重視 Hosted MCP 公式未明記 ワークスペース全体 最新技術試行 全プラン対応 : 無料版でも利用可能 細かい制御 : ページ単位でアクセス権限設定 安定動作 : Node.js環境があれば確実に動作（今更感もあるけども…） カスタマイズ : 必要に応じて機能拡張可能 互換性 : 各種MCPクライアントで動作確認済み そのため、確実性と柔軟性を重視してnpx経由での実装方法をご紹介します。 方法1：Notionコネクタでの簡単接続 Claude Desktopの コネクタ機能 を使用する方法です。これはAnthropicが推奨する公式ツールで、ブラウザ上でMCP認証を簡単に完了できます。 接続手順 Claude Desktop → 設定 → コネクタ 「カスタムコネクターを追加」をクリック 「Notion」を検索・選択 自動的に認証ページが開くので、認証を完了 重要な注意点 コネクタ版では ワークスペース全体 に接続されるため、Claudeからワークスペース内のすべての情報にアクセス可能になります。機密情報が含まれる場合は、次の「Notion Integration版」をご検討ください。 トラブルシューティング MCPの接続が何度か失敗する場合は、コネクタから切断をして再度認証を行ってください。 方法2：Notion Integration作成してMCP接続 こちらの方法では、NotionのAPIを使用してMCPを構築し、アクセス権限を細かく制御できます。特定のページのみにアクセスを限定したい場合におすすめです。 こちらの方法に関しては Notion公式が記事としてまとめています 。 Integration作成 Notion Integrations にアクセス 「New integration」をクリック 以下を設定： Name : Claude MCP Integration Workspace : 使用するワークスペースを選択 Capabilities : デフォルトのまま（Read content, Update content, Insert content） Integration Token取得 作成後、「Internal Integration Secret」を取得してください。 ntn_ で始まるトークン（例： ntn_abc123def456... ）が表示されます。 セキュリティ注意 このトークンは機密情報です。安全に保管し、他人と共有しないでください。 ページへのアクセス権限付与 Notionで任意のページを開く 右上の「…」メニュー → 「接続を追加」 作成したIntegrationを選択して接続 この手順により、指定したページのみにMCPからのアクセスが制限されます。 設定ファイルの場所確認 Claude Desktopから設定ファイルにアクセスする方法が最も簡単です： Claude Desktop → 設定（Settings） 開発者（Developer）タブ 「Edit Config」ボタンをクリック 参考：ファイルパス Windows: %APPDATA%\\Claude\\claude_desktop_config.json ファイルが存在しない場合は新規作成してください。 設定ファイルの作成・編集 以下の内容で設定ファイルを作成・編集します： { "mcpServers": { "notionApi": { "command": "npx", "args": [ "-y", "@notionhq/notion-mcp-server" ], "env": { "OPENAPI_MCP_HEADERS": "{\"Authorization\":\"Bearer ntn_your_token_here\",\"Notion-Version\":\"2022-06-28\"}" } } } } 重要 : ntn_your_token_here を Step 2で取得した実際のIntegration Tokenに置き換えてください。 動作確認 Claude Desktopの再起動 Claude Desktopを完全に終了（システムトレイからも終了） Claude Desktopを再起動 接続テスト Claude Desktopで以下のプロンプトを試してください： Notionのワークスペースに接続できているか確認してください。利用可能なページがあれば一覧を表示してください。 実際にページを操作してみる 「テストページ」という名前で新しいページを作成して、簡単な内容を追加してください。 成功すれば、Claude経由でNotionページが作成・編集されます！ どれを選ぶべきか 実際に複数の方法を試してみて感じた違いをお話しします。 これからNotion×Claudeを始める方 : コネクタ版がおすすめ（プラン制限の詳細は公式発表を確認） 細かいアクセス制御が必要・確実性重視 : Integration版一択 開発者・他AIツールも検討中 : Integration版でMCPサーバー構築 最新技術を試したい方 : Hosted MCP Server（ 互換性問題 承知の上で） 今後の展望：AIフレンドリーなNotion環境構築 現在の私のNotion環境は、残念ながらAIフレンドリーとは言えません。今後は以下の改善を検討しています： AIが効率的にアクセスできるページ構造への再編 よく使用するページの階層浅化 AI専用ワークスペースの構築 皆さんも、AIパートナーとしてClaudeを活用する際は、Notionの構造も合わせて最適化していくことをおすすめします。 まとめ 今回の記事では、Claude ProとNotion MCPを接続するための複数の方法を紹介しました。コネクタ版は簡単に始められる一方、Integration版はより細かい制御が可能です。どの方法を選ぶにしても、AIとNotionの連携によって情報管理と創造性が大きく向上するでしょう。ぜひ皆さんも試してみてください！ ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Claude×Notion MCP実装術｜コネクタ版とIntegration版の選び方解説 first appeared on SIOS Tech. Lab .

はじめに Git & GitLab入門ブログ Gitマスターへの道の第2回です。前回の「 Gitの基本とGitLab / GitHubについて 」では、Gitの基本を解説しました。 今回は、ローカルPCにGit、VSCodeを導入し、最初のコミットを行うまでの手順を解説します。Windows環境をメインに説明しますが、他のOSをご利用の方にも役立つ情報を含んでいます。 初期環境構築 Gitを使い始めるためには、まずお使いのPCにGitをインストールし、基本的な設定を行う必要があります。 今回のGit操作入門では、VSCodeを使用してGitの操作やコードの編集を説明します。 Gitのインストール Gitの公式サイト（ https://git-scm.com/download/win ）にアクセスし、最新のインストーラーをダウンロードします。 ダウンロードしたインストーラーを実行します。インストール中の設定は、特にこだわりがなければすべてデフォルトのままで問題ありません。「Next」をクリックしていき、インストールを完了させてください。 Windows + R から「ファイル名を指定して実行」を開き、「cmd」と入力してEnterキーを押し、コマンドプロンプトを開きます。以下のコマンドを実行してバージョンが確認されれば成功です。 $ git --version VS Codeのインストール VS Codeの公式サイト（ https://code.visualstudio.com/download ）にアクセスし、Windows版のインストーラーをダウンロードします。 ダウンロードしたインストーラーを実行します。「同意する」を選択し、「次へ」をクリックしてインストールを進めます。 この際、「Codeで開く」アクションをエクスプローラーのコンテキストメニューに追加するオプションにチェックを入れておくと便利です。 その他のOSについて（Mac/Linux） Mac：Homebrew ( https://brew.sh/index_ja ) を利用するのが最も簡単です。ターミナルで以下のコマンドを実行してください。 $ brew install git VS Codeも公式サイトからダウンロード・インストールできます。 Linux：各ディストリビューションのパッケージマネージャーを利用します。例えばUbuntuであれば、ターミナルで以下のコマンドを実行します。 $ sudo apt update && sudo apt install git VS Codeも公式サイトから.debや.rpmパッケージをダウンロードしてインストールできます。 ユーザー名とメールアドレスの設定 Gitをインストールしたら、コミットの際に記録されるユーザー名とメールアドレスを設定します。これは、誰がどの変更を行ったかを識別するために重要です。 コマンドプロンプトを開き、以下のコマンドを実行してください。 $ git config --global user.name "名前" $ git config --global user.email "メールアドレス" “名前” の部分には、表示したいユーザー名を記載してください。これは、GitHubなどでもコミット履歴として確認されます。 “メールアドレス” の部分には、普段お使いのメールアドレスを記載してください。 この設定は–globalオプションを付けているため、一度設定すれば、そのPC上のすべてのGitリポジトリに適用されます。 VSCodeにおける操作　（windows) VS Codeの左側にあるソース管理アイコンから後述するGitの操作が可能です。 この機能により、本来 コマンドプロンプトで実行するGit操作がGUI上でも実行可能となります。 ローカルリポジトリの作成 Gitでバージョン管理を始めるには、まず、リポジトリを作成する必要があります。前回説明しましたが、Gitリポジトリにはローカルリポジトリとリモートリポジトリの２種類あります。 今回は、手元のPCに作成する「ローカルリポジトリ」を作成します。VSCodeなどの開発時に利用するエディタの拡張機能を用いてGitを管理する事で、利便性や効率性を持たせてGitを扱うことが出来ます。 VS Codeを開き、「ファイル」>「フォルダーを開く」を選択します。 Gitで管理したいプロジェクトのフォルダー（例：git-tutorial）を新しく作成し、そのフォルダーを選択して開きます。 VS Codeの左側にあるソース管理アイコンをクリックします。 「リポジトリを初期化」ボタンをクリックします。 コマンドで実行する場合は、VSCodeからCtrl + @ でターミナルを起動し、以下のコマンドを実行します。 $ git init これで、指定したフォルダーがGitによって管理されるようになり、ローカルリポジトリが作成されました。フォルダー内に.gitという隠しフォルダーが作成されていれば成功です。 最初のコミット リポジトリを作成したら、最初のファイルを作成し、それをGitに記録（コミット）してみます。 コミットの基本的な流れは、以下の3つのステップから構成されます。 変更 この時点ではまだ、その変更がGitのバージョン管理の対象として確定されたわけではありません。例えるなら、ノートに下書きを書いた状態です。 ステージング 変更を加えたファイルをGitのバージョン管理に含めるためには、「ステージングエリア」と呼ばれる一時的な領域に、その変更を「ステージ（追加）」する必要があります。ステージングのステップが必要な理由のひとつとしては、一度に複数のファイルを変更した場合でも、その中の特定の変更だけをコミットしたい場合に対応するためです。 コミット ステージングエリアに準備が整った変更を、最終的にGitのバージョン履歴として確定させる操作です。いくつかの呼称がありますが、コミットはコミットIDという一意のハッシュ値で識別されます。 最初のファイルを作成していきます。VS Codeの左側のエクスプローラービューで先ほど作成したフォルダー内に新しいファイルを作成します。例えば、index.phpというファイルを作成し、以下の内容を記述します。 Hello world! ファイルを保存すると、VS Codeのソース管理ビューにindex.phpが「変更」として表示されます。これは、Gitがファイルに変更があったことを検知している状態です。 ndex.phpの行にマウスカーソルを合わせると表示される「ステージング」（プラスアイコン）をクリックします。これにより、index.phpがコミットの対象として選択（ステージ）されます。 ターミナルで実行する場合は、以下のコマンドを実行します。 $ git add index.php 上部のテキストボックスにコミットメッセージを入力します。コミットメッセージは、そのコミットでどのような変更を行ったかを簡潔に説明するものです。今回は「Initial commit」と入力しましょう。 コミットメッセージを入力したら、上部のチェックマークアイコン（コミットボタン）をクリックします。 ターミナルで実行する場合は、以下のコマンドを実行します。 $ git commit -m “Initial commit” これで、最初のコミットが完了しました。Gitはindex.phpの現在の状態を履歴として保存しました。 改めてGit操作の第1歩としてはまず、ローカルリポジトリ上での変更→ステージング→コミットの流れについて覚えていくのが重要です。 まとめ 今回はGitの環境構築と最初のコミットなどを解説しました。これでバージョン管理に足を一歩踏み入れました。次回はチーム開発に向けて解像度を上げるために、他のGitの機能やコミットの戻し方等を解説します。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Git & GitLab 入門 (2) ～Git マスターへの道～「Git操作入門」 first appeared on SIOS Tech. Lab .

Material Designをはじめとして、グラフィカルユーザーインターフェース（GUI）のデザインシステムは数多く公開されています。 各デザインシステムに含まれるUIコンポーネントは、各ブランドやサービスに最適化された独自の内容ですが、基本的な部分は共通しています。 たとえば「Button」コンポーネントは、どのデザインシステムでも、同じ役割かつ同じ名前で定義されています。 一方、役割は概ね同じでも、名称が異なるケースもあります。 この記事では、そのようなケースの具体例を挙げながら、UIコンポーネントの名称を整理します。 各デザインシステムのコンポーネントのカタログ化の粒度がさまざまで、グループ化の判定は筆者独自のものですが、複数のデザインシステムを参照する際の参考になれば幸いです。 今回対象としたデザインシステムやUI Kit Apple Human Interface Guidelines Bootstrap Atlassian Design System Material Design（Google） Carbon Design System（IBM） U.S. Web Design System（USWDS） GOV.UK Design System SmartHR Design System デジタル庁デザインシステム Fluent 2（Microsoft） Shadcn/ui （コンポーネント名は、オリジナルが複数形の場合も単数形に変更して統一しています。例：Chips → Chip） テキスト入力：「Text field」「Text input」など UIコンポーネント名 デザインシステム Text field Apple Atlassian Material Design（Google） Text input Carbon（IBM） USWDS GOV.UK Input SmartHR Fluent 2（Microsoft） Shadcn/ui Input text デジタル庁 テキストを入力する基本的なコンポーネントです。 「Text input」や「Input」は、HTMLの<input type=”text”>と一致する名称です。（inputタグのデフォルトタイプはtext） なお、Material Design、USWDS、Appleは、1行のみの入力と複数行の入力を1つのUIコンポーネントにまとめています。 それ以外のデザインシステムでは、1行入力を「Text input」、複数行入力を「Textarea」のように、コンポーネントを分けているケースが多いです。 これもHTMLの<textarea>タグに合わせた名称です。 確認するもの：「Dialog」「Modal Dialog」など UIコンポーネント名 デザインシステム Dialog Material Design（Google） SmartHR Fluent 2（Microsoft） Shadcn/ui Modal Bootstrap Carbon（IBM） USWDS Modal dialog Atlassian デジタル庁 Alert Apple Alart Dialog Shadcn/ui 「ダイアログ」は直訳すると「対話」です。 「モーダル」は「モードの」という意味で、ひとつのモードに入っていて他の操作をさせないことを示します。対義語は「モードレス」です。 上記のコンポーネントの多くがモーダルな動作をしますが、たとえばSmartHRには「ModelessDialog」も存在します。 また、Material Designや、Bootstrapでは、フルスクリーン表示もサポートされています。 Shadcn/uiでは「Dialog」と「Alart Dialog」が別に定義されています。 左右でオンとオフを選ぶ：「Switch」「Toggle」 UIコンポーネント名 デザインシステム Switch Apple Bootstrap Material Design（Google） SmartHR Fluent 2（Microsoft） Shadcn/ui Toggle Atlassian Carbon（IBM） Appleでは「Switch」「Checkbox」「Radio Button」など、2つの状態を選択させることをまとめて「Toggle」として案内しています。 また、Shadcn/uiでは、「Switch」と「Toggle」が別のコンポーネントとして定義されています。Toggleはシンプルなボタン表現です。 なお、「Switch」と「Checkbox」は、どちらもオンオフの二択入力ですが、「Checkbox」が入力後に登録ボタンを押して有効になるのに対し、「Switch」は入力と同時に有効とするのが、一般的な使い分けです。 小さい情報：「Chip」「Tag」 UIコンポーネント名 デザインシステム Chip Material Design（Google） SmartHR Tag Atlassian Carbon（IBM） USWDS GOV.UK Fluent 2（Microsoft） 「ソーシャルタグ」「ハッシュタグ」「タグ付け」など、テキスト情報（ラベル）に着目した名前が「Tag」です。 これに対して、「Chip」はテキストなどが乗っているオブジェクトに焦点を当てたネーミングだと考えられます。 ひょっこり現れる：「Snackbar」「Toast」など UIコンポーネント名 デザインシステム Snackbar Material Design（Google） Toast Bootstrap Carbon（IBM） Fluent 2（Microsoft） Sonner Shadcn/ui Flag Atlassian 画面の外側からスライドして現れ、状態の変化や警告などをオーバーレイで表示するコンポーネントです。 Shadcn/uiでは以前からあった「Toast」コンポーネントを非推奨にして、代わりに「Sonner」が追加されました。 「Sonner」は「Toast」を基本としたコンポーネントのようです。 以下は、各名称について筆者の解釈です。 「Snackbar」は少ない情報を提供することを、軽食店に例えた。 「Toast」はトースターからパンが飛び上がる様子から。 「Flag」は注意を引く際の旗を上げる様子から。 「Sonner」はフランス語の「（警報などが）鳴り響く、知らせる」の意味の単語から。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post そのUIどう呼ぶ？チームの認識を揃えるためのコンポーネント名称整理 first appeared on SIOS Tech. Lab .

今号では、systemd.timer について、その仕組みや設定方法について説明します！ 前回と前々回の記事では cron についてご紹介したので、cron の代替として位置づけられている systemd.timer についても知っておくことで、よりタスク管理を理解できるかと思います。 systemd.timer とは systemd.timer とは、以前ご紹介した cron のように定期的にタスクを実行してくれる機能の名称です。RHEL9 以降、タスク管理の仕組みとして cron ではなく systemd.timer が標準として搭載されています。 ※ cron を使用することもできますが、デフォルトで配置されていたいくつかのジョブは systemd.timer へ移行しています。 cron は crond というデーモンとして動作するのに対し、systemd.timer は systemd が提供する機能のひとつ として動作します。 具体的な機能、設定方法についてはこの後ご説明しますが、systemd.timer は cron と比較して、書式がよりシンプルに変更されていたり、時間指定がより柔軟に設定できるようになっています。 Linux におけるタスク管理とは何か？については、cron の記事で詳しく説明していますので、ぜひご参照ください！ ・ 知っておくとちょっと便利！cron によるタスク管理1 ・ 知っておくとちょっと便利！cron によるタスク管理2 systemd.timer の設定ファイル、ディレクトリ構成 systemd.timer は、基本的に下記 2つのファイルで構成されます。 (※今回は RHEL9 の環境を前提に説明します) 　・ .timer ファイル ：スケジュールを定義します。 　・ .service ファイル ：実行するコマンドやスクリプトを定義します。 .timer ファイルで指定されたスケジュール (日時や間隔) に基づいて、対応する .service ファイルに記載された内容を処理します。 (例えば、A.timer には A.service というファイルが対応します) これらのファイルは、デフォルトは /usr/lib/systemd/system もしくは /etc/systemd/system 配下に配置されています。 なお、ユーザが独自の .timer や .service を定義したい場合は、通常 /etc/systemd/system 配下に各ファイルを配置します。 ちなみに、ファイルの内容は /usr/lib/systemd/system よりも /etc/systemd/system の方が優先されるため、既存の .timer や .service の内容に新しい処理を上書きしたい場合も、 /usr/lib/systemd/system 配下のファイルを直接編集するのではなく /etc/systemd/system 配下にファイルを配置することを推奨しています。 systemd.timer の設定方法 まずは既存のファイルの内容から、どのような設定ができるのかを見ていきたいと思います。 例として、logrotate.timer の内容を見てみます。 logrotate.timer の内容 [Unit] Description=Daily rotation of log files Documentation=man:logrotate(8) man:logrotate.conf(5) [Timer] OnCalendar=daily AccuracySec=1h Persistent=true [Install] WantedBy=timers.target [Unit] セクション timer ユニットの一般的な情報とドキュメントを定義します。 Description このユニットの概要です。 Documentation このユニットに関連するドキュメント情報です。 [Timer] セクション タスクがいつ、どのように動作するか定義します。 OnCalendar=daily タスク (この場合ですと、logrotate.service) が実行される頻度を指定します。 daily は毎日実行されることを意味します。 他には hourly（毎時）、weekly（毎週）、特定の日付や時刻 なども指定できます。 AccuracySec=1h 精度を指定します。1h は 1時間を意味します。 これは、タスクが OnCalendar で指定された時刻から最大 1時間の遅延を許容することを示します。 これにより、すべてのタスクが同時に起動してシステムに負荷をかけるのを避けることができます。 他には s（秒）、m（分）、d（日） なども指定できます。 Persistent=true この設定が true である場合、システムがシャットダウンしている間に実行されるはずだったタスクが、システム起動後直ちに実行されるようになります。 反対に、この設定が false である場合 (もしくは設定されていない場合、デフォルトでは false の動作となる)、スケジュールした時間になってもタスクが実行されなかった場合、そのタイミングでの実行は一度スキップされ、次回の実行タイミングまで待ちます。 [Install] セクション ユニットが有効化された時の動作を指定します。 WantedBy=timers.target systemctl enable (システム起動時に、当該のサービスを自動的に有効化する) である場合、どのタイミングで有効化されるかを決めます。 この設定が timers.target である場合、タイマー (定期実行されるタスク) の動作準備が完了したタイミングで、当該のサービスが起動されます。 .timer ファイルを使用している場合は、この設定を使用することが多いです。 他には multi-user.target （サービスの動作準備が完了したタイミング）、 graphical.target (GUI 環境が使用可能になったタイミング)、 なども指定できます。 systemd.timer に設定可能な項目は、他にもたくさんあります。 より詳しく知りたい方は、 man systemd.timer コマンドでマニュアルを確認してみてください。 次号について 次号では、 systemd.timer によるタスク管理の tips についてご紹介します！ ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 知っておくとちょっと便利！systemd.timer によるタスク管理1 first appeared on SIOS Tech. Lab .