https://techblog.zozo.com/entry/agent-skills-for-techblog-review

Claude Code Agent Skillsを活用したTECH BLOGレビュー ── AIで推進するレビュー自動化

はじめに

こんにちは。Developer Engagementブロック（略称DevEngブロック）の@wirohaです。ZOZO TECH BLOGの運営や、開発者向けイベントの企画・運営などを担当しています。

TECH BLOGの運営において、レビューには一定の工数がかかるため、効率化を進めています。その一環として、Claude CodeのAgent Skills（以下、スキル）を用いたレビュー支援の仕組みを整備しました。Claude Code上で記事のレビューを依頼すると、定義したルールに基づくレビュー結果を得られます。

以下は、スキルによるレビュー結果の抜粋です。

概要がわかる例

本記事では、このスキルを用いたTECH BLOGレビューの取り組みについて紹介します。

背景・課題

ZOZO TECH BLOGは執筆したチーム内で技術的な正確性をレビューした後、DevEngブロックで文章表現・社内ルール準拠などをレビューして公開しています。DevEngブロックでは、現在2名体制で年間約100本の記事をレビューしており、次の課題があります。

担当者が少なく属人化しやすい
時間がかかってしまう
指摘が多いと漏れが発生しやすく、修正と再レビューの往復で進行が詰まりやすい

記事はGitHub上で管理しており、文章を校正するtextlintのGitHub Actionsを動かしているため、ある程度のチェックは自動化されています。¹ ただ、それだけでは網羅できない観点が多くあるため、AIを活用してレビューの自動化をさらに推進することにしました。

解決の方針

AIを活用したレビューには複数の選択肢がある中で、Claude Codeのスキルを用いることにしました。Claude Codeはブラウザやエディタを介さず、ターミナル（CLI）で動作し、手元のファイルや外部サービスの情報を扱いながら作業を支援できるAIツールです。スキルは特定のタスクを実行するためのカスタムモジュールで、ドメイン知識やルールに基づいた処理を一貫した手順でAIに実行させられます。スキルの詳細はClaude Codeの公式ドキュメントをご覧ください。

code.claude.com

今回の場合、claudeコマンドでClaude Codeを起動し、「記事をレビューしてください」のように指示するだけで、スキルが呼び出されてレビューを実行できます。

AIレビューの手段として、ChatGPTのGPTsやGeminiのGemなど対話型AIのカスタマイズ、GitHub Actionsによる自動チェックも検討しました。最終的にスキルを採用した理由は次のとおりです。

ブラウザで使用するAIツールと異なり、記事本文をコピーしてAIにペーストする手間が省ける
同じ仕組みをDevEngブロック以外も使用でき、執筆者によるセルフレビューとしても使える
社内にはClaude Codeの利用者が多く、操作に慣れている
レビュールールをGitHub上で管理し、誰でもPRを出して改善提案する運用にできる
Claude Code GitHub ActionsやDevinでPR上に自動コメントするよりは、任意利用から始めて少しずつAIの精度を高めたい

何度も実行しやすく、レビュールールを継続的に改善しやすい仕組みが重要だと考えました。

スキルの設計

Claude Codeの公式ドキュメント「Claude をスキルで拡張する」を参考に、TECH BLOGレビュー用のスキルを設計しました。

執筆時点でのスキルの内容を掲載します。スキル定義ファイルであるSKILL.mdと、TECH BLOGレビューのルールをまとめたrules.mdの2つのファイルで構成されています。

SKILL.md

---
name: techblog-review
description: "ZOZO TECH BLOGの記事をレビューする。「記事をレビュー」「テックブログをチェック」「entry.mdを確認」などのリクエストで起動"
allowed-tools: Read, WebFetch
---

## テックブログ記事レビュー

`entry.md` をZOZO TECH BLOGのルールに基づいてレビューします。

### 手順

1. `entry.md` を読む
2. `rules.md` のルールに基づいてレビューする
3. 記事内のリンクをWebFetchで確認し、リンク切れがないかチェックする
4. 問題がある場合のみ、以下のルールで出力する（「問題なし」「確認のみ」といった項目は記載しない）

