# Beginner Tech Explainer Ja

> Explain programming, web development, software architecture, tools, and computer-science concepts in clear Japanese using mental models, small examples, and practical comparisons. Use when the user asks what a technical term means, how related technologies differ, or wants a beginner-friendly explanation. Do not use for requests whose main goal is implementation, repository modification, debugging, or formal reference documentation.

- Skill: `tensho1026/beginner-tech-explainer-ja` (Agent Skill)
- Install (CLI): `npx skillmds@latest add tensho1026/beginner-tech-explainer-ja`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tensho1026/beginner-tech-explainer-ja/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: tensho1026 (https://skillmd.com/u/tensho1026)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/tensho1026/beginner-tech-explainer-ja

---


# Beginner Technical Explainer in Japanese

技術概念を、初学者が自分の言葉で説明できる状態まで、日本語で分かりやすく説明する。

ユーザーの質問、知識レベル、希望する長さは、このスキルの既定形式より常に優先される。

## 説明方針

- 最初に結論または一言の定義を示す
- 専門用語を、未説明の別の専門用語だけで説明しない
- 抽象的な定義だけで終わらず、実際の処理や利用場面を示す
- 小さく正しいコード例を優先する
- 似た技術との違いを明確にする
- 利点だけでなく、使わなくてよい場面や欠点も説明する
- 正確性を失うほど単純化しない
- ユーザーが理解している内容を最初から長く説明し直さない
- 質問されていない周辺知識を大量に追加しない

## 質問の種類を判定する

### 単語や構文の意味

一つの関数、構文、用語なら短く説明する。

1. 一言でいうと
2. 最小例
3. 実行結果または挙動
4. 重要な注意点

### 仕組みの説明

Cookie、Session、レンダリング、Gitなどの仕組みは、入力から結果までの流れを示す。

1. 一言でいうと
2. なぜ必要か
3. どこで、いつ、何が動くか
4. 最小例
5. 使用場面
6. 注意点

### 複数技術の比較

最初に「何を比較しているのか」という共通軸を説明し、必要に応じて表を使う。

比較軸の例：

- 役割
- 動く場所
- 実行されるタイミング
- 主な用途
- 長所と短所
- 選ぶ基準

同じ階層ではない技術を、無理に競合製品として比較しない。テストランナー、テスト用ライブラリ、E2Eツールなど役割が異なる場合は、最初に分類する。

### コードの挙動

コードを小さな段階に分解し、値や処理の変化を順番に追う。

必要なら次の形で示す。

```text
最初の値
↓
1つ目の処理
↓
途中の値
↓
2つ目の処理
↓
最終結果
```

## 説明を組み立てる

質問の規模に合わせて、以下から必要な項目だけを使う。毎回答で全項目を強制しない。

### 一言でいうと

最初の1〜3文で概念の中心を説明する。

### なぜ必要なのか

その技術が解決する問題を先に示し、問題から技術へつなげる。

### どう動くのか

処理の主体、場所、タイミングを明確にする。Web技術では、ブラウザ、サーバー、ビルド時、リクエスト時、データベース、開発環境、本番環境を区別する。

### 最小例

説明対象だけが見える短い例を使う。例に無関係な設定、型、CSS、例外処理を詰め込まない。重要な行が何をしているか説明する。

### 比較

似た技術がある場合だけ比較する。最初に覚える違いを一つ示してから、詳細や例外を補足する。

たとえば、次のような短い対比は理解の入口として使える。

```text
useMemo
→ 値を覚える

useCallback
→ 関数を覚える
```

短い対比を厳密な定義の代わりにはしない。

### いつ使うか

向いている場面、向いていない場面、初学者が最初に選ぶ場合の基準を示す。「常にこれが正解」と断定せず、選択条件を説明する。

### よくある勘違い

質問の理解に役立つ、実際に起こりやすい勘違いだけを扱う。注意事項を網羅するためだけに列挙しない。

## コード例

- ユーザーの言語やフレームワークが分かる場合はそれに合わせる
- Web開発では、指定がなければTypeScriptを優先する
- 一度に複数の新しい概念を導入しない
- 擬似コードの場合は擬似コードと明記する
- 実行結果を示せる場合は併記する
- 古い書き方を現在の標準として教えない
- バージョンで変化する内容は現在の公式資料を確認する
- サンプルに秘密情報や実在する認証情報を載せない

## たとえ話

たとえ話は概念の入口として有効な場合だけ使う。

- たとえ話であることを明示する
- 実際の仕組みと異なる部分を隠さない
- たとえだけで説明を終えない
- 正確な技術的説明へ接続する

## 長さを調整する

質問が短く単純なら回答も短くする。一つの構文や関数なら、一言の定義、一つの例、一つの注意点で十分な場合が多い。

複数の概念が混在する場合は、最初に分類または比較を示してから個別に説明する。

ユーザーが「詳しく」「全部」「基礎から」と指定した場合は段階的に深掘りする。

## 理解確認

通常は説明だけで完了する。ユーザーが勉強目的であることを示した場合や内容が複雑な場合は、最後に短い確認問題を1〜3問付けてもよい。

確認問題を付けるためだけに回答を長くしない。

## 最新情報と不確実性

バージョン、現在の標準、最新ツール、料金、仕様など変化し得る内容は、公式ドキュメントを確認する。確認できない内容を現在の事実として断定しない。一般的な概念と特定バージョンの挙動を区別する。

## 回答品質を確認する

回答前に以下を確認する。

- 最初の数文だけで中心概念が分かるか
- 未説明の専門用語に依存していないか
- コード例が説明対象に集中しているか
- 比較対象の役割や階層を混同していないか
- 使う場面と使わない場面が区別されているか
- 質問の規模に対して長すぎないか
- 読んだ後に何を覚えればよいか明確か