カスタム投稿タイプとは
「register_post_type」は、カスタム投稿タイプを作成できる関数です。
関数の解説をする前に、まずカスタム投稿タイプについて少しだけ説明します。
カスタム投稿タイプは独自の投稿を作るイメージ
WordPressでよく使うものと言えば、「投稿」と「固定ページ」ではないでしょうか。
カスタム投稿タイプは、その標準の「投稿」とは別に、オリジナルの「投稿」を作るようなものだと思っていただければいいと思います。
既存の「投稿」ではできなかった、こんなすごいことができる！というイメージよりは、かゆいところに手が届くようなイメージでしょうか。
読者よりも、記事を投稿する人が使いやすくなるカスタマイズとも言えそうです。
オススメはプラグインではなくて、「functions.php」に記載すること
カスタム投稿タイプは、実はプラグインを使っても作成できます。
その中でもオススメのプラグインは「Custom Post Type UI」でしょう。
直感的で無駄がなく、日本語にも対応しています。
すでに、多くの人に使われているプラグインです。
しかし、実はこのプラグインでも設定できない項目がいくつかあります。
加えて、他のブログに同じカスタム投稿タイプを作成しようと思っても、プラグインを入れるところから始まります。
もちろん、プラグインを入れたら設定もイチから行わなければなりません。
テーマファイルの「functions.php」に記述する「register_post_type」ならば、コピー＆ペーストをすればよく、移植性に優れています。
（「Custom Post Type UI」には、設定内容を「register_post_type」に自動変換してくれる「Get Code」という機能もありますが、バグも含まれており、実用には至っていません。）
functions.phpに「register_post_type」を指定する方が格段に柔軟で、オススメできます。
「register_post_type」のデメリットと言えば、やはり覚えなくてはならないことでしょうか。
「register_post_type」を噛み砕く
それでは、「register_post_type」の詳しい設定内容を噛み砕いていきましょう。
なお、ここに挙げた設定内容はあくまで一例であり、未知の設定が見つかったりもします・・・。
見つかり次第、この記事に追記していきます。
参考までに、Codex（WordPress公式サイト内のドキュメント）では、例として以下のように記載されています。
function codex_custom_init() {
$labels = array(
'name' => 'Books',
'singular_name' => 'Book',
'add_new' => 'Add New',
'add_new_item' => 'Add New Book',
'edit_item' => 'Edit Book',
'new_item' => 'New Book',
'all_items' => 'All Books',
'view_item' => 'View Book',
'search_items' => 'Search Books',
'not_found' => 'No books found',
'not_found_in_trash' => 'No books found in Trash',
'parent_item_colon' => '',
'menu_name' => 'Books'
);
$args = array(
'labels' => $labels,
'public' => true,
'publicly_queryable' => true,
'show_ui' => true,
'show_in_menu' => true,
'query_var' => true,
'rewrite' => array( 'slug' => 'book' ),
'capability_type' => 'post',
'has_archive' => true,
'hierarchical' => false,
'menu_position' => null,
'supports' => array( 'title', 'editor', 'author', 'thumbnail', 'excerpt', 'comments' )
);
register_post_type( 'book', $args );
}
add_action( 'init', 'codex_custom_init' );
post_type
register_post_type( $post_type , $args );上記は「register_post_type」関数の基本構文です。
第一引数（$post_type）にカスタム投稿の名前を入力します。
これは、URLにも含まれることになるので、よく考えて設定してください。
第二引数（$args）には、上記の例では設定値の変数を入れています。
この書き方に限定するわけではなく、以下の設定値を連想配列で入力してあれば問題ありません。
label
「label」では、投稿タイプの翻訳のための複数形の名前を設定します。と日本語版のCodexには書かれています。
日本語環境では、例えば「book」というカスタム投稿タイプならば「本」という「label」を付けることが多いでしょう。
もちろん、日本語の使用が可能です。
後述する「labels」の「name」値も同様の意味を示しますが、「label」の設定値が優先されます。
初期値：空の場合は、カスタム投稿タイプの英語名が入ります。
labels
「labels」では、主に管理画面でのラベルを設定します。
似たような名前のものが多いですが、基本的にはそのまま見てもらえればわかるかと思います。
需要があれば、解説しますが、今回は割愛します。
ちなみに、上記の例以外にもいくつか変更できる箇所があります。
初期値：空の場合は、「name」に「label」の値がセットされ、「singular_name」に「name」の値がセットされます。
description
例にはありませんが、「description」も設定できます。
文字通り、そのカスタム投稿タイプに対する説明を入力するものです。
簡単な覚書を入力しておくと、後々便利になるでしょう。
記事などに書き出すことも可能だと思います。
初期値：空
public
Codexには、公的に利用するか否かの設定値で、「false」を使用すると、管理画面やフロントエンドで利用できません・・・と書いてありますね。
ちょっとよくわからない表現ですが、結局のところ後述する「exclude_from_search」、「publicly_queryable」、「show_ui」、「show_in_nav_menus」の初期値に影響するという話のようです。
詳しく表現すると、「この投稿タイプでユーザーインターフェースを表示しない(show_ui=false)」、「post_type クエリがフロントエンドで実行できない(publicly_queryable=false)」、「検索結果からこの投稿タイプを除外する(exclude_from_search=true)」、「ナビゲーションメニューで post_type を選択候補から外す(show_in_nav_menus=false)」（日本語版Codexより抜粋）という設定になるようです。
より詳しくは・・・それぞれの項目で解説します。
それぞれを個別に設定する場合は「public」の設定値はあまり意味を成しませんが、通常は「true」で良いでしょう。
初期値：false
show_ui
管理画面にてカスタム投稿タイプを表示するかどうかの設定です。
「false」にすると、管理画面にも一切表示されず、編集等も全くできなくなるようです。
ただし、気になるのはCodexでは「標準のインターフェイスを表示するかどうか」と書いてあるように見えなくもありません。
また、あらかじめ存在する投稿タイプ、例えば「post」や「page」では意図的に「false」に設定しています、とも書いてあります。
この記述を見ると、カスタマイズしたユーザーインターフェイスを表示するには、この設定を「false」にする、という意味にとれますが、どうなんでしょうか。
初期値：「public」の設定と同じ
publicly_queryable
?post_type={post_type_key}
?{post_type_key}={single_post_slug}
?{post_type_query_var}={single_post_slug}
上記のようなURLにアクセスすると、新着順に該当する記事一覧（要は、アーカイブページ）を表示してくれるようです。
通常の用途であれば「true」にすることが多いと思います。
初期値：「public」の設定と同じ
exclude_from_search
上記の例にはありませんが、これは大切な設定値になります。
要は、検索の対象とするかどうかを設定できます。
ここでの検索とは、サイト内での検索です。
検索で引っかかってはまずいようなら、「false」にしてください。
初期値：「public」の設定の反対（「public」が「false」ならば、「exclude_from_search」は「true」）
show_in_nav_menus
「show_ui」が「true」でないと「true」にできません。
ナビゲーションメニューに表示するかどうかの設定のようです。
（「外観」→「メニュー」を示していると思われます）
初期値：「public」の設定と同じ
show_in_menu
「show_ui」が「true」でないと「true」にできません。
管理画面のメニュー（左カラムのメニュー）に表示するかどうかの設定のようです。
この設定のみ、「true」、「false」以外に任意の文字列を設定できます。
任意の文字列と書きましたが、実際には「wp-admin」以下にあるPHPファイル名を指定すると（例えば投稿を編集する際にアクセスする「edit.php」を指定すると）、そのメニューのサブメニューとしてカスタム投稿タイプを設定できます。
show_in_admin_bar
管理バーに表示するかどうかの設定のようです。
menu_position
管理画面の左サイドメニューでの表示位置を変更できます。
数字を指定するのですが、既存のメニューにはすでに数字がふってあるので、それを参考にします。
5 – 投稿
10 – メディア
15 – リンク
20 – 固定ページ
25 – コメント
60 – 1つ目の境界線
65 – プラグイン
70 – ユーザー
75 – ツール
80 – 設定
100 – 2つ目の境界線
上記はCodexより抜粋です。
上記に従うと、「menu_position」を「5」にすると「投稿」の下に表示され、「4」にすると「投稿」の上に表示されます。
ちなみに確定情報ではないですが、「0」または「1」で「ダッシュボード」の上に、「2」または「3」で「ダッシュボード」の下に表示されるようです。
menu_icon
管理画面の左サイドメニューにあるアイコン（投稿だとピンのマークでしょうか）を変更できます。
なにも指定しないと、ピンのマークになります。
これはなかなか面白そうな設定ですね！
capability_type
これを指定することで、独自の権限を設定できます。
何も指定しないと、「投稿」と同様の権限が付与されます。
この設定単体ではあまり意味を成しませんが、「add_role」などと併用することで、該当するカスタム投稿タイプだけに独自の権限を振ることができます。
大人数が管理するようなWordPressサイトの場合は、この設定は要チェックでしょう。
hierarchical
記事の階層構造を許可するかどうかを設定できます。
supports
投稿時に、使用できる投稿用のパーツを指定できます。
余分なものを指定しないことで、すごくすっきりとした投稿画面にカスタマイズできます。
指定できるものは以下のようなものがあるようです。
‘title’
‘editor’ (content)
‘author’
‘thumbnail’ (featured image, current theme must also support post-thumbnails)
‘excerpt’
‘trackbacks’
‘custom-fields’
‘comments’ (also will see comment count balloon on edit screen)
‘revisions’ (will store revisions)
‘page-attributes’ (menu order, hierarchical must be true to show Parent option)
‘post-formats’ add post formats, see Post Formats