### 出力ルール

**L{行番号}** - {観点}：{修正内容の要約}
```diff
- {修正前の文}
+ {修正後の文}
```

### 出力例

**L73** - 文法：「〜なこと」→「〜こと」
```diff
- ドキュメントが古いなことが原因で
+ ドキュメントが古いことが原因で
```

**L89** - 冗長表現：「〜というのは」→「〜のは」
```diff
- 自動化できるというのは大きな利点です。
+ 自動化できるのは大きな利点です。
```

descriptionには、スキルを起動する際のキーワードを記載しています。allowed-toolsには、スキルが使用できるツールを指定しています。Readは、rules.mdや記事原稿であるentry.mdを読むために必要です。記事内のリンク切れをチェックするために、WebFetchも許可しています。

rules.md

肝となるレビュールールは、DevEngブロックがこれまでに行ってきたレビューやSuggestコメントをもとにしています。Claude Codeに過去3年間のレビューコメントをGitHub CLI²で収集させ、ルール案を作成させました。PR上のレビュー履歴を資産として活用し、案は人手で精査してブラッシュアップしました。

以下では、rules.mdの一部を紹介します。全文は長くなるため、付録として記事の末尾に掲載します。

# ZOZO TECH BLOG レビュールール

## 1. 文体・表現

### 1.1 文体の統一
- **である調とですます調を混在させない**
- 基本的にですます調を使用する

### 1.2 文は短くする
- **一文が長すぎると読みにくい**
- 複数の情報を含む文は分割する
- 目安：一文100文字以内

### 1.3 口語表現の回避
- 口語表現は文語表現に置き換える

| 口語 | 文語 |
|------|------|
| 〜なんですが | 〜ですが |
| 無かったです | ありませんでした |
| ですので | そのため / したがって |
| ないですが | ありませんが |
| 食わせる | 与える / 読み込ませる |

### 1.4 曖昧表現の回避
- 「〜と思います」より「〜です」を使う
- 「〜ような」で曖昧にせず断定する
- 断定できる場合は断定する

```
❌ 複数の機能を一度にデプロイするようなリリースサイクルを採用していました。
✅ 複数の機能を一度にデプロイするリリースサイクルを採用していました。
```

これらの観点の一部は以前Zennの記事「技術をわかりやすく伝えるテクニカルライティングのtips」などにまとめて共有していましたが、そこに含まれない多くの観点を整理できました。なお、rules.mdに含まれる例文は、生成されたルール案をもとに手動で改変し、特定の記事が推測されないよう配慮しています。

スキルの使用方法

スキルはブログ執筆用リポジトリのルートに配置しているため、プロジェクトスキルとして自動的に有効になります。

Claude Code上で「今書いている記事をレビューしてください」などと指示すれば、スキルが起動してレビューを実行します。ローカルにある自分の記事をセルフレビューする場合の例は次のとおりです。Use skill "techblog-review"?と聞かれるので「Yes」と答えると結果が返ってきます。

自分の記事をレビューさせた場合の例

自分の記事をレビューさせた場合の例2

DevEngブロックのメンバーは、自分が書いていない記事もレビューします。ローカルにない記事もClaude Code上で「<URL>の記事をレビューしてください」のように指示すれば、GitHub CLIを使って自動的に記事を取得し、レビューしてくれます。

リモートの記事をレビューさせた場合の例2

手動でチェックアウトしてきたり、コピー＆ペーストしたりする必要がなく、非常に便利です。

実行例

本記事を執筆しながら、実際にスキルを使ってレビューした際の結果を例として紹介します。

1. SKILL.mdでの指定どおり、リンク切れをチェックして有効である旨を表示しています。リンクチェック

2. ルールに書いてある、冗長表現を見つけて指摘しています。冗長表現の指摘の例

3. ルールに書いていない観点でもチェックしてくれます。行頭に不要なスペースが入っている例です。

4. リンクを埋め込み形式で表示するためのembed:citeが誤って入っているのも見つけています。無効なembed:citeの指摘の例

