はじめに
Airbnb JavaScript Style Guideは、JavaScriptのコーディング規約として最も有名なものの一つですね。
GitHubで148,000スター以上を獲得していて、これは単なるドキュメントとしては異例の数字です。個人的には、「JavaScriptの書き方で迷ったらとりあえずAirbnbを参考にする」というのが、10年近く定番になっている印象があります。
正直なところ、最初は「スタイルガイドなんて読まなくても書けるじゃん」と思っていたんですよ。でもチーム開発を経験するうちに、「なぜこう書くべきか」という理由が明文化されていることの価値に気づきました。コードレビューで「なんとなくこっちの書き方のほうがいい」という曖昧な指摘をしなくて済むようになる。
ライセンスはMITで、商用利用も含めて自由に使えます。
Airbnb JavaScript Style Guideとは
Airbnbが社内で使用しているJavaScriptのコーディング規約を公開したものです。2014年頃から公開されていて、継続的にメンテナンスされています。
特筆すべきは、単なるルール集ではなく「なぜそう書くべきか」という理由が詳細に説明されていること。これ、意外と重要で、理由がわかると納得してルールに従えるし、例外を判断する基準にもなる。
ES6以降のモダンJavaScriptに対応していて、React向けのスタイルガイドも別途用意されています。
特徴・メリット
1. ESLintとの完璧な連携
eslint-config-airbnbというパッケージが公式に提供されていて、スタイルガイドのルールをそのままESLintで自動チェックできます。
ドキュメントを読んで覚える必要がない。書いたコードがルールに違反していれば、ESLintが教えてくれる。時短になるし、チーム全体で一貫したスタイルを維持できます。
2. 実務で検証されたルール
Airbnbは数千人規模のエンジニアを抱える企業で、このスタイルガイドは実際の大規模プロダクトで使われています。
「理論的に正しい」だけでなく「実務で機能する」ことが検証されている。30代になって思うのは、こういう実績のあるものを採用するのが結局は効率的だということ。
3. 理由が明文化されている
各ルールに「Why?」セクションがあって、なぜそのルールが存在するのか説明されています。
例えば「constを優先してletは必要な時だけ使う」というルールには、「意図せず変数を再代入するバグを防げる」「コードを読む人が変数の性質をすぐ理解できる」といった理由が書かれている。
新人教育にも使えるし、ルールに疑問を持った時の判断基準にもなります。
4. コミュニティの圧倒的な支持
148kスターという数字が示すように、世界中で使われています。
Stack Overflowで質問しても、Airbnbスタイルを前提とした回答が得られることが多い。情報が豊富という点で、コスパ的に優れた選択肢です。
5. React対応
eslint-config-airbnbにはReactのルールも含まれています。JSXの書き方、コンポーネントの命名規則、Hooks のルールなど、React開発に必要なものが網羅されている。
別途React用のESLint設定を探す必要がないのがありがたい。
インストール方法
前提条件
- Node.js 14以上
- npm、yarn、pnpmのいずれか
eslint-config-airbnbのインストール
Reactプロジェクトの場合
# npm
npx install-peerdeps --dev eslint-config-airbnb
# yarn
npx install-peerdeps --dev eslint-config-airbnb --yarn
# pnpm
npx install-peerdeps --dev eslint-config-airbnb --pnpm
install-peerdepsを使うと、必要なpeer dependenciesも一緒にインストールされます。手動で入れようとすると依存関係が複雑なので、これを使うのがおすすめ。
React以外のプロジェクト(純粋なJavaScript/Node.js)
# npm
npx install-peerdeps --dev eslint-config-airbnb-base
# yarn
npx install-peerdeps --dev eslint-config-airbnb-base --yarn
ESLint設定ファイルの作成
.eslintrc.jsonを作成:
{
"extends": ["airbnb"]
}
React以外の場合:
{
"extends": ["airbnb-base"]
}
これだけで動きます。ゼロコンフィグとまではいかないけど、かなりシンプル。
基本的な使い方
リントの実行
# 指定ディレクトリをリント
npx eslint ./src
# 自動修正を適用
npx eslint ./src --fix
package.jsonへの追加
{
"scripts": {
"lint": "eslint ./src",
"lint:fix": "eslint ./src --fix"
}
}
主要なルールの例
Airbnb Style Guideで特に重要なルールをいくつか紹介します。
変数宣言
// Bad: varは使わない
var count = 1;
// Good: constを優先
const count = 1;
// Good: 再代入が必要な場合のみlet
let total = 0;
total += count;
オブジェクトの省略記法
const name = 'John';
const age = 30;
// Bad
const user = {
name: name,
age: age,
};
// Good: プロパティ省略記法を使う
const user = {
name,
age,
};
アロー関数
// Bad: 無名関数
[1, 2, 3].map(function (x) {
return x * 2;
});
// Good: アロー関数を使う
[1, 2, 3].map((x) => x * 2);
分割代入
// Bad
const firstName = user.firstName;
const lastName = user.lastName;
// Good: 分割代入を使う
const { firstName, lastName } = user;
テンプレートリテラル
// Bad: 文字列連結
const message = 'Hello, ' + name + '!';
// Good: テンプレートリテラルを使う
const message = `Hello, ${name}!`;
ルールのカスタマイズ
プロジェクトによっては、一部のルールを変更したいこともあります。
{
"extends": ["airbnb"],
"rules": {
"no-console": "warn",
"import/prefer-default-export": "off",
"react/jsx-filename-extension": [
"error",
{ "extensions": [".jsx", ".tsx"] }
]
}
}
個人的には、import/prefer-default-exportは無効にすることが多い。named exportのほうがリファクタリングしやすいケースも多いので。
実践的なユースケース
TypeScriptプロジェクトでの使用
TypeScriptを使う場合は、追加の設定が必要です。
npm install --save-dev @typescript-eslint/parser @typescript-eslint/eslint-plugin eslint-import-resolver-typescript
.eslintrc.json:
{
"extends": [
"airbnb",
"airbnb-typescript"
],
"parserOptions": {
"project": "./tsconfig.json"
}
}
eslint-config-airbnb-typescriptが公式に提供されているので、これを使うのが楽です。
VS Code連携
settings.jsonに追加:
{
"editor.codeActionsOnSave": {
"source.fixAll.eslint": true
},
"eslint.validate": [
"javascript",
"javascriptreact",
"typescript",
"typescriptreact"
]
}
保存時に自動でESLintの修正が走るので、手動で--fixを実行する必要がなくなります。QOL上がりますね。
Prettierとの併用
AirbnbのスタイルガイドとPrettierを併用する場合、ルールの競合を避ける設定が必要です。
npm install --save-dev eslint-config-prettier
{
"extends": [
"airbnb",
"prettier"
]
}
prettierを最後に追加することで、フォーマット関連のルールはPrettierに任せる形になります。
CI/CD統合
GitHub Actionsでの使用例:
name: Lint
on: [push, pull_request]
jobs:
eslint:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '20'
- run: npm ci
- run: npm run lint
PRでリントエラーがあれば失敗するようにしておくと、コードの品質を維持しやすくなります。
他のスタイルガイドとの比較
主要なスタイルガイドを比較しておきます。
| 観点 | Airbnb | Standard | |
|---|---|---|---|
| セミコロン | あり | なし | あり |
| 厳格さ | 厳しめ | 緩め | 中程度 |
| React対応 | 充実 | 別パッケージ | なし |
| コミュニティ | 最大規模 | 大きい | 中程度 |
| カスタマイズ性 | 高い | 低い | 高い |
Standardはセミコロンなしスタイルで、設定なしで使えるのが売り。ただし、Airbnbほどルールが細かくない。
個人的には、チーム開発ではAirbnb一択ですね。ルールが厳しめなのは最初は面倒に感じるかもしれないけど、長期的には統一されたコードベースを維持できる。
よくある質問
Q: ルールが厳しすぎない?
最初はそう感じるかもしれません。でも、慣れると「なぜこのルールがあるのか」がわかってきて、自然と良いコードが書けるようになります。
どうしても合わないルールがあれば、.eslintrcでオフにすればいい。
Q: 古いプロジェクトに導入できる?
できます。ただし、最初は大量のエラーが出る可能性があります。
# エラー数を確認
npx eslint ./src --format compact | wc -l
まずは--fixで自動修正できるものを直して、残りは段階的に対応していくのが現実的です。
Q: Biomeに移行すべき?
これは悩ましい問題ですね。Biomeは高速だし設定もシンプル。ただ、AirbnbスタイルをそのままBiomeで再現するのは難しい。
新規プロジェクトならBiomeを検討してもいいけど、既存プロジェクトでAirbnbを使っているなら無理に移行する必要はないと思います。
まとめ
Airbnb JavaScript Style Guideを使ってみて感じたこと:
- コードレビューの効率化: 「なんとなく」ではなく「ルールに基づいた」指摘ができる
- 学習効果: Why?セクションを読むと、JavaScript の深い理解が得られる
- チームの統一感: 誰が書いても同じスタイルになる
- 長期的な価値: 10年近く使われている実績がある
チーム開発でJavaScript/TypeScriptを書くなら、導入を検討する価値があります。
ルールが厳しいと感じるかもしれないけど、それは「理由のある厳しさ」です。慣れてくると、むしろガイドラインがあることで迷いなくコードが書けるようになる。
まずは既存プロジェクトの一部に適用してみて、チームの反応を見てから全体に広げていくのがおすすめです。