命名規則とは？AWSのリソースの命名規則を考える上でのポイントを解説

命名規則とは？

命名規則とは、変数名などのプログラムソースコード上で用いる、識別子についての一貫したルールのことです。

プログラム言語仕様や開発環境などによって定められているものと、組織やチームで内部的に定められているものがあります。古くはコンピュータのリソース節約の為に、名前の文字数の制限が定められることもありました。

命名規則は、なぜ必要なのでしょうか？

開発効率や保守性の向上の為に必要です。

クラス名やメソッド名、関数名、定数名、変数名、プログラム上で扱う対象に名前を付ける機会は多くありますが、複数人で開発を行う場合を考えてみましょう。

それぞれの考え方、基準などで名前を付けていくと、プログラムの可読性や視認性が損なわれることが考えられます。プログラムに限らず、AWSリソースにも同様のことがいえます。

役割が分かりづらいAWSリソース名になっていると、AWSリソース削除の判断を難しくしてしまったり、用途を勘違いすることによって、オペレーションミスが起こることが考えられます。

そこで、名前の付け方に一貫したルールを設けて、それに従って識別名を付けるようにするのが命名規則です。

よく定義された命名規則に従うことで、意味や機能、使い方等が名前からある程度推測することが可能になり、リソースの名前自体がドキュメントの役割を果たすようになります。

命名規則を考える上で、守るべきルールは？

規格化された標準等は、ありません。

命名規則の決め方はプログラミング言語や開発環境の制約、組織や開発メンバーの考え方や方針によって様々です。必ずしも良し悪しや優劣はありません。プログラミング言語やフレームワークによっては、仕様上に定められている命名規則が存在する場合もあります。

では、実際にはどのようにAWSリソースを命名したらよいのでしょうか。次項では命名規則をどのように考えればよいのかについて説明します。

命名規則のポイント

AWSリソースの目的、役割を考えます。

AWSリソース名から知りたいことを考えましょう。AWSのリソース毎に知りたい情報は異なりますが、どのようなリソースであっても知りたい情報には以下のようなものがあります。

〇何のシステムか（対象のシステム）
〇どのような環境か（本番、検証、開発）

また、AWSリソース毎に以下のようなものが考えられます。

〇Subnet/RouteTable
・ネットワークレイヤー（パブリック、プライベート、プロテクト）

〇EC2/IAMRole
・種別（アプリケーションサーバー、Webサーバー、メールサーバー、DBサーバー）

〇S3
・用途（ログ、静的コンテンツ、ファイル）

命名規則の具体的な表現の方法には、以下のようなものがあります。

キャメルケース

アルファベットで複合語やフレーズ（句）を一語に繋げて表記する際に、各単語や要素の先頭を大文字で表記する方式を「キャメルケース」（camel case）といいます。語句の途中に大文字が出現する場合をラクダ（camel）のこぶに例えた表現です。

使用言語：JavaScript、Java等

プログラミング言語など要素名にスペース（空白）が使えないので、「isEmpty」のように、複数の単語からなるフレーズを繋げて表記します。

その際、「getStaffName」のように最初の文字を小文字で表記する方式を「ローワーキャメルケース（Lower Camel Caseまたは、LCC）」と呼びます。

また、「GetStaffAddress」のように最初の文字を大文字で表記する方式を「アッパーキャメルケース（Upper Camel Caseまたは、UCC）」または「パスカルケース（Pascal Case）」と呼びます。

スネークケース

アルファベットで複合語やフレーズ（句）を一語に繋げて表記する際に、単語と単語の間をアンダースコア（_）で区切って表現する方式を「スネークケース」（snake case）といいます。

大文字・小文字が混在せずに、まっ平らな様子を蛇（snake）に例えた表現です。「list_order_date」や「HTTP_ACCEPT_LANGUAGE」のような表記がこれに当たります。

使用言語：C、PHP 等

ケバブケース

アルファベットで複合語や、フレーズ（句）を一語に繋げて表記する際に、単語と単語の間をハイフン（-）で区切って表現する方式を「ケバブケース」（kebab case）といいます。

串に刺さっているケバブ（kebab）の肉に例えた表現です。「data-add-customer」のような表記がこれに当たります。「チェインケース」ともいわれます。

使用言語：HTML、CSS 等

ハンガリアン記法

プログラムのソースコードを書く際、特別な名前の先頭（接頭辞）や末尾（接尾辞）に決まった意味のフレーズ（句）を付与する方式をハンガリアン記法（Hungarian notation）といいます。

ハンガリー出身のチャールズ・シモニー（Charles Simonyi）が考案者であることに由来しています。

（参考）アプリケーションハンガリアン

変数名の先頭に意味や目的、種別などを意味する接頭辞（prefix）を付加することで、意味として誤ったコードや処理を記述することを未然に防ぐというものです。

接頭辞には短いものが好まれます。

例えば車体重量（単位：ボンド）を表す変数名を「lbVehicleWeight」、車体重量（単位：キロ）を表す変数名を「kgVehicleWeight」のように命名しておくと、それらを直接加算するコード「pondVehicleWeight+ kiroVehicleWeight」は不自然であることが一目瞭然となります。

この方式のことを「アプリケーションハンガリアン」と呼びます。

（参考）システムハンガリアン

データ型などプログラム上の形式的な仕様を表現する接頭辞を付与します。

一般的にハンガリアン記法としてよく知られている命名規則です。

文字列（string）は「s」、整数値（integer）は「i」、真偽値（boolean）は「b」という具合に（言語によって異なる）、「sMessageId」は文字列、「iCount」は整数値、「bMale」は真偽値、であることが分かります。

AWSリソースを命名する

AWSリソースにはケバブケースがおすすめです。

使用する文字は「半角英数字とハイフン(-)等の一部記号のみ」とします。特殊文字を安易に使用することは、プログラムで処理する際の苦しみを生むことになるので避けましょう。

S3のバケットの名前には大文字や、アンダースコアを含めることはできません。WebACLではハイフンが利用できない等の一部例外もありますが、基本的にはケバブケースケースで作成することが可能です。

AWSリソースに適正な名前を付けて、効率的な運用を！

今回は命名規則とは何か、そしてAWSリソースの命名規則を考える上でのポイントをご紹介しました。リソースの名前を適当に設定したとしても、システムの動作には関係ありません。しかし、不要な作業が発生する潜在的な要因となります。

システムハンガリアンにて環境毎にリソースを区別した場合は、開発コードを本番環境に移行する際に問題が発生する場合があります。移行時にこれらすべての文字列の変更が必要になるからです。

大量のグローバル検索/置換のオペレーションが必要になり、このようなオペレーションは非常に手間がかかり、エラーの原因になる可能性もあります。

解決手段としては、プログラム側で対応する方法か、AWSにて命名規則のサポートをコードに実装する方法もあります。それらを活用して、今一度リソース名を見直してみては如何でしょうか。