5. ルールにある「正式名称・表記」の観点で、サービス名の誤りを指摘しています。正式名称の指摘の例

6. 広く知られているサービス名だけではなく、ファイル名の誤りも発見できるのは驚きでした。ファイル名の誤りの例

7. TODOと書いていなくても、消し忘れか対応漏れかもしれないコメントを指摘しており、細やかです。コメント残りの例

8. ルールにある「文の流れ」の観点はやや厳密にも感じますが、たしかに読点を入れた方が読みやすいため修正しました。文の流れの例

9. 次の例ではURLの誤りを指摘しており、それ自体は適切であるものの、修正案が英語版ドキュメントのURLになってしまっていました。手動で日本語の方に修正しましたが、こういった誤りもあるため、自動適用はせず人が確認する運用にしています。 URL誤りの例

以上のように、表記・記法・リンクといった観点を中心に、幅広く指摘できました。

導入効果

実行例で示したとおり、さまざまな観点でチェックできており、修正案を考える時間を短縮できるようになりました。rules.mdで定義した観点に基づき、過去30件のPRのレビューコメントをAIで分類したところ、約75％をカバーできると推定されました。残り25％は「文章の圧縮・再構成」「表現の適切さ」「説明の追加・明確化」といった文脈依存の判断が必要なもので、ルールベースでの検出ができない点でした。

これまで暗黙知としてDevEngブロックメンバーの中で蓄積されていたチェック観点を、rules.mdとして明文化し、AIが担えるようになりました。その結果、レビュー観点が個人の経験やスキルに依存しにくくなり、再現性のあるチェックが行えるようになっています。

また、特定分野の技術を知っていないと見つけづらいタイポなど、自分では見落としていた点も検出でき、記事の品質向上に寄与しています。細部のチェックをAIに任せることで、全体の構成やわかりやすさといった観点に意識を向けやすくなり、読みやすい記事づくりにつながっています。

執筆者にはまだ展開したばかりで、セルフレビューで用いるのは必須とはしていません。ルールの精度を向上させ、執筆段階でセルフレビューとして使うケースが増えていけば、修正と再レビューの往復が減り、執筆者・レビュアー双方の負担軽減につながると考えています。

運用上の注意点

実行例の部分にも記述したとおり、現在の運用ではAIの指摘をそのまま採用せず、提案として扱っています。指摘に誤りが含まれる場合や、厳密すぎる場合があるためです。たとえばルールでは口語表現を回避するよう定めていますが、イベントレポート系の記事では口語の表現を残した方が感情を伝えやすい場合もあります。そのあたりのバランスは人が判断しています。

また、社外秘や推測可能な情報が混入していないかなども人が確認しています。

今後の展望

今後は、スキルの精度向上と機能拡張に継続して取り組みます。記事をレビューした結果をもとにフィードバックループを回し、改善を図ります。

執筆者からの意見次第では、Claude Code以外のAIツールへの対応も検討しています。rules.mdを整備したことで、同じ観点を他のツールにも転用しやすくなりました。Claude Codeを使用していない人でも利用できる導線を用意してもよいかもしれません。

また、本記事に反響があれば、スキルをオープンソース化し最新のルールを社外の方も利用できるようにすることも検討したいと考えています。各社で技術ブログの運用方法は異なるため、本取り組みを通じて、より良いレビューや運用方法について意見交換ができればと思います。

まとめ

本記事では、Claude CodeのAgent SkillsとしてTECH BLOGのレビュー観点を集約し、効率化した取り組みを紹介しました。AIの発展は目覚ましく、優れたツールが次々と登場しています。DevEngブロックは新しい技術を積極的に取り入れ、より良い執筆体験を提供できるよう努めていきます。今回の記事が生成AIをレビュー支援に取り入れる際の設計・運用のヒントになれば幸いです。

ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。技術記事の執筆が好きな方も大歓迎です。ご興味のある方は、以下のリンクからぜひご応募ください。

corp.zozo.com

付録：rules.md全文

# ZOZO TECH BLOG レビュールール

## 1. 文体・表現

