この記事の要点

samp 要素はプログラム・コンピューターからの出力例を表すインライン要素 Sample (見本) の略。コマンド実行結果・エラーメッセージ・ログなどに使う 既定スタイル: 等幅フォント (monospace) で表示される 関連要素との使い分け: code (ソースコード) / kbd (ユーザー入力) / samp (出力) 入れ子可能: <samp> の中に <kbd> を入れてシステムからのキー操作指示などを表現 CSS で samp { ... } セレクタを使って配色・背景・余白を調整できる

samp 要素とは

samp 要素（Sample Output）は、コンピューターやプログラムからの出力例を表す HTML のインライン要素です。「サンプル出力」の意味で、コマンド実行結果やエラーメッセージ、ログ抜粋などの表示に使います。

ブラウザの既定スタイルでは等幅フォント (monospace) でレンダリングされるため、見た目もコンソール出力風になります。

基本構文

<p>コマンドを実行すると次のように出力されます:</p>
<p>
  <samp>Hello, World!</samp>
</p>

典型的なユースケース

1. コマンド出力

<p>
  <code>ls -la</code> を実行すると <samp>total 16</samp> のような出力が始まります。
</p>

2. エラーメッセージ

<p>
  ファイルが無い場合、次のエラーが出ます:
</p>
<p>
  <samp>cat: hoge.txt: No such file or directory</samp>
</p>

3. プログラムの実行結果

<p>
  <code>System.out.println("Hello")</code> の出力は
  <samp>Hello</samp> です。
</p>

関連要素との使い分け

要素	意味	例
code	ソースコード・コマンド・識別子	<code>ls -la</code>
kbd	ユーザーが入力する文字・キー	<kbd>Ctrl + C</kbd>
samp	プログラム / コンピューターからの出力	<samp>Hello</samp>
var	変数・引数	<var>x</var>
pre	整形済みテキスト（複数行）	複数行のコード/出力をブロック表示

複数行の出力 (pre と組合せ)

<p>git status の出力例:</p>
<pre><samp>On branch main
Your branch is up to date with 'origin/main'.

nothing to commit, working tree clean</samp></pre>

samp はインライン要素なので複数行の出力には pre でブロック化するのが定番です。

kbd / samp / var の入れ子

<!-- システムからの入力指示 (samp内のkbd) -->
<p>
  画面に <samp>パスワードを入力: <kbd>****</kbd></samp> と表示されたら入力してください。
</p>

<!-- 変数を含む出力 (samp内のvar) -->
<p>
  <samp>Welcome, <var>USERNAME</var>!</samp>
</p>

仕様上、samp の中に kbd や var を入れて意味の細分化ができます。

CSS でスタイリング

/* 基本: ターミナル風配色 */
samp {
  font-family: ui-monospace, "SFMono-Regular", Menlo, monospace;
  background: #1e293b;
  color: #e2e8f0;
  padding: 0.1em 0.3em;
  border-radius: 3px;
  font-size: 0.92em;
}

/* ブロックレベルにしたい場合 */
.terminal samp {
  display: block;
  padding: 1em;
  white-space: pre;
  overflow-x: auto;
}

