## はじめに

ここ数年でAIコーディングツールは急速に進化し、開発現場での役割も大きく変わってきています。本記事では、これまでのAI活用の変遷を振り返りつつ、「AIが自律的にコーディングを行う」開発体制を実現するためのアイデアと、それを支える技術・ルールについて紹介します。

## これまでのAIの使い方

### 2025年頃：人間主体、AIはサポート役

この頃のAIは、あくまで人間の開発をサポートする存在でした。

- GitHub Copilot のサジェスト機能でコード補完してもらう
- 分からないことをチャットで質問する

主役はあくまで人間で、AIは「気の利く補助ツール」という位置づけです。コードの大部分は人間が書いており、AIの提案を取捨選択しながら開発を進めていました。

### 2026年〜：AI主体、人間がサポート役

過去記事「[AIエージェントを中心に据えた開発環境への移行](https://sterfield.co.jp/blog/ide-to-ai-agent/)」で紹介したように、Claude Code の活用が進んだことで主従関係が逆転しました。

- コーディングはAIが行い、人間は指示を出すだけ
- ISSUEを渡せば、実装からPR作成までAIが進めてくれる
- 複数のタスクを並列で走らせられるようになり、1スプリントあたりのISSUE消化量が2倍近くに増えた

人間は「コードを書く人」から「AIに指示を出し、成果物を確認する人」に変わりつつあります。

## これから実現したいこと

次のステップとして目指しているのが、**AIが自律的にコーディングを行う**開発体制です。

イメージとしては、AIを1人のプログラマーとしてチームに迎え入れる感覚です。役割分担は次のように考えています。

| 工程           | 担当                 |
| :------------- | :------------------- |
| 設計           | 人間（AIがサポート） |
| コーディング   | **AI**               |
| コードレビュー | 人間（AIがサポート） |
| 結合テスト     | 人間（AIがサポート） |

線引きの考え方はシンプルで、**機械的に検証できる工程はAIに渡せる、実環境での判断や責任を伴う工程は人間に残す**、という基準で工程を仕分けています。

![開発フロー図](https://cont.sterfield.co.jp/uploads/dev_flow_303eb03ad7.png)

人間が設計してISSUEを起票すると、AIがそれを拾って実装し、PRを作成する。人間はレビューと結合テストで品質を確認する。コーディング工程を丸ごとAIに任せることで、人間は設計や検証といった、より判断が求められる仕事に集中できます。

これまでの「人間がAIに指示を出しながら一緒にコーディングする」スタイルとの一番の違いは、**コーディング中に人間が張り付いていなくてもよい**ことです。指示を出して結果を待つのではなく、ISSUEを起票した時点で人間の手を離れ、次に人間が関わるのはPRのレビューから。この間、人間は別の設計やレビューを進められますし、AIも複数のISSUEを並行して処理できます。

## 実現するための技術

### スキルエンジニアリング

スキルエンジニアリングとは、**チームの開発手順や暗黙知を「スキル」としてAIに教え込む**取り組みです。

Claude Code にはスキルという仕組みがあり、定型化された手順をパッケージ化しておけます。人間が明示的に呼び出せるだけでなく、AIが「今のタスクに関係する」と判断すれば自律的に使ってくれるのが強力な点です。例えば次のようなスキルを整備しています。

- ISSUEに書かれた仕様を元に実装し、lintなどの静的解析ツール実行までを一気通貫で行うスキル
- 人間がPRに書き込んだ指摘を読み取り、修正するスキル

ポイントは、毎回プロンプトで細かく指示するのではなく、**一度作り込んだ手順を何度でも再利用できる**ことです。プロンプトの品質が人によってバラつく問題も、スキルとして標準化してしまえば解消できます。

人間のプログラマーに開発マニュアルを渡して教育するのと同じように、AIにもスキルという形で手順を渡す。スキルが充実するほど、AIは「指示待ち」ではなく「手順を知っている状態」で作業できるようになります。

### ループエンジニアリング

ループエンジニアリングとは、**AIが自分で結果を確認し、修正を繰り返せるフィードバックループを設計する**ことです。

AIに自走してもらうには、「実装して終わり」ではなく「実装 → 単体テスト → 失敗したら修正 → 再テスト」というループを自力で回せる環境が必要です。具体的には次のような整備を進めています。

- 単体テストやlint、型チェックをコマンド一発で実行できるようにしておく
- 「単体テストが通るまで修正を繰り返す」という完了条件を明示して指示する
- レビュー指摘への対応も「修正 → 単体テスト → コミット」のループとして定義する

判定基準が機械的にチェックできる形になっていれば、AIは人間の介入なしにループを回し続けられます。逆にここが曖昧だと、AIは中途半端な状態で作業を終えてしまいます。

さらに一歩進めて、「ISSUEが起票されたらAIが自動で着手する」「レビューコメントが付いたら自動で修正に入る」といった、**開発フロー全体を大きなループとして回す**仕組みも構想しています。ここまでできれば、AIは本当の意味で「自走するプログラマー」になります。

### コンテキストエンジニアリング

もうひとつ重要なのが、**AIが判断に必要な情報へ迷わずたどり着ける状態を作る**ことです。

CLAUDE.md にプロジェクトのルールや構成を記述しておく、設計の背景をISSUEに残しておく、ドキュメントを最新に保つ。人間の新メンバーがオンボーディング資料で立ち上がるのと同じで、コンテキストが整理されているほどAIのアウトプットの精度は上がります。

## ルール

技術だけでなく、運用ルールも重要です。AIに任せる範囲が広がるほど、「どこまで任せてよいか」「問題が起きたとき誰が責任を持つか」を明確にしておく必要があります。現時点で決めているルールを3つ紹介します。

### 人間がやること、AIがやることを守る

人間がやらないといけないことを、AIがやってはいけません。

設計・コードレビュー・結合テストは人間の担当です。もちろんAIにサポートしてもらうのは構いませんが、**最終的な確認と判断は必ず人間が行う**。この線引きを守ることで、システムの品質を担保します。

AIの出力をそのまま信じてマージしてしまうと、品質の責任の所在が曖昧になります。「AIが書いたコードでも、承認した人間が責任を持つ」という原則は崩さないようにしたいです。

### 開発環境を人間とAIで分ける

「AIがコーディング中だから人間が動作確認できない…」という事態を防ぎたいので、開発環境は人間とAIで分離します。

- Dockerでコンテナを分ける
- 作業ディレクトリを分ける（git worktree の活用など）
- 同じポートやDBをなるべく共有しない

AIを1人のプログラマーとして扱うなら、環境も1人分用意するのが自然な考え方です。人間のチームでも開発環境を取り合うことはないはずで、AIも例外ではありません。物理的にPCを分けてしまうのもアリかもしれません。

環境が分離されていれば、AIが多少大胆な変更を試しても人間の作業には影響しません。これは「AIに安心して任せられる範囲」を広げることにも繋がります。

### GitHubのユーザーを分ける

次の理由から、人間の意思でコミット・PRを出したのか、AIが自律的にやったのかを判別できるようにしておくべきだと考えています。

- コミット履歴やPR一覧を見れば、AIの成果物だと一目で分かる
- ブランチ保護でレビューを必須にしている場合、自分のアカウントでAIが作ったPRは自分では承認できないが、ユーザーが分かれていればAIのPRを人間がレビュー・承認するフローが自然に成立する

これらを実現するために、AIのコミット・PRは GitHub App 経由で行うことを考えています。トレーサビリティの確保は、AIに権限を渡すうえでの大前提です。

## おわりに

この構想を実現して、より迅速かつ品質の高いサービスを提供していく所存です。

「AIに任せる範囲を広げること」と「人間が品質を担保すること」は、ルールと仕組みさえ整えれば両立できるはずです。これからも目まぐるしく発展するAIに乗り遅れないようにしたいですね。

large_eyecatch.jpg

medium_eyecatch.jpg

small_eyecatch.jpg

thumbnail_eyecatch.jpg

eyecatch.jpg

AIをチームの一員として迎える開発体制の構想

## はじめに

データを分析する際、数値をそのまま眺めるだけでなく、グラフなどで可視化して視覚的に分かりやすくすることが重要です。
そんな時に活用できるのが、Google が提供する無料の BI ツール<a href="https://lookerstudio.google.com" target="_blank" rel="noopener noreferrer">Looker Studio</a>です。

今回は Looker Studio の基本的な使い方から、少し応用的な機能までを紹介します。

## Looker Studio とは？

Looker Studio（ルッカースタジオ）とは、Google が提供する無料の BI（ビジネスインテリジェンス）ツールです。

点在する様々なデータを一つに集約し、グラフや表、地図などを用いて視覚的に分かりやすいダッシュボードやレポートを自動で作成できます。

プログラミングなどの専門知識は不要で、直感的なマウス操作（ドラッグ＆ドロップ）で誰でも簡単に見やすいレポートを作成できるのが大きな特長です。

以前は「Google データポータル」という名称で知られていましたが、2022 年 10 月に Google のデータ分析プラットフォーム「Looker」ファミリーに統合され、現在の名称に変更されました。

## Looker Studio でできること

### 様々なデータソースへの接続

Google アナリティクス（GA4）や Google 広告、Google スプレッドシートはもちろん、YouTube アナリティクス、BigQuery（Google Cloud のデータウェアハウス）など、様々な Google サービスに接続できます。さらに、CSV ファイルのアップロードや、外部のデータベース（MySQL など）にも対応しており、社内外に散らばるデータを一元的に管理できます。

### データの可視化（ビジュアライゼーション）

棒グラフ、折れ線グラフ、円グラフ、地図、スコアカード、ピボットテーブルなど、多彩なグラフを作成できます。また、色やフォント、レイアウトを自由に変更し、ブランドイメージに合ったレポートを作成可能です。

### インタラクティブなレポート作成

静的なグラフを並べるだけでなく、閲覧者が期間を指定したり、特定の項目で絞り込み（フィルタ）をかけたりできる「動的なレポート」を作成できます。これにより、レポートの閲覧者は自身でデータを深掘りし、必要な情報を得ることができます。

### レポートの共有と共同編集

作成したレポートは、URL を共有するだけで、チームや顧客と簡単に共有できます。閲覧のみ、編集可能といった権限設定も柔軟に行えるため、安全なデータ共有が可能です。また、Google ドキュメントのように、複数人で同時にレポートを編集することもできます。

### レポート作成の自動化

一度レポートを作成すれば、元のデータソースが更新されると、Looker Studio のレポートも自動的に最新の状態に更新されます。これにより、「毎週」「毎月」といった定期的なレポート作成の手間から解放されます。

## Looker Studio の使い方（基本）

### データ追加

今回はサンプルとして、<a href="https://www.data.jma.go.jp/risk/obsdl/" target="_blank" rel="noopener noreferrer">気象庁のサイト</a>からダウンロードした、以下のような気象データを使用します。

![add_data_02.png](https://cont.sterfield.co.jp/uploads/add_data_02_1a8ab6e92a.png)

Looker Studio にデータを追加するには、ヘッダーメニューの「データを追加」ボタンをクリックします。

![add_data_01.png](https://cont.sterfield.co.jp/uploads/add_data_01_6b95f9f27b.png)

次に、接続したいデータソースのコネクタ（今回は Google スプレッドシート）を選択し、必要な設定を行って「追加」ボタンをクリックすると、データがレポートに追加されます。

![add_data_03.png](https://cont.sterfield.co.jp/uploads/add_data_03_a5b2662327.png)

スプレッドシートを選択した場合は、以下のように対象のシートやオプションを設定できます。

![add_data_04.png](https://cont.sterfield.co.jp/uploads/add_data_04_bea158b4f6.png)

### グラフ追加

上部のツールバーから「グラフを追加」をクリックし、表示されるリストから追加したいグラフの種類を選択します。そして、レポートのキャンバス上の任意の場所をクリックするとグラフが配置されます。グラフの種類は後からでも変更可能です。

![add_graph_01.png](https://cont.sterfield.co.jp/uploads/add_graph_01_afdb9d1f57.png)

### ディメンションと指標

Looker Studio では、主に「ディメンション」と「指標」を使ってグラフを作成します。

- **ディメンション**: データをどのような切り口で見るかを定義する項目です（例：日付、商品カテゴリ、地域など）。グラフでは主に軸として使われます。
- **指標**: 集計・計算される具体的な数値データのことです（例：売上、ユーザー数、気温など）。グラフでは主に値として使われます。

例えば、折れ線グラフでディメンションを「年月日」、指標を「平均気温(℃)」に設定すると、以下のような時系列グラフが作成されます。

![dimension_metric_01.png](https://cont.sterfield.co.jp/uploads/dimension_metric_01_11a1ff756e.png)

### コントロール

コントロールは、閲覧者がレポートの表示内容を動的に変更できるようにする機能です。例えば、表示するデータの期間を任意に変更したり、特定の流入経路だけのデータを表示するなど、インタラクティブな操作が可能になります。

コントロールは、上部ツールバーの「コントロールを追加」から追加できます。

![control_01.png](https://cont.sterfield.co.jp/uploads/control_01_a60e4026c4.png)

先ほど作成したグラフに「期間設定」のコントロールを追加すると、以下のように閲覧者が表示期間を自由に変更できるようになります。

![control_02.png](https://cont.sterfield.co.jp/uploads/control_02_dbb96f3ee0.png)

### レポートの共有

画面右上の「共有」ボタンから、作成したレポートを他のユーザーと共有できます。共有する際には、「閲覧者」「編集者」といった権限をユーザーごとに設定できます。

![share_01.png](https://cont.sterfield.co.jp/uploads/share_01_f0f4339505.png)

## Looker Studio の使い方（応用）

### スタイル調整

各グラフや表を選択した際に表示される「スタイル」タブから、タイトル、フォント、色、凡例の表示などを細かく調整できます。レポート全体のデザインを統一したり、ブランドイメージに合わせたりすることが可能です。

![layout_01.png](https://cont.sterfield.co.jp/uploads/layout_01_eb5dccc5a9.png)

### データ統合

データ統合は、複数のデータソースを 1 つのデータソースにまとめることができる機能です。これは、SQL の JOIN のように、異なるデータソースを共通のキー（結合キー）で紐づける機能です。

今回は例として、<a href="https://www.data.jma.go.jp/risk/obsdl/" target="_blank" rel="noopener noreferrer">気象庁のサイト</a>から追加でダウンロードした、別の気象データを使用して説明します。

![join_02.png](https://cont.sterfield.co.jp/uploads/join_02_a1c65241db.png)

メニューの「リソース」→「統合を管理」から統合の管理画面に移動し、「統合を追加」をクリックします。

![join_01.png](https://cont.sterfield.co.jp/uploads/join_01_b169ba434f.png)

結合するテーブルを選択し、それぞれのテーブルから使用するディメンションと指標を設定します。

![join_03.png](https://cont.sterfield.co.jp/uploads/join_03_97eeb6d6c3.png)

次に「結合を設定」から、結合方法（内部、左外部など）や結合条件（キーとなるフィールド）を設定します。

![join_04.png](https://cont.sterfield.co.jp/uploads/join_04_ed2ec6ee9f.png)

統合して作成された新しいデータソースをグラフのデータソースとして選択することで、複数のデータソースをまたいだグラフが作成できます。

![join_05.png](https://cont.sterfield.co.jp/uploads/join_05_e196c456c1.png)

### 計算フィールド

計算フィールドは、既存の項目をもとに、演算子、関数、正規表現などを使って、独自のディメンションや指標を定義できる機能です。

ここでは例として、日ごとの寒暖差（最高気温 - 最低気温）を算出する計算フィールドを作成します。

メニューの「リソース」→「追加済みのデータソースの管理」からデータソースの管理画面に移動し、計算フィールドを追加したいデータソースの「編集」をクリックします。

![calc_01.png](https://cont.sterfield.co.jp/uploads/calc_01_cb7e01df8b.png)

次に「フィールドを追加」→「計算フィールドを追加」をクリックします。

![calc_02.png](https://cont.sterfield.co.jp/uploads/calc_02_176eeb1325.png)

![calc_03.png](https://cont.sterfield.co.jp/uploads/calc_03_1719d9110e.png)


フィールド名と計算式を入力します。計算式には、四則演算や CASE 文、さらには様々な<a href="https://cloud.google.com/looker/docs/studio/function-list" target="_blank" rel="noopener noreferrer">関数</a>を使用できます。

![calc_04.png](https://cont.sterfield.co.jp/uploads/calc_04_b8706b2ab0.png)

作成した計算フィールドは、通常のフィールドと同様に、グラフのディメンションや指標として利用できます。

![calc_05.png](https://cont.sterfield.co.jp/uploads/calc_05_4b0d576972.png)

## まとめ

今回は、Google が提供する無料の BI ツール「Looker Studio」について、基本的な使い方から応用的な機能までを紹介しました。
Looker Studio を活用することで、プログラミングの知識がなくても、様々なデータを可視化し、示唆に富んだインタラクティブなレポートを簡単に作成できます。

主なポイントは以下の通りです。

- **多様なデータソース接続**: Google 系のサービスはもちろん、CSV や外部 DB など、様々なデータに接続可能。
- **直感的な操作**: ドラッグ＆ドロップでグラフや表を自由に配置し、レポートを作成。
- **動的なレポート**: フィルタや期間設定などのコントロールを追加し、インタラクティブな分析を実現。
- **高度な機能**: データ統合や計算フィールドにより、より深いデータ分析が可能。
- **簡単な共有と自動更新**: 作成したレポートは URL で簡単に共有でき、データは自動で最新の状態に保たれる。

本記事が、Looker Studio を使い始めるきっかけとなれば幸いです。

## 参考

- <a href="https://www.dsk-cloud.com/blog/gc/what-is-google-looker-studio" target="_blank" rel="noopener noreferrer">https://www.dsk-cloud.com/blog/gc/what-is-google-looker-studio</a>
- <a href="https://www.dsk-cloud.com/blog/gc/basic-usage-of-looker-studio" target="_blank" rel="noopener noreferrer">https://www.dsk-cloud.com/blog/gc/basic-usage-of-looker-studio</a>
- <a href="https://inhouse-plus.jp/reporting/google-dataportal-guide/" target="_blank" rel="noopener noreferrer">https://inhouse-plus.jp/reporting/google-dataportal-guide/</a>
- <a href="https://inhouse-plus.jp/reporting/looker-studio-add-components/" target="_blank" rel="noopener noreferrer">https://inhouse-plus.jp/reporting/looker-studio-add-components/</a>
- <a href="https://inhouse-plus.jp/reporting/calculated-field/" target="_blank" rel="noopener noreferrer">https://inhouse-plus.jp/reporting/calculated-field/</a>
- <a href="https://www.plan-b.co.jp/blog/seo/31762/" target="_blank" rel="noopener noreferrer">https://www.plan-b.co.jp/blog/seo/31762/</a>
- <a href="https://cloud.google.com/looker/docs/studio/add-data-to-a-report" target="_blank" rel="noopener noreferrer">https://cloud.google.com/looker/docs/studio/add-data-to-a-report</a>
- <a href="https://www.uncovertruth.co.jp/dx-accelerator/blog/articles/looker_studio/003/" target="_blank" rel="noopener noreferrer">https://www.uncovertruth.co.jp/dx-accelerator/blog/articles/looker_studio/003/</a>
- <a href="https://note.com/tscloud_jp/n/n357732008126" target="_blank" rel="noopener noreferrer">https://note.com/tscloud_jp/n/n357732008126</a>
- <a href="https://it-pocket.com/lookerstudio/797/" target="_blank" rel="noopener noreferrer">https://it-pocket.com/lookerstudio/797/</a>
- <a href="https://www.principle-c.com/column/lookerstudio/looker-studio-data-blending-techniques/" target="_blank" rel="noopener noreferrer">https://www.principle-c.com/column/lookerstudio/looker-studio-data-blending-techniques/</a>


small_eyecatch.png

thumbnail_eyecatch.png

eyecatch.png

Looker Studio の使い方

## はじめに

GitHub Actions を利用する際、似たような処理を何度も記述していませんか？ ワークフローが複雑になるにつれて、メンテナンスコストが増大し、変更への対応も煩雑になりがちです。  
この記事では、GitHub Actions の処理を共通化することで、これらの問題を解決するための手法を、具体的な例を交えながら解説します。

## 再利用可能なワークフローによる共通化

まずは、<a href="https://docs.github.com/ja/actions/sharing-automations/reusing-workflows" target="_blank" rel="noopener noreferrer">ワークフローの再利用</a>を活用した共通化の方法を説明します。

**on** キーワードで、ワークフローを直接トリガーするイベントの代わりに **workflow_call** イベントを指定すると、別のワークフローからそのワークフローを呼び出すことができます。

**例: .github/workflows/deploy.yml**

```yaml
name: Deploy to Production

on:
  workflow_call: # ワークフローを再利用可能にするイベント
    inputs: # 呼び出し元のワークフローからパラメータを受け取る
      environment:
        required: true
        type: string
      target_host:
        required: true
        type: string

    secrets: # シークレットを受け渡す場合は明示的に指定する必要がある
      SSH_PRIVATE_KEY:
        required: true

    outputs: # 処理結果を呼び出し元のワークフローに返す
      deployment_status:
        description: "The status of the deployment job"
        value: ${{ jobs.deploy.outputs.status }}

jobs:
  deploy:
    runs-on: ubuntu-latest
    outputs:
      status: ${{ job.status }}
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
      - name: Set up SSH
        run: |
          mkdir -p ~/.ssh
          echo "${{ secrets.SSH_PRIVATE_KEY }}" | tr -d '\r' > ~/.ssh/id_rsa
          chmod 600 ~/.ssh/id_rsa
          ssh-keyscan -H ${{ inputs.target_host }} >> ~/.ssh/known_hosts
      - name: Deploy to server
        run: rsync -avz -e "ssh -i ~/.ssh/id_rsa" ./ ${{ inputs.environment }}@${{ inputs.target_host }}:/var/www/html
```

上記のワークフローを呼び出すには、以下のように記述します。  
**jobs** セクションで新しいジョブを定義し、そのジョブ内で **uses** キーワードを使って、再利用可能なワークフローのパスを指定します。

**例: .github/workflows/deploy.yml**

```yaml
name: Deploy Application

on:
  push:
    branches: [main]

jobs:
  deploy-staging:
    uses: ./.github/workflows/deploy.yml # 共通化したワークフローのパス
    with: # 呼び出し元の inputs で定義した値を渡す
      environment: "staging"
      target_host: "staging.example.com"
    secrets: # 呼び出し元の secrets で定義した値を渡す
      SSH_PRIVATE_KEY: ${{ secrets.STAGING_SERVER_SSH_KEY }}

  deploy-production:
    uses: ./.github/workflows/deploy.yml
    with:
      environment: "production"
      target_host: "prod.example.com"
    secrets:
      SSH_PRIVATE_KEY: ${{ secrets.PRODUCTION_SERVER_SSH_KEY }}

  post-deployment-check:
    needs: [deploy-staging, deploy-production]
    runs-on: ubuntu-latest
    steps:
      - name: Check deployment status
        # 呼び出し元の outputs で定義した値を受け取る
        run: |
          echo "Staging deployment status: ${{ jobs.deploy-staging.outputs.deployment_status }}"
          echo "Production deployment status: ${{ jobs.deploy-production.outputs.deployment_status }}"
```

## Composite Action による共通化

次に、<a href="https://docs.github.com/ja/actions/sharing-automations/creating-actions/creating-a-composite-action" target="_blank" rel="noopener noreferrer">Composite Action</a> を活用した共通化の方法を説明します。

Composite Action は、通常のワークフローとは異なり、フォルダ階層は自由ですが、ファイル名は **action.yml** にする必要があります。 <a href="https://www.google.com/search?q=https://docs.github.com/ja/actions/sharing-automations/creating-actions/creating-a-composite-action%23creating-a-composite-action-within-the-same-repository" target="_blank" rel="noopener noreferrer">GitHub Docs</a> では、**.github/actions/{任意の名前}/action.yml** というフォルダ構成で作成することが推奨されています。

また、現時点では secrets の受け渡しはできません。 <a href="https://www.google.com/search?q=https://github.com/actions/runner/blob/main/docs/adrs/0549-composite-run-steps.md%23secrets" target="_blank" rel="noopener noreferrer">今後サポートされる予定</a> のようです。

**例: .github/actions/test/action.yml**

```yaml
name: "Node.js Test"
description: "Test implemented in node.js"
inputs: # 呼び出し元のワークフローからパラメータを受け取る
  working-directory:
    description: "Path to the working directory"
    required: true

outputs: # 処理結果を呼び出し元のワークフローに返す
  test_report_path:
    description: "Path to the test report file (if generated)"
    value: ${{ steps.report.outputs.test_report_path }}

runs:
  using: "composite" # Composite Action であることを宣言
  steps:
    - name: Checkout code
      uses: actions/checkout@v4

    - name: Set up Node.js ${{ inputs.node_version }}
      uses: actions/setup-node@v4
      with:
        node-version: 22.X

    - name: Install dependencies
      run: npm install
      shell: bash # コマンド実行には shell を明示的に指定する
      working-directory: ${{ inputs.working-directory }}

    - name: Run tests
      run: npm run test --report_output=./test-results.xml
      shell: bash
      working-directory: ${{ inputs.working-directory }}

    - name: Set test report output
      id: report
      run: echo "test_report_path=$(pwd)/test-results.xml" >> "$GITHUB_OUTPUT"
      shell: bash
      working-directory: ${{ inputs.working-directory }}
```

上記の Composite Action を実行するには、以下のように記述します。

**例: .github/workflows/test.yml**

```yaml
name: Test Application

on:
  push:
    branches: [main]

jobs:
  test-app1:
    runs-on: ubuntu-latest
    steps:
      - name: Test
        id: test
        uses: ./.github/actions/test # 実行する Composite Action のディレクトリ
        with:
          working-directory: "./app1" # 呼び出し元の inputs で定義した値を渡す

      - name: Output test results
        # 呼び出し元の outputs で定義した値を受け取る
        run: cat ${{ steps.test.outputs.test_report_path }}

  test-app2:
    runs-on: ubuntu-latest
    steps:
      - name: Test
        id: test
        uses: ./.github/actions/test
        with:
          working-directory: "./app2"

      - name: Output test results
        run: cat ${{ steps.test.outputs.test_report_path }}
```

## どちらの方法を選ぶべきか

再利用可能なワークフローは、ワークフロー全体を共通化する仕組みです。 GitHub Actions は job 単位で別々のコンテナで実行されるため、共通処理内で変更した内容 (生成したファイルやインストールしたパッケージなど) は、後続の処理に引き継ぐことができません。

一方、Composite Action は step 単位で共通化するため、共通処理内で変更した内容は後続の処理に引き継がれます。 また、再利用可能なワークフローは実行のたびに新しいコンテナを立ち上げる必要があるため、単純で実行回数の多い処理の場合は Composite Action を利用することで、処理時間の短縮と料金の節約につながります。

以上の点を考慮すると、以下のように使い分けるのが適切です。

**再利用可能なワークフロー**

- 共通処理内で変更した内容を後続の処理に引き継ぐ必要がない場合（例: ビルド、デプロイ処理、セキュリティスキャンなど）
- 環境を変えて (Node.js のバージョンなど) 共通処理を実行する場合

**Composite Action**

- 共通処理内で変更した内容を後続の処理に引き継ぐ必要がある場合（例: 依存関係のインストール、環境設定、複数のコマンド実行など）
- 単純または実行回数の多い処理（例: テスト結果やデプロイ結果の出力、チャット通知など）

## まとめ

この記事では、GitHub Actions におけるワークフローの共通化手法として、再利用可能なワークフローと Composite Action の 2 つを紹介しました。

どちらの手法を選択するかは、共通化したい処理の粒度や、処理内で変更した内容を後続の処理で利用する必要があるかどうかなどを考慮して判断する必要があります。 これらの手法を適切に活用することで、ワークフローのメンテナンス性を向上させ、開発効率を高めていきましょう！

## 参考サイト

- <a href="https://docs.github.com/ja/actions/sharing-automations/reusing-workflows" target="_blank" rel="noopener noreferrer">https://docs.github.com/ja/actions/sharing-automations/reusing-workflows</a>
- <a href="https://docs.github.com/ja/actions/sharing-automations/creating-actions/creating-a-composite-action" target="_blank" rel="noopener noreferrer">https://docs.github.com/ja/actions/sharing-automations/creating-actions/creating-a-composite-action</a>
- <a href="https://zenn.dev/moaikids/articles/32363c5386978e" target="_blank" rel="noopener noreferrer">https://zenn.dev/moaikids/articles/32363c5386978e</a>
- <a href="https://zenn.dev/kinjosan/articles/bd82e07aa69080" target="_blank" rel="noopener noreferrer">https://zenn.dev/kinjosan/articles/bd82e07aa69080</a>

small_github.png

thumbnail_github.png

github.png

GitHub Actions 共通化手法

## はじめに

Google Cloud 上でバッチ処理を行う際に、[Cloud Run jobs](https://cloud.google.com/run/docs/create-jobs)を使用したので紹介します。
本記事では、他サービスとの比較と[Cloud Run jobs](https://cloud.google.com/run/docs/create-jobs)の使い方について説明します。

## Google Cloud でバッチ処理できるサービス

Cloud Run jobs を使用するにあたって、他のサービスについても調べたのでそれぞれの特徴をまとめました。

### [Cloud Functions](https://cloud.google.com/functions)

様々なイベントをトリガーにできるので、特定のイベントが発生したときに動かしたいバッチ処理の場合は Cloud Functions を使うと良さそうです。
例えば [Cloud Storage](https://cloud.google.com/storage) に画像がアップロードされた際に、自動的にサムネイルを作成したり、画像にフィルターをかけたりする処理が簡単に作れます。
しかし、最大実行時間に制限(60 分)があるため長時間の処理には適さない場合があります。

### [Batch](https://cloud.google.com/batch)

大規模なバッチ処理ワークロードを効率的に実行するためのフルマネージドなサービスです。
高性能コンピューティング（HPC）、機械学習、データ処理など、さまざまな種類のバッチジョブをスケーラブルかつ柔軟に実行できます。
また、最大実行時間に制限が無いので長時間の処理に適しています。
しかし、Cloud Functions や Cloud Run jobs よりも設定が複雑になってしまうので採用しませんでした。

### [Cloud Run jobs](https://cloud.google.com/run/docs/create-jobs)

Cloud Run の一機能で、バッチ処理や非同期タスクの実行に特化したサービスです。
最大実行時間に制限がありますが、24 時間実行できるのでほとんどのバッチ処理は問題ないでしょう。

## Cloud Run jobs の基本要素

### Cloud Run jobs のリソース構造

Cloud Run jobs は以下のようなリソースで構成されています。<br>
 ![リソース構造](https://cont.sterfield.co.jp/uploads/resource_a778e2a692.jpg) 

### ジョブ (Job)

実行したいタスクの全体像を定義するルートリソースです。

ジョブでは以下の項目を設定できます。

- コンテナイメージ
- タスク数
- 並列実行数
- リソース(各タスクに割り当てる CPU やメモリなどのリソース量)
- 環境変数
- サービスアカウント

### タスク (Task)

ジョブによって定義されたタスクのインスタンスです。
タスクはジョブに設定された数だけ実行されます。コンテナインスタンスを 1:1 で用意し、コンテナインスタンスごとの進捗を管理します。タスクがエラーで終了した場合は、タスク単位で再実行もできます。

### 実行 (Execution)

タスクの実行履歴です。
ジョブの設定に応じてタスクを実行し、全てのタスクが完了するまでの状態を管理します。1 度作成した実行は、何度でも再実行が可能です。

## Cloud Run jobs の作成・実行方法

### サンプルアプリケーションの用意

以下のコードを適当なフォルダに作成します

環境変数に`SLEEP_MS`を設定すると、設定した時間だけスリープするようになり、時間のかかる処理を再現できます。
`FAIL_RATE`を設定すると、指定した確率でジョブがエラーになり、エラー時の挙動を確認できます。

main.js

```js
// Retrieve Job-defined env vars
const { CLOUD_RUN_TASK_INDEX = 0, CLOUD_RUN_TASK_ATTEMPT = 0 } = process.env;
// Retrieve User-defined env vars
const { SLEEP_MS, FAIL_RATE } = process.env;

// Define main script
const main = async () => {
  console.log(
    `Starting Task #${CLOUD_RUN_TASK_INDEX}, Attempt #${CLOUD_RUN_TASK_ATTEMPT}...`
  );
  // Simulate work
  if (SLEEP_MS) {
    await sleep(SLEEP_MS);
  }
  // Simulate errors
  if (FAIL_RATE) {
    try {
      randomFailure(FAIL_RATE);
    } catch (err) {
      err.message = `Task #${CLOUD_RUN_TASK_INDEX}, Attempt #${CLOUD_RUN_TASK_ATTEMPT} failed.\n\n${err.message}`;
      throw err;
    }
  }
  console.log(`Completed Task #${CLOUD_RUN_TASK_INDEX}.`);
};

// Wait for a specific amount of time
const sleep = (ms) => {
  return new Promise((resolve) => setTimeout(resolve, ms));
};

// Throw an error based on fail rate
const randomFailure = (rate) => {
  rate = parseFloat(rate);
  if (!rate || rate < 0 || rate > 1) {
    console.warn(
      `Invalid FAIL_RATE env var value: ${rate}. Must be a float between 0 and 1 inclusive.`
    );
    return;
  }

  const randomFailure = Math.random();
  if (randomFailure < rate) {
    throw new Error("Task failed.");
  }
};

// Start script
main().catch((err) => {
  console.error(err);
  process.exit(1); // Retry Job Task by exiting the process
});
```

package.json

```json
{
  "main": "main.js",
  "scripts": {
    "start": "node main.js"
  },
  "engines": {
    "node": ">=20.0.0"
  }
}
```

Dockerfile

```Dockerfile
FROM node:20
WORKDIR /app
COPY . .
RUN npm install
CMD [ "npm", "start" ]
```

### コンテナをプッシュ

次のコマンドで [Artifact Registry](https://cloud.google.com/artifact-registry) にコンテナをプッシュします。`${REGION}`と`${PROJECT_ID}`は各自で置き換えてください。

```
gcloud builds submit --tag ${REGION}-docker.pkg.dev/${PROJECT_ID}/gcr.io/job-sample
```

### ジョブを作成

今回は、以下の Cloud Run のコンソールから作成します。<br>
https://console.cloud.google.com/run/jobs

「ジョブの作成」をクリックします。<br>
 ![ジョブの作成ボタン](https://cont.sterfield.co.jp/uploads/job_create_1_691d934c36.png) 

「コンテナ イメージの URL」に先ほど作成したコンテナを選択します。
イメージ名が自動的に設定されます。
リージョンやタスク数はお好みで設定して下さい。<br>
 ![ジョブの詳細](https://cont.sterfield.co.jp/uploads/job_create_2_c2c65e6a14.png) 

### ジョブの実行

「実行」をクリックし、ジョブを開始します。<br>
 ![実行ボタン](https://cont.sterfield.co.jp/uploads/job_create_3_3049895faf.png)

しばらく経つと、全てのタスクが完了し、実行が完了します。実行の詳細を開くとタスクが完了していることが確認でき、各タスクのログ等が確認できます。<br>
 ![タスク](https://cont.sterfield.co.jp/uploads/job_create_4_6281075873.png) 

### 作成した Job を定期実行する方法

「トリガー」タブを選択し、「スケジューラ トリガーを追加」をクリックします。<br>
 ![トリガー追加ボタン](https://cont.sterfield.co.jp/uploads/scheduler_1_1e1f8511c4.png) 

頻度を unix-cron 形式で選択します。
今回は 5 分ごと(`*/5****`)に実行してみます。<br>
 ![トリガー詳細](https://cont.sterfield.co.jp/uploads/scheduler_2_f70181ea5b.png) 

指定した通り、5 分ごとにジョブが実行されました。<br>
 ![ジョブ一覧](https://cont.sterfield.co.jp/uploads/scheduler_3_69acf4aa19.png) 

## まとめ

今回は Cloud Run jobs について説明しましたが、各サービスのメリット・デメリットを比較し、要件に合った最適なサービスを選択することが重要です。
今後、他サービスにも触れる機会がありましたら紹介したいです。

## 参考

- https://speakerdeck.com/satohjohn/gcptenohatutichu-li-hatanwokao-etemiru
- https://zenn.dev/google_cloud_jp/articles/cloudrun-jobs-basic
- https://cloud.google.com/run/docs/quickstarts/jobs/build-create-nodejs

small_cloud-run.png

thumbnail_cloud-run.png

cloud-run.png

Cloud Run jobs を利用したバッチ処理

## はじめに

Prisma でデータベーススキーマを書く際に、[ZenStack](https://zenstack.dev/) というフレームワークが便利だったので紹介します。
ZenStack にはさまざまな機能がありますが、今回はデータベーススキーマの定義について重点的に説明します。

## ZenStack とは

ZenStack は、Node.js と TypeScript 向けのフルスタック開発フレームワークです。データベーススキーマを定義するだけで、フロントエンドとバックエンドの実装を自動的に生成できます。
ZenStack は、Prisma ORM をベースとして構築されているので、Prisma のすべての機能を利用できます。

## ZenStack を使用したデータベーススキーマの書き方

ZenStack では、[ZModel](https://zenstack.dev/docs/reference/zmodel-language) というデータモデリング言語でデータベーススキーマを作成します。
[Prisma Schema](https://www.prisma.io/docs/orm/prisma-schema) をベースとしているので、基本的な文法は Prisma Schema と同じように書くことができます。

また、VSCode 向けに[ZenStack の拡張機能](https://marketplace.visualstudio.com/items?itemName=ZenStack.ZenStack)が用意されています。
エラーチェックやコード補完をしてくれるので、ZModel でデータベーススキーマを書く際はインストールしておくと便利です。

## ZModel を Prisma Schema に変換する方法

ZModel で定義したデータベーススキーマを Prisma で使用するには、以下のコマンドで ZModel → Prisma Schema に変換する必要があります。

```
npx zenstack generate
```

変換元と変換先のファイルパスを指定したい場合は package.json に以下の設定を記述します。

```
  "zenstack": {
    "schema": "[変換元のZModelファイル(デフォルト：./schema.zmodel)]"
    "prisma": "[変換先のSchemaファイル(デフォルト：./prisma/schema.prisma)]",
  },
```

## ZModel の便利機能

Zmodel で利用できる便利な機能をいくつか紹介します。

### abstract

ベースとなる抽象化 model を作成し、各項目を継承できます。
登録日時などのように、各テーブルに共通なフィールドがある場合に使うと便利です。

```
generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "postgresql"
  url = env("DATABASE_URL")
}

abstract model Base {
  id Int @id @default(autoincrement())
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt
}

model User extends Base {
  email String @unique
  name String
  posts Post[]
}

model Post extends Base {
  title     String
  content   String?
  published Boolean @default(false)
  author    User? @relation(fields:  [authorId], references: [id])
  authorId  Int?
}
```

上記 ZModel を変換すると、以下のような Prisma Schema が生成されます。

```
datasource db {
    provider = "postgresql"
    url = env("DATABASE_URL")
}

generator client {
    provider = "prisma-client-js"
}

model User {
    id Int @id() @default(autoincrement())
    createdAt DateTime @default(now())
    updatedAt DateTime @updatedAt()
    email String @unique()
    name String
    posts Post[]
}

model Post {
    id Int @id() @default(autoincrement())
    createdAt DateTime @default(now())
    updatedAt DateTime @updatedAt()
    title String
    content String?
    published Boolean @default(false)
    author User? @relation(fields: [authorId], references: [id])
    authorId Int?
}
```

### ファイル分割

1 ファイルで全てのスキーマを定義すると、スキーマが増えてくるにつれて管理が大変になると思います。
そこで、ZModel ファイルを分割してスキーマ定義する方法を紹介します。

今回の例では ZModel ファイルを以下のように分割してみます。

- base.zmodel: generator や datasource を記述するファイル
- user.zmodel: user のスキーマ
- post.zmodel: post のスキーマ

base.zmodel

```
// importに分割したZmodelファイルをすべて記載します
import "user"
import "post"

generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "postgresql"
  url = env("DATABASE_URL")
}
```

user.zmodel

```
model User {
  id Int @id() @default(autoincrement())
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt()
  email String @unique()
  name String
  posts Post[]
}
```

post.zmodel

```
model Post {
  id Int @id() @default(autoincrement())
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt()
  title String
  content String?
  published Boolean @default(false)
  author User? @relation(fields: [authorId], references: [id])
  authorId Int?
}
```

変換元のファイルを「base.zmodel」に指定して変換すると、以下のような Prisma Schema が生成されます。

```
datasource db {
    provider = "postgresql"
    url = env("DATABASE_URL")
}

generator client {
    provider = "prisma-client-js"
}

model User {
    id Int @id() @default(autoincrement())
    createdAt DateTime @default(now())
    updatedAt DateTime @updatedAt()
    email String @unique()
    name String
    posts Post[]
}

model Post {
    id Int @id() @default(autoincrement())
    createdAt DateTime @default(now())
    updatedAt DateTime @updatedAt()
    title String
    content String?
    published Boolean @default(false)
    author User? @relation(fields: [authorId], references: [id])
    authorId Int?
}
```

### 属性

ZModel でのみ使用できる属性を一部紹介します。
詳しい内容は[公式リファレンス](https://zenstack.dev/docs/reference/zmodel-language#attribute)をご確認ください。

#### @password

データベースにハッシュ化した文字列を登録/更新します。
内部的には[bcryptjs](https://github.com/dcodeIO/bcrypt.js#readme)ライブラリを使用してハッシュ化しているようです。

以下のように引数が定義されていて、saltLength からハッシュのコストを設定したり、salt の設定も可能です。

```
@password(saltLength: Int?, salt: String?)
```

#### @omit

この属性を指定したフィールドはデータ呼び出し時に値が取得されなくなります。
上記の@password と組み合わせて使用すると便利です。

## まとめ

最近リリースされたばかりのフレームワークだからなのか、情報量が少なく調べるのに苦労しました。
今回は ZModel を重点的に紹介しましたが、他にも魅力的な機能がたくさんあるライブラリなので、次の機会に紹介したいと思います！

## 参考

- https://ZenStack.dev/
- https://www.ey-office.com/blog_archive/2023/09/20/i-learned-a-little-more-about-zenstack-zmodel-is-useful/
- https://www.Prisma.io/docs/orm/Prisma-schema/data-model/models
- https://zenn.dev/smish0000/articles/f1a6f463417b65


thumbnail_logo.png

logo.png

ZenStack を使用してデータベーススキーマを作成する

## はじめに

2023 年 10 月に[Gmail のメール送信者ガイドライン](https://support.google.com/mail/answer/81126)がアップデートされました。<br>
2024 年 2 月から適用されるので、ギリギリになってしまいましたが、ガイドラインからどのような設定が必要なのかをまとめました。

## 対象となる送信者

個人用 Gmail アカウントに 1 日あたり 5,000 件以上のメールを送信している場合が対象になります。<br>
個人用 Gmail アカウントとは、末尾が @gmail.com または @googlemail.com のアカウントを指します。<br>
現在のガイドラインでは Google Workspace を利用しているアカウントは対象外ですが、今後のアップデートで Google Workspace を利用しているアカウントも対象になる可能性があるので、個人用 Gmail アカウントにメールを送信していなくても今のうちに設定しておくことをおすすめします。

### 5,000 件のカウント方法について

同じプライマリドメインから送信されたすべてのメールが対象になります。<br>
例えば、1 日あたり@example.com から 3,000 件、@sub.example.com から 2,500 件送信している場合、5,500 件とカウントされます。

## ガイドラインの適応スケジュール

[Google の FAQ](https://support.google.com/a/answer/14229414)によると、以下のスケジュールで順次対応するようです。

### 2024 年 2 月

要件を満たしていないメールのうち、一部のメールが一時的なエラーを受け取るようになります。

### 2024 年 4 月

要件を満たしていないメールの拒否を開始します。<br>
一部のメールから拒否をし始めて、徐々にその割合を増加します。

### 2024 年 6 月

全ての商用メール、プロモーションメールに、ワンクリックでの登録解除を実装する必要があります。

## 対応が必要な内容

今回のガイドラインで対応が必要な項目は下記の通りです。

- 送信ドメインで SPF と DKIM を設定する
- 送信元のドメイン、 IP アドレスに正引き、逆引き DNS レコードを設定する
- メールの送信に TLS 接続を使用する
- [Postmaster Tools](https://gmail.com/postmaster/)で報告される迷惑メール率を 0.1%未満に維持する
- [RFC 5322](https://datatracker.ietf.org/doc/html/rfc5322)に準拠する形式でメールを作成する
- DMARC を設定する
- メーリングリスト等、転送する場合は ARC ヘッダを追加する
- ヘッダ From ドメインは SPF、DKIM ドメインと一致させる
- ワンクリックでの配信停止に対応する

## DNS レコードについて

DNS（Domain Name System）とは、インターネット上でドメイン名と IP アドレスを紐づけるためのシステムです。<br>
今回のガイドラインでは、送信元ドメインの A レコードから送信元 IP アドレスを参照できるようにし（正引き）、逆に送信元 IP アドレスの PTR レコードから送信元ドメインを参照できるようにする（逆引き）必要があります。

### DNS レコードの例

「example.com」から IP アドレス「172.16.0.1」を参照（正引き）する設定は以下のように記述します。

```
example.com. IN A 172.16.0.1
```

IP アドレス「172.16.0.1」から「example.com」を参照（逆引き）する設定は以下のように記述します。

```
1.0.16.172.in-addr.arpa. IN PTR example.com
```

「1.0.16.172.in-addr.arpa.」の部分は、以下の手順で変換したものを記載します。

1. IP アドレスの各オクテットを逆順に並べる
   「172.16.0.1」の場合は「1.0.16.172」のようにします
2. IP アドレスが IPv4 形式の場合は、後ろに「.in-addr.arpa.」を記述する
   ※ IPv6 形式の場合は「.ip6.arpa.」を付与します

## SPF レコードについて

SPF（Sender Policy Framework）とは、電子メールの送信元ドメインが詐称されていないかを検査するための仕組みです。<br>
メールを受信する際に受信側は送信側の DNS ヘ SPF レコードを要求し、返答された SPF レコードが受信したメールの実際の送信元 IP アドレスと一致するかを確認します。<br>
2 つの IP アドレスが一致すれば認証が成功し、ドメインの管理者が意図した通りのメールサーバーから届けられた正しい送信元からのメールであることが証明できます。

### SPF レコードの例

「example.com」の IP アドレス「172.16.0.1」から送信されたメールアドレスのみを認証する場合は、以下のように記述します。

```
example.com. IN TXT "v=spf1 ip4:172.16.0.1 -all"
```

## DKIM レコードについて

DKIM（DomainKeys Identified Mail）とは、電子メールの送信元ドメインの認証技術の一種です。<br>
メール送信者が秘密鍵を使ってメールに署名し、受信者は送信元ドメインの公開鍵を使って、この署名の正当性を検証します。<br>
署名が正当であれば、そのメールは送信元ドメインの管理者が意図した通りのメールサーバーから届けられた正しい送信元からのメールであることが証明できます。

### DKIM レコードの例

DKIM レコードは下記のように記載します。<br>
セレクタ名は、任意の最大 63 文字の英数字を設定できます。<br>
ただし、セレクタ名はドメインに対して一意である必要があります。

```
[セレクタ名]._domainkey.example.com. IN TXT "v=DKIM1;k=rsa;p=[公開鍵]";
```

## DMARC レコードについて

DMARC（Domain-based Message Authentication, Reporting and Conformance）とは、電子メールの送信元ドメインの認証技術の一種であり、SPF や DKIM と併用することで、なりすましメール対策の強化が期待できます。<br>
DMARC の仕組みは、以下の 3 つに分けられます。

- 認証
  DMARC は、SPF と DKIM の認証結果を組み合わせて、メールの送信元ドメインの正当性を検証します
- ポリシー
  DMARC は、認証に失敗したメールをどのように処理するかを、ポリシーとして定義できます
- レポート
  DMARC は、認証結果を送信元ドメインに報告できます

ポリシーは、以下の 3 種類に分けられます。

- p=none
  認証に失敗したメールをすべて受信する
- p=quarantine
  認証に失敗したメールを、受信者から隔離する
- p=reject
  認証に失敗したメールを、受信者に拒否する

### DMARC レコードの例

「example.com」でポリシーを「none」、レポートの送り先を「dmarc-fb@example.com」に設定する場合、以下のように記述します。

今回のガイドラインでは、ポリシーは「none」でも問題ありません。

```
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-fb@example.com"
```

## ARC ヘッダについて

ARC（Authenticated Received Chain）とは、メールの認証状況を伝達し、なりすましメールや不正な改ざんを防ぐための技術です。<br>
SPF、DKIM、DMARC と連携して、メールの信頼性をさらに高める役割を果たします。<br>
メーリングリストやメールボックスプロバイダの自動転送機能などでメールを転送する場合、SPF や DKIM が失敗することがあるため、それを回避するために ARC ヘッダを追加する必要があります。

## TLS 接続について

TLS（Transport Layer Security）とは、インターネット上での通信を暗号化し、安全性を高めるための技術です。HTTPS や IMAP、POP3、SMTP などのプロトコルで使用され、通信内容の盗聴や改ざん、なりすましを防ぎます。

TLS 接続に対応しているメール配信システムを利用していれば問題ありません。

## ワンクリックでの配信停止について

今回のガイドラインでは、マーケティング目的のメールは 1 クリックでの配信停止の対応が必要です。<br>
具体的には、[RFC8058](https://datatracker.ietf.org/doc/html/rfc8058)に従い、以下をメールヘッダに含む必要があります。

配信停止リクエストを API 等で処理する場合は下記のように記述します。

```
List-Unsubscribe-Post: List-Unsubscribe=One-Click
List-Unsubscribe: <https://example.com/unsubscribe>
```

配信停止リクエストを指定されたアドレスにメール形式で送信する場合は下記のように記述します。

```
List-Unsubscribe-Post: List-Unsubscribe=One-Click
List-Unsubscribe: <mailto:unsubscribe@example.com>
```

[Google の FAQ](https://support.google.com/a/answer/14229414)によると、メール本文内の配信停止リンクを設置するだけでは要件を満たさないのでご注意ください。

## 各種設定の確認方法

設定が正しく適用されているか確認するためのツールを紹介します。

### [dmarcian](https://dmarcian.com/)

SPF、DKIM、DMARC レコードを診断してくれるツールです。

### [mail-tester](https://www.mail-tester.com/)

メールを実際に分析し、送信ドメイン認証のほか、様々な観点で送信メールのチェックを行い、10 点満点で評価をしてくれます。

## まとめ

ガイドラインの要件を満たしていない場合、メールがブロックされたり、迷惑メールに振り分けられたりする可能性が高くなるので、なるべく早く対応することをおすすめします。<br>
また、[ガイドライン](https://support.google.com/a/answer/81126)は今後も更新される可能性があるため、定期的にチェックしましょう。<br>
また、Google だけでなく、[米国 yahoo でも同様のアナウンス](https://blog.postmaster.yahooinc.com/post/730172167494483968/more-secure-less-spam)がされていますので、利用している方はこちらも対応が必要です。

## 参考

- https://blastmail.jp/blog/spam/gmail-guideline-202402
- https://sendgrid.kke.co.jp/blog/?p=17213
- https://sendgrid.kke.co.jp/blog/?p=5190
- https://sendgrid.kke.co.jp/blog/?p=1822
- https://www.value-domain.com/media/spf-record/
- https://www.cloudflare.com/ja-jp/learning/dns/dns-records/dns-dkim-record/
- https://hp-shizuoka.jp/column/2016/10/7515/
- https://baremail.jp/blog/2022/06/16/2552/
- https://docs.oracle.com/ja-jp/iaas/Content/Email/Tasks/configure-dkim-using-the-console.htm


large_20240202_1.jpg

medium_20240202_1.jpg

small_20240202_1.jpg

thumbnail_20240202_1.jpg

20240202_1.jpg

Gmail 送信のガイドラインへの適応

## はじめに

本記事では、これから TDD の導入を考えている方や、TDD を導入している案件に携わる方に向けて、私が実際に TDD をやってみて感じたメリット・デメリットをまとめたいと思います。

## テストの重要性

テストは、ソフトウェアの品質向上や開発効率化に欠かせないものになってきています。テストを効果的に活用することで、ソフトウェアの品質や信頼性を向上させ、開発コストを削減することができます。

## TDD(テスト駆動開発)とは

テスト駆動開発（Test-Driven Development、TDD）は、ソフトウェア開発の手法の一つで、テストの作成から始めて、その後にコードを実装するというサイクルを繰り返すことで、品質の高いソフトウェアを開発する手法です。
手動テストするのではなく、[Jest](https://jestjs.io/ja/)や[JUnit](https://junit.org/junit5/)などのテストフレームワークを使用します。

一般的な開発では、下図のように設計とテスト作成は分けて行うと思います。

 ![image](/uploads/20230908_2_b6073f3e4b.png) 

TDD では、最初にテストを作成します。
テスト作成 ≒ 設計のようなイメージです。

 ![image](/uploads/20230908_3_11d5709f45.png) 

## TDD の基本サイクル

TDD は「レッド」「グリーン」「リファクタリング」と呼ばれる工程で進められます。各工程で何をするのか、説明していきます。

### レッド

要件から、実装する機能のテストを作成します。この段階では実装をしていないので、テストはすべて失敗します。
テストツールを使っているときにテストが失敗すると赤色でエラー表示されるため、この工程はレッドと呼ばれます。

### グリーン　

レッドで作成したテストをもとに、実装を行います。
ここで重要なのは、完璧なコードを書くことではなく、先に設定したテスト条件を全てクリアさせるだけの「最小限」のコードを書くということです。
テストツールを使っているときにテストが通ると緑色でエラー表示されるため、この工程はグリーンと呼ばれます。

### リファクタリング

すべてのテストが通るようになったら、リファクタリングを行ってコードの可読性を高めます。
この工程は後回しになりがちですが、プログラムの規模が大きくなると大変になってしまうので、こまめにリファクタリングすることをお勧めします。

## TDD のメリット

TDD を実施すると、以下のようなメリットがあります。

### 安心して実装ができる

テスト条件を全てクリアさせるように実装することで、実装漏れやバグの発生を抑制できます。
また、何を実装すれば良いのかはテストを見ればすぐにわかるので、工数の削減が期待できます。

### 品質向上

テストが既にあることで、開発者がコードを変更する際にも、影響を受ける他の部分に対して問題がないかを確認できます。また、テストが十分にカバレッジされている場合、バグやエラーを早期に発見できるため、ソフトウェアの信頼性が向上します。

### ドキュメントとしての役割

テストコードはソフトウェアの仕様や振る舞いを示すドキュメントとして機能します。ソフトウェアの動作がテストによって明確になり、コードの理解が容易になります。
テストコードはソフトウェアの変更に伴って、常に最新の状態に保つ必要があります。そのため、テストコードはソフトウェアのバージョン管理システムに登録し、管理することが一般的です。

### リファクタリングのサポート

リファクタリングを行う前に、テストケースを実行して、リファクタリング後にもテストが通ることを確認することで、ソフトウェアの外部的な振る舞いを保てていることになるため、安全にリファクタリングを行うことができます。
また、リファクタリングで起きがちなデグレ(デグレード)やバグの発生を防止できます。

## TDD のデメリット

TDD は、ソフトウェアの品質向上や開発効率化に効果的な手法ですが、導入にはいくつかの課題があります。

### テストを作るのに時間(工数)がかかる

TDD は、テストコードを先に作成する必要があるため、開発プロセス全体において時間がかかることがあります。
ただし、長期的にはバグの減少や品質向上が見込めることから、開発全体で考えると時間の節約と考えることもできます。

### 熟練度と学習コスト

TDD は、初めて取り組む開発者にとっては学習コストがかかる場合があります。
効果的なテストを作成するためには、適切なテストケースを選択し、適切なカバレッジを持つことが必要です。
しかし、開発の初期段階に完璧なテストコードを書くのは難しいので、今思い浮かぶ機能の中でテストを作成し、仕様変更などのタイミングでより細かいテストを増やしていく方針で進めていました。

### テストの保守

ソフトウェアの変更に伴い、テストコードも頻繁に更新する必要があるため、テストの保守に工数がかかることがあります。
TDD を導入する際にはその負担をチームに理解してもらう必要があります。

## 課題の解決策

TDD の課題を解決するためには、以下のような対策が考えられます。

### テストコードの自動生成ツールを活用する

テストコードの自動生成ツールとは、ソフトウェアの設計や仕様を元に、テストコードを自動的に生成してくれるツールです。
例えば、テストフレームワークに[Jest](https://jestjs.io/ja/)を使用しているのであれば、[jest-test-gen](https://github.com/egm0121/jest-test-gen)などがあります。
テストコードの自動生成ツールを活用することで、テストコードの作成にかかる時間を短縮することができます。

### テストケースの標準化を図る

テストケースの標準化とは、テストケースの作成や評価に使用するルールや手法を定義することです。
テストケースの標準化をすることで、開発者の経験やスキルに依存することなくテストコードを作成できるため、テストコードの作成や保守の効率化を図ることができます。

### チームでのテスト文化を醸成する

チームでのテスト文化を醸成することで、テストの重要性や必要性を理解してもらい、テストへの協力を得やすくなります。

## まとめ

私は気になるところがあるとすぐにリファクタリングしたくなっちゃう性格なので、TDD にはとても助けられています。
TDD は、一見面倒な手法に思われるかもしれませんが、バグの早期発見や仕様の理解、コードの品質向上など、多くのメリットがあります。
メリットとデメリットを理解した上で、適切に活用していきましょう！

## 参考リンク

- [テスト駆動開発（TDD）とは？基本サイクルと運用時の注意点を解説！【ソフトウェア開発・テスト用語 】| Qbook](https://www.qbook.jp/column/713.html)
- [テスト駆動開発（TDD）入門](https://products.sint.co.jp/ober/blog/tdd)
- [テスト駆動開発（TDD）とは？目的やメリット・デメリット、やり方を解説 ｜ソフトウェアテストの SHIFT](https://service.shiftinc.jp/column/4654/)

medium_20230908_1.jpg

small_20230908_1.jpg

thumbnail_20230908_1.jpg

20230908_1.jpg

TDD(テスト駆動開発)について

【Git初心者向け】ソースツリーを利用したGit操作について

<p>最近のシステム開発ではGitを使うことが一般的になってきました。<br />
実際、スターフィールドでもほぼすべての案件でGitを活用しています。</p>
<p>しかし、Gitは覚えることが多く仕組みも複雑なため、これからGitを使い始める人にとっては高いハードルになっているでしょう。<br />
私も初めてGitを使った時は何がなんだかさっぱりわかりませんでした。</p>
<p>この記事では</p>
<ul>
<li>これからGitを使い始めるけど、用語とか仕組みが全然わからない！</li>
<li>名前はなんとなく聞いたことあるけど、どんなものなのかわからない！</li>
</ul>
<p>という人向けに、基本的な用語や仕組みを重点的に説明します。</p>
<h2>そもそもGitとはどういうものなのか？</h2>
<p>Gitは、ざっくり言うとファイルを「いつ・誰が・どこを・どのように」編集したかを管理するツールです。</p>
<p>ファイルの変更履歴を管理するツールは昔から多数存在しますが、Gitはそのツールの中でも分散型バージョン管理システムという分類にあたります。<br />
分散型バージョン管理システムの特徴は、各自のPCにファイルを持ち、自分の好きなタイミングで編集内容を同期(プッシュやプル)できることです。<br />
同期さえしなければ、どんなにファイルを編集したり削除しても別の作業者に影響しないというメリットがあります。<br />
そのため、Gitは複数人で開発をする際に多く利用されています。</p>
<p>また、集中型バージョン管理システムというものも存在し、CVS・Subversionなどがこれに該当します。<br />
これらは編集が完了したらすぐに作業者全員に共有されるので、誤った変更内容を登録すると作業者全員に影響を与えてしまいます。</p>
<h2>GitとGitHubの違い</h2>
<p>Gitを使う際に、GitHubもセットで登場してくることが多いので混同する方もいると思いますが、GitとGitHubは同じものではありません！<br />
上記で述べたように、Gitは分散型バージョン管理システムというツールです。<br />
一方でGitHubはGitの仕組みを利用した、開発支援をしてくれるwebサービスです。<br />
Gitは「システム」でGitHubは「サービス」のような関係にあたります。<br />
「メール」というシステムにおける「Gmail」というサービス、「動画」というシステムにおける「YouTube」というサービス、といったような関係と同じものです。</p>
<h2>Gitの仕組み</h2>
<p>Gitは以下のような構造でファイルの変更履歴を管理しています。</p>
<p><img loading="lazy" class="alignnone size-medium wp-image-11600" src="/uploads-archive/lc/2023/03/5135bc1d47ef31711ee94ad1dd2aea87-300x225.png" alt="" width="600" height="450" srcset="/uploads-archive/lc/2023/03/5135bc1d47ef31711ee94ad1dd2aea87-300x225.png 300w, /uploads-archive/lc/2023/03/5135bc1d47ef31711ee94ad1dd2aea87-768x576.png 768w, /uploads-archive/lc/2023/03/5135bc1d47ef31711ee94ad1dd2aea87-600x450.png 600w, /uploads-archive/lc/2023/03/5135bc1d47ef31711ee94ad1dd2aea87.png 960w" sizes="(max-width: 600px) 100vw, 600px" /></p>
<p>用語と仕組みを説明していきます。</p>
<h3>リポジトリ（repository）</h3>
<p>ファイルやディレクトリを保存している場所のことです。<br />
変更履歴もリポジトリに保存しています。<br />
リポジトリには以下の2種類があります。</p>
<h4>リモートリポジトリ（remote repository）</h4>
<p>主にサーバー上にあるリポジトリで、作業者全員の編集内容を共有するためのリポジトリです。<br />
各PCで行った編集内容を取りまとめしているリポジトリです。<br />
GitHubなどのサービスを利用することで、誰でも簡単にリモートリポジトリを作成できます。</p>
<h4>ローカルリポジトリ（local repository）</h4>
<p>自分のPC上にあるリポジトリです。<br />
作業者はこのリポジトリに対して編集します。</p>
<h3>クローン（clone）</h3>
<p>一言で言うと「ダウンロード」に近い機能です。<br />
リモートリポジトリから、自分のPCにローカルリポジトリを作成します。<br />
ほとんどの場合、Gitで最初に行う作業となります。</p>
<h3>プル（pull）</h3>
<p>リモートリポジトリにある最新の変更内容をローカルリポジトリに反映する機能です。<br />
クローンと少し似ている機能ですが、クローンはリモートリポジトリの内容をすべてダウンロードするのに対し、プルはローカルリポジトリに反映されていない最新の変更内容のみをダウンロードします。</p>
<h3>フェッチ（fetch）</h3>
<p>リモートリポジトリにある最新の変更履歴をローカルリポジトリに反映する機能です。<br />
プルと少し似ている機能ですが、プルは変更内容も反映するのに対し、フェッチは変更履歴のみを反映します。</p>
<h3>プッシュ（push）</h3>
<p>一言で言うと「アップロード」に近い機能です。<br />
ローカルリポジトリの変更内容をリモートリポジトリに反映します。<br />
プッシュを行うことで、自分の変更内容をリモートリポジトリに反映し、別の作業者がプルすることで自分の変更を別の作業者に反映できます。</p>
<h2>コミット（commit）</h2>
<p>ゲームで例えると「セーブ」のような機能です。<br />
コミットを実行することで、ファイルの変更履歴をローカルリポジトリに記録できます。<br />
また、コミットメッセージを記入すれば、このコミットでどのような変更をしたかなどを記録できます。</p>
<p><img loading="lazy" class="alignnone size-medium wp-image-11601" src="/uploads-archive/lc/2023/03/8fdcc7d29d3c66ae37c29c8503f30619-300x123.png" alt="" width="600" height="246" srcset="/uploads-archive/lc/2023/03/8fdcc7d29d3c66ae37c29c8503f30619-300x123.png 300w, /uploads-archive/lc/2023/03/8fdcc7d29d3c66ae37c29c8503f30619-768x315.png 768w, /uploads-archive/lc/2023/03/8fdcc7d29d3c66ae37c29c8503f30619-600x246.png 600w, /uploads-archive/lc/2023/03/8fdcc7d29d3c66ae37c29c8503f30619.png 957w" sizes="(max-width: 600px) 100vw, 600px" /></p>
<p>コミットを行わないと編集した内容がローカルリポジトリに適用されず残り続けてしまうので、編集が完了したら忘れずにコミットしましょう！</p>
<p>&nbsp;</p>
<p>さらに、コミットする前段階に「ワークツリー」と「インデックス」というものがあります。<br />
コミットするためには、以下のような段階を踏む必要があります。</p>
<p><img loading="lazy" class="alignnone size-medium wp-image-11602" src="/uploads-archive/lc/2023/03/2e1d56395b7836f2c7e7eefd0a2aadf5-300x111.png" alt="" width="600" height="222" srcset="/uploads-archive/lc/2023/03/2e1d56395b7836f2c7e7eefd0a2aadf5-300x111.png 300w, /uploads-archive/lc/2023/03/2e1d56395b7836f2c7e7eefd0a2aadf5-768x283.png 768w, /uploads-archive/lc/2023/03/2e1d56395b7836f2c7e7eefd0a2aadf5-600x221.png 600w, /uploads-archive/lc/2023/03/2e1d56395b7836f2c7e7eefd0a2aadf5.png 950w" sizes="(max-width: 600px) 100vw, 600px" /></p>
<h3>ワークツリー</h3>
<p>現在編集中の内容を仮置きしている場所です。<br />
ワークツリー内にある変更内容はコミットされないので、コミットしたい変更内容をインデックスに登録(add)する必要があります。</p>
<h3>インデックス</h3>
<p>コミットする変更内容を仮置きしている場所です。</p>
<p>&nbsp;</p>
<p>なぜこのような機能があるかというと</p>
<ul>
<li>この変更、まだ途中だから今はコミットしたくない</li>
<li>この変更は複数のコミットに分けたい</li>
</ul>
<p>という時に、変更した一部分だけコミットできるようにするためです。<br />
使い慣れるととても便利な機能なので、ワークツリーとインデックスを積極的に活用していきましょう！</p>
<h2>ブランチ（branch）</h2>
<p>感覚的な例えになってしまいますが、「パラレルワールド」のようなことを実現できます。<br />
以下のように、ファイルの変更内容を分岐させて記録できます。</p>
<p><img loading="lazy" class="alignnone size-medium wp-image-11603" src="/uploads-archive/lc/2023/03/a7532ee5b4e19612918b9757dcfbf02d-300x120.png" alt="" width="600" height="240" srcset="/uploads-archive/lc/2023/03/a7532ee5b4e19612918b9757dcfbf02d-300x120.png 300w, /uploads-archive/lc/2023/03/a7532ee5b4e19612918b9757dcfbf02d-1024x410.png 1024w, /uploads-archive/lc/2023/03/a7532ee5b4e19612918b9757dcfbf02d-768x308.png 768w, /uploads-archive/lc/2023/03/a7532ee5b4e19612918b9757dcfbf02d-600x240.png 600w, /uploads-archive/lc/2023/03/a7532ee5b4e19612918b9757dcfbf02d.png 1028w" sizes="(max-width: 600px) 100vw, 600px" /></p>
<p>なぜこのような機能があるかというと、複数人で開発する際にありがちな</p>
<ul>
<li>別の人が変更した内容のせいで自分の修正した箇所が動かなくなった・・・</li>
<li>同じファイルを複数人で編集したせいで、変更内容が消えた・・・</li>
</ul>
<p>という問題を防ぐためにあります。</p>
<p>&nbsp;</p>
<p>ブランチを作成することによって、別のブランチでコミットした内容に影響されず開発を進めることができ、作業の効率化を図ることができます。</p>
<p>また、自分のブランチでコミットした内容は別のブランチでは影響がないため、自分のコミットした内容に不具合があっても別の作業者に迷惑をかける心配もありません。</p>
<p>スターフィールドでは、機能の追加や不具合の修正などの作業単位でブランチを分けることが多いです。</p>
<p>複数人で開発する際は積極的にブランチを利用することをお勧めします！</p>
<h3>マージ（merge）</h3>
<p>2つのブランチでコミットした変更内容を統合させる機能です。<br />
以下のように、機能追加のため切り分けたブランチで作業が完了し、メインのブランチに変更内容を適用する際にこの機能を利用します。</p>
<p><img loading="lazy" class="alignnone size-medium wp-image-11604" src="/uploads-archive/lc/2023/03/c0731fa21e459a7fcbc6fb0c07356808-300x85.png" alt="" width="600" height="170" srcset="/uploads-archive/lc/2023/03/c0731fa21e459a7fcbc6fb0c07356808-300x85.png 300w, /uploads-archive/lc/2023/03/c0731fa21e459a7fcbc6fb0c07356808-1024x291.png 1024w, /uploads-archive/lc/2023/03/c0731fa21e459a7fcbc6fb0c07356808-768x218.png 768w, /uploads-archive/lc/2023/03/c0731fa21e459a7fcbc6fb0c07356808-600x171.png 600w, /uploads-archive/lc/2023/03/c0731fa21e459a7fcbc6fb0c07356808.png 1027w" sizes="(max-width: 600px) 100vw, 600px" /></p>
<h3>コンフリクト（conflict）</h3>
<p>同じファイルの同じ箇所を変更したブランチをマージする際に起きる現象です。</p>
<p>コンフリクトを解消しないと、マージできません。</p>
<p>コンフリクトが多発すると作業効率が落ちてしまうので、できるだけコンフリクトを起こさないようにしましょう！</p>
<p>できるだけ他の作業者が変更している、または変更しそうなファイルはいじらないようにすればコンフリクトは抑えられます。</p>
<h2>その他Gitの便利機能</h2>
<p>私がよく使っているGitの機能を紹介します。</p>
<h3>リバート（revert）</h3>
<p>特定のコミットで変更した内容を打ち消すコミットを作成します。</p>
<p>この機能を使うことによって、特定のコミットの変更を無かったことにできます。</p>
<h3>アメンド（amend）</h3>
<p>1つ前のコミット内容とコミットメッセージを修正する機能です。</p>
<p>コミットし忘れたファイルがあったり、コミットメッセージに誤字があった時に修正できます。</p>
<p>プッシュ済みのコミットや2つ以降前のコミットには使えないので注意が必要です。</p>
<h3>スタッシュ（stash）</h3>
<p>コミットしていない変更内容を「一時退避」する機能です。</p>
<p>今の作業を中断して別の作業をする時などに、今の変更内容はとっておきたいけど一旦無かったことにしたい時に便利です。</p>
<h2>まとめ</h2>
<p>この記事では、Gitを活用するために必要な用語と仕組みを紹介しました。</p>
<p>Gitはプログラム開発などを行うエンジニアにとっては必須のスキルになりつつあるので、ぜひ身につけておきましょう！</p>
<h2>参考にさせていただいたサイト</h2>
<p><a href="https://tcd-theme.com/2019/12/what-is-Git.html">https://tcd-theme.com/2019/12/what-is-Git.html</a></p>
<p><a href="https://www.i3design.jp/in-pocket/3111#GitHub%E3%81%A8%E3%81%AF%EF%BC%9F">https://www.i3design.jp/in-pocket/3111#GitHub%E3%81%A8%E3%81%AF%EF%BC%9F</a></p>
<p>&nbsp;</p>


Gitとは何か？

Blogブログ

Articles

Contact Us