### 1.1 文体の統一
- **である調とですます調を混在させない**
- 基本的にですます調を使用する

### 1.2 文は短くする
- **一文が長すぎると読みにくい**
- 複数の情報を含む文は分割する
- 目安：一文100文字以内

### 1.3 口語表現の回避
- 口語表現は文語表現に置き換える

| 口語 | 文語 |
|------|------|
| 〜なんですが | 〜ですが |
| 無かったです | ありませんでした |
| ですので | そのため / したがって |
| ないですが | ありませんが |
| 食わせる | 与える / 読み込ませる |

### 1.4 曖昧表現の回避
- 「〜と思います」より「〜です」を使う
- 「〜ような」で曖昧にせず断定する
- 断定できる場合は断定する

```
❌ 複数の機能を一度にデプロイするようなリリースサイクルを採用していました。
✅ 複数の機能を一度にデプロイするリリースサイクルを採用していました。
```

### 1.5 体言止めの回避
- **体言止めは曖昧になりやすいため、技術記事では避ける**
- 文として言い切る形にする
- **ただし、箇条書きの場合は体言止めでも許容**

```
❌ 先月、ついに新機能をリリース。
✅ 先月、ついに新機能をリリースしました。
```

### 1.6 「〜たり」の用法
- 並列の「〜たり」は**2回以上繰り返して使う**

```
❌ コードを書いたりレビューができます
✅ コードを書いたりレビューをしたりできます
```

### 1.7 「〜になります」「〜となります」の回避
- 変化しない場合は「です」を使う

```
❌ 本ツールはログ収集の定番ライブラリになります。
✅ 本ツールはログ収集の定番ライブラリです。
```

### 1.8 丁寧すぎる表現の回避
- 物に対する過剰な丁寧表現は避ける

```
❌ 環境変数を設定ファイルに追記してあげる必要があります。
✅ 環境変数を設定ファイルに追記する必要があります。
```

### 1.9 敬称
- 社外の方（技術顧問、登壇者等）には「さん付け」を使う
- 自社社員には敬称は不要とする

### 1.10 簡潔にできる表現（任意）
簡潔にしたい場合は、以下のように表現を変える

- 「なぜ〜したか」→「〜した理由」
- 「どのように〜するか」→「〜する方法」
- 「どれくらい閲覧されたか」→「閲覧数」

---

## 2. 受動態と能動態

### 2.1 能動態を優先する
- **受動態が多いと読みづらくなる**
- 主語を明確にして能動態で書く

```
❌ 複数の設定ファイルはバッチ処理から順次実行されることで、対象システムの状態を更新していきます。
✅ バッチ処理が複数の設定ファイルを順次実行し、対象システムの状態を更新します。
```

### 2.2 受動態と能動態の混在を避ける

```
❌ そのAPIに対してタイムアウトを設定されており
✅ そのAPIにはタイムアウトが設定されており
```

---

## 3. 主語と述語

### 3.1 主語を省略しない
- 主語がないと何の話かわからない

```
❌ この処理の流れの特徴として、決済完了のタイミングで管理画面からメールをユーザーへ同期的に送信します。
✅ この処理の流れの特徴として、システムは決済完了のタイミングで管理画面の機能を介してメールをユーザーへ同期的に送信します。
```

### 3.2 主語と述語のねじれを避ける
- 主語と述語が対応しているか確認する

```
❌ 特に気になった変更点は、新しいログ出力機能が追加されました。
✅ 特に気になった変更点は、新しいログ出力機能が追加されたことです。

❌ 今回の会場は、東京国際フォーラムで開催されました。
✅ 今回の会場は、東京国際フォーラムです。
✅ 今回のイベントは、東京国際フォーラムで開催されました。

❌ 結論はコストと移行の容易さからマネージドサービスを選定しました。
✅ 結論として、コストと移行の容易さからマネージドサービスを選定しました。
```

### 3.3 「〜とは」の後に意味を書く
- 「〇〇とは」と書いたら、その後に定義・意味を書く