/* エラー出力を赤く */
samp.error { color: #ff6b6b; }
samp.success { color: #51cf66; }

アクセシビリティとセマンティクス

• スクリーンリーダーは特別な扱いをしないことが多いが、「これはプログラム出力」という意味は HTML 構造から伝わる
• 装飾だけが目的なら span + CSS のほうが軽量だが、意味があるなら samp を使うほうが SEO / 検索キャッシュ / 読み上げに有益
• 視覚的な強調は CSS で行い、要素の選択は意味で決めるのが原則

記事や技術文書での実用パターン

<h2>npm の動作確認</h2>

<p>次のコマンドを実行します:</p>
<pre><kbd>npm --version</kbd></pre>

<p>正しくインストールされていれば、以下のような出力が表示されます:</p>
<pre><samp>10.2.4</samp></pre>

<p>もしバージョン番号ではなく
<samp>command not found: npm</samp>
が出る場合は、Node.js を再インストールしてください。</p>

記事を書くときに code / kbd / samp をきちんと使い分けると読者の理解度が確実に上がります。装飾だけの目的でも、適切な要素を選ぶ習慣をつけたいところです。

samp 要素が技術文書で重宝される理由

技術文書や API リファレンス、チュートリアル記事を書いていると、コマンド・ユーザー入力・プログラム出力・ファイルパス・変数名など、種類の異なる「コードっぽい文字列」が大量に登場します。すべて code 要素で囲んでしまうと、読者は何がコマンドで何が出力結果なのか、文脈から推測しないと分からなくなります。samp 要素を出力に対して使うだけで、視覚的にも意味的にも明確な区別ができ、読者の理解スピードが大きく上がります。

とくに長いチュートリアルでは、「このコマンドを打ったら、こういう出力が出るはず」というステップ・バイ・ステップの解説が頻出します。コマンドは kbd、想定される出力は samp で囲むと、読者は自分の画面と本文の出力を一目で比較でき、間違いを発見しやすくなります。これは画像で出力例を貼るよりも軽量で、テキスト検索にも引っかかるため、技術文書の品質を底上げするテクニックとして覚えておきたいところです。

samp 要素を活用したスタイル設計の考え方

samp 要素は既定で等幅フォントになりますが、CSS でさらに表現を強化できます。多くの技術系サイトでは、samp に対してターミナル風の暗色背景と緑系の文字色を当ててコンソール出力風に演出しています。これによって読者は無意識のうちに「ここから先は機械が返してきた結果だ」と理解でき、自分の作業ログと照らし合わせるストレスが減ります。

さらに、エラー出力は赤系、成功メッセージは緑系というクラス分けを用意しておくと、長いコードブロックの中でも視線誘導が効きます。実装する際は samp.error や samp.success のようにクラスを切るだけで済むため、CSS の負荷も最小限です。出力例の長さや種類に応じてマークアップを使い分けると、技術文書の「読みやすさ」「正確さ」「信頼性」が同時に高まります。

samp 要素と機械可読性

samp 要素は意味的なマークアップなので、検索エンジンのクローラーや支援技術（スクリーンリーダー、翻訳ツールなど）も内容を区別して扱える可能性があります。たとえば翻訳サービスは samp 内のテキストを「機械が返した固定の出力」と判定し、安易に翻訳しないという振る舞いをすることがあります。これは「メッセージそのもの」を保護したい技術記事にとって、思いがけずありがたい挙動です。

また、Markdown から HTML に変換する SSG (静的サイトジェネレーター) を運用している場合、独自シンタックスで samp 要素を生成できるようにしておくと、技術ブログ全体の品質を底上げできます。たとえば「output: ...」のようなブロック記法を samp + pre に変換するプラグインを導入するだけで、長期的な記事資産がより読みやすくなり、SEO 的にも構造化されたページとして評価されやすくなります。

意味的マークアップは「やってもやらなくても見た目は同じ」と思われがちですが、長期運用される文書サイトにおいてはアクセシビリティ、機械可読性、保守性、検索エンジン対応など多方面でじわじわ効いてくる種類の投資です。samp 要素のような小さな要素でも、正しく使い続ければ数年後のメンテナンス品質に明確な差が現れるため、テンプレートやスタイルガイドにあらかじめ組み込んでおくことを強くおすすめします。

チュートリアル記事を書く人へのアドバイス

初心者向けのチュートリアルを書くときは、コマンド入力と出力の区別を明確にすることが何より大切です。読者が画面の前で同じことを試している最中、自分の入力欄に何を書くべきか、画面に表示されているものが正しい応答か、判断に迷う場面が必ず訪れます。kbd と samp を使い分けてマークアップしておけば、視覚的にも意味的にもこの区別がはっきりするため、読者が迷う頻度が確実に下がります。

長期間にわたって読まれる教材コンテンツでは、版を重ねるごとにコマンドや出力が少しずつ変わっていきます。たとえばツールのバージョンが上がって出力フォーマットが変わると、当時の samp 部分を最新のものに差し替える必要が出てきます。マークアップが一貫していれば、テンプレートエンジンで一括置換しやすく、メンテナンス工数を抑えられます。逆にすべてを単なる code や pre で書いていると、後から「これは入力？それとも出力？」と人間が判断しなければならず、更新作業の負担が膨らんでいくのです。最初の一手間が、結果的に大きな省力化に繋がります。

FAQ

Q: code 要素で同じ見た目になるなら samp 要らないのでは？
A: 見た目は似ますが、意味は異なります。「これは出力」と「これはコード本体」を区別したい技術文書では samp が適切。

Q: ブロック要素にできる？
A: 標準ではインライン。CSS で display: block; にすればブロック表示にできるが、複数行なら pre + samp の組合せが自然。

Q: pre の中で改行はどう扱われる？
A: pre 内なので改行も空白もそのまま保持。samp がインラインでも pre 側の白文字保持ルールが効きます。

Q: ブラウザ対応は？
A: HTML2.0 から存在する古典要素なので、すべてのブラウザで対応済み。心配不要。

関連記事

• data要素