```
❌ マイクロサービスアーキテクチャとは、システムを独立した小さなサービス単位に分割し、開発スピードと拡張性を大幅に向上させることができます。
✅ マイクロサービスアーキテクチャとは、システムを独立した小さなサービス単位に分割し、開発スピードと拡張性を大幅に向上させる設計手法のことです。
```

---

## 4. 助詞の使い方

### 4.1 助詞の誤用

| 助詞 | 悪い例 | 良い例 |
|------|--------|--------|
| を | サーバーを起動を開始 | サーバーの起動を開始 |
| を | パラメータを設定をしました | パラメータを設定しました |
| が | テスト実行にかかる時間が、全体時間を占める割合が増えた | テスト実行にかかる時間の、全体時間に占める割合が増えた |

### 4.2 助詞を省略しない

```
❌ 空レスポンス
✅ 空のレスポンス

❌ パフォーマンス影響が出た
✅ パフォーマンスに影響が出た

❌ この項目は必須でありません
✅ この項目は必須ではありません
```

### 4.3 助詞と動詞の対応

```
❌ 設定値を環境間に複製
✅ 設定値を環境間で複製

❌ 2018年より会社を設立しました
✅ 2018年に会社を設立しました
（「より」は継続の開始を示すため、一時点の出来事には「に」を使う）

❌ 会場内にノベルティが配布されました
✅ 会場内でノベルティが配布されました

❌ このツールには標準で自動リトライ機能を提供しています
✅ このツールは標準で自動リトライ機能を提供しています
```

### 4.4 冗長な表現を避ける

| 冗長 | 簡潔 |
|------|------|
| 〜について | 〜を |
| 〜に対して | 〜に |
| 〜に関して | 〜の / 〜を |
| 記載をします | 記載します |
| 〜というのは | 〜のは |
| 〜ということで | 〜ため / 〜ので |

```
❌ 運用コストを削減できるというのは大きなメリットでした。
✅ 運用コストを削減できるのは大きなメリットでした。
```

### 4.5 逆接でない「〜が」を避ける
- 逆接でない「〜が」を接続に使うことを避ける
- **主格の「が」は問題ない**
- 単なる文の接続に「〜が」を使うのは避ける

```
❌ 本機能は外部APIを利用してデータを取得しますが、取得したデータはデータベースへ保存され、ユーザー画面に表示されます。
✅ 本機能は外部APIを利用してデータを取得します。取得したデータはデータベースへ保存され、ユーザー画面に表示されます。
```

---

## 5. 漢字とひらがなの使い分け

### 5.1 ひらがなにする語
- 公用文作成の要領や記者ハンドブックでは、実質的な意味を持たない言葉をひらがなで書くよう定めており、概ねそれに則る。

1. 常用外漢字
2. 形式名詞
3. 接続詞
4. 補助動詞
5. 一部の動詞
6. 副助詞
7. 副詞
など

具体例

| 漢字 | ひらがな | 分類 | 備考 |
|------|----------|------|------|
| 殆ど | ほとんど | 常用外漢字・副詞 | |
| 為 | ため | 形式名詞 | 「〜のため」 |
| 事 | こと | 形式名詞 | 「〜すること」 |
| 所 | ところ | 形式名詞 | 「改善したいところ」 |
| 尚 | なお | 接続詞 | |
| 但し | ただし | 接続詞 | |
| 又 | また | 接続詞 | |
| 下さい | ください | 補助動詞 | 「ご確認ください」 |
| 頂く | いただく | 補助動詞 | 「教えていただく」 |
| 居る | いる | 補助動詞 | 「動いている」※補助動詞の場合 |
| 無い | ない | 補助動詞 | 「問題ない」※補助形容詞の場合 |
| 有る | ある | 補助動詞 | 「設定してある」※補助動詞の場合 |
| 出来る | できる | 補助動詞・動詞 |  |
| 迄 | まで | 副助詞 | |
| 位 | くらい/ほど | 副助詞 | |
| 是非 | ぜひ | 副詞 | |
| 丁度 | ちょうど | 副詞 | |
| 更に | さらに | 副詞 | |
| 予め | あらかじめ | 副詞 | |
| 様々 | さまざま | 慣習 | 公用文では漢字表記 |

### 5.2 送り仮名の確認

```
❌ 楽しく話ながら作業した
✅ 楽しく話しながら作業した
```

---

## 6. 語順・修飾

### 6.1 修飾語は被修飾語の近くに置く

```
❌ 細かいアーキテクチャの説明は省略します
✅ アーキテクチャの細かい説明は省略します
```

### 6.2 語順を整理する

```
❌ 過去1年間のコミット数を開発状況を可視化するダッシュボードで確認してみたところ
✅ 開発状況を可視化するダッシュボードで過去1年間のコミット数を確認してみたところ
```

### 6.3 同じ単語・名詞の繰り返しを避ける
- ただし、並列構造の場合は同じ単語が続いても問題ない

```
❌ フローが複雑化してリードタイム低下とならないよう、フローの再設計を行いました。
✅ 複雑化によるリードタイム低下を避けるため、フローの再設計を行いました。

# 並列構造の例（問題なし）
✅ 2024年には初期段階としてフェーズ1をリリースし、翌年の2025年には計画どおりフェーズ2をリリースしました。
```

---

## 7. 見出し・構成

### 7.1 タイトル
- 「〜の話」で終わるタイトルは避ける
- 主題と副題をダッシュ（──）で繋ぐ形式を推奨

### 7.2 見出しの統一
- 見出しの文体・形式を統一する（体言止め or 文）
- 見出しがバラバラだと読みにくい

### 7.3 前提を書く
- 読者が知らない前提（社内ルールなど）は明記する

### 7.4 結論から書く
- 前置きが長いと読者が離脱する
- 結論→理由→詳細の順で書く

### 7.5 「後述します」の多用を避ける
- 「後述」を多用すると読者が混乱する
- 可能な限りその場で説明する

### 7.6 文の流れを意識する
- 唐突に話が変わらないようにする
- 前後の文脈をつなげる

```
❌ 現在、チームのチャットツールは有料プランで運用しています。必要な情報を後から見返せる仕組みは、業務上欠かせないと考えています。しかし無料プランへ移行すると、過去ログの検索期間に制限がかかります。
✅ 現在、チームのチャットツールは有料プランで運用しています。無料プランへ移行すると、過去ログの検索に制限がかかります。業務上、情報を後から見返せる仕組みは不可欠と考えています。
```

### 7.7 複雑なことは図示する
- 文章だけで説明が難しい場合は図を追加する

---

## 8. 記号・フォーマット

### 8.1 全角スラッシュは使わない
- 「／」（全角スラッシュ）は使わない
- 「/」（半角スラッシュ）または「・」を使う

### 8.2 英語の頭文字をとった略語は大文字
- API（Application Programming Interface）など、英語の頭文字をとった略語は大文字で表記する
- class名やファイル名などで小文字表記の場合は例外とする

### 8.3 引用記法
- 引用記法（`>`）は**実際の引用のときのみ**使用する

### 8.4 CustomPathはハイフンつなぎ
- アンダースコアは使わない
```
❌ CustomPath: my_article_path
✅ CustomPath: my-article-path
```

### 8.5 ダッシュの表記
- タイトルの主題と副題を繋ぐ際は**─を2つ + 前後に半角スペース**を使用

```
❌ システム移行の課題にどう立ち向かうか - 私たちが実践した解決策
✅ システム移行の課題にどう立ち向かうか ── 私たちが実践した解決策
```

---

## 9. 正式名称・表記

### 9.1 サービス・製品名は正式名称を使用

| 誤 | 正 | 参考URL |
|----|----|----|
| Golang | Go | https://go.dev/ |
| Go言語 | Go | https://go.dev/ |
| Spring boot | Spring Boot | https://spring.io/projects/spring-boot |
| Alloy DB | AlloyDB | https://cloud.google.com/alloydb |
| Firebase app check | Firebase App Check | https://firebase.google.com/docs/app-check |
| Secrets manager | Secrets Manager | https://aws.amazon.com/secrets-manager/ |
| slack bot | Slackbot | https://slack.com/help/articles/202026038 |
| Kintone | kintone | https://kintone.cybozu.co.jp/ （小文字始まり） |
| docker | Docker | https://www.docker.com/ （大文字始まり） |
| JS Nation | JSNation | https://jsnation.com/ （スペースなし） |
| iosDC | iOSDC Japan | https://iosdc.jp/ |
| ArgoCD | Argo CD | https://argo-cd.readthedocs.io/ （スペースあり） |

### 9.2 社名・サービス名の正式表記
- 社名やサービス名は公式サイトを確認し、正式名称を使用する
- スペースの有無、大文字小文字を正確に記載する
- ルールに記載されていない名称も都度検索して確認すること

**ZOZOに関する表記**
- 「ZOZO」はZOZOTOWNの略称ではない
- 「ZOZO Yahoo!店」→「ZOZOTOWN Yahoo!店」

---

## 10. はてなブログ固有のルール

### 10.1 太字記法
- はてなブログでは `**太字**` の前後に半角スペースは入れない

### 10.2 埋め込み記法
- URLは埋め込み形式にすると見栄えが良い
- `[https://example.com/:embed:cite]`

### 10.3 キャプション記法
- 画像にはfigureタグでキャプションを付けられる

```html
<figure class="figure-image figure-image-fotolife" title="タイトル">
[f:id:vasilyjp:20230101120000]
<figcaption>キャプション</figcaption>
</figure>
```

### 10.4 Markdownの改行
- パラグラフをわけるときは空行を入れる
- 同じパラグラフ内で改行する必要がある場合は `<br>` か `  `（半角スペース2つ）による強制改行を使う。ただし、デバイス依存の表示崩れやSEO・アクセシビリティの低下などを招くため、必要な場合のみに留める。

```
1行目

2行目（別のパラグラフになる）
```

### 10.5 箇条書きの前後には空行が必要
- 箇条書き（`-` や `1.`）の前後には空行を入れる
- 空行がないとレイアウトが崩れる場合がある

```
❌ 下記の項目を記載しています。
   - 依頼の概要
   - 依頼部門の課題

✅ 下記の項目を記載しています。

   - 依頼の概要
   - 依頼部門の課題
```

### 10.6 続きを読む記法
- `<!-- more -->` ははてなブログで「続きを読む」の区切りとして使用される
- このコメントは削除しない

---

## 11. リンク・参照

### 11.1 リンク切れの確認
- リンクが有効か確認する（404になっていないか）

### 11.2 リンク先の確認
- リンク先が正しいか確認する
- リンク先が不適切・不確かな情報でないか確認する

### 11.3 リンクテキストの書き方
- 「こちら」だけでなく、リンク先が分かるようにテキストを明示する

```
❌ 詳しくは[こちら](https://example.com)をご覧ください。
✅ 詳しくは[公式ドキュメント](https://example.com)をご覧ください。
✅ 詳しくは「[独自のアプリケーションの作成](https://example.com)」を参考にしてください。
```

### 11.4 採用リンク
- 記事末尾の採用リンクは有効か確認する

---

## 12. その他

### 12.1 ファイル末尾
- ファイル末尾の改行は必須ではない

### 12.2 機密情報
- 機密情報が含まれていないか確認する
- 例示で使う数字はダミーにし、その旨を明記する

### 12.3 将来の機能・予定
- 未確定の将来計画は公開可否を確認する

### 12.4 引用・著作権
- 他サイトの画像・スクリーンショットを使用する場合は引用の要件を満たす
- 引用元を明記する
- 参考: [文化庁「著作権を学ぶ（教材・講習会）」](https://www.bunka.go.jp/seisaku/chosakuken/seidokaisetsu/index.html)

### 12.5 画像の掲載許諾
- 人物写真は掲載許諾を確認する
- 他社ロゴ・アイコンは使用許可を確認する

### 12.6 追記の書き方
- 記事公開後に追記する場合は日付を明記する

```
❌ 追記：〜
✅ （2023/5/16追記）〜（追記ここまで）
```