こんにちは。Tomoyuki（@tomoyuki65）です。

モンスターハンターワイルズは発売後に賛否両論ありましたが、2026年2月18日（水）に最終アップデート配信が完了し、かつ拡張コンテンツを開発中であることも公表されました。

モンハンワイルズ単品としては各種コンテンツが出揃ったので、もう一度プレイしてみようかなという復帰勢の方や、拡張コンテンツ発売前に駆け込みたい方向けに、ストーリークリア後にやることをまとめておこうと思います。

よければぜひ参考にしてみて下さい！

【モンハンワイルズ】復帰勢向けクリア後にやることまとめ｜拡張前に進める装備・金策・装飾品・護石・エンドコンテンツ解説

まずモンハンワイルズは、これまでモンハンシリーズをプレイしたことがない初心者でも楽しめるように、ストーリークリアまで（チャプター6-2「萌芽の産声」まで）の難易度は優しくなっており、普通に遊びながらクリアしていけます。

ストーリークリア直前ぐらいでHRが40前後、最後のチャプターを進めるにはHR50以上必要になるため、ストーリークリア時点でHRが50ぐらいです。

その後は、HR100以上にしないと受注できないクエストがあるため、ストーリークリア後は装備を整えながらHR100を目指して進めます。

ストーリークリア後のHR50ぐらいからHR100までにやること

武器について

武器については、武器種問わず、生産武器を最終強化まですれば十分なので、何らかの生産武器を最終強化まで強化して下さい。

属性に関しては通常使いは麻痺や爆破などがおすすめで、特定のモンスターでは火属性や龍属性を使う感じになります。

HR50までに作っておいた方がいいおすすめ汎用装備

※空きスロット：②スロ×3、①スロ×3（武器種に応じて、渾身、逆襲、スタミナ急速回復、回避距離UP、耳栓、納刀術、体術、環境適応、水場・油泥適応、緩衝などを付ける）

ゴア装備4個でシリーズスキル「黒蝕一体II」（大型モンスターと対峙した時、狂竜症に感染し、攻撃力が上昇する。克服時、さらに攻撃力が上昇する。）が付き、かつ「無我の境地Lv3」（狂竜ウイルスに感染した時、かなり克服しやすくなる。克服状態の時、さらに会心率+10%）を組み合わせて使うのが単純に強いです。

※狂竜症感染時に攻撃力+10、克服時にさらに攻撃力+10、会心率+25%（+15% + 無我の境地Lv3の10%）

また、ゴア装備を使うと火耐性と雷耐性を20以上にして属性やられを防ぐことが不可能になるため、イベントクエストで生産可能な「ラウンドアイα」を使って属性やられ耐性Lv3（すべての属性やられを無効化）を付けてます。

・イベントクエスト「その閃光は私に効かない」

※ラウンドアイαの必要素材：花舞のカタログ×2、歴戦狩猟の証Ⅱ×2、暗器蛸の尖爪×3、ユニオン鉱石×4

・挑戦の護石の素材

挑戦の護石I（生産）：雌火竜の上鱗×6、雌火竜の翼膜×3、怪鳥の上鱗×5、竜玉×1

挑戦の護石II（強化）：歴戦狩猟の証Ⅲ×5、歴戦狩猟の証Ⅱ×3、波衣竜の水玉×1、火竜の紅玉×1

防具を強化するための鎧玉を集めるイベントクエスト

・堅鎧玉を集めるイベントクエスト「白い暴れん坊、手に負えない」

・重鎧玉を集めるイベントクエスト「天滄無窮」

※防具は鎧玉を集めて最大強化して下さい。

装飾品を集めるためのイベントクエスト

・防具用の装飾品を集めるイベントクエスト「白き王子の豪勇魂」

・武器用の装飾品を集めるイベントクエスト「千の光はすべて刃」

※装飾品集めは調査クエストの方が効率がいいですが、調査クエストを集めるのが面倒ならこれらのイベントクエストで集めましょう。

金策について

金策については色々ありますが、モンスターを周回して余った素材を売却するのが単純に楽だと思います。

例えばラギアクルスの素材の場合、海竜の上鱗が2200z、海竜の上皮が3300zで売却可能です。

HR50以上である程度装備が整ったら2種類の歴戦王を狩猟して装備集め

・イベントクエスト「無言の閃耀」（歴戦王レ・ダウ）

・イベントクエスト「漣の古き都に眠れば愛し」（歴戦王ウズ・トゥナ）

・作りたい汎用装備

※空きスロット：③スロ×2、②スロ×1、①スロ×2

歴戦王の装備を3個付けるとグループスキル「根性【果敢】（ヌシの魂）」（致命的な大ダメージを一度だけ軽減。発動前は攻撃力が上がり防御力が下がる。発動後は防御力と耐性値が上がる。）が発動できます。

ゴア装備が2個になって火力は下がりますが、星9以上のクエストでは一撃で致命傷になる技を使ってくるモンスターが多いため、基本的にグループスキル「根性【果敢】（ヌシの魂）」を付けるのがおすすめです。

また、各種耐性系の珠（耐火珠【1】、耐水珠【1】、耐雷珠【1】、耐氷珠【1】、耐龍珠【1】、耐絶珠【1】、耐裂珠【1】、耐震珠【1】）を3個ずつ集めておくのと、属性やられ対策としては各種耐性系の珠と合わせて食事も活用することでステータスを20以上にして防げます。

※3つの食材を使った食事で属性耐性+5以上にできます。または各種食事券（ログインボーナス、配信バウンティ、タルコロなどで入手可能）を使って大集会場で食事をすれば属性耐性+10にできます。

・抗狂の護石の素材

抗狂の護石I（生産）：狂竜結晶の欠片×5、影蜘蛛の堅鋏角×2、風鋏竜の上尾爪×2、カブレライト鉱石×4

抗狂の護石II（強化）：狂竜結晶×5、雪獅子の剛毛×4、雪獅子の髭×3、ノヴァクリスタル×1

抗狂の護石III（強化）：黒蝕竜の上鱗×6、黒蝕竜の鋭惨爪×4、黒蝕竜の尖触角×2、黒蝕竜の闇玉×1

HR100まで上げる

上記のような装備集めをしつつ、HRを100まで上げて下さい。

HR100からやること

歴戦王ヌ・エグドラを狩猟して装備集め

・イベントクエスト「闇き漁火よ、呪われてあれ」（歴戦王ヌ・エグドラ）

※火耐性20以上、環境適応Lv2（Lv1：暑さ、寒さの影響を無効化する。Lv2：地形によるダメージを無効化する。）を付けるの推薦です。

・作りたい汎用装備

※空きスロット：②スロ×1、①スロ×4

頭と手をエグゾルスγ装備に変えるとスロットを増やせ、各種耐性系の装飾品を付けやすくできます。

護石は武器種に合わせて最適なものを装備して下さい。（例えば太刀なら渾身の護石III、ライトボウガンなら跳躍の護石IIIなど）

・渾身の護石の素材

渾身の護石I（生産）：影蜘蛛の鋭爪×6、影蜘蛛の堅鋏角×3、毒怪鳥の頭×3、鳥竜玉×1

渾身の護石II（強化）：歴戦狩猟の証Ⅲ×5、歴戦狩猟の証Ⅱ×3、暗器蛸の暗玉×1、煌雷竜の雷玉×1

渾身の護石III（強化）：SF6チケット×3、赫猿獣の堅殻×5、黒蝕竜の闇玉×1、波衣竜の水玉×1

※SF6チケットは、大集会場にあるスト6コラボの闘技大会クエスト「覚悟の証明、強者の証」、「うぬは真の強者たるか」で入手可能です。（スト6コラボのサイドミッション「強さの頂き、その先へ」で解放されます。）

・体術の護石の素材

体術の護石I（生産）：赫猿獣の鱗×2、赫炎結晶×1、赫猿獣の背甲×1、クラノダスの頭殻×1

体術の護石II（強化）：怪鳥の上鱗×6、怪鳥の翼×4、怪鳥の耳×3、カブレライト鉱石×5

体術の護石III（強化）：護兇爪竜の尖爪×4、護兇爪竜の鋭牙×3、護闢獣の鋭爪×3、獣玉×1

体術の護石IV（強化）：黒蝕竜の上暗翼×4、黒蝕竜の尻尾×2、護兇爪竜の宝玉×1、黒蝕竜の闇玉×1

体術の護石V（強化）：歴戦狩猟の証Ⅲ×5、泡狐竜の紫上毛×6、泡狐竜の上錦ヒレ×4、泡狐竜の水玉×1

・早気の護石の素材

早気の護石I（生産）：暗器蛸の皮×2、暗器蛸の爪×1、獄焔蛸の皮×1、暗器蛸の髄液×1

早気の護石II（強化）：ゴム質の上皮×4、毒怪鳥の尻尾×2、ライトクリスタル×2、鳥竜玉×1

早気の護石III（強化）：黄金の硬角質×6、暗器蛸の尖爪×4、闢獣の鋭牙×3、暗器蛸の暗玉×1

・跳躍の護石の素材

跳躍の護石I（生産）：沙海竜の甲殻×2、沙海竜の頭殻×1、影蜘蛛の爪×1、ドラグライト鉱石×2

跳躍の護石II（強化）：沙海竜の堅殻×6、刺花蜘蛛の鋭爪×4、タリオスの上鱗×5、竜玉×1

跳躍の護石III（強化）：火竜の堅殻×6、火竜の翼×4、赫猿獣の堅甲×3、火竜の紅玉×1

防具の限界突破と強化

HR100から防具の限界突破も可能になるため、以降の歴戦王ジン・ダハドやゴグマジオスに挑む前にちゃんと防具も強化して下さい。

歴戦王ジン・ダハドを狩猟して装備集め

・イベントクエスト「ジュデッカの心臓」（歴戦王ジン・ダハド）

※氷耐性20以上、環境適応Lv1、拘束耐性Lv3（近接のみ）、回避性能Lv5（大集会場の「あつあつアズズ料理」を食べるとお食事回避術【大】が付き、これが回避性能Lv3相当なので、装備で回避性能Lv2を付ければ実現できます。）を付けるの推薦です。

特に胴の「ダハディラメイルγ」が優秀なので作っておきましょう。

ゴグマジオス狩猟前の準備

全ての歴戦王装備を集め終わったら、次はゴグマジオスの狩猟になりますが、ゴグマジオスでは火属性武器（第1、第2フェーズで使用）と龍属性武器（最終フェーズで使用）が必要になるため、まだ作ってない場合は作りましょう。

また、上記で記載した通り、防具も限界突破および強化して下さい。

ゴグマジオスを狩猟して装備集め

・イベントクエスト「咎は戦禍に睡臥する」

※火属性武器と龍属性武器が必須です。防具は火耐性20以上（大集会場の食事込みで実現可能です。）、耐震Lv2、水場・油泥適応Lv1、環境適応Lv1（第2フェーズで灼熱地帯になるので周回するならあると便利。無くても高台にいるヒンヤリコロモムシで代用可能。）、ハンター生活Lv1（第2フェーズの分脈束の運搬が楽になります。）を付けるの推薦です。

※第3フェーズは小型破竜筒（スリンガー）をチャージしてから弱点に当てると高ダメージを出せ、抑制にも繋がります。尚、周回であれば小型破竜筒を上手く使ってパーツ破壊を最優先にするようにしましょう。

・巨戟アーティア武器の作成

ゴグマジオスを狩猟できるようになると、巨戟アーティア武器を作れるようになり、これが生産武器より強いので優先的に作りましょう。

一応エンドコンテンツの一つになり、最終的には厳選したいところですが、とりあえず龍属性の武器を一つ作りましょう。

まずアーティア武器の生産については、基礎攻撃力増強のパーツを3つ使って作り、復元強化でナナイロカネを50個使って強化して下さい。（復元強化の際に復元ボーナスがランダムで付きますが、厳選するのは大変なのでステータスはなんでもいいです。）

次にゴグマジオスの狩猟で入手した巨戟変異パーツを3個（一部の武器を除き、デメリットが無い属性激化タイプを選ぶ）使い、アーティア武器を巨戟アーティア武器に強化します。

次にナナイロカネの場合は20個使い、巨戟アーティア武器をさらに巨戟復元強化して復元ボーナスのステータスをアップします。

尚、巨戟アーティア武器にはシリーズスキルとグループスキルが付き、最終的にはこれを厳選しますが、主に「巨戟龍の黙示録 + ヌシの魂」または「黒蝕竜の力 + ヌシの魂」の組み合わせが一番いいです。

※素材に余裕があれば、ゴグマジオスの狩猟を早くするためにも、火属性武器も同じように作って下さい。

・作りたい汎用装備

※空きスロット：③スロ×2、②スロ×4、①スロ×5

ゴグマジオス装備を4個付けるとシリーズスキル「宣戦呼応II」（Iが戦闘中の大型モンスターが怒ると属性攻撃値が上昇する。IIがIの効果が上昇し、一定時間、ダメージを防ぐ防壁を得る。）が付き、特に防壁の効果が非常に優秀（75ダメージ分の被ダメージを無効化でき、防壁発動後から2分50秒経過すれば再発動も可能）です。

歴戦王装備を外すのでグループスキル「根性【果敢】（ヌシの魂）」がなくなりますが、食事でシルドニンニク・特秀を使うか、大集会場の食事「とれたてシルド料理」でお食事ド根性【大】（体力が約45%以上ある時、1回のみそれを超えるダメージを受けても力尽きず同時に体力が回復する。）を付与できるのでこれで代用可能です。

※巨戟アーティア武器を厳選して「巨戟龍の黙示録 + ヌシの魂」を付けられれば、「宣戦呼応II + 根性【果敢】」を付けられるようになります。（これが最終目標です。）

・挑戦の護石IIIの素材

挑戦の護石III（強化）：凍峰竜の狩猟証γ×3、凍峰竜の尖爪×6、巨戟龍の大爪×6、戦火の龍玉×1

星10の歴戦王アルシュベルドを狩猟して装備集め

・イベントクエスト「孤独から出でし君という自由」

※いずれかの属性の巨戟アーティア武器が必須（属性武器じゃないと強化解除して大ダウン取れないため）です。防具は龍耐性20以上か属性やられ耐性Lv3（属性ダメージが大事なので）、気絶耐性Lv3（主に近接のみ）、回避性能Lv5（ガード可能武器以外の場合は食事込みで実現する。空中から突進してコンボしてくるのは最初に相手方向へ回避するといい。）を付けるの推薦です。

・作りたい汎用装備

※空きスロット：②スロ×3、①スロ×3

巨戟アーティア武器を厳選して「巨戟龍の黙示録 + ヌシの魂」を付与できていれば、上記の装備でスキル「宣戦呼応II + 加速再生I + 根性【果敢】+ 属性やられ耐性Lv3」を同時に付けられます。

弱いモンスター用にはシリーズスキル「黒蝕一体」装備がおすすめ

星10クエストなど強力なモンスター相手にはゴグマジオス装備でシリーズスキル「宣戦呼応II」を付けるのが安定ですが、それが必要ない弱いモンスター用としてはシリーズスキル「黒蝕一体」を付けた装備がおすすめです。

スキルを厳選した巨戟アーティア武器（黒蝕竜の力 + ヌシの魂）に加え、ゴア装備やナディアさんの追加サイドミッションをクリアして作れる「クイーンα」装備を組み合わせると、シリーズスキル「黒蝕一体II」を組み込んで火力アップを図れます。

エンドコンテンツ

巨戟アーティア武器の厳選

エンドコンテンツの一つ目は、巨戟アーティア武器の厳選になります。

まずはアーティア武器を生産する段階において、使用している武器種の各属性ごとに復元強化で付くボーナス種類の厳選をします。

次に巨戟アーティア武器へ強化する際や、スキルの再付与にて、「巨戟龍の黙示録 + ヌシの魂」または「黒蝕竜の力 + ヌシの魂」のスキルを付けるように厳選します。

最後に巨戟復元強化で復元ボーナスのステータスアップの厳選をします。

尚、巨戟アーティア武器の厳選をやろうとすると大量のお金も必要になりますが、ゴグマジオスの不要な素材を売却すると、厳選用の資金を調達できます。

護石ガチャ

エンドコンテンツの二つ目は、星10の歴戦王クエストで入手できる「古びたお守り」によるレア度の高い護石ガチャ（レア7 or レア8の護石）です。

武器種に応じて以下の3種類のいずれかが狩猟しやすい（星9の歴戦王とそんなにかわらない）ので、お好みのクエストを周回して下さい。

・イベントクエスト「楼蘭の睥睨者」（歴戦王レ・ダウ）

・イベントクエスト「トゥオネラの番人より告ぐ」（歴戦王ウズ・トゥナ）

・イベントクエスト「黒き揺り篭の吾子」（歴戦王ヌ・エグドラ）

または、失敗率も高いですが狩猟時の報酬が美味しいのは歴戦王アルシュベルドになります。

・イベントクエスト「孤独から出でし君という自由」（歴戦王アルシュベルド）

最後に

今回は復帰勢や拡張前に駆け込みたい人向けにストーリークリア後にやることをまとめました。

使用している武器種によって細かい必要な装備などは変わるので、その点は別途調べていただく必要がありますが、汎用的な部分はまとめられたと思います。

これからモンハンワイルズをプレイする方は、ぜひ参考にしてみて下さい！

こんにちは。Tomoyuki（@tomoyuki65）です。

Webアプリケーション開発の際には、別途DB操作に関わる管理画面を作ったりしますが、PythonのDjangoを使うと簡単に管理画面が作れるらしいというのを知ったので、試してみることにしました！

この記事では、そんなPythonのDjangoで管理画面を開発する方法についてまとめます。

PythonのDjangoで管理画面を開発する方法まとめ

まずは以下のコマンドを実行し、各種ファイルを作成します。

$ mkdir django-admin && cd django-admin
$ mkdir -p deploy/docker/local/py && touch deploy/docker/local/py/Dockerfile
$ mkdir -p deploy/docker/local/db && touch deploy/docker/local/db/Dockerfile
$ mkdir -p deploy/docker/local/db/init && touch deploy/docker/local/db/init/init.sql
$ touch .env compose.yml

※ローカル開発環境の構築については、いつものようにDockerを利用するため、試したい方は事前にDocker DesktopなどをインストールしてDockerを使える環境を準備して下さい。

次に作成したファイルをそれぞれ以下のように記述します。

・「deploy/docker/local/py/Dockerfile」

FROM python:3.14.0-slim-trixie

# タイムゾーン設定
ENV TZ=Asia/Tokyo

# パッケージ管理用のpoetryをインストール
RUN pip3 install --no-cache-dir poetry

# [開発用] 仮想環境を作成
RUN poetry config virtualenvs.in-project true

WORKDIR /py

EXPOSE 8000

※今回はPythonのバージョン「3.14」を使います。各種ライブラリのパッケージ管理には「poetry」を使います。開発時専用のライブラリを入れるためにpoetryのコンフィグ設定で仮想環境設定「virtualenvs.in-project」を有効化しています。

・「deploy/docker/local/db/Dockerfile」

FROM postgres:18.1

ENV LANG ja_JP.utf8

# PostgreSQLの日本語化で「ja_JP.utf8」を使うために必要
RUN apt-get update && \
    apt-get install -y locales && \
    rm -rf /var/lib/apt/lists/* && \
    localedef -i ja_JP -c -f UTF-8 -A /usr/share/locale/locale.alias ja_JP.UTF-8

・「deploy/docker/local/db/init/init.sql」

-- usersテーブルの作成
CREATE TABLE "public"."users" ("id" bigint NOT NULL GENERATED BY DEFAULT AS IDENTITY, "uid" character varying NOT NULL, "last_name" character varying NOT NULL, "first_name" character varying NOT NULL, "email" character varying NOT NULL, "created_at" timestamptz NOT NULL, "updated_at" timestamptz NOT NULL, "deleted_at" timestamptz NULL, PRIMARY KEY ("id"));
CREATE INDEX "user_deleted_at" ON "public"."users" ("deleted_at");
CREATE UNIQUE INDEX "users_email_key" ON "public"."users" ("email");
CREATE UNIQUE INDEX "users_uid_key" ON "public"."users" ("uid");

※管理画面は後から作成されることが多く、対象のDBには既にテーブルが存在することを前提に試すため、DBコンテナ起動時にSQLを実行して「users」テーブルを作成しておきます。尚、今回はDBにPostgreSQLを使用します。

・「.env」

ENV=local
DB_NAME=pg-db
DB_USER=pg-user
DB_PASSWORD=pg-password
DB_HOST=db-django

※ローカル環境用の環境変数ファイル

・「compose.yml」

services:
  django:
    container_name: django-admin
    build:
      context: .
      dockerfile: ./deploy/docker/local/py/Dockerfile
    volumes:
      - .:/py
    ports:
      - "8000:8000"
    env_file:
      - .env
    tty: true
    stdin_open: true

次に以下のコマンドを実行し、Dockerコンテナをビルドします。

$ docker compose build --no-cache

次に以下のコマンドを実行し、パッケージ管理用のpoetryの初期化をします。

docker compose run --rm django poetry init

コマンド実行後、対話形式で各種設定について聞かれるので、「Package name [py]:」は「django-admin」、「Author [None, n to skip]:」は「n」、「Would you like to define your main dependencies interactively? (yes/no) [yes]」は「no」、「Would you like to define your development dependencies interactively? (yes/no) [yes]」は「no」を入力して実行し、それ以外はそのまま実行して進めます。

完了後、poetryの設定ファイル「pyproject.toml」が作成されます。

次に以下のコマンドを実行し、今回利用する各種パッケージをインストールします。

$ docker compose run --rm django poetry add django "psycopg[binary]"
$ docker compose run --rm django poetry add --dev ruff

※djangoの他、PostgreSQL用のドライバー「psycopg[binary]」および、開発専用ライブラリとして「ruff」（フォーマッター + 静的コード解析）を使います。

次に以下のコマンドを実行し、Djangoのプロジェクトを作成します。

$ docker compose run --rm django poetry run django-admin startproject myapp ./src

コマンド実行後、以下のように各種ファイルが作成されればOKです。

次に設定用のファイル「src/myapp/settings.py」を以下のように修正します。

・「src/myapp/settings.py」

"""
Django settings for myapp project.

Generated by 'django-admin startproject' using Django 6.0.

For more information on this file, see
https://docs.djangoproject.com/en/6.0/topics/settings/

For the full list of settings and their values, see
https://docs.djangoproject.com/en/6.0/ref/settings/
"""

import os
from pathlib import Path

# Build paths inside the project like this: BASE_DIR / 'subdir'.
BASE_DIR = Path(__file__).resolve().parent.parent


# Quick-start development settings - unsuitable for production
# See https://docs.djangoproject.com/en/6.0/howto/deployment/checklist/

# SECURITY WARNING: keep the secret key used in production secret!
SECRET_KEY = 'django-insecure-jr21o1cjct+97fvqon)d$hdjm8oo7h0ko_th=dlv!8@ts#4!&5'

# SECURITY WARNING: don't run with debug turned on in production!
DEBUG = True

ALLOWED_HOSTS = []


# Application definition

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    # プロジェクトのディレクトリ追加
    'myapp'
]

MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
]

ROOT_URLCONF = 'myapp.urls'

TEMPLATES = [
    {
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        'DIRS': [],
        'APP_DIRS': True,
        'OPTIONS': {
            'context_processors': [
                'django.template.context_processors.request',
                'django.contrib.auth.context_processors.auth',
                'django.contrib.messages.context_processors.messages',
            ],
        },
    },
]

WSGI_APPLICATION = 'myapp.wsgi.application'


# Database
# https://docs.djangoproject.com/en/6.0/ref/settings/#databases

DATABASES = {
    # PostgreSQLへの接続設定
    'default': {
        'ENGINE': 'django.db.backends.postgresql',
        'NAME': os.environ['DB_NAME'],
        'USER': os.environ['DB_USER'],
        'PASSWORD': os.environ['DB_PASSWORD'],
        'HOST': os.environ['DB_HOST'],
        'PORT': '5432',
    }
}


# Password validation
# https://docs.djangoproject.com/en/6.0/ref/settings/#auth-password-validators

AUTH_PASSWORD_VALIDATORS = [
    {
        'NAME': 'django.contrib.auth.password_validation.UserAttributeSimilarityValidator',
    },
    {
        'NAME': 'django.contrib.auth.password_validation.MinimumLengthValidator',
    },
    {
        'NAME': 'django.contrib.auth.password_validation.CommonPasswordValidator',
    },
    {
        'NAME': 'django.contrib.auth.password_validation.NumericPasswordValidator',
    },
]


# Internationalization
# https://docs.djangoproject.com/en/6.0/topics/i18n/

# 日本語化設定
LANGUAGE_CODE = 'ja'
TIME_ZONE = 'Asia/Tokyo'

USE_I18N = True

USE_TZ = True


# Static files (CSS, JavaScript, Images)
# https://docs.djangoproject.com/en/6.0/howto/static-files/

STATIC_URL = 'static/'

※INSTALLED_APPSにプロジェクトのディレクトリを追加、DATABASESにPostgreSQLへの接続設定を追加、LANGUAGE_CODEとTIME_ZONEで日本語化設定をしています。

次にファイル「deploy/docker/local/py/Dockerfile」、「compose.yml」をそれぞれ以下のように修正します。

・「deploy/docker/local/py/Dockerfile」

FROM python:3.14.0-slim-trixie

# タイムゾーン設定
ENV TZ=Asia/Tokyo

# パッケージ管理用のpoetryをインストール
RUN pip3 install --no-cache-dir poetry

# [開発用] 仮想環境を作成
RUN poetry config virtualenvs.in-project true

WORKDIR /py

# poetry.lockから依存関係をインストール
COPY pyproject.toml poetry.lock .
RUN poetry install --no-root

COPY ./src ./src

EXPOSE 8000

・「compose.yml」

services:
  django:
    container_name: django-admin
    build:
      context: .
      dockerfile: ./deploy/docker/local/py/Dockerfile
    command: poetry run python ./src/manage.py runserver 0.0.0.0:8000
    volumes:
      - ./pyproject.toml:/py/pyproject.toml
      - ./poetry.lock:/py/poetry.lock
      - ./src:/py/src
    ports:
      - "8000:8000"
    env_file:
      - .env
    tty: true
    stdin_open: true
    depends_on:
      - db-django
  db-django:
    container_name: django-db
    build:
      context: .
      dockerfile: ./deploy/docker/local/db/Dockerfile
    environment:
      POSTGRES_DB: ${DB_NAME}
      POSTGRES_USER: ${DB_USER}
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      TZ: Asia/Tokyo
      # ローカル環境でもパスワードを有効化する設定
      POSTGRES_INITDB_ARGS: --auth-local=scram-sha-256 --auth-host=scram-sha-256
    volumes:
      - ./deploy/docker/local/db/init:/docker-entrypoint-initdb.d
      - db-django-data:/var/lib/postgresql
    ports:
      - "5432:5432"
    env_file:
      - .env
volumes:
  db-django-data:

次に以下のコマンドを実行し、Dockerコンテナの再ビルドおよび起動をします。

$ docker compose down
$ docker compose build --no-cache
$ docker compose up -d

次にブラウザで「http://localhost:8000」を開き、以下のような画面が表示されればOKです。

次に以下のコマンドを実行し、DBからスキーマ情報を取得します。

$ docker compose exec django poetry run python ./src/manage.py inspectdb > ./src/myapp/models.py

※尚、後からテーブルを追加するような場合は、別のファイル名で出力し、元の「src/myapp/models.py」に別途手動で設定を追加するようにして下さい。

コマンド実行後、以下のようにファイルが作成されればOKです。

※DBからスキーマ情報を取得した場合、メタ情報の設定に「managed = False」が追加され、マイグレーション関連の処理が実行されないようになっています。

次にファイル「src/myapp/models.py」を以下のように修正します。

・「src/myapp/models.py」

from django.db import models
from django.utils.translation import gettext_noop

class Users(models.Model):
    id = models.BigAutoField(primary_key=True)
    uid = models.CharField(unique=True)
    last_name = models.CharField()
    first_name = models.CharField()
    email = models.CharField(unique=True)
    # 作成日と更新日を自動設定するように修正
    created_at = models.DateTimeField(auto_now_add=True)
    updated_at = models.DateTimeField(auto_now=True)
    deleted_at = models.DateTimeField(blank=True, null=True)

    class Meta:
        managed = False
        db_table = 'users'
        # 表示設定（日本語化で翻訳されないようにgettext_noopを使用）
        verbose_name = gettext_noop("User")
        verbose_name_plural = gettext_noop("Users")

※DBスキーマ用のモデル設定はこのファイルで行います。

次に以下のコマンドを実行し、管理画面用の設定ファイルを追加します。

$ touch src/myapp/admin.py

次に作成したファイルを以下のように記述します。

・「src/myapp/admin.py」

from django.contrib import admin
from django.contrib.admin.models import LogEntry
from .models import Users

# サイト名の設定
admin.site.site_header = "Django Admin"
admin.site.site_title = "Django Admin"

# 操作履歴用にデフォルトであるモデルを管理画面に追加
admin.site.register(LogEntry)

# DBスキーマに関するモデルを管理画面に追加
admin.site.register(Users)

※管理画面用の設定はこのファイルで行います。

次に以下のコマンドを実行し、管理画面用の設定をDBに追加するためのマイグレーションを実行します。

$ docker compose exec django poetry run python ./src/manage.py migrate

※マイグレーションを実行すると、管理画面用の各種テーブル等がDBに作成されます。もしモデルの定義のメタ情報で「managed = False」が設定されていなければ、自動でマイグレーションが実行されてテーブルなど作成されたりするので注意して下さい。尚、メタ情報で「managed = False」を設定していても、管理者ユーザーの権限設定で使用できるデータを追加するためにマイグレーションの実行は必要なので、後からモデルを追加した際は再度マイグレーションの実行が必要です。

コマンド実行後、以下のようにマイグレーションが成功しているログ出力が表示されればOKです。

次に以下のコマンドを実行し、管理画面用のスーパーユーザーを作成します。

$ docker compose exec django poetry run python ./src/manage.py createsuperuser

コマンド実行後、各種入力を求められるため、今回はユーザー名「local-db-root」、メールアドレスは無し、パスワード「pass-pg-2512」を設定して実行します。

次に以下のコマンドを実行し、コンテナを再起動させます。

$ docker compose down
$ docker compose up -d

次にブラウザで「http://localhost:8000/admin」を開き、以下のように管理画面用のログイン画面が表示されればOKです。

次に先ほど作成したスーパーユーザーのユーザー名「local-db-root」とパスワード「pass-pg-2512」でログインし、以下のように表示されればOKです。

これでDBスキーマから設定した対象テーブルのCRUD処理や、管理画面として最低限必要になる管理者ユーザー機能（パーミッション機能を含む）や、操作履歴のログ機能が簡単に実装できます。

CRUD機能を試す

では簡単に実装できたCRUD機能を試してみます。

まずはデータを追加するため、Usersの右側の「+追加」をクリックします。

次に「Uid」、「Last name」、「First name」、「Email」をそれぞれ入力し、画面下の「保存」をクリックします。

これでデータ追加がされたため、一覧画面から対象のデータをクリックします。

これで追加したデータの詳細が確認できます。

次に「Email」を修正し、画面下の「保存」をクリックします。

これでデータの更新ができたので、一覧画面から対象のデータをクリックします。

対象データの詳細画面から「Email」を確認し、更新されていればOKです。

続けて、画面右下の「削除」をクリックします。

削除の確認画面が表示されるので、「はい、大丈夫です」をクリックします。

これでデータが削除されればOKです。

操作履歴を確認する

次にメニューに追加しておいた操作履歴を確認してみます。

まずはトップページから「ログエントリー」をクリックします。

次に削除に関するデータをクリックしてみます。

これで操作履歴の詳細が確認できます。

表示などをカスタマイズして改善する

上記のようにCRUD機能は簡単に実装できますが、そのままだと画面表示がイマイチだったり、実務では論理削除が必要になったりするため、いくつかカスタマイズしてみます。

では管理画面用の設定ファイル「src/myapp/admin.py」を以下のように修正します。

・「src/myapp/admin.py」

from django.contrib import admin
from django.contrib.admin.models import LogEntry
from django.utils import timezone

from .models import Users

# サイト名の設定
admin.site.site_header = "Django Admin"
admin.site.site_title = "Django Admin"


###############################
# 操作履歴をメニューに追加する設定
###############################


# デフォルトで存在するモデルを使用する
@admin.register(LogEntry)
class LogEntryAdmin(admin.ModelAdmin):
    # 一覧画面に表示するフィールド設定
    list_display = (
        "action_time",
        "user",
        "content_type",
        "object_repr",
        "action_flag",
    )

    # 一覧画面のフィルター設定
    list_filter = ("action_flag", "content_type")

    # 検索用の対象フィールド
    search_fields = ("object_repr", "change_message", "user__username")

    # 変更不可フィールド設定
    readonly_fields = (
        "action_time",
        "user",
        "content_type",
        "object_repr",
        "action_flag",
    )

    # 詳細画面の表示設定
    fieldsets = (
        (
            None,
            {
                "fields": (
                    "action_time",
                    "user",
                    "content_type",
                    "object_repr",
                    "action_flag",
                ),
            },
        ),
    )


###############################
# 共通フィルター用のクラス定義
###############################


# 削除日用のクラス定義
class DeletedAtFilter(admin.SimpleListFilter):
    title = "削除日（deleted_at）"
    parameter_name = "deleted"

    # 選択肢の設定
    def lookups(self, request, model_admin):
        return (
            ("alive", "未削除"),
            ("deleted", "削除済み"),
        )

    # 選択肢に対するクエリ設定
    def queryset(self, request, queryset):
        value = self.value()
        if value == "alive":
            return queryset.filter(deleted_at__isnull=True)
        if value == "deleted":
            return queryset.filter(deleted_at__isnull=False)
        return queryset


###############################
# DBモデルをメニューに追加する設定
###############################


# usersの設定
@admin.register(Users)
class UsersAdmin(admin.ModelAdmin):
    # 一覧画面に表示するフィールド設定
    list_display = [field.name for field in Users._meta.get_fields()]

    # 一覧画面のフィルター設定
    list_filter = ((DeletedAtFilter),)

    # 検索用の対象フィールド
    search_fields = ("id", "uid", "last_name", "first_name", "email")

    # 変更不可フィールド設定
    readonly_fields = ("id", "created_at", "updated_at")

    # 詳細画面の表示設定
    fieldsets = (
        (
            None,
            {
                "fields": (
                    "id",
                    "uid",
                    "last_name",
                    "first_name",
                    "email",
                    "created_at",
                    "updated_at",
                    "deleted_at",
                ),
            },
        ),
    )

    # 単体用の論理削除設定
    def delete_model(self, request, obj):
        obj.updated_at = timezone.now()
        obj.deleted_at = timezone.now()
        obj.save()

    # 一括用の論理削除設定
    def delete_queryset(self, request, queryset):
        queryset.update(updated_at=timezone.now(), deleted_at=timezone.now())

※削除処理時は論理削除をするように設定

次に以下のコマンドを実行し、フォーマット修正を行います。

$ docker compose exec django poetry run ruff format .
$ docker compose exec django poetry run ruff check . --select I --fix

次に以下のコマンドを実行し、静的コード解析でエラーがでないことを確認します。

$ docker compose exec django poetry run ruff check .

CRUD機能を試す

では再度CRUD機能を試してみます。

まずはデータを追加するため、Usersの右側の「+追加」をクリックします。

次に「Uid」、「Last name」、「First name」、「Email」をそれぞれ入力し、画面下の「保存」をクリックします。

これでデータが追加され、一覧画面からも対象データの詳細を確認できます。

続けて対象データのIDをクリックします。

これで追加したデータの詳細が確認できます。

次に「Email」を修正し、画面下の「保存」をクリックします。

これでデータの更新ができたので、一覧画面から対象データのIDをクリックします。

対象データの詳細画面から「Email」を確認し、更新されていればOKです。

続けて、画面右下の「削除」をクリックします。

削除の確認画面が表示されるので、「はい、大丈夫です」をクリックします。

これで削除処理ができたので、対象データのDeleted_atに削除日が設定されていればOKです。

操作履歴を確認する

次に再度操作履歴を確認してみます。

まずはトップページから「ログエントリー」をクリックします。

これで一覧画面からも詳細が確認できます。

続けて最新の操作履歴をクリックしてみます。

これで操作履歴の詳細が確認できます。

グループ機能と管理ユーザー機能について

詳細は割愛しますが、デフォルトでグループ機能や管理ユーザー機能もついており、これらを使うことで各種権限を付与した管理ユーザーの作成も可能です。

※例えばユーザーテーブルを確認することだけができる管理ユーザーの作成などが可能

最後に

今回はPythonのDjangoで管理画面を開発する方法についてまとめました。

実際に試してみると、本当に簡単に管理画面を作ることができ、かつシンプルでスマートな感じもめちゃめちゃ良かったです。

私は以前にPHPのLaravel-Adminでの管理画面開発の経験もありますが、それと比較しても作りやすかったので、今後はこれを使っていくべきだなと思いました。

今回は簡単な例をご紹介しましたが、他にも色々カスタマイズはできそうなので、より深掘りしていくのもありかなと思います。

ということで、管理画面を作るならPythonのDjangoがおすすめなので、興味がある方はぜひ参考にしてみて下さい。

こんにちは。Tomoyuki（@tomoyuki65）です。

日進月歩で生成AI関連が盛り上がっていますが、将来的にもあらゆるアプリケーションにAI関連機能が組み込まれるのは避けられないでしょう。

そんなAI関連機能を作るならPythonを使うのが主軸であり、かつマイクロサービスとして作るなら「FastAPI」というフレームワークを使いながら、DDD（ドメイン駆動設計）と呼ばれる方法で作られることが多いのではと思います。

そこでこの記事では、PythonのFastAPIでDDD構成のバックエンドAPIを開発する方法についてまとめます。

PythonのFastAPIでDDD（ドメイン駆動設計）構成のバックエンドAPIを開発する方法まとめ

まずは以下のコマンドを実行し、各種ファイルを作成します。

$ mkdir fastapi-domain && cd fastapi-domain
$ mkdir -p deploy/docker/local/py && touch deploy/docker/local/py/Dockerfile
$ mkdir -p src/myapp && touch src/myapp/__init__.py src/myapp/main.py
$ touch .env compose.yml

※ローカル開発環境の構築については、いつものようにDockerを利用するため、試したい方は事前にDocker DesktopなどをインストールしてDockerを使える環境を準備して下さい。

次に作成したファイルをそれぞれ以下のように記述します。

・「deploy/docker/local/py/Dockerfile」

FROM python:3.14.0-slim-trixie

# パッケージ管理用のpoetryをインストール
RUN pip3 install --no-cache-dir poetry

# [開発用] 仮想環境を作成
RUN poetry config virtualenvs.in-project true

WORKDIR /py

EXPOSE 9004

※今回はPythonのバージョン「3.14」を使います。各種ライブラリのパッケージ管理には「poetry」を使います。開発時専用のライブラリを入れるためにpoetryのコンフィグ設定で仮想環境設定「virtualenvs.in-project」を有効化しています。

・「src/myapp/main.py」

from fastapi import FastAPI
from fastapi.responses import PlainTextResponse

app = FastAPI()


@app.get("/", response_class=PlainTextResponse)
def root() -> str:
    return "Hello World !!"

・「.env」

ENV=local
TEST_VALUE=test123

※ローカル環境用の環境変数ファイル

・「compose.yml」

services:
  fastapi:
    container_name: fastapi
    build:
      context: .
      dockerfile: ./deploy/docker/local/py/Dockerfile
    volumes:
      - .:/py
    ports:
      - "9004:9004"
    env_file:
      - .env
    tty: true
    stdin_open: true

次に以下のコマンドを実行し、Dockerコンテナをビルドします。

$ docker compose build --no-cache

次に以下のコマンドを実行し、パッケージ管理用のpoetryの初期化をします。

$ docker compose run --rm fastapi poetry init

コマンド実行後、対話形式で各種設定について聞かれるので、「Package name [py]:」は「fastapi-domain」、「Author [None, n to skip]:」は「n」、「Would you like to define your main dependencies interactively? (yes/no) [yes]」は「no」、「Would you like to define your development dependencies interactively? (yes/no) [yes]」は「no」を入力して実行し、それ以外はそのまま実行して進めます。

完了後、poetryの設定ファイル「pyproject.toml」が作成されます。

次に以下のコマンドを実行し、今回利用する各種パッケージをインストールします。

$ docker compose run --rm fastapi poetry add fastapi uvicorn pydantic
$ docker compose run --rm fastapi poetry add --dev ruff mypy

※FastAPI用の「fastapi」、「uvicorn」、「pydantic」、開発専用ライブラリとして「ruff」（フォーマッター + 静的コード解析）、「mypy」（型チェック）を使います。

次にpoetryの設定ファイル「pyproject.toml」を以下のように修正します。

[project]
name = "fastapi-domain"
version = "0.1.0"
description = ""
authors = [
    {name = "Your Name",email = "you@example.com"}
]
readme = "README.md"
requires-python = ">=3.14"
dependencies = [
    "fastapi (>=0.122.0,<0.123.0)",
    "uvicorn (>=0.38.0,<0.39.0)",
    "pydantic (>=2.12.5,<3.0.0)"
]

# パッケージの読み込み設定
packages = [
    { include = "myapp", from = "src" }
]


[build-system]
requires = ["poetry-core>=2.0.0,<3.0.0"]
build-backend = "poetry.core.masonry.api"

[dependency-groups]
dev = [
    "ruff (>=0.14.7,<0.15.0)",
    "mypy (>=1.19.0,<2.0.0)"
]


# =========================================================
# ruffの設定（フォーマッター + 静的コード解析）
# =========================================================
[tool.ruff]
# Pythonのバージョン指定
target-version = "py314"

# チェック対象外のディレクトリ
exclude = [
    ".venv",
    ".mypy_cache",
    ".ruff_cache",
]

# ==========
# lint設定
# ==========
lint.select = [
    "E", # Pycodestyle エラー
    "F", # Pyflakes
    "B", # bugbear（バグ検出）
    "I", # isort（import整理）
    "UP", # pyupgrade（最新構文）
]

# =========================================================
# mypyの設定（型チェック）
# =========================================================
[tool.mypy]
# Pythonのバージョン指定
python_version = "3.14"

# 厳密モードの有効化
strict = true

# 追加の表示設定
warn_unused_configs = true # 無効な設定や使われていない設定を警告として表示
warn_unreachable = true # 到達不可能コードを警告
show_error_context = true # エラー発生箇所の前後コンテキストを表示
show_column_numbers = true # エラー箇所の列番号を表示

# Pydantic v2の設定
plugins = ["pydantic.mypy"]

# チェック対象外のディレクトリ
exclude = [
    ".venv",
    ".mypy_cache",
    ".ruff_cache",
]

# 外部ライブラリは無視 
ignore_missing_imports = true

※[project]にpackagesの設定を追加（srcディレクトリのmyappパッケージを読み込む）、ruffとmypyの設定（ほぼ最小構成のはず！）を追加します。

次にファイル「deploy/docker/local/py/Dockerfile」、「compose.yml」をそれぞれ以下のように修正します。

・「deploy/docker/local/py/Dockerfile」

FROM python:3.14.0-slim-trixie

# タイムゾーン設定
ENV TZ=Asia/Tokyo

# パッケージ管理用のpoetryをインストール
RUN pip3 install --no-cache-dir poetry

# [開発用] 仮想環境を作成
RUN poetry config virtualenvs.in-project true

WORKDIR /py

# poetry.lockから依存関係をインストール
COPY pyproject.toml poetry.lock .
RUN poetry install --no-root

COPY ./src ./src
EXPOSE 9004

・「compose.yml」

services:
  fastapi:
    container_name: fastapi
    build:
      context: .
      dockerfile: ./deploy/docker/local/py/Dockerfile
    command: poetry run uvicorn myapp.main:app --app-dir src --reload --host 0.0.0.0 --port 9004
    volumes:
      - ./pyproject.toml:/py/pyproject.toml
      - ./poetry.lock:/py/poetry.lock
      - ./src:/py/src
    ports:
      - "9004:9004"
    env_file:
      - .env
    tty: true
    stdin_open: true

※commandでオプション「–app-dir src」を付与し、「myapp」がトップレベルになるようにしています。これによってimport時のファイルパスが短くなります。

次に以下のコマンドを実行し、Dockerコンテナの再ビルドおよび起動します。

$ docker compose down
$ docker compose build --no-cache
$ docker compose up -d

次に以下のコマンドを実行し、ログ出力を確認します。

$ docker compose logs

コマンド実行後、以下のようにFastAPIの起動に関するログ出力がされていればOKです。

次にブラウザで「http://localhost:9004」を開き、以下のように「Hello World !!」が出力されていればOKです。

OpenAPIの仕様書を確認する方法

FastAPIではOpenAPI形式の仕様書が自動で作成されるため、確認したい場合はブラウザで「http://localhost:9004/docs」または「http://localhost:9004/redoc」を開くと確認できます。

・「http://localhost:9004/docs」

・「http://localhost:9004/redoc」

コード修正後に利用するコマンド

今回は開発専用ライブラリとして「ruff」（フォーマッター + 静的コード解析）、「mypy」（型チェック）を使えるようにしたため、コードを修正した際は必要に応じて以下のコマンドを実行し、フォーマット統一および、警告やエラーがでていないことを確認して下さい。

・フォーマット修正

$ docker compose exec fastapi poetry run ruff format .

・importの並び替え（フォーマット修正）

$ docker compose exec fastapi poetry run ruff check . --select I --fix

・静的コード解析によるチェック

$ docker compose exec fastapi poetry run ruff check .

・型チェック

$ docker compose exec fastapi poetry run mypy .

共通設定用の各種ファイル作成

次に以下のコマンドを実行し、共通設定用の各種ファイルを作成します。

$ mkdir -p src/myapp/infrastructure/config
$ touch src/myapp/infrastructure/__init__.py src/myapp/infrastructure/config/settings.py src/myapp/infrastructure/config/__init__.py
$ mkdir -p src/myapp/infrastructure/logger
$ touch src/myapp/infrastructure/logger/__init__.py src/myapp/infrastructure/logger/logger.py
$ mkdir -p src/myapp/application/context
$ touch src/myapp/application/__init__.py src/myapp/application/context/__init__.py src/myapp/application/context/request_context.py
$ mkdir -p src/myapp/presentation/middleware
$ touch src/myapp/presentation/__init__.py src/myapp/presentation/middleware/__init__.py src/myapp/presentation/middleware/request_middleware.py
$ mkdir -p src/myapp/presentation/exception
$ touch src/myapp/presentation/exception/__init__.py src/myapp/presentation/exception/definitions.py src/myapp/presentation/exception/handlers.py
$ mkdir -p src/myapp/infrastructure/database
$ touch src/myapp/infrastructure/database/__init__.py src/myapp/infrastructure/database/database.py
$ mkdir -p src/myapp/presentation/schema/common
$ touch src/myapp/presentation/schema/__init__.py src/myapp/presentation/schema/common/error.py src/myapp/presentation/schema/common/__init__.py

※Pythonの場合は、各ディレクトリをパッケージと認識させるための「__init__.py」も作成します。（最近は省略もできるっぽいですが、テストコードなどで影響が出る可能性があったりして、基本的に作った方がいいようです。）

次に作成したファイルをそれぞれ以下のように記述します。

・「src/myapp/infrastructure/config/settings.py」

from pydantic_settings import BaseSettings, SettingsConfigDict


class Settings(BaseSettings):
    env: str = "local"
    # デフォル値を付けない場合は必須になるので注意！
    test_value: str

    model_config = SettingsConfigDict(
        env_file=".env",
    )


# サーバー起動時にインスタンス化
# .envがない場合はOSから環境変数を読み込む
settings = Settings()


def get_settings() -> Settings:
    return settings

※環境変数を読み込むためのファイルです。

・「src/myapp/infrastructure/config/__init__.py」

from .settings import Settings, get_settings

__all__ = ["Settings", "get_settings"]

・「src/myapp/infrastructure/logger/logger.py」

import logging
from logging.config import dictConfig

from myapp.application.context import request_id
from myapp.infrastructure.config.settings import get_settings

settings = get_settings()


class EnvFilter(logging.Filter):
    def filter(self, record: logging.LogRecord) -> bool:
        record.env = settings.env
        return True

class RequestIDFilter(logging.Filter):
    def filter(self, record: logging.LogRecord) -> bool:
        record.request_id = request_id.get()
        return True


LOGGING = {
    "version": 1,
    "disable_existing_loggers": False,
    "filters": {
        "request_id_filter": {"()": RequestIDFilter},
        "env_filter": {"()": EnvFilter},
    },
    "formatters": {
        "default": {
            "format": (
                "%(asctime)s [%(levelname)s] "
                "ENV=%(env)s - %(name)s "
                "[request_id=%(request_id)s] "
                "%(message)s"
            )
        }
    },
    "handlers": {
        "console": {
            "class": "logging.StreamHandler",
            "filters": ["request_id_filter", "env_filter"],
            "formatter": "default",
        }
    },
    "root": {
        "level": "INFO",
        "handlers": ["console"],
    },
}


def init_logging() -> None:
    dictConfig(LOGGING)


def get_logger(name: str = "fastapi-domain") -> logging.Logger:
    return logging.getLogger(name)

※ロガーの設定変更が必要な場合はこのファイルを修正して下さい。

・「src/myapp/infrastructure/logger/__init__.py」

from .logger import get_logger, init_logging

__all__ = ["init_logging", "get_logger"]

※「__init__.py」を設定することで、他のファイルからimportする時のパスを短くできます。

・「src/myapp/application/context/request_context.py」

from contextvars import ContextVar

# リクエストID（リクエスト単位で一意のID）
request_id: ContextVar[str | None] = ContextVar("request_id", default=None)

※リクエスト単位で一意の値を持たせられるようにするため、コンテキスト変数を作成します。

・「src/myapp/application/context/__init__.py」

from .request_context import request_id

__all__ = ["request_id"]

・「src/myapp/presentation/middleware/request_middleware.py」

import uuid

from starlette.middleware.base import BaseHTTPMiddleware, RequestResponseEndpoint
from starlette.requests import Request
from starlette.responses import Response

from myapp.application.context import request_id
from myapp.infrastructure.logger import get_logger


class RequestMiddleware(BaseHTTPMiddleware):
    async def dispatch(
        self, request: Request, call_next: RequestResponseEndpoint
    ) -> Response:
        # UUIDの取得
        new_uuid = str(uuid.uuid4())

        # リクエストID用コンテキストにUUIDを設定
        request_id.set(new_uuid)

        # レスポンスヘッダーにX-Request-IDを設定
        response = await call_next(request)
        response.headers["X-Request-ID"] = new_uuid

        # リクエスト開始ログ出力
        logger = get_logger()
        logger.info("start request !!")

        return response

※コンテキストとレスポンスヘッダーにリクエストIDを設定します。

・「src/myapp/presentation/middleware/__init__.py」

from .request_middleware import RequestMiddleware

__all__ = ["RequestMiddleware"]

・「src/myapp/presentation/exception/definitions.py」

######################
# 例外定義
######################

# DBエラー
class DatabaseError(Exception):
    def __init__(self, message: str):
        self.message = message
        super().__init__(message)

※カスタム例外を定義します。

・「src/myapp/presentation/exception/handlers.py」

from typing import cast

from fastapi import Request
from fastapi.exception_handlers import request_validation_exception_handler
from fastapi.exceptions import RequestValidationError
from fastapi.responses import JSONResponse

from myapp.infrastructure.logger import get_logger

######################
# 例外用のハンドラー定義
######################


# RequestValidationError用
async def request_validation_error_handler(
    request: Request, exc: Exception
) -> JSONResponse:
    cast_exc = cast(RequestValidationError, exc)
    logger = get_logger()
    logger.warning(f"バリデーションエラー: {cast_exc.errors()}")
    return await request_validation_exception_handler(request, cast_exc)

# バリデーションエラー
async def valid_error_exception_handler(
    request: Request, exc: Exception
) -> JSONResponse:
    return JSONResponse(
        status_code=422,
        content={"detail": str(exc)},
    )


# DBエラー
async def db_error_exception_handler(request: Request, exc: Exception) -> JSONResponse:
    return JSONResponse(
        status_code=500,
        content={"detail": str(exc)},
    )


# 共通エラー
async def general_exception_handler(request: Request, exc: Exception) -> JSONResponse:
    return JSONResponse(
        status_code=500,
        content={"detail": f"Internal Server Error: {str(exc)}"},
    )

※例外発生時の処理を制御させるためのハンドラー設定です。

・「src/myapp/presentation/exception/__init__.py」

from .definitions import DatabaseError
from .handlers import (
    db_error_exception_handler,
    general_exception_handler,
    request_validation_error_handler,
    valid_error_exception_handler,
)

__all__ = [
    "request_validation_error_handler",
    "valid_error_exception_handler",
    "DatabaseError",
    "db_error_exception_handler",
    "general_exception_handler",
]

・「src/myapp/infrastructure/database/database.py」

# 今回はDBインスタンスはダミーとする。
def get_db() -> str:
    return "DBインスタンスのダミー"

※今回はDBは使わないで進めるため、ダミーとして文字列を返すように定義する。実際にDBを使う場合は、インスタンスを返すようにして下さい。

・「src/myapp/infrastructure/database/__init__.py」

from .database import get_db

__all__ = ["get_db"]

・「src/myapp/presentation/schema/common/error.py」

from pydantic import BaseModel, ConfigDict


# 400 Bad Request
class BadRequestResponse(BaseModel):
    detail: str

    # OpenAPI用設定
    model_config = ConfigDict(
        # 書き換え不可設定
        frozen=True,
        # 「Example Value」に表示されるJSON
        json_schema_extra={
            "example": {
                "detail": "Bad Request",
            }
        },
    )


# 401 Unauthorized
class UnauthorizedResponse(BaseModel):
    detail: str

    # OpenAPI用設定
    model_config = ConfigDict(
        # 書き換え不可設定
        frozen=True,
        # 「Example Value」に表示されるJSON
        json_schema_extra={
            "example": {
                "detail": "Unauthorized",
            }
        },
    )


# 422 Unprocessable Entity
class UnprocessableEntityResponse(BaseModel):
    detail: str

    # OpenAPI用設定
    model_config = ConfigDict(
        # 書き換え不可設定
        frozen=True,
        # 「Example Value」に表示されるJSON
        json_schema_extra={
            "example": {
                "detail": "Unprocessable Entity",
            }
        },
    )


# 500 Internal Server Error
class InternalServerErrorResponse(BaseModel):
    detail: str

    # OpenAPI用設定
    model_config = ConfigDict(
        # 書き換え不可設定
        frozen=True,
        # 「Example Value」に表示されるJSON
        json_schema_extra={
            "example": {
                "detail": "Internal Server Error",
            }
        },
    )

※主にOpenAPI用に共通エラー用のスキーマを定義します。

・「src/myapp/presentation/schema/common/__init__.py」

from .error import (
    BadRequestResponse,
    InternalServerErrorResponse,
    UnauthorizedResponse,
    UnprocessableEntityResponse,
)

__all__ = [
    "BadRequestResponse",
    "UnauthorizedResponse",
    "UnprocessableEntityResponse",
    "InternalServerErrorResponse",
]

DDD（ドメイン駆動設計）のディレクトリ構成について

この後にDDD（ドメイン駆動設計）でAPIを作成していきますが、ディレクトリ構成としてはDDDの思想に基づいたレイヤードアーキテクチャを採用しています。

/src
 ├── /myapp
 |    ├── /application（アプリケーション層）
 |    |    ├── /context（独立した値を持たせるためのコンテキスト変数）
 |    |    └── /usecase（ユースケース層）
 |    |
 |    ├── /di（依存注入によってユースケースのインスタンスをまとめる）
 |    |
 |    ├── /domain（ドメイン層）
 |    |    ├── entity（ドメインモデルの定義）
 |    |    ├── ValueObject（意味のある値を扱うためのオブジェクト定義）
 |    |    ├── repository（リポジトリのインターフェース定義）
 |    |    └── （仮）service（外部サービスのインターフェース定義）
 |    |
 |    ├── /infrastructure（インフラストラクチャー層）
 |    |    ├── /database（データベース設定）
 |    |    ├── /logger（ロガーの実装）
 |    |    ├── /persistence（リポジトリの実装。DB操作による永続化層。）
 |    |    ├── （仮）/cache（キャッシュを含めたリポジトリの実装。インターフェースはリポジトリと同一。）
 |    |    └── （仮）/externalapi（外部サービスの実装）
 |    |
 |    └── /presentation（プレゼンテーション層）
 |         ├── /exception（カスタム例外定義）
 |         ├── /handler（ハンドラー層）
 |         ├── /middleware（ミドルウェア定義）
 |         ├── /router（ルーター定義）
 |         └── /schema（APIの入出力の仕様を決めるスキーマ定義）
 |
 └── /tests（テストコード用ディレクトリ）

※（仮）のものは将来的に追加する想定の例です。

Postドメインを例にAPIを作る

次に以下の手順でPostドメインを例にAPIを作成します。

ドメインの定義

まずは以下のコマンドを実行し、各種ファイルを作成します。

$ mkdir src/myapp/domain/post
$ touch src/myapp/domain/__init__.py src/myapp/domain/post/text.py src/myapp/domain/post/entity.py src/myapp/domain/post/repository.py src/myapp/domain/post/__init__.py

次に作成したファイルをそれぞれ以下のように記述します。

・「src/myapp/domain/post/text.py」

# 型ヒントでまだ定義されていないクラス名を文字列として書けるようにする設定
# これによってクラス同士が互いを参照するような場合でも型ヒントが使いやすくなる
from __future__ import annotations

from dataclasses import dataclass


# 値オブジェクトの定義（フィールドは変更不可設定）
@dataclass(frozen=True)
    class Text:
    value: str

def __post_init__(self) -> None:
    ######################
    # バリデーションチェック
    ######################
    if not self.value:
        raise ValueError("テキストの値は必須です。")

    if len(self.value) > 20:
        raise ValueError("テキストの値は20文字以内で入力して下さい。")

    # オブジェクトを文字列として表示する際に呼ばれるメソッド
    # print() や str() を使う時にこのメソッドの戻り値が表示されます
    def __str__(self) -> str:
        return self.value

    # DBからの復元用クラスメソッド（チェック処理無し）
    @classmethod
    def from_raw(cls, raw_value: str) -> Text:
        # __init__を呼ばずにインスタンス作成した値を設定
        obj = cls.__new__(cls)
        object.__setattr__(obj, "value", raw_value)
        return obj

※今回はPostエンティティ（モデル）のフィールド「text」に意味があることを想定して値オブジェクト（意味のある値を扱うためのオブジェクト）を定義します。新規データ登録時は必ずバリデーションチェックが必要ですが、DB登録後のデータ取得時は基本的にバリデーションチェックは不要なため、復元用のメソッド（from_raw）も定義します。

・「src/myapp/domain/post/entity.py」

# 型ヒントでまだ定義されていないクラス名を文字列として書けるようにする設定
# これによってクラス同士が互いを参照するような場合でも型ヒントが使いやすくなる
from __future__ import annotations

from dataclasses import dataclass

from .text import Text


@dataclass
class Post:
    text: Text
    id: int = 0

    def __post_init__(self) -> None:
    ######################
    # バリデーションチェック
    ######################
    if self.text is None:
        raise ValueError("textは必須です。")

    # DBからの復元用クラスメソッド（チェック処理無し）
    @classmethod
    def from_raw(cls, raw_id: int, raw_text: Text) -> Post:
        # __init__を呼ばずにインスタンス作成した値を設定
        obj = cls.__new__(cls)
        obj.id = raw_id
        obj.text = raw_text
        return obj

※Postエンティティ（モデル）を定義します。フィールド「text」の型には上記で定義した値オブジェクトを利用します。

・「src/myapp/domain/post/repository.py」

from abc import ABC, abstractmethod

from .entity import Post


class PostRepository(ABC):
    # 今回はDB設定はダミー値を使っているため、dbの型はstrにしている
    @abstractmethod
    async def create(self, db: str, post: Post) -> Post:
        pass

    # 今回はDB設定はダミー値を使っているため、dbの型はstrにしている
    @abstractmethod
    async def find_all(self, db: str) -> list[Post]:
        pass

※Postモデルのリポジトリ用の抽象クラス（他のクラスに継承し、定義したメソッドを持つことを強制させる設計図のようなもの）を定義します。今回は例として新規データ作成用と全データ取得用の2種類のみ定義します。ユースケース層でトランザクション管理をするため、メソッドでDBインスタンスを渡せる設計にしてますが、今回はDB設定はダミー値を使うのでstr型で設定してます。

・「src/myapp/domain/post/__init__.py」

from .entity import Post
from .repository import PostRepository
from .text import Text

__all__ = ["Post", "PostRepository", "Text"]

リポジトリの実装

次に以下のコマンドを実行し、リポジトリ実装用のファイルを作成します。

$ mkdir -p src/myapp/infrastructure/persistence/post
$ touch src/myapp/infrastructure/persistence/__init__.py src/myapp/infrastructure/persistence/post/post_repo_impl.py src/myapp/infrastructure/persistence/post/__init__.py

次に作成したファイルをそれぞれ以下のように記述します。

・「src/myapp/infrastructure/persistence/post/post_repo_impl.py」

from myapp.domain.post import Post, PostRepository, Text
from myapp.presentation.exception import DatabaseError


class PostRepositoryImpl(PostRepository):
    # 今回はDB設定はダミー値を使っているため、dbの型はstrにしている
    async def create(self, db str, post: Post) -> Post:
        try:
            # DBへデータ登録を完了した想定でpostを返す
            return post

        except Exception as e:
            raise DatabaseError(f"DBエラーが発生しました。: {str(e)}") from e

    # 今回はDB設定はダミー値を使っているため、dbの型はstrにしている
    async def find_all(self, db str) -> list[Post]:
        try:
            # DBからデータを取得した想定で固定値を返す
            posts = [
                Post.from_raw(
                    raw_id=1, raw_text=Text.from_raw(raw_value="Postデータ１")
                ),
                Post.from_raw(
                    raw_id=2, raw_text=Text.from_raw(raw_value="Postデータ２")
                ),
            ]

            return posts

        except Exception as e:
            raise DatabaseError(f"DBエラーが発生しました。: {str(e)}") from e

※今回はDBを使わないので固定値で返しますが、DBから取得したデータはfrom_rawメソッドを利用してドメインに変換して返します。

・「src/myapp/infrastructure/persistence/post/__init__.py」

from .post_repo_impl import PostRepositoryImpl

__all__ = ["PostRepositoryImpl"]

スキーマの定義

次に以下のコマンドを実行し、APIの入出力の仕様を決めるスキーマ定義用の各種ファイルを作成します。

$ mkdir -p src/myapp/presentation/schema/post
$ touch src/myapp/presentation/schema/post/request.py src/myapp/presentation/schema/post/response.py src/myapp/presentation/schema/post/__init__.py

次に作成したファイルをそれぞれ以下のように記述します。

・「src/myapp/presentation/schema/post/request.py」

from pydantic import BaseModel, ConfigDict, Field


class PostCreateRequest(BaseModel):
    text: str = Field(..., max_length=20, description="テキスト")

    # OpenAPI用設定
    model_config = ConfigDict(
        # 書き換え不可設定
        frozen=True,
        # 「Example Value」に表示されるJSON
        json_schema_extra={
            "example": {
                "text": "Postテキスト",
            }
        },
    )

※リクエスト用のスキーマ定義の場合、各種フィールどには「Field()」を使ってバリデーションチェックの条件を付けます。

・「src/myapp/presentation/schema/post/response.py」

from pydantic import BaseModel


class PostResponse(BaseModel):
    id: int
    text: str

※Postデータをレスポンス結果として返すためのスキーマ定義

・「src/myapp/presentation/schema/post/__init__.py」

from .request import PostCreateRequest
from .response import PostResponse

__all__ = ["PostCreateRequest", "PostResponse"]

ユースケースの定義

次に以下のコマンドを実行し、ユースケース用のファイルを作成します。

$ mkdir -p src/myapp/application/usecase/post
$ touch src/myapp/application/usecase/__init__.py src/myapp/application/usecase/post/create_post.py src/myapp/application/usecase/post/get_posts.py src/myapp/application/usecase/post/__init__.py

次に作成したファイルをそれぞれ以下のように記述します。

・「src/myapp/application/usecase/post/create_post.py」

import logging

from fastapi import HTTPException

from myapp.domain.post import Post, PostRepository, Text
from myapp.presentation.schema.post import PostCreateRequest, PostResponse


class CreatePostUsecase:
    # コンストラクタで依存注入する
    # 今回はDB設定はダミー値を使っているため、dbの型はstrにしている
    def __init__(
        self, logger: logging.Logger, db: str, post_repo: PostRepository
    ) -> None:
        self.logger = logger
        self.db = db
        self.post_repo = post_repo

    async def execute(self, req: PostCreateRequest) -> PostResponse:
        try:
            # 新規Postデータ作成
            newPost = Post(text=Text(req.text))

            # DB登録
            post = await self.post_repo.create(self.db, newPost)
            return PostResponse(id=post.id, text=post.text.value)

        # ValueError発生時の例外処理
        except ValueError as e:
            self.logger.warning("バリデーションエラー: %s", e)
            raise HTTPException(
                status_code=422, detail=f"バリデーションエラー: {str(e)}"
            ) from e

        except Exception as e:
            self.logger.error("DB登録に失敗しました。: %s", e)
            raise e

・「src/myapp/application/usecase/post/get_posts.py」

import logging

from myapp.domain.post import PostRepository
from myapp.presentation.schema.post import PostResponse


class GetPostsUsecase:
    # コンストラクタで依存注入する
    # 今回はDB設定はダミー値を使っているため、dbの型はstrにしている
    def __init__(
        self, logger: logging.Logger, db: str, post_repo: PostRepository
    ) -> None:
        self.logger = logger
        self.db = db
        self.post_repo = post_repo

    async def execute(self) -> list[PostResponse]:
        try:
            # データ取得
            posts = await self.post_repo.find_all(self.db)
            return [PostResponse(id=p.id, text=p.text.value) for p in posts]

        except Exception as e:
            self.logger.error("DBからのデータ取得に失敗しました。: %s", e)
            raise e

・「src/myapp/application/usecase/post/__init__.py」

from .create_post import CreatePostUsecase
from .get_posts import GetPostsUsecase

__all__ = ["CreatePostUsecase", "GetPostsUsecase"]

DIコンテナの作成

次に以下のコマンドを実行し、依存注入によってユースケースのインスタンスをまとめるためのファイルを作成します。

$ mkdir -p src/myapp/di
$ touch src/myapp/di/container.py src/myapp/di/__init__.py

次に作成したファイルを以下のように記述します。

・「src/myapp/di/container.py」

import logging
from typing import Annotated

from fastapi import Depends

from myapp.application.usecase.post import CreatePostUsecase, GetPostsUsecase
from myapp.domain.post import PostRepository
from myapp.infrastructure.database import get_db
from myapp.infrastructure.logger import get_logger
from myapp.infrastructure.persistence.post import PostRepositoryImpl


# リポジトリのDI用関数
def get_post_repository() -> PostRepository:
    return PostRepositoryImpl()


# Post用ユースケース
def create_post_usecase(
    logger: Annotated[logging.Logger, Depends(get_logger)],
    # 今回はDB設定はダミー値を使っているため、dbの型はstrにしている
    db: Annotated[str, Depends(get_db)],
    post_repo: Annotated[PostRepository, Depends(get_post_repository)],
) -> CreatePostUsecase:
    return CreatePostUsecase(logger=logger, db=db, post_repo=post_repo)


def get_posts_usecase(
    logger: Annotated[logging.Logger, Depends(get_logger)],
    # 今回はDB設定はダミー値を使っているため、dbの型はstrにしている
    db: Annotated[str, Depends(get_db)],
    post_repo: Annotated[PostRepository, Depends(get_post_repository)],
) -> GetPostsUsecase:
    return GetPostsUsecase(logger=logger, db=db, post_repo=post_repo)

※FastAPI用のDependsを使って依存注入しています。今回使ったPythonのバージョンでは「Annotated」を使った依存注入が最適でした。（Pythonのバージョンによってここら辺の書き方が変わるので注意）

ハンドラーの定義

次に以下のコマンドを実行し、ハンドラー用のファイルを作成します。

$ mkdir -p src/myapp/presentation/handler/post
$ touch src/myapp/presentation/handler/__init__.py src/myapp/presentation/handler/post/post.py src/myapp/presentation/handler/post/__init__.py

次に作成したファイルをそれぞれ以下のように記述します。

・「src/myapp/presentation/handler/post/post.py」

from typing import Annotated

from fastapi import Depends

from myapp.application.usecase.post import CreatePostUsecase, GetPostsUsecase
from myapp.di.container import create_post_usecase, get_posts_usecase
from myapp.presentation.schema.post import PostCreateRequest, PostResponse


class CreatePostHandler:
    def __init__(
        self,
        usecase: Annotated[CreatePostUsecase, Depends(create_post_usecase)],
    ):
        self.usecase = usecase

    async def execute(self, req: PostCreateRequest) -> PostResponse:
        return await self.usecase.execute(req)


class GetPostsHandler:
    def __init__(
        self,
        usecase: Annotated[GetPostsUsecase, Depends(get_posts_usecase)],
    ):
        self.usecase = usecase

    async def execute(self) -> list[PostResponse]:
        return await self.usecase.execute()

※DIコンテナを使ってハンドラーに依存注入して実行します。

・「src/myapp/presentation/handler/post/__init__.py」

from .post import CreatePostHandler, GetPostsHandler

__all__ = ["CreatePostHandler", "GetPostsHandler"]

ルーター設定

次に以下のコマンドを実行し、ルーター設定用のファイルを作成します。

$ mkdir -p src/myapp/presentation/router
$ touch src/myapp/presentation/router/router.py src/myapp/presentation/router/__init__.py

次に作成したファイルをそれぞれ以下のように記述します。

・「src/myapp/presentation/router/router.py」

from typing import Annotated, Any

from fastapi import APIRouter, Depends

from myapp.presentation.handler.post import CreatePostHandler, GetPostsHandler
from myapp.presentation.schema.common import InternalServerErrorResponse
from myapp.presentation.schema.post import PostCreateRequest, PostResponse

router = APIRouter()

# OpenAPI用の共通エラーレスポンス定義
common_error_res: dict[int | str, dict[str, Any]] | None = {
    500: {"description": "サーバーエラー", "model": InternalServerErrorResponse},
}


@router.post(
    "/post",
    response_model=PostResponse,
    status_code=201,
    responses=common_error_res,
    summary="Postデータ新規作成",
    description="Postデータを新規作成する",
    tags=["Post"],
)
async def create_post(
    req: PostCreateRequest,
    handler: Annotated[CreatePostHandler, Depends(CreatePostHandler)],
) -> PostResponse:
    return await handler.execute(req)


@router.get(
    "/posts",
    response_model=list[PostResponse],
    status_code=200,
    responses=common_error_res,
    summary="Postデータ全件取得",
    description="Postデータを全件取得する",
    tags=["Post"],
)
async def get_posts(
    handler: Annotated[GetPostsHandler, Depends(GetPostsHandler)],
) -> list[PostResponse]:
    return await handler.execute()

※ハンドラーをルーター設定に依存注入して実行します。また@router部分ではOpenAPI用の定義も記述しています。

・「src/myapp/presentation/router/__init__.py」

from .router import router

__all__ = ["router"]

main.pyの修正

次にファイル「src/myapp/main.py」を以下のように修正します。

from collections.abc import AsyncIterator
from contextlib import asynccontextmanager

from fastapi import FastAPI
from fastapi.exceptions import RequestValidationError
from fastapi.middleware.cors import CORSMiddleware

from myapp.infrastructure.logger import get_logger, init_logging
from myapp.presentation.exception import (
    DatabaseError,
    db_error_exception_handler,
    general_exception_handler,
    request_validation_error_handler,
    valid_error_exception_handler,
)
from myapp.presentation.middleware import RequestMiddleware
from myapp.presentation.router import router


##########################
# アプリ全体の共通初期化処理
##########################
@asynccontextmanager
async def lifespan(app: FastAPI) -> AsyncIterator[None]:
    ############
    # 起動時処理
    ############
    # ロガーの初期化
    init_logging()

    # サーバー起動ログ出力
    logger = get_logger()
    logger.info("start server !!!")
    # アプリ起動
    yield
    ############
    # 終了時処理
    ############
    # サーバー停止ログ出力
    logger.info("stop server !!!")


#############
# ルーター設定
#############
app = FastAPI(
    lifespan=lifespan,
    title="fastapi-domain API",
    description="FastAPIによるDDD構成のAPIです。",
    version="1.0.0",
    # terms_of_service="https://example.com/terms/",
    # contact={
    # "name": "サポート",
    # "url": "https://example.com/contact/",
    # "email": "support@example.com",
    # },
    # license_info={
    # "name": "Apache 2.0",
    # "url": "https://www.apache.org/licenses/LICENSE-2.0.html",
    # },
)
app.include_router(router)

###################
# ミドルウェアの設定
###################

# 許可したいオリジン
origins = [
    "http://localhost:3000",
]

# CORS設定
app.add_middleware(
    CORSMiddleware,
    allow_origins=origins,
    allow_credentials=True,
    allow_methods=["GET", "POST", "PUT", "DELETE", "OPTIONS"],
    allow_headers=["Content-Type", "Authorization"],
)

# リクエスト用ミドルウェア
app.add_middleware(RequestMiddleware)


###################
# 例外ハンドラー設定
###################
app.add_exception_handler(RequestValidationError, request_validation_error_handler)
app.add_exception_handler(DatabaseError, db_error_exception_handler)
app.add_exception_handler(ValueError, valid_error_exception_handler)
app.add_exception_handler(Exception, general_exception_handler)

※各種共通用設定も記述しています。

次に以下のコマンドを実行し、フォーマット修正、静的コード解析、型チェックを行い、警告が出ないことを確認します。

$ docker compose exec fastapi poetry run ruff format .
$ docker compose exec fastapi poetry run ruff check . --select I --fix
$ docker compose exec fastapi poetry run ruff check .
$ docker compose exec fastapi poetry run mypy .

Dockerコンテナの再ビルドと起動

次に以下のコマンドを実行し、Dockerコンテナを再ビルドします。

$ docker compose down
$ docker compose build --no-cache

次に以下のコマンドを実行し、Dockerコンテナを起動します。

$ docker compose up -d

PostドメインのAPIを試す

次に上記で作成したPostドメインのAPIをPostmanを使って試します。

まずはPOSTメソッドで「http://localhost:9004/post」を実行し、下図のようにステータスコード201で想定通りの結果になればOKです。

次にリクエストパラメータ「text」を21文字以上にして再度実行し、バリデーションチェックでエラーになればOKです。

次にGETメソッドで「http://localhost:9004/posts」を実行し、下図のようにステータスコード200で想定通りの結果になればOKです。

テストコードを追加

次にテストコードを追加して試しますが、まずは以下のコマンドを実行し、テストコードに必要なライブラリをインストールします。

$ docker compose exec fastapi poetry add --dev pytest pytest-asyncio pytest-mock httpx

次にpytestの設定をするため、ファイル「pyproject.toml」の末尾に以下のような設定を追加します。

・「pyproject.toml」

・・・

# =========================================================
# pytestの設定
# =========================================================
[tool.pytest.ini_options]
# パス設定
pythonpath = ["src"]
testpaths = ["src/tests"]

# マーカー設定
markers = [
    "unit: mark a test as a unit test",
    "integration: mark a test as an integration test"
]

次に以下のコマンドを実行し、Dockerコンテナを再ビルドして起動します。

$ docker compose down
$ docker compose build --no-cache
$ docker compose up -d

次に以下のコマンドを実行し、テストコード用のファイルを作成します。

$ mkdir -p src/tests/domain/post
$ touch src/tests/__init__.py src/tests/domain/__init__.py src/tests/domain/post/test_text.py src/tests/domain/post/test_entity.py src/tests/domain/post/__init__.py
$ mkdir -p src/tests/application/usecase/post
$ touch src/tests/application/__init__.py src/tests/application/usecase/__init__.py src/tests/application/usecase/post/test_create_post.py src/tests/application/usecase/post/test_get_posts.py src/tests/application/usecase/post/__init__.py
$ mkdir -p src/tests/presentation/handler/post
$ touch src/tests/presentation/__init__.py src/tests/presentation/handler/__init__.py src/tests/presentation/handler/post/test_post.py src/tests/presentation/handler/post/__init__.py

次に作成したファイルをそれぞれ以下のように記述します。

・「src/tests/domain/post/test_text.py」

import dataclasses

import pytest

from myapp.domain.post import Text


@pytest.mark.unit
class TestText:
    def test_create_text_success(self) -> None:
        text = Text("hello")
        assert text.value == "hello"
        assert str(text) == "hello"

    def test_empty_value_should_raise_error(self) -> None:
        with pytest.raises(ValueError, match="テキストの値は必須です。"):
            Text("")

    def test_over_20_chars_should_raise_error(self) -> None:
        over_text = "a" * 21
        with pytest.raises(
            ValueError, match="テキストの値は20文字以内で入力して下さい。"
        ):
            Text(over_text)

    def test_exactly_20_chars_is_ok(self) -> None:
        t = Text("a" * 20)
        assert t.value == "a" * 20

    def test_frozen_object_cannot_be_modified(self) -> None:
        t = Text("hello")
        with pytest.raises(dataclasses.FrozenInstanceError):
            t.value = "changed" # type: ignore[misc]

    def test_from_raw_should_skip_validation(self) -> None:
        raw = "a" * 100
            t = Text.from_raw(raw)
        assert t.value == raw
        assert isinstance(t, Text)

※テスト実行時にユニットテストのみを指定できるようにするため、「@pytest.mark.unit」を付けています。mypyの型チェックでのエラーをスキップするため、対象箇所に「# type: ignore[misc]」を付けています。

・「src/tests/domain/post/test_entity.py」

import pytest

from myapp.domain.post import Post, Text


@pytest.mark.unit
class TestPost:
    def test_create_post_success(self) -> None:
        text = Text("hello")
        post = Post(text=text, id=1)

        assert post.id == 1
        assert post.text == text
        assert isinstance(post.text, Text)

    def test_missing_text_should_raise_error(self) -> None:
        with pytest.raises(ValueError, match="textは必須です。"):
            Post(text=None) # type: ignore[arg-type]

    def test_default_id_is_zero(self) -> None:
        text = Text("hello")
        post = Post(text=text)

        assert post.id == 0

    def test_from_raw_should_skip_validation(self) -> None:
        raw_text = Text.from_raw("raw-text")
        post = Post.from_raw(raw_id=123, raw_text=raw_text)

        assert isinstance(post, Post)
        assert post.id == 123
        assert post.text == raw_text
        assert post.text.value == "raw-text"

・「src/tests/application/usecase/post/test_create_post.py」

import pytest
from pytest_mock import MockerFixture

from myapp.application.usecase.post import CreatePostUsecase
from myapp.domain.post import Post, Text
from myapp.presentation.schema.post import PostCreateRequest, PostResponse


@pytest.mark.unit
@pytest.mark.asyncio
class TestCreatePost:
    # 正常系テスト
    async def test_create_post_success(self, mocker: MockerFixture) -> None:
        # ===================
        # モック作成
        # ===================
        mock_logger = mocker.Mock()
        mock_db = mocker.Mock()
        mock_post_repo = mocker.Mock()

        # リポジトリのモック化
        mock_post_return_value = Post(text=Text("Postデータ"))
        mock_post_return_value.id = 1
        mock_post_repo.create = mocker.AsyncMock(return_value=mock_post_return_value)

        # ユースケースのモック化
        usecase = CreatePostUsecase(
            logger=mock_logger, db=mock_db, post_repo=mock_post_repo
        )

        # ===================
        # リクエストデータ作成
        # ===================
        req = PostCreateRequest(text="Postデータ")

        # ===================
        # テスト実行
        # ===================
        res = await usecase.execute(req)

        # ===================
        # 検証
        # ===================
        assert isinstance(res, PostResponse)
        assert res.id == 1
        assert res.text == "Postデータ"

        # 対象のリポジトリが1回呼ばれること
        mock_post_repo.create.assert_awaited_once()

※非同期関数の場合は「@pytest.mark.asyncio」を付けます。ユニットテストでは各種モック化してテストします。

・「src/tests/application/usecase/post/test_get_posts.py」

import pytest
from pytest_mock import MockerFixture

from myapp.application.usecase.post import GetPostsUsecase
from myapp.domain.post import Post, Text
from myapp.presentation.schema.post import PostResponse


@pytest.mark.unit
@pytest.mark.asyncio
class TestGetPosts:
    # 正常系テスト
    async def test_get_posts_success(self, mocker: MockerFixture) -> None:
        # ===================
        # モック作成
        # ===================
        mock_logger = mocker.Mock()
        mock_db = mocker.Mock()
        mock_post_repo = mocker.Mock()

        # リポジトリのモック化
        mock_post_return_value = [
            Post.from_raw(raw_id=1, raw_text=Text.from_raw(raw_value="Postデータ１")),
            Post.from_raw(raw_id=2, raw_text=Text.from_raw(raw_value="Postデータ２")),
        ]
        mock_post_repo.find_all = mocker.AsyncMock(return_value=mock_post_return_value)

        # ユースケースのモック化
        usecase = GetPostsUsecase(
            logger=mock_logger, db=mock_db, post_repo=mock_post_repo
        )

        # ===================
        # テスト実行
        # ===================
        res = await usecase.execute()

        # ===================
        # 検証
        # ===================
        assert isinstance(res, list)
        assert all(isinstance(item, PostResponse) for item in res)
        assert res[0].id == 1
        assert res[0].text == "Postデータ１"
        assert res[1].id == 2
        assert res[1].text == "Postデータ２"

        # 対象のリポジトリが1回呼ばれること
        mock_post_repo.find_all.assert_awaited_once()

・「src/tests/presentation/handler/post/test_post.py」

import pytest
from fastapi.testclient import TestClient

from myapp.main import app

client = TestClient(app)


@pytest.mark.integration
class TestPostAPI:
    def test_create_post_success(self) -> None:
        # テスト実行
        res = client.post(
            "/post",
            json={"text": "Postテキスト"},
        )

        # 検証
        assert res.status_code == 201
        assert res.json() == {"id": 0, "text": "Postテキスト"}

    def test_create_post_valid_error(self) -> None:
        # テスト実行
        res = client.post(
            "/post",
            json={"text": "aaaaabbbbbcccccddddd1"},
        )

        # 検証
        assert res.status_code == 422
        data = res.json()
        assert "String should have at most 20 characters" in data["detail"][0]["msg"]
        assert data["detail"][0]["ctx"]["max_length"] == 20

    def test_get_posts_success(self) -> None:
        # テスト実行
        res = client.get("/posts")

        # 検証
        assert res.status_code == 200
        assert res.json() == [
            {"id": 1, "text": "Postデータ１"},
            {"id": 2, "text": "Postデータ２"},
        ]

※ハンドラーのテストはインテグレーションテストとして、リクエストを実行してテストします。（もし実際にDB操作がある場合はそれも実行されるため、テスト用のDB設定も必要になります。）

次に以下のコマンドを実行し、ユニットテストを実行します。

$ docker compose exec fastapi poetry run pytest -m unit 

コマンドを実行後、以下のように全てのテストがPASSすればOKです。

※オプション「-m unit」でマーク「unit」が付いたものだけ実行しているため、それ以外のスキップしたテストが「3 deselected」として表示されますが、それは仕様なので気にしなくてOKです。

次に以下のコマンドを実行し、インテグレーションテストを実行します。

$ docker compose exec fastapi poetry run pytest -m integration

コマンドを実行後、以下のように全てのテストがPASSすればOKです。

データベースついて

今回はDB部分は省略しましたが、組み込みたい場合は以前に書いた以下の記事などを参考にしつつ（生成AIを使っていない時代に書いた記事で情報が古いので参考程度にどうぞ）、必要な部分を追加修正していけばできると思います。

関連記事

【FastAPI入門】Dockerで環境構築してPythonのAPIを開発する方法まとめ

2024年5月4日

あるドメインのデータを別のドメインで使いたい場合について

上記では基本的なDDD構成についてご紹介しましたが、実際にはあるドメインのデータを別のドメインのユースケースなどで使いたいというようなことも出てくると思います。

その際はどう処理を書くべきか悩ましいところですが、トランザクション管理（データベースで「安全にまとめて作業をする仕組み」のこと）の観点からすると1ハンドラー1ユースケースで作るのが最適なため、一つのユースケース内で各種ドメインを呼び出すような形で作って下さい。

ただし、将来的にマイクロサービス化したくなった場合、ドメイン単位で独立した設計になっていないユースケースの部分については分割するのが難しくなりますが、その点はしょうがないのであきらめましょう！

※ただし、ドメインの境界線はしっかり分けてDB設計、データ更新していくのが大事ではあるので、その点はモノリスになりすぎないように注意して下さい。

本番環境用Dockerコンテナを作って試す

次に本番環境へのデプロイを想定し、専用のDockerコンテナを作ってローカル環境で試してみますが、コンテナ一つで複数ワーカーを動かしたいかどうかで若干やり方が変わるため、それぞれご紹介します。

まずは以下のコマンドを実行し、本番環境用のDockerfileを作成します。

$ mkdir -p deploy/docker/prod && touch deploy/docker/prod/Dockerfile

k8sやCloud Runなどコンテナ単位でスケールする場合

k8sやCloud Runなどコンテナ単位でスケールする場合、上記までのローカル環境と同様に「Uvicorn」のみで起動させればよいです。

その場合、ファイル「deploy/docker/prod/Dockerfile」は以下のように記述します。

・「deploy/docker/prod/Dockerfile」

####################
# ビルドステージ
####################
FROM python:3.14.0-slim-trixie AS builder

# poetryをインストール
RUN pip3 install --no-cache-dir poetry

# プラグイン「poetry-plugin-export」を追加
RUN poetry self add poetry-plugin-export

WORKDIR /build

# 依存関係のみコピー
COPY pyproject.toml poetry.lock ./

# 本番環境用の依存関係のみをファイル「requirements.txt」に記述
RUN poetry export -f requirements.txt --without-hashes --only main -o requirements.txt

####################
# 実行ステージ
####################
FROM python:3.14.0-slim-trixie AS runner

# 環境変数設定
ENV ENV=production

# テスト用の環境変数設定（ローカルではコマンドで渡す必要があるため）
ARG TEST_VALUE
ENV TEST_VALUE=${TEST_VALUE}

# タイムゾーン設定
ENV TZ=Asia/Tokyo

WORKDIR /py

# 必要なパッケージをインストール
COPY --from=builder /build/requirements.txt .
RUN pip3 install --no-cache-dir -r requirements.txt

COPY ./src/myapp ./src/myapp

# 非rootユーザーを設定
RUN addgroup --system --gid 1001 appuser && \
    adduser --system --uid 1001 appuser
USER appuser

EXPOSE 9004

# k8sやCloud Runなどコンテナ単位でスケールする場合
# Uvicornのみで起動させる
CMD ["uvicorn", "myapp.main:app", "--app-dir", "src", "--host", "0.0.0.0", "--port", "9004"]

※環境変数「TEST_VALUE」は必須にしているため、ビルドコマンド実行時に値を渡せるようにしています。

ECSなどでコンテナ一つで複数ワーカーを動かしたい場合

ECSなどでコンテナ一つで複数ワーカーを動かしたい場合、サーバー起動には「Gunicorn + UvicornWorker」の組み合わせを利用します。

その場合、まずは以下のコマンドを実行し、poetryで「gunicorn」をインストールします。

$ docker compose exec fastapi poetry add gunicorn

次に以下のコマンドを実行し、Gunicorn用の設定ファイルを作成します。

touch gunicorn_conf.py

次に作成したファイルを以下のように記述します。

・「gunicorn_conf.py」

import os

# サーバー設定
bind = "0.0.0.0:9004"
workers = int(os.getenv("WORKERS", "4"))
worker_class = "uvicorn.workers.UvicornWorker"

# ログ設定
loglevel = "info"
accesslog = "-" # 標準出力に出す
errorlog = "-" # 標準エラー出力に出す

次に事前に作成したファイル「deploy/docker/prod/Dockerfile」は以下のように記述します。

・「deploy/docker/prod/Dockerfile」

####################
# ビルドステージ
####################
FROM python:3.14.0-slim-trixie AS builder

# poetryをインストール
RUN pip3 install --no-cache-dir poetry

# プラグイン「poetry-plugin-export」を追加
RUN poetry self add poetry-plugin-export

WORKDIR /build

# 依存関係のみコピー
COPY pyproject.toml poetry.lock ./

# 本番環境用の依存関係のみをファイル「requirements.txt」に記述
RUN poetry export -f requirements.txt --without-hashes --only main -o requirements.txt

####################
# 実行ステージ
####################
FROM python:3.14.0-slim-trixie AS runner

# 環境変数設定
ENV ENV=production

# テスト用の環境変数設定（ローカルではコマンドで渡す必要があるため）
ARG TEST_VALUE
ENV TEST_VALUE=${TEST_VALUE}

# タイムゾーン設定
ENV TZ=Asia/Tokyo

WORKDIR /py

# 必要なパッケージをインストール
COPY --from=builder /build/requirements.txt .
RUN pip3 install --no-cache-dir -r requirements.txt

COPY ./src/myapp ./src/myapp

# 非rootユーザーを設定
RUN addgroup --system --gid 1001 appuser && \
    adduser --system --uid 1001 appuser
USER appuser

EXPOSE 9004

# ECSなどでコンテナ一つで複数ワーカーを動かしたい場合
# （Gunicorn + UvicornWorker）の組み合わせ
COPY gunicorn_conf.py .
WORKDIR /py/src
CMD ["gunicorn", "-c", "/py/gunicorn_conf.py", "myapp.main:app"]

※環境変数「TEST_VALUE」は必須にしているため、ビルドコマンド実行時に値を渡せるようにしています。

Dockerコンテナ単体でのビルドと起動

次に以下のコマンドを実行し、Dockerコンテナのビルドおよび起動をします。

$ docker compose down
$ docker build --no-cache --build-arg TEST_VALUE='PROD-VALUE' -f ./deploy/docker/prod/Dockerfile -t fastapi-domain-api:latest .
$ docker run -d -p 80:9004 fastapi-domain-api:latest

※ビルド時に「–build-arg TEST_VALUE=’PROD-VALUE’」で環境変数への値を渡しています。今回はテストなのでタグは「latest」ですが、実際にはバージョンのタグを指定するのでご注意下さい。

PostmanでAPIを試す

次にエンドポイントを「http://localhost/」とし、上記と同様にAPIをPostmanで実行して試して下さい。

各種APIを実行し、想定通りの結果になればOKです。

最後に

今回はPythonのFastAPIでDDD構成のバックエンドAPIを開発する方法について解説しました。

これから数年間は間違いなくAI関連機能の開発が盛り上がるのは避けられないため、その際は主にPythonを使ったAPI開発が増えるのではと思います。

その際は軽量でバランスがいいFastAPIでのAPI開発が増えそうですが、実務ではドメイン駆動設計で開発することが多いと思うので、FastAPIでDDD構成のバックエンドAPIを開発したい方はぜひ参考にしてみて下さい。

こんにちは。Tomoyuki（@tomoyuki65）です。

私は元システムエンジニアで、現在はWeb系エンジニアの仕事をしていますが、最近色々な転職サイトを使ったりして色々思うところが多いです。

簡単に言うと、「なんでこんなクソみたいなやり方してるの？？？」ということが多かったりします。

これにはもちろん既存の転職サイトにおける構造的な問題も含まれていたりしますが、そもそも採用活動をテキトウにやっていることが原因なんじゃないかなと思うことも多いです。

そこでこの記事では、現役Web系エンジニアである私の視点から、ITエンジニア採用における問題点とその解決策についてまとめておきます。

もしITエンジニア採用に困っている人事関係者や、ITエンジニアについてよくわかっていない経営者の方々は、ぜひ参考にしてみて下さい。

ITエンジニア採用は難しい！？現役エンジニア視点における問題点と解決策まとめ

まず現役Web系エンジニアである私の目線から、現在のITエンジニア採用における問題点については以下の通りです。

問題点1：大量のテキトウなスカウトメール

転職サイトに登録すると、大量のスカウトメールが届くことが多いです。

ただし、本当にテキトウな文面でスカウトが届くことが多く、ただ大量にかつテキトウにスカウトメールを送っているだけで、私のプロフィールはちゃんと見てないんだなというのがよくわかり、とても悲しい気持ちになることが多いのも事実です。

このやり方では優秀なエンジニアは採用できないのは明確だと思うのですが、それがわからないような無能な人がエンジニア採用をしているということなのでしょうか？。。。

解決策

スカウトメールを送って、返信がくるのは約3%未満という話を聞いたことがありますが、だから大量にスカウトメール送信する、というバカみたいなことは今すぐ辞めましょう。

多くの場合、それはさまざまなコスト面で非常に無駄なことをしています。それだけにとどまらず、企業の信頼を落としてしまっている可能性も高いのを理解しましょう。

有名な某ユニコーン企業さんとかもそういうことをやられていて、企業としてやっていることは魅力なのに、スカウトのやり方がクソすぎて非常に残念な気持ちになりました。

今はインターネットによって良い口コミも悪い口コミも簡単に広まる世の中なので、数打ち当たるという戦法はリスクが高いです。

もし大量にスカウトメールを送る必要があるのであれば、せめて「条件に合致した方に一斉にスカウトを送信させていただいております。他の採用媒体含めて送信させていただいている可能性もあるため、重複していた場合はご了承下さい。」というような文面をちゃんと記述するようにして下さい。

今の時代、何事も信用が大事なのです。真摯な文面を心がけましょう。

問題点2：文章内の本人が送っていないという嘘スカウト

スカウト文の文面について、「株式会社︎︎のCTOをしているXXです。〜」というようなスカウトが届くことがあるのですが、それに返信した際に「株式会社︎︎の採用担当です。〜」という返答をされることが多々あります。

はい。そうですね。採用担当の方が社長やCTOなどを語ってスカウト文を送信しているというケースが多々存在するんです。

それでも一応カジュアル面談もしてみたりすることがあるのですが、結局は採用担当者がテキトウにスカウトを送信しているんだなというのがわかり、とても悲しい気持ちになることがよくあります。

こういうやり方をしていると、「企業からスカウトを送ってきたのにもかかわらず、書類選考されて落ちた。」みたいな結果を招き、それが悪い口コミとして広がる恐れがあります。

解決策

嘘つくのやめろ！！

問題点3：生成AIバレバレの気持ちが入ってないスカウト文

最近はChatGPTやGeminiなどの生成AIを使うことで、スカウトメールの文面も簡単に作ることができますよね。

そのようなスカウトメールを受け取ることも増えてきたように感じますが、明らかに生成AIで作った文面を読んだ人の気持ちを考えたことはないのでしょうか？？？？

私には理解できません。

例えば好きな人に対してラブレターを送ろうとした場合、生成AIで作った文章をそのまま伝えるのでしょうか？それで相手に自分の気持ちが伝わるのでしょうか？

文章で伝えるにしろ、言葉で伝えるのしろ、自分の言葉で伝えるようにしないと、気持ちが伝わるわけがないのです。

そのようなクソみたいな文章を送ってくる相手のことを魅力的に思うことはありません。

解決策

生成AIを使って文章を作るのはとても効率的なのでこれからの時代は積極的に使っていくべきですが、誰かに何かを伝える際には必ず自分の言葉で書き直した文章にしてから送るようにして下さい。

自分の言葉にして送ることで、あなたの気持ちを文章で伝えることが可能になります。それは生成AIや機械にはできない、人間にしかできないことなのです。

問題点4：具体的にどんな人材を募集しているかわからない求人票

私がITエンジニア向けの求人票を見て多々思うこととしては、非エンジニアの方が作ったと思われるような、具体的なことがちゃんと書かれていない求人票が多いです。

具体的なことをちゃんと書かないことにより、例えばカジュアル面談の場で質問しなければいけないことが増えるため、企業側と求職者側で無駄なやりとり、無駄な時間が多くなってしまいます。

解決策

求人票に書いておいて欲しいことは以下の通りです。

※多数のプロダクトを作っていて、それぞれ異なる技術スタックを使っていた場合、その求人票ではどのプロダクトの仕事で、具体的にどの技術スタックを使うことになるのかがわからないと、そもそも応募ができません。それぐらいエンジニア目線では大事なことです。

問題点5：雑用フルスタックエンジニア（笑）の募集

主に中小企業においては少人数で開発することが多く、優秀なフルスタックエンジニアを求めることがよくあると思います。

特にそういった時の求人票を見ると、だいたい「フルスタックエンジニア募集！年収500〜700万円」というような感じで募集がされていることも少なくありません。

ただ優秀なエンジニアがそのような求人票を見て思うことは、「あ、雑用の募集ね。。」というのが現実です。

それはなぜかというと、フルスタックエンジニアというのはフロントエンドもバックエンドもインフラも全てある程度できることが前提ですが、それぞれの領域には専門性があり、全ての領域をある一定以上のレベルでやれるような優秀な人材はほとんどいないからです。

仮にそんな人材がいたとしても、最低年収は1000万円以上になると思います。本当のフルスタックエンジニアというのはそういった存在なのです。

解決策

まずは安直に「フルスタックエンジニア」という言葉を使うことを辞めましょう。

もし業務内容がフルスタックエンジニア的なものを想定しているのであれば、フロントエンド、バックエンド、インフラの全ての領域に携わってくれるソフトウェアエンジニアを募集というような言葉に変えて下さい。

またはもしちゃんとしたプロダクトを作っている企業であれば、プロダクトエンジニアを募集するというような形でも大丈夫でしょう。

言葉の使い方を間違えると、当たり前ですが笑われることがあります。

問題点6：人気が無いのにフルリモートワーク無し

XなどのSNSではよくフルリモートワークについて燃えたりしていますよね。

コロナ禍ではフルリモートワークが流行っていったものの、最近では有名な大手企業を中心に出社回帰をしているケースも増えたりしています。

そういったニュースが増えてくると、うちの会社でもフルリモートワークは廃止しようということを考える経営者の方も多いのではないのでしょうか。

別にフルリモートワークを廃止するかどうかはその企業の自由ですが、その際には一つ確認しておくべきことがあります。

あなたの会社は、何もしなくてもエンジニアからの応募が困らないような、大人気企業なのでしょうか？

もしここで「はい。」と言えないのであれば、フルリモートワークを廃止すべきではありません。

有名で人気の企業であるAmazonなどがフルリモートワークを廃止してもいいのは、廃止してもそこで働きたいと思う人が多く、エンジニア採用に困らないからです。

解決策

エンジニアの種類によってはもちろん出社必須の現場もあると思いますが、Web系エンジニアの仕事においてはその限りではありません。

Web系エンジニアにおけるフルリモートワークというのは福利厚生の一つであり、それがあるかどうかは非常に大きな要素になっています。

もちろんリモートワークは向き不向き、好き嫌いがあるため、最も良いのはフルリモートワークも出社するのも自由に選べることです。

もしあなたの企業が中小企業であり、かつ人気が無くてエンジニア採用に困っているのであれば、フルリモートワークを導入すべきです。

フルリモートワークを導入することで地方のエンジニアも採用候補になるため、そういった点でもメリットがあります。

また、リモートワークに関して否定的な意見の一つに「サボる人がいる」というのがあったりしますが、それはまた別のベクトルの話であり、そもそもそんな責任感が無い人材を雇ってしまっている企業の責任です。

フルリモートワーク人材を雇う際は、少なからず「真面目で責任感がる人材であるかどうか」はちゃんと見たほうがいいでしょう。

尚、フルリモートワークではジュニアレベルの人材のマネジメントはほぼ不可能なので、例えばもし新卒採用が必要になってきたというような場合においては、対象者が一人前になるまでは出社必須にすべきだし、マネジメントする人にも出社をお願いしなければならなくなるため、その点は抑えておいて下さい。

問題点7：人気が無いのにコーディング試験がある

エンジニアの採用フローの中にはコーディング試験がある場合があり、特に最近だと某スタートアップ企業がWebコーディング試験のプロダクトを出していたりするので、ついつい導入してしまった中小企業もあったりするのではないでしょうか。

そんなコーディング試験についてですが、私としては否定的な見解であり、コーディング試験がある企業については基本的に応募することは避けるようにしています。

実務ができるエンジニア目線としては、コーディング試験は本当にめんどくさいです。時間の無駄です。

そんな私も一度試しに受けてみたことがありますが、実際にやってみて思ったこととして、「プラットフォームが使いづらい」、「プラットフォーム慣れが必要」、「制限時間が邪魔」、「問題がわかりづらく、実務と関係ない」、「バグみたいな挙動がある」、「慣れている人が有利なだけ」というよう感じでした。

正直クソです。こんなものでエンジニアの能力を測り切れるものではありません。

なのでもしあなたの企業がコーディング試験を導入しているなら、ほんとうにそれは必要なのかをちゃんと検証したほうがいいでしょう。

コーディング試験の導入すべきであるといいことを言って勧めてくる企業があった場合は、基本的にはビジネスとして自分たちの商品を売ってお金を稼ぎたいだけです。その点は注意しましょう。

解決策

コーディング試験が効果的な場面としては、有名で人気な大手企業があって、エンジニアの応募が多すぎて全ての人の面接などができない場合です。

その場合はコーディング試験で一定以上の点数を取る必要があるという壁を設けることにより、応募者のフィルタリングが可能になるため、そういう場合は導入する価値があると思います。

逆にそういうことではなく、コーディング試験によってエンジニアの能力を測り、優秀なエンジニアを採用したいと思って導入しているような場合は、実務ができるエンジニアをフィルタリングしてしまったり、そもそも実務ができるエンジニアの応募が少なくなってしまうというデメリットもあったりするので注意して下さい。

もしあなたの企業が人気が無くてエンジニア採用に困っている中小企業などである場合、コーディング試験の導入はデメリットが大きいので避けた方がいいです。

問題点8：市場価値を見ていない年収レンジ

求人票には「年収500〜700万円」というような年収レンジが記載されていると思いますが、業務内容と年収レンジが見合ってないことも多々あります。

年収レンジが高すぎる場合は問題ないですが、逆に低すぎる場合についてはエンジニアの価値を軽視していると捉えられ、応募を避けられる可能性が出てくるので注意しましょう。

解決策

エンジニアといっても使う技術スタックによって市場価値は様々で、その時々で市場価値も変わるため、ちゃんと現在の市場価値に見合った金額を提示できているかどうかはしっかり確認すべきです。

問題点9：マネジメント職は別のロール（役割・仕事）

日本のIT企業ではマネジメント職の方が年収が高かったりすることがあったりすると思いますが、マネジメント職と開発職は別々のロール（役割・仕事）であり、求められることも違うため、マネジメント職の方が年収が高いという仕組みになっているのはおかしいです。

もしあなたの企業がそのような仕組みで運用している場合、優秀で技術があるエンジニアから避けられてしまうデメリットもあるため、そういった仕組みについてもちゃんと考えた方がいいでしょう。

解決策

組織で仕事をしていく場合、人材は適材適所で配置していく方が上手く行くのは間違いないため、開発したい人には開発をやらせるべきだし、マネジメントしたい人にはマネジメントをやらせるべきです。

なので、開発職とマネジメント職は別のロールとして捉え、それぞれのロールごとに適切なグレードを設けるようにして、開発職とマネジメント職の年収の乖離が大きくならないような仕組みにすべきです。

問題点10：技術スタックがレガシー

エンジニア採用をしている企業の中には、プロダクトに使っている技術スタックがレガシーになってしまっていることも多々あると思います。

エンジニアが求人票を見る際は、ほぼ必ずモダンな技術スタックを使っているかどうかは見られてしまうため、技術スタックがレガシーだと応募者が来ないことも多いのではないでしょうか。

解決策

まず大前提として、システムは作った後は腐っていきます。作っている時はモダンな技術であったとしても、ほっとけばいずれレガシーな技術になってしまうんです。

そのため、プロダクトやサービスを長期的に運用していくのであれば、使っている技術スタックがレガシーになりそうなら、タイミングを見計らってモダンな技術にリプレイスするということも必要になるでしょう。

もしそれが様々な条件があってできなくて、それでもエンジニア採用を成功させたいとするならば、少なからずその企業のエンジニアとして働くことによって提供できることをある程度明確に提示するような形で求人票を作って募集をしていくべきです。

例えば「技術はレガシーだけど、社会的に長期的な運用が求められるシステムに携わることができ、そのエンジニアとして働くことで特定のドメイン知識にも精通できるようになったりでき、かつ能力が高い人なら早く出世もできる環境があります。」というような感じで、企業として提供できることをちゃんと求人表に書くようにしましょう。

もしそれでもエンジニア採用ができない場合、もうそれは淘汰されるしかないので、諦めて下さい。それが嫌ならシステムのリプレイスが必要です。

問題点11：優秀なエンジニアの定義を間違えている

どんな企業も優秀なエンジニアを採用したいはずですが、私が感じるのは優秀なエンジニアの定義が間違っているのではということです。

具体的には、過去に有名企業に在籍していた経験があったり、過去の経歴において求めている実務経験があることだったり、そういった過去の経験を見過ぎているなという印象です。

もしそういった経験豊富な人材を採用しようとした場合、そもそもそんな人材は数が少ないのと、採用しようとしても高い年収を提示する必要があり、コスパも悪い可能性があります。

そして優秀であればあるほど、おそらく自分で起業したり、就職するにしてもリファラル採用されることの方が多いはずなので、転職市場に出てこないことがほとんどでしょう。

そもそも社会における仕事というのは、答えがまだない問題を解決していくことが本質なので、過去に経験があるかどうかは重要ではありません。未知なる問題が発生してもそれを解決できるかどうかの方が重要です。

あとは企業の役割の一つとして、社員に対して成長の機会を与えることもあるので、現在何をしているかだったり、将来どうなっていきたいかというような、その人の人間性だったり、将来的なポテンシャルの部分に目を向けた方がいいのではないかなと、私は思います。

解決策

私が思う優秀なエンジニアの定義としては、主に以下のような人材です。

まず社会で組織に属して働くことにおいて、最も大事なことはコミュニケーション能力です。

エンジニアの中には技術はあってもコミュニケーション能力が低い人が一定数いると思いますが、そういう人材は残念ながら組織における優秀な人材には該当しません。

特定の領域においては専門性や技術的なことが必須で一番大事になることもあると思いますが、多くの場合はコミュニケーション能力が一番大事であり、その次に技術的な要素になると思います。

次にその人がエンジニアの素養があるかどうかは非常に重要です。それを判断する一つの方法としては、「普段から技術的な勉強をしていくのが苦では無く、好きで趣味のようにやっているかどうか」です。

よく「エンジニアは土日も勉強しないといけないから大変」みたいなことを言う人がいたりしますが、そういった考えに共感するような人はエンジニアに向いていないので採用すべきではありません。

現在の競争社会における優秀な人材になっていくためには勉強し続けるのは必須であり、それをするためには自分が好きなことである必要もあるため、エンジニアにとっては普段から趣味のように技術をキャッチアップできるかどうかは非常に大事なことです。

あとはインプットだけでなく、アウトプットも定期的にちゃんとやっていることも非常に大事なので、何らかのアウトプット活動をしているような人なのかはちゃんと見るべきです。

上記のような要素を兼ね備えた人材であれば、基本的には自走できる人材だと思うし、何か問題があっても自分で解決していける人だと思うので、まだ経験が浅くても将来的には優秀なエンジニアになっていくでしょう。

問題点12：エンジニアを採用しても辞めていく問題

やっとのことエンジニアを採用できたとしても、「すぐに辞めてしまう」ということもよく聞いたりしますよね。

優秀な人材であればあるほど常に高みを目指しているため、求める環境が無くなれば辞めて行ってしまうのはしょうがないことです。

それを少しでも食い止めたいということであれば、優秀な人材の声には常に耳を傾け、その人が求めるポジションや役割を会社として適宜提供し続けていくしかないです

そもそも、人が会社を辞めるのを無くすことは不可能です。

その点については無駄なことは考えずに諦めましょう。

解決策

人が辞めていくのを無くすのは不可能なので、辞めていく時は快く送り出し、辞めた後に「あの会社は働きやすくて良かったな」と思ってもらえるような環境作りに力を入れた方が後々会社のためになることが多いと思います。

最近だとアルムナイ制度（退職者との組織的な繋がりを維持し、再雇用や新たな関係構築につなげる仕組み）がある会社も存在するので、そういった制度を作ったりするような形で頑張って行った方が合理的です。

問題点13：プロダクトの魅力を語れないスタートアップ経営者

とあるスタートアップのカジュアル面談にて、これから作ろうとしているAI関連プロダクトの詳細について聞いたことがありました。

その際には顧客の問題解決のためにこういったものを作りたいというのはよくわかったのですが、ただ現状想定しているものが単なるツール的なもの（他社プロダクトとの連携を前提としているようなもの）を想定していて、将来的にそのプロダクトをどのようにしていきたいのかという、プロダクトを作っていく魅力の部分について語れない経営者の方がいました。

はっきり言うと、それだと優秀なエンジニアが協力してくれることはありません。

優秀なエンジニアの方は基本的に魅力的なプロダクトの開発に携わりたい生き物なので、魅力もないプロダクトを開発するために、わざわざリスクを取ってスタートアップに入社することはないです。

もしそれでもそういったものを作りたいなら、外部のIT企業にお願いして作ってもらうしかないと思いますが、それだとお金のためにぼったくられることも多かったりするので、いつかどこかで破綻すると思います。

解決策

非エンジニアの経営者で、あまりソフトウェア開発の知識が無いのであれば、できるだけ早い段階で技術的に詳しいアドバイザーなどに相談し、作ろうとしているプロダクトに何か問題がないかはチェックしてもらった方がいいです。

問題点14：人売りIT企業多すぎ問題

日本でエンジニアの仕事を探そうとすると、SIerやSESといったサービスの提供を事業としているIT企業が非常に多いです。

大手企業ならまだ問題ないと思いますが、多重下請け構造になってしまっている中小企業が非常に多いのも現実です。

結局、そういった中小企業が多いのは、経営者だけが甘い汁を吸えるようなビジネスモデルになっているからです。

ただ最近だと生成AIも発達してきて、非エンジニアの方でもシステム開発のハードルが下がってきているので、そういった中小企業の仕事が無くなっていくのは時間の問題かなと思います。

解決策

生成AIの発達次第で、特に中小企業は案件獲得が厳しくなっていくのが想定されるため、多重下請け構造での稼ぎがメインになっている中小企業はご注意下さい。

はっきり言ってそういったサービスを提供するようなビジネスモデルは時間の切り売りをしているだけでバイトするのと変わらず、優秀なエンジニアほど魅力を感じなくて避けていくので、優秀なエンジニアの獲得はより厳しくなっていくと思います。

自社プロダクトを作る気が全くないIT企業は淘汰されろ！

問題点15：リファレンスチェックという糞システム

選考フローの中に「リファレンスチェック」というのを導入している企業があります。

このリファレンスチェックというのは、企業が採用候補者の前職の上司や同僚など、候補者をよく知る第三者に対して、候補者の働きぶりや実績、そして人物像などを問い合わせるような採用活動のことです。

最近だとリファレンスチェック用のSaaSなどもあり、メールや発行したURLなどを共有して回答してもらうような形式で行われています。

これは企業側にとっては採用候補者の第三者目線の評価が聞けるというメリットはあるのもの、逆に採用候補者側としては過去に一緒の働いたことがある上司や同僚などの誰かにリファレンスチェックへの回答を無償でお願いしなければならないという、心理的ハードルもめちゃめちゃ高いこともしなければならないという、非常に糞システムであることが最大のデメリットです。

いや別に人気企業で採用に困ってないなら導入してもフィルタリング効果があるのでいいですが、そうじゃないのにこれを導入している企業は頭が悪いのではないでしょうか。

世の中にはこういったことを気軽に頼めるような人脈形成が得意な陽キャの人が沢山いるということなのでしょうか？？

私はそうじゃない人の方が多いと思うし、これを導入することによって、逆に陽キャ系のキラキラ人材みたいな属性の人しか集まらないのではないでしょうか？？

別にそれでいいなら問題ないですが。。。

これを導入していて、人手不足とか言ってないですよね？？？

解決策

これについても採用に困っているなら導入すべきではないです。

これがあるだけでそもそも選考に進まないという人も一定数いるので、自分で自分の首を絞めることになります。

もしどうしても導入したいというなら、対応するのが厳しいという人に対しては、無理に強制せず、柔軟な採用フローにするようしっかり検討しておくべきです。

ITエンジニアの採用方法やコツ

上記ではITエンジニア採用における様々な問題点や解決方法についてご紹介しましたが、ITエンジニア採用を成功させるための基本的な方法についてご紹介しておきます。

少なからず以下のことは確実に必要だと思うので、こういうのが出来ていなかったなというのがあれば、ぜひ参考にしてみて下さい。

尚、エンジニア採用のために技術ブログをやっている企業もあったりしますが、技術ブログはその会社でしか知り得なかった貴重な情報を無料公開し、それによって社会に貢献することで価値を示せる効果はありますが、それが組織作りにおけるアピール機会としてはそれほど効果はないと思います。

もし広報活動をSNSなどで行おうとするのであれば、例えばnoteで人の感情に訴えかけるような企業の魅力を伝える記事を書いたり、会社の魅力や社内環境をわかりやすく伝えられるようなYouTube動画を公開したりしていく方が効果的です。

ITエンジニアに人気の環境について

次にエンジニア目線で魅力的に映る企業環境についてご紹介しておきます。社内環境を整える必要がある場合は参考にしてみて下さい。

尚、2025年9月時点におけるモダンな技術スタックの例としては以下の通りです。

※迷ったらメルカリの技術スタックを真似するのがいいです。

ITエンジニア採用でおすすめの採用媒体（サイト）について

私は色々な転職サイトを使ってみましたが、2025年9月時点でおすすめの採用媒体（サイト）についてご紹介しておきます。

1. 各種SNSによるダイレクトリクルーティング

私がこれからの時代においてもっとも良い方法として思っているのは、各種SNS（X、Facebook、LinkedInなど）を利用したダイレクトリクルーティングです。

対象者を探すのは大変ですが、対象者がいれば直接コンタクトを取って交渉できる可能性があるため、採用コストを安くできたり、人との繋がりを作っていける活動になるからです。

特にこれからの時代は、よりダイレクトリクルーティングが発展していくのではと思っているので、どうしてもエンジニアが採用できないという企業さんは、一度SNSで人材を探すのを試してみてはいかがでしょうか。

2. 転職ドラフト

実務経験があるエンジニアが使うべき転職サイトで最も合理的なのは、転職ドラフトです。

求職者登録には実務経験が必要で審査もあり、プロフィールもしっかり書く必要があります。

そして企業側がスカウトをする際は、最初に年収提示が必須になって、スカウト文も丁寧に作って送る必要があるため、求職者側と企業側がお互いに合理的なやり取りが可能になっています。

3. Findy

GitHubやブログなどを用いてアウトプット活動をしっかりやっている人がよく使っているのがFindyです。

求職者側視点でも自社開発系企業が多く、求人を探しやすいなという印象が強いため、2025年9月時点においては優秀な人材が集まりやすいサイトです。

求職者視点ではサイト自体がモダンでシンプルで使いやすい感じなので、自走できるような優秀なエンジニアを探している場合は、一度利用してみてはいかがでしょうか。

4. ビズリーチ

実務経験があり、大企業出身者やマネジメント職の人材を中心に集めたいなら、ビズリーチがおすすめです。

私も登録しているため、エンジニアも一定数いますが、エンジニア目線では転職ドラフトやFindyの方が求人を探しやすいため、技術力があるエンジニアの採用にはそれほど向いていないので注意です。

5. WantedlyやGrenn

実務経験よりも、若手やポテンシャル採用をしたい場合は、WantedlyやGreenを使って探すのが無難です。

Wantedlyは共感で繋がるビジネスSNS、GreenはIT人材向けの求職サイトですが、それぞれ低い年収レンジでスカウトが来ることが多い感じです。

最後に

今回は現役Web系エンジニアである私の視点から、ITエンジニア採用における問題点とその解決策についてまとめました。

ITエンジニア採用が難しく、苦労している企業さんが非常に多そうですが、

それはやり方が間違っているだけじゃない？

と、私は伝えたいです。

今回ご紹介したような考え方などをしっかり持っているようなCTOなどに協力してもらいながら、経営戦略的なところからエンジニアの組織作りのところまでしっかり検討していくようなやり方をすれば、エンジニア採用に困ることは少なくなっていくと思います。

もし現在エンジニア採用でお困りの人事関係者や経営者の方がいたら、ぜひ今回ご紹介した内容を参考にしてみて下さい。

こんにちは。Tomoyuki（@tomoyuki65）です。

特定の技術に特化した専門技術ブログとして「Golang-Tech」を別途運営していますが、また新しくRust専門技術ブログとして「Rust-Tech」を解説しました！

Rust専門の技術ブログ「Rust-Tech」を開設しました！

Rustについてはまだまだ普及はしていませんが、私の予想ではおそらくあと3〜5年後ぐらいには今のGolangぐらい普及している可能性があるなと睨んでいるため、Golangをメインで使いつつも、サブにRustを使っていこうと思ってます。

そんなRustはメモリ安全性やパフォーマンス性が高いのが特徴で、大量データを処理したり、高トラフィックが想定されるようなパフォーマンスを最重視したい場面においては、GolangよりもRustが採用されるケースが増えてくると思います。

逆に弱点としては学習コストが高く、まだ情報も少ないことで、私も実際に試しましたが、ある程度理解するまでに非常に苦労しました。Rustの能力を引き出すには、あと2年ぐらいは使い込まないと厳しそうです。

最後に

ということで、私はこれからRustも使っていこうと思ってますが、キャッチアップしたことはRust-Techの方にまとめていきます。

もしRustに興味がある方がいたら、ぜひ参考にしてみて下さい！

＼ Rust専門の技術ブログはこちら ／

>> Rust-Tech

こんにちは。Tomoyuki（@tomoyuki65）です。

前回の記事から約11ヶ月が経ちましたが、現在 無職 です！w

というか普通に求職活動中なのですが、キリのいいタイミングなので、また記録を残しておきます。

関連記事

37歳Web系エンジニア3年目。生成AI（ChatGPT・Gemini）現る。

2024年7月3日

Web系エンジニアを3年頑張ってきた結果とこれから

私がWeb系エンジニアの転向を決意したのが2022年6月で当時は35歳でしたが、あれから約3年経ちました。

その当時に考えていたのは、約3年頑張れば普通にWeb系エンジニアとして働いていけるぐらいにはなるだろうと、私は不安な状態からもそう思っていました。

それから3年が経ち。。

ついに私は。。

Gopherへ進化したのであった！！

え！？

そうですね、Web系エンジニアとして普通に仕事はできるようになったし、途中から希望していたGoエンジニアの実務経験も積んで、一応Goエンジニアとして働けるようにもなりましたよ！！

順風満帆で全て希望通りというわけではありませんが、運も良くてこれまで色々な経験を積むことができました。（メインはバックエンドですが、フロントエンド開発もできます！）

とはいえ、まだまだインフラ面は弱いし、やりたいこと、やらなければならないこともたくさんあるため、Web系エンジニアの道は奥が深いなと、つくづく思います。

現在求職活動中です！【2025年5月末時点】

直近の会社については、自社開発系でGo言語のバックエンドエンジニアとして勤めていましたが、経営上の問題があって話し合った結果、会社都合退職になりました。

プロダクトのコードを見た時に、このままだと長期運営していくのは厳しそうだなと思っていましたが、それが現実的になった感じです。

まあベンチャー企業であるあるだと思うので、その点はしょうがないと思いますが、もし3年ぐらい早く私がジョインしてたら、未来を変えることができたのかも？とは思いました。

ということで現在絶賛求職活動中なんですが、今後も自社開発系のGoのバックエンドエンジニアとしてキャリアを磨きたいので、そういった仕事ができる企業を前提として探しています。

あとはこれまででちゃんとしたWebサービスの長期運用経験を積めなかったので、次は2年、3年としっかり運用経験も積んでいけるような環境も求めてます。

もし、今のこのタイミングでGoエンジニアを求めている企業さんから直接ご連絡をいただければ対応いたします。

ダイレクトマーケティングなら“低コスト”で、Goエンジニアを採用できるチャンスが、今ここにありますよ！！

次の3年間にやること

これまではアプリケーション開発の部分に注力してきましたが、これからの3年間に関しては本格的にインフラ面の強化をしていく予定です。

AWSないし、Google Cloudの知識およびスキルを磨いて、あらゆるWebサービスのバックエンドを安定して運用できるようになりたいところです。

そして現在、生成AIの進化が非常に話題ですが、もうこれは避けては通れない技術革新なので、この生成AIをアプリケーションに組み込めるようにするのは前提としつつも、生成AI関連ツールを上手く使いこなして、より効率的に開発ができるようにしないといけないと思ってます。

また、プログラミング言語については引き続きGo言語の肉付けを継続して行いつつ、今後のパフォーマンスを最重視する場面においてはRustが流行るのではと睨んでいるので、Golangをメインとしつつも、必要に応じてRustも使えるようにしていこうと考えています。

そんなRustについても最近、Rust専門技術ブログ「Rust-Tech」を立ち上げたので、Go専門技術ブログ「Golang-Tech」と合わせて、興味がある方はぜひ参考にしてみて下さい！

これまでの3年間でわかった自社開発系のWeb系エンジニアに必要なこと

これまでの3年間の経験でわかったこととして、会社に勤めて実務経験を積むのは大事ではあるものの、それ以上に大事なのが自己学習によって継続的に技術を磨いていくことです。

もちろん実務でしか積めない経験もあるので、それについては運良く携われたらラッキーですが、それ以外の部分いついてはほぼ全て自己学習で学んだことが全てだったので、継続的な自己学習ができない人については、自社開発系のWeb系エンジニアには向いていないです。

たまに「エンジニアは休みの日も勉強が必要だから大変そう。」みたいなことが話題になることがありますが、そういう考えの人は向いてないです。

例えば私なんかは趣味でプログラミングの勉強をしている感じなので、大変とか辛いとか思ったことは一度もありません。好きでやっているし、好きじゃないと周りの同業者に立ち向かえないです。今はそんな時代です。

あと企業で働く上で最も大事なことを教えます。

コミュニケーション能力っす！！

これは当たり前のことなんですが、技術はあってもこれが足りてない人は多いんじゃないかなと思います。特にリーダーやマネージャーなど、人の上に立つような人には必須です。

なのでまだ技術に自信がなくても、普通のコミュニケーション能力をちゃんと持っているなら、あとは継続的な自己学習をしていける素養があるかどうかが大事だと思うので、もしこれからWeb系エンジニアなろうと頑張っていて該当している方は、自信を持ってスキル磨きを頑張ってみて下さい！

※女性の方がコミュニケーション能力が高い人が多いと思うので、もっと女性のエンジニアが増えてもいいのではと思ってます。

最後に

ということで、私のWeb系エンジニアに挑戦した3年間についてまとめました。

まだまだ学び足りないのと、生成AIという技術革新によって今後どうなっていくのかわかりませんが、引き続きやるべきことをコツコツやっていこうと思います。

現在も尚、Web系エンジニアにキャリアチェンジしたいと悩んでいる方も多かったりするのではと思いますが、私がこれまで歩んできた経験は記事にまとめているので、よければ参考にしてみて下さい！

こんにちは。Tomoyuki（@tomoyuki65）です。

まだまだ普及はしていませんが、一部の間で愛されているプログラミング言語に「Rust」があります。

そんなRustはメモリ安全性を重視したプログラミング言語であり、CやC++言語並のパフォーマンスを発揮しながら、ガベージコレクション（不要になったメモリ領域を自動的に解放する仕組み）なしでメモリ管理の安全性を実現（メモリ関連のバグを未然に防ぎやすい）しているのが特徴です。

どちらかというとC言語に近いため、ツール開発等に向いているような言語ですが、Web系のバックエンドAPI開発も普通に可能なため、将来的に普及していく可能性は高いと思われます。

ということで、そんなRustを使ってバックエンドAPI開発について試してみましたので、この記事では得られた知見をまとめます。

RustのaxumでバックエンドAPI開発を試す！

今回はaxumというフレームワークを用いてバックエンドAPI開発を試してみますが、開発環境の構築にはDockerを使いますので、もしまだ使えないという方はDocker Desktopなどをインストールして事前に使えるようにして下さい。

ではまず以下のコマンドを実行し、各種ファイルを作成します。

$ mkdir rust-sample && cd rust-sample
$ mkdir -p docker/local/rust && cd docker/local/rust
$ touch Dockerfile && cd ../../..
$ touch .env compose.yml

次に作成した各種ファイルをそれぞれ以下のように記述します。

・「docker/local/rust/Dockerfile」

FROM rust:1.86

WORKDIR /app

COPY . .

# ホットリロード用のライブラリをインストール
RUN cargo install cargo-watch

# Rust用のリンターをインストール
RUN rustup component add clippy

・「.env」

ENV=local
PORT=8080

・「compose.yml」

services:
  api:
    container_name: rust-api
    build:
      context: .
      dockerfile: ./docker/local/rust/Dockerfile
    command: cargo watch -x run
    volumes:
      - .:/app
    ports:
      - "8080:8080"
    env_file:
      - ./.env
    tty: true
    stdin_open: true

次に以下のコマンドを実行し、コンテナをビルドします。

$ docker compose build --no-cache

次に以下のコマンドを実行し、Rustのプロジェクト作成用の初期化を行います。

$ docker compose run --rm api cargo init --name rust_api

コマンド実行後、下図のように「src/main.rs」、「.gitignore」、「Cargo.toml」が作成されればOKです。

次に以下のコマンドを実行し、「src/main.rs」をコンパイルして実行してみます。

$ docker compose run --rm api cargo run

コマンド実行後、下図のように文字列「Hello, world!」が出力されればOKです。

axumというフレームワークでAPIを作る

次に以下のコマンドを実行し、APIで必要になる各種クレートを追加します。

$ docker compose run --rm api cargo add axum
$ docker compose run --rm api cargo add tokio --features full
$ docker compose run --rm api cargo add serde --features derive
$ docker compose run --rm api cargo add envy
$ docker compose run --rm api cargo add thiserror
$ docker compose run --rm api cargo add serde_json

次に以下のコマンドを実行し、API用の各種ファイルを作成します。

$ mkdir -p src/api && cd src/api
$ touch mod.rs router.rs

$ mkdir configs && cd configs
$ touch mod.rs config.rs && cd ..

$ mkdir errors && cd errors
$ touch mod.rs error.rs && cd ..

$ mkdir repositories && cd repositories && touch mod.rs
$ mkdir sample && cd sample
$ touch mod.rs sample_repository.rs && cd ../..

$ mkdir services && cd services && touch mod.rs
$ mkdir sample && cd sample
$ touch mod.rs sample_service.rs && cd ../..

$ mkdir handlers && cd handlers && touch mod.rs
$ mkdir sample && cd sample
$ touch mod.rs sample_handler.rs && cd ../..

$ mkdir usecases && cd usecases && touch mod.rs
$ mkdir sample && cd sample
$ touch mod.rs sample_usecase.rs && cd ../../../..

※クリーンアーキテクチャを参考に、ハンドラー層、ユースケース層、サービス層、リポジトリー層に分ける形でファイルを分割しています。

次に作成した各種ファイルをそれぞれ以下のように記述します。

・「src/api/mod.rs」

pub mod configs;
pub mod errors;
pub mod handlers;
pub mod repositories;
pub mod router;
pub mod services;
pub mod usecases;

※Rustではディレクトリ内にmod.rsを作成し、それによってモジュールの公開設定を行います。対象のモジュールを公開すると、別のモジュールファイルからアクセスできるようになります。尚、対象のモジュールの特定の処理だけ公開するとかも可能です。

・「src/api/router.rs」

// axum
use axum::{
    Router,
    routing::{get, post},
};

// ハンドラー用のモジュール
use super::handlers::sample::sample_handler;

pub fn router() -> Router {
    // APIのグループ「v1」
    let v1 = Router::new()
        .route("/sample/get", get(sample_handler::sample_get))
        .route(
            "/sample/get/{id}",
            get(sample_handler::sample_get_path_query),
        )
        .route("/sample/post", post(sample_handler::sample_post));

    // ルーティング
    Router::new()
        .nest("/api/v1", v1)
}

・「src/api/configs/mod.rs」

pub mod config;

・「src/api/configs/config.rs」

use envy;
use serde::{Deserialize};

// 環境変数のデフォルト値を返す関数
fn default_env() -> String {
    "local".to_string()
}

fn default_port() -> u16 {
    8080
}

// 環境変数の構造体
#[derive(Deserialize, Debug)]
pub struct Config {
    #[serde(default = "default_env")]
    pub env: String,
    #[serde(default = "default_port")]
    pub port: u16,
}

// 環境変数を返す関数
pub fn get_config() -> Config {
    match envy::from_env::<Config>() {
        Ok(config) => config,
        Err(err) => {
            println!("環境変数の初期化エラー: {}", err);

            // 環境変数にデフォルト値を設定して返す
            Config {
                env: default_env(),
                port: default_port(),
            }
        }
    }
}

※コンフィグファイルで環境変数を取得できるようにしています。「envy::from_env::<Config>()」戻り値は「Result<T, E>」型になっているため、matchで「Ok」または「Err」で条件判定させています。

・「src/api/errors/mod.rs」

pub mod error;

・「src/api/errors/error.rs」

use thiserror::Error;

#[derive(Error, Debug)]
pub enum CommonError {
    #[error("Internal Server Error")]
    InternalServerError,
}

※エラーファイルで、共通のエラー型を定義できるようにしています。

・「src/api/repositories/mod.rs」

pub mod sample;

・「src/api/repositories/sample/mod.rs」

pub mod sample_repository;

・「src/api/repositories/sample/sample_repository.rs」

// 共通エラー用モジュール
use crate::api::errors::error::CommonError;

// 文字列「Sample Hello !!」を返す関数
pub async fn sample_hello() -> Result<String, CommonError> {
    let text = "Sample Hello !!".to_string();

    if text.is_empty() {
        return Err(CommonError::InternalServerError);
    }

    Ok(text)
}

※リポジトリーファイルではDB操作や外部APIの実行などを記述する想定ですが、今回の例では文字列を返すだけの簡単な関数の処理にしています。

・「src/api/services/mod.rs」

pub mod sample;

・「src/api/services/sample/mod.rs」

pub mod sample_service;

・「src/api/services/sample/sample_service.rs」

// 共通エラー用モジュール
use crate::api::errors::error::CommonError;

// リポジトリ用のモジュール
use crate::api::repositories::sample::sample_repository;

// サンプルテキストを取得するサービス
pub async fn sample_get_text_hello() -> Result<String, CommonError> {
    let text = match sample_repository::sample_hello().await {
        Ok(text) => text,
        Err(err) => return Err(err),
    };

    Ok(text)
}

・「src/api/handlers/mod.rs」

pub mod sample;

・「src/api/handlers/sample/mod.rs」

pub mod sample_handler;

・「src/api/handlers/sample/sample_handler.rs」

// axum
use axum::{
    extract::{Path, Query},
    response::{Json, Response},
};

// 変換用のクレート
use serde::Deserialize;

// サービス用のモジュール
use crate::api::usecases::sample::sample_usecase;

// クエリパラメータ用の構造体
#[derive(Deserialize, Debug)]
pub struct QueryParams {
    pub item: Option<String>,
}

// リクエストボディの構造体
#[derive(Deserialize, Debug)]
pub struct RequestBody {
    pub name: String,
}

// GETメソッド用のAPIサンプル
pub async fn sample_get() -> Response {
    sample_usecase::sample_get_usecase().await
}

// GETメソッドかつパスパラメータとクエリパラメータ有りのAPIサンプル
pub async fn sample_get_path_query(
    Path(id): Path<String>,
    Query(params): Query<QueryParams>,
) -> Response {
    sample_usecase::sample_get_path_query_usecase(id, params).await
}

// POSTメソッド用のAPIサンプル
pub async fn sample_post(Json(body): Json<RequestBody>) -> Response {
    sample_usecase::sample_post_usecase(body).await
}

・「src/api/usecases/mod.rs」

pub mod sample;

・「src/api/usecases/sample/mod.rs」

pub mod sample_usecase;

・「src/api/usecases/sample/sample_usecase.rs」

// axum
use axum::{
    http::{StatusCode},
    response::{IntoResponse, Json, Response},
};

// json変換用マクロ
use serde_json::json;

// サービス用のモジュール
use crate::api::services::sample::sample_service;

// クエリパラメータ用の構造体
use crate::api::handlers::sample::sample_handler::QueryParams;

// リクエストボディ用の構造体
use crate::api::handlers::sample::sample_handler::RequestBody;

// GETメソッド用APIのサンプルユースケース
pub async fn sample_get_usecase() -> Response {
    // サンプルテキストを取得するサービスを実行
    let text = match sample_service::sample_get_text_hello().await {
        Ok(text) => text,
        Err(err) => {
            // json形式のメッセージを設定
            let msg = Json(json!({ "message": err.to_string()}));

            // レスポンス結果の設定
            let res = (StatusCode::INTERNAL_SERVER_ERROR, msg).into_response();

            // 戻り値としてレスポンス結果を返す
            return res;
        }
    };

    // json形式のメッセージを設定
    let msg = Json(json!({ "message": text}));

    // レスポンス結果を設定して戻り値として返す
    (StatusCode::OK, msg).into_response()
}

// GETメソッドかつパスパラメータとクエリパラメータ有りのサンプルユースケース
pub async fn sample_get_path_query_usecase(id: String, params: QueryParams) -> Response {
    let text = format!(
        "id: {}, item: {}",
        id,
        params.item.unwrap_or("".to_string())
    );

    // json形式のメッセージを設定
    let msg = Json(json!({ "message": text}));

    // レスポンス結果を設定して戻り値として返す
    (StatusCode::OK, msg).into_response()
}

// POSTメソッドのサンプルユースケース
pub async fn sample_post_usecase(body: RequestBody) -> Response {
    let text = format!("name: {}", body.name);

    // json形式のメッセージを設定
    let msg = Json(json!({ "message": text}));

    // レスポンス結果を設定して戻り値として返す
    (StatusCode::OK, msg).into_response()
}

次にファイル「src/main.rs」を以下のように修正します。

// axum
use axum::{
    Router,
    serve,
};

// apiモジュール
mod api;

// routerモジュール
use api::router::router;

// configsモジュール
use api::configs::config;

#[tokio::main]
async fn main() {
    // 環境変数取得
    let config = config::get_config();

    // サーバー起動のログ出力
    println!("Start rust_api (ENV:{}) !!", config.env);

    // サーバー起動
    let app = Router::new().merge(router());
    let addr = format!("0.0.0.0:{}", config.port);
    let listener = tokio::net::TcpListener::bind(addr).await.unwrap();
    serve(listener, app).await.unwrap();
}

次に以下のコマンドを実行し、コンテナを起動します。

$ docker compose up -d

次に作成したAPIを試しますが、APIの実行にはPostmanを使って試すため、もしまだ使ってないという方は事前に使えるようにして下さい。

ではまずGETメソッドのAPI「http://localhost:8080/api/v1/sample/get」を実行し、下図のように想定通りに正常終了すればOKです。

次にGETメソッドかつパスパラメータとクエリパラメータ有りのAPI「http://localhost:8080/api/v1/sample/get/11?item=book」を実行し、下図のように想定通りに正常終了すればOKです。

次にPOSTメソッドのAPI「http://localhost:8080/api/v1/sample/post」を実行し、下図のように想定通りに正常終了すればOKです。

テストコードを考慮してリポジトリー層をモック化しやすいように修正

上記ではクリーンアーキテクチャを参考にハンドラー層、ユースケース層、サービス層、リポジトリー層にコードを分けてAPIを作りましたが、さらにテストコードを書くことを考慮すると、特にリポジトリー層についてはモック化しやすいようにしておく必要があります。

そこでRustのstruct（構造体の定義）、impl（メソッドの定義）、trait（インターフェースの定義）を利用し、リポジトリー層をサービス層へ依存注入（他のオブジェクトを受け取って利用）できるように修正していきます。

まずは以下のコマンドを実行し、traitでasync fn（非同期関数）を扱いやすくする「async_trait」クレートを追加します。

$ docker compose exec api cargo add async_trait

次にユースケース層のファイルは1ハンドラー1ユースケースになるようファイル分割して作るため、以下のコマンドを実行してファイル「src/api/usecases/sample/sample_usecase.rs」の削除および、新しいファイルを3つ作成します。

$ rm -f src/api/usecases/sample/sample_usecase.rs
$ touch src/api/usecases/sample/sample_get_usecase.rs.rs
$ touch src/api/usecases/sample/sample_get_path_query_usecase.rs.rs
$ touch src/api/usecases/sample/sample_post_usecase.rs.rs

次に以下の各種ファイルについて、それぞれ修正等を行います。

・「src/api/repositories/sample/sample_repository.rs」

// 共通エラー用モジュール
use crate::api::errors::error::CommonError;

// サンプルリポジトリーの構造体
pub struct SampleRepository;

impl SampleRepository {
    // 初期化用メソッド
    pub fn new() -> Self {
        SampleRepository
    }
}

// サンプルリポジトリー用のトレイト（モック化もできるように定義）
#[async_trait::async_trait]
pub trait SampleRepositoryTrait {
    async fn sample_hello(&self) -> Result<String, CommonError>;
}

#[async_trait::async_trait]
impl SampleRepositoryTrait for SampleRepository {
    // 文字列「Sample Hello !!」を返す関数
    async fn sample_hello(&self) -> Result<String, CommonError> {
        let text = "Sample Hello !!".to_string();

        if text.is_empty() {
            return Err(CommonError::InternalServerError);
        }

        Ok(text)
    }
}

・「src/api/services/sample/sample_service.rs」

// 共通エラー用モジュール
use crate::api::errors::error::CommonError;

// リポジトリ用のモジュール
use crate::api::repositories::sample::sample_repository::SampleRepositoryTrait;

// 使用するリポジトリーをまとめる構造体
pub struct SampleCommonRepository {
    // Box<T>型で動的にメモリ領域確保
    // Send: オブジェクトが異なるスレッド間で安全に送信できることを保証
    // Sync: オブジェクトが複数のスレッドから同時にアクセスできることを保証
    // 'static: オブジェクトのライフタイムがプログラムが終了するまで破棄されない
    pub sample_repo: Box<dyn SampleRepositoryTrait + Send + Sync + 'static>,
}

// サンプルサービス
pub struct SampleService {
    repo: SampleCommonRepository,
}

impl SampleService {
    pub fn new(repo: SampleCommonRepository) -> Self {
        SampleService { repo }
    }
}

// サンプルサービス用のトレイト（モック化もできるように定義）
#[async_trait::async_trait]
pub trait SampleServiceTrait {
    async fn sample_get_text_hello(&self) -> Result<String, CommonError>;
}

#[async_trait::async_trait]
impl SampleServiceTrait for SampleService {
    async fn sample_get_text_hello(&self) -> Result<String, CommonError> {
        let text = match self.repo.sample_repo.sample_hello().await {
            Ok(text) => text,
            Err(err) => {
                return Err(err);
            }
        };

        Ok(text)
    }
}

※トレイトを依存注入できるようにするためにはBox<T>型を使う必要がありました。

・「src/api/usecases/sample/mod.rs」

pub mod sample_get_path_query_usecase;
pub mod sample_get_usecase;
pub mod sample_post_usecase;

・「src/api/usecases/sample/sample_get_usecase.rs」

// axum
use axum::{
    http::StatusCode,
    response::{IntoResponse, Json, Response},
};

// json変換用マクロ
use serde_json::json;

// サービスのモジュール
use crate::api::services::sample::sample_service::{SampleService, SampleServiceTrait};

// 使用するサービスをまとめる構造体
pub struct SampleCommonService {
    pub sample_service: SampleService,
}

// 実行するユースケースの構造体
pub struct SampleGetUsecase {
    pub service: SampleCommonService,
}

impl SampleGetUsecase {
    pub async fn exec(&self) -> Response {
        // サンプルテキストを取得するサービスを実行
        let text = match self.service.sample_service.sample_get_text_hello().await {
            Ok(text) => text,
            Err(err) => {
                // json形式のメッセージを設定
                let msg = Json(json!({ "message": err.to_string()}));

                // レスポンス結果の設定
                let res = (StatusCode::INTERNAL_SERVER_ERROR, msg).into_response();

                // 戻り値としてレスポンス結果を返す
                return res;
            }
        };

        // json形式のメッセージを設定
        let msg = Json(json!({ "message": text}));

        // レスポンス結果を設定して戻り値として返す
        (StatusCode::OK, msg).into_response()
    }
}

・「src/api/usecases/sample/sample_get_path_query_usecase.rs」

// axum
use axum::{
    http::StatusCode,
    response::{IntoResponse, Json, Response},
};

// json変換用マクロ
use serde_json::json;

// クエリパラメータ用の構造体
use crate::api::handlers::sample::sample_handler::QueryParams;

// 実行するユースケースの構造体
pub struct SampleGetPathQueryUsecase;

impl SampleGetPathQueryUsecase {
    pub async fn exec(&self, id: String, params: QueryParams) -> Response {
        // テキスト設定
        let text = format!(
            "id: {}, item: {}",
            id,
            params.item.unwrap_or("".to_string())
        );

        // json形式のメッセージを設定
        let msg = Json(json!({ "message": text}));

        // レスポンス結果を設定して戻り値として返す
        (StatusCode::OK, msg).into_response()
    }
}

・「src/api/usecases/sample/sample_post_usecase.rs」

// axum
use axum::{
    http::StatusCode,
    response::{IntoResponse, Json, Response},
};

// json変換用マクロ
use serde_json::json;

// リクエストボディ用の構造体
use crate::api::handlers::sample::sample_handler::RequestBody;

// 実行するユースケースの構造体
pub struct SamplePostUsecase;

impl SamplePostUsecase {
    pub async fn exec(&self, body: RequestBody) -> Response {
        // テキスト設定
        let text = format!("name: {}", body.name);

        // json形式のメッセージを設定
        let msg = Json(json!({ "message": text}));

        // レスポンス結果を設定して戻り値として返す
        (StatusCode::OK, msg).into_response()
    }
}

・「src/api/handlers/sample/sample_handler.rs」

// axum
use axum::{
    extract::{Path, Query},
    response::{Json, Response},
};

// 変換用のクレート
use serde::Deserialize;

// リポジトリーのモジュール
use crate::api::repositories::sample::sample_repository::SampleRepository;

// サービスのモジュール
use crate::api::services::sample::sample_service::{SampleCommonRepository, SampleService};

// ユースケースのモジュール
use crate::api::usecases::sample::sample_get_path_query_usecase::SampleGetPathQueryUsecase;
use crate::api::usecases::sample::sample_get_usecase::{SampleCommonService, SampleGetUsecase};
use crate::api::usecases::sample::sample_post_usecase::SamplePostUsecase;

// クエリパラメータ用の構造体
#[derive(Deserialize, Debug)]
pub struct QueryParams {
    pub item: Option<String>,
}

// リクエストボディの構造体
#[derive(Deserialize, Debug)]
pub struct RequestBody {
    pub name: String,
}

// GETメソッド用のAPIサンプル
pub async fn sample_get() -> Response {
    // サービスのインスタンス化
    let sample_repo = Box::new(SampleRepository::new());
    let sample_common_repo = SampleCommonRepository { sample_repo };
    let sample_service = SampleService::new(sample_common_repo);
    let sample_common_service = SampleCommonService { sample_service };

    // ユースケースを実行
    let sample_get_usecase = SampleGetUsecase {
        service: sample_common_service,
    };
    sample_get_usecase.exec().await
}

// GETメソッドかつパスパラメータとクエリパラメータ有りのAPIサンプル
pub async fn sample_get_path_query(
    Path(id): Path<String>,
    Query(params): Query<QueryParams>,
) -> Response {
    // ユースケースを実行
    let sample_get_path_query_usecase = SampleGetPathQueryUsecase;
    sample_get_path_query_usecase.exec(id, params).await
}

// POSTメソッド用のAPIサンプル
pub async fn sample_post(Json(body): Json<RequestBody>) -> Response {
    // ユースケースを実行
    let sample_post_usecase = SamplePostUsecase;
    sample_post_usecase.exec(body).await
}

次に3つのAPIをそれぞれ再度実行してみて下さい。修正前と同様にそれぞれ正常終了すればOKです。

尚、この記事ではテストコードについては割愛しますが、「mockall」クレートを追加後に対象のリポジトリーに「#[mockall::automock]」を追加することでモック用の構造体も自動作成され、それを使うとテストコードで対象のリポジトリーのモック化が可能になります。

最後に

今回はRustのaxum（フレームワーク）でバックエンドAPI開発を試した知見をまとめました。

Rustに関してはGo言語以上に情報が少なかったり、言語自体の難易度も高めなので、今回ご紹介した部分の基本的なことでさえキャッチアップするのが大変でした。

ただ基本的なところはある程度ご紹介できたと思うので、これからRustでバックエンドAPIを開発しようと検討している方は、ぜひ参考にしてみて下さい！

こんにちは。Tomoyuki（@tomoyuki65）です。

ついに発売された期待の最新作「モンスターハンターワイルズ」ですが、めちゃめちゃ面白くてトロフィーコンプまでやり込んでしまいました！

ということでこの記事では、モンハンワイルズの攻略情報をまとめます。

モンハンワイルズ攻略まとめ【MHWilds】

今作は初めてモンスターハンターシリーズをプレイする人にも楽しめるように、ゲーム全体の難易度としては優しめに設計されています。

特にゲーム序盤から上位帯に入るまではムービーなども多く、チュートリアル的な内容なため、サクサクプレイ可能です。

そして上位帯に入ってからは自由度が増し、HR（ハンターランク）を上げることでストーリーが進みますが、その過程の中でも例えば捕獲などのモンハン知識を深めるような設計をしており、上位帯のストーリーをクリアするところまで進めて一段落となります。

※逆に言うとモンハン経験者はサクッとクリアできて物足りなさを感じると思いますが、そういう方は今後のアップデートが全て終わってから一気にプレイするというのもありなのではないでしょうか。

モンハンワイルズの各種設定について

モンハンワイルズをプレイし始める際、最初に確認した方がいいグラフィック設定やオプション設定については、オープンβテスト時のものですが以下の記事を参考にしてみて下さい。

【関連記事】

モンハンワイルズでおすすめのグラフィック設定まとめ【Monster Hunter Wilds】

2024年11月2日

モンハンワイルズでおすすめのオプション設定まとめ【Monster Hunter Wilds】

2024年11月4日

救難信号でサポートハンター（NPC）を呼んで快適にソロプレイをする方法

ストーリーを進めると途中で救難信号と呼ばれる機能が使えるようになり、それを使うとマルチプレイが可能になります。

そして今作は救難信号を使った際にサポートハンター（NPC）を1〜3名呼ぶこともでき、ソロプレイでもNPCを含んだパーティーで快適にプレイできるようにもなってます。

救難信号使用時にサポートハンターを強制的に呼びたい場合、クエストカウンターからクエストの受注・参加画面を開き、メニュー「設定」から関連設定が可能です。

マルチプレイ設定がデフォルトでは「他プレイヤー＆サポートハンター」になっていますが、「サポートハンター」に変更すると強制的にサポートハンターを呼び出せます。

ただし、トロフィーコンプリートを目指したい場合、オトモと100回クエストをクリアするやつがあるため、トロフィーが取れるまでは最大参加人数を2に変更すると、サポートハンターを1名（+サポートハンターのオトモ）のみ呼び出せます。

モンハンワイルズでおすすめの装備について

私がよく利用している武器については、以下のように関連記事を書いているため、同じ武器種を使う場合はよければ参考にしてみて下さい。

【関連記事】

モンハンワイルズでおすすめの太刀装備まとめ【MHWilds】

2025年3月9日

モンハンワイルズでおすすめのライトボウガン装備まとめ【MHWilds】

2025年3月29日

上位帯に入ってからやるべきサイドミッション

上位帯に入ってからはHRを上げることでストーリーを進められますが、そんなHRを上げるのにはサイドミッションを進めていくのがおすすめです。

そのサイドミッションの中に回復アイテムなどの調合素材を効率的に集めるための機能が解放されるものがあるため、それについては優先的にクリアしましょう。

※チャプター4-3以降、スージャのアパルと会話でも一つ解放

また、モンハンシリーズ恒例の力の護符と守りの護符は以下のクエストで入手できます。

上位のストーリークリア後にやること

上位ストーリークリア後は一段落し、エンドコンテンツに入っていくわけですが、クリア後にやれることは以下の通りです。

装飾品の集め方

今作の装飾品は武器と防具で別カテゴリになっており、それぞれ集める必要がありますが、主な集め方は以下の通りです。

金の錬金チケットを集め、マカ錬金「竜人の錬金術」でガチャ

金の錬金チケットを集めたい場合、まずは隔ての砂原か緋の森で満月の時に咲く「一夜花の月華粉」を入手します。

隔ての砂原の場合、上図の赤丸の位置に咲きます。

※上図右側の方の場合、近くの簡易キャンプに崖がありますが、セクレトに乗った状態からジャンプすると崖を上がれます。

緋の森の場合、上図の赤丸の位置に咲きます。

次にもちもの交換から「セッカ」を選びます。

※セッカはスージャにいます

交換リストに「金の錬金チケット」があれば交換可能です。

※交換リストにない場合、休憩などをしてリストを更新すると出現する可能性があります。

次にスージャのマカ錬金から「竜人の錬金術」を選択します。

「古びた珠・剣」や「古びた珠・鎧」を選び、金の錬金チケットを利用してガチャを回せます。

※尚、武器の装飾品の方が集めにくい（いいやつが多い）ため、「古びた珠・剣」の方を優先的にガチャを回した方がいいです。

「古びた珠・剣」の場合、金の錬金チケット1枚で10個取得できます。

「古びた珠・鎧」の場合、金の錬金チケット1枚で20個取得できます。

通常個体のアルシュベルド等を周回してガチャ

調査クエストから装飾品を集めたい場合、通常個体のアルシュベルドなどは「古びた珠・剣」や「古びた珠・鎧」が入手しやすいため、救難信号などからマルチに参加するなどして周回して下さい。

※尚、アルシュベルドなどの余った素材は、アーティア武器の強化素材や防具を強化する鎧玉の素材にもなります。

マカ錬金「装飾品の錬金」でレア度が低い装飾品を取得

今作ではレア度が低い装飾品（主に1スロや2スロのもの）については、マカ錬金「装飾品の錬金」で取得可能になっているため、必要なものがあればここから取得して下さい。

※HR100以上になると2スロットの装飾品も交換できるようになります。

エンドコンテンツ

アーティア武器

モンハンワイルズのエンドコンテンツの一つとして、アーティア武器の作成があります。

歴戦個体のアルシュベルドなどを周回してアーティアパーツを集め、そのパーツを組み合わせてアーティア武器を生産し、そのアーティア武器を復元強化すると能力を解放できます。

アーティア武器の復元強化にはナナイロカネが50個必要になりますが、アルシュベルドなどの余った素材を利用し、油涌き谷の精錬所で交換して集められます。

※復元強化される能力についてはテーブル形式になっており、アーティア武器を生産した段階でどのような能力が付与されるかが決まっています。復元強化で能力確認後、ハズレなら解体することで利用したナナイロカネは戻ってきます。また、付与すべき能力については、基本的に攻撃力特化にした方が期待値が高いようです。

勲章集めてトロフィーコンプリート（実績解除）を目指すのもおすすめ

モンハンワイルズのやり込み要素の一つとして勲章集め（トロフィー集め・実績解除）がありますが、難易度は低めに設計されているため、コツコツやっていけば普通にコンプリートできると思います。

コンプリート報酬としてめちゃめちゃカッコいいネームプレートが貰えるため、トロフィーコンプリートを目指す価値は高いです！

トロフィーコンプで一番面倒なのがモンスターの最小金冠、最大金冠を集めることですが、今作は双眼鏡で事前にそのモンスターが金冠かどうかを確認できたり、金冠だった場合に調査クエストとして保存できるため、フレンドなどと一緒にできると効率的に集められます。

※ジンダハド、護竜アルシュベルド、ゾシアに金冠はありません

今後追加予定の無料タイトルアップデート

モンハンシリーズは発売後、数回の無料タイトルアップデートが行われ、新モンスターやイベントクエストなどが追加されるため、継続的に楽しめます。

詳しい情報については適宜発信されるので、詳細はモンハンワイルズの公式サイトなどをチェックしてみて下さい。

最後に

今回はモンハンワイルズの攻略情報についてまとめました。

今作もめちゃめちゃ面白く、私はトロフィーコンプリートまでやり込んでしまいましたが、忙しい現代人にも遊びやすい設計になっていて、神ゲーだと思います。

これからまだまだアップデートもされていって継続的に遊べる作品なので、今回ご紹介した情報もぜひ参考にしてみて下さい。

こんにちは。Tomoyuki（@tomoyuki65）です。

ついに発売された期待の最新作「モンスターハンターワイルズ」ですが、サブ武器として多用しているライトボウガンについても理解が深まりました。

この記事ではこれからモンハンワイルズを始める方向けに、おすすめのライトボウガン装備をご紹介します。

モンハンワイルズでおすすめのライトボウガン装備まとめ【MHWilds】

序盤〜下位ストーリークリアまで

モンハンワイルズの下位ストーリークリアまでについては、始めてモンハンをプレイする方向けのチュートリアル的な難易度になっているため、基本的には防御力だけ上げることを最重視すれば問題ありません。

ライトボウガンについては機動性を活かしつつ被弾しない立ち回りが大事なので、間合い管理しやすくなる回避距離UPLv3があると快適になります。

※上記装備で防御力を上げたい場合は鎧玉で強化して下さい。

また、武器についてはスキル「ファーストショット」（装填速度アップ）が付いている武器がおすすめです。

序盤はハンターライフルIでパーツを貫通弾追加弾倉に変更して貫通弾を使うようにしつつ、生産可能になったらレ・メドルギシュIに変更してそれを強化していけばいいです。

上位序盤〜上位のストーリークリアまで

上位からも基本的には防御力重視でいいと思いますが、ライトボウガン用に回避距離UPを付けたい場合は上記の通りです。

モンハンワイルズで火力を上げるのにおすすめのスキルの一つが連撃Lv1なので、上位序盤ではコンガメイルαを使うといいです。

また、上位のストーリークリアまでで一番強いのは終盤のゴアマガラなので、ゴアマガラの狩猟前には鎧玉で防御力を強化するか、別途防御力重視の装備に切り替えるのもありです。

上位クリア後

上位クリア後は回避距離UPLv3に加え、弱点特攻Lv5を最優先で付けつつ防御力も高めたいため、跳躍の護石とアルシュベルド防具を中心に作るのがおすすめです。

頭装備については一旦なんでもいいですが、もちもの交換で「アズズのなめし革」を入手すると解放される「アズズヘッドα」には渾身Lv2が付いていて会心率を上げれるのでおすすめです。

また、武器の装飾品については、貫通珠【３】、集中珠III【３】、集中珠II【２】、射法珠III【３】、射法珠II【２】、初弾珠【1】の取得を目指し、お好みの組み合わせで利用して下さい。（私は貫通珠【３】、射法珠II【２】、初弾珠【1】の組み合わせで使ってます。）

尚、エンドコンテンツのアーティア武器では貫通弾で強い武器は無いため、貫通弾を使う場合はこの煌雷銃メドルギシュが一旦最終装備です。

※歴戦王レ・ダウが実装されたら武器強化があるかも？

エンドコンテンツについて（アーティア武器）

モンハンワイルズのエンドコンテンツの一つとしてはアーティア武器の作成になります。

ライトボウガンのアーティア武器では残念ながら貫通弾が強い武器は無く、他の武器種ほどアーティア武器の必要性はありませんが、一部モンスターには有効だったりするため、必要に応じて作成して下さい。

ライトボウガンのアーティア武器としては各属性弾用の武器を作ることになりますが、水＞火＞氷＞雷の順番で作っていけばいいと思います。

※属性弾を使う際は弾切れしやすいため、必ず調合素材の持ち込みもするようにして下さい。また使い方としては「通常弾か貫通弾で速射ゲージ溜め→速射モードで属性弾→速射ゲージが切れたらまた通常弾か貫通弾で速射ゲージ溜め」を繰り返す感じになります。

アーティア武器に付与するボーナスについては、復元ボーナスで装填数強化×2を付けるのが必須で、残りは基礎攻撃力特化で作成する方が期待値が高いようなので、属性増強、基礎攻撃力増強×3、装填数強化×2、基礎攻撃力強化×3の組み合わせで作成できるとよさそうです。

また必要になる武器の装飾品については、各属性の属会・︎︎珠【３】、初弾・︎︎珠【３】、集中・︎︎珠【３】になります。

2025年3月時点の最終装備

※空きスロット：①×5

モンハンワイルズではゴア装備を2部位以上使うと発動する黒蝕一体（強制的に狂竜症を発症し、克服時に会心率+15%）と無我の境地Lv3（狂竜症を克服しやすくなり、克服時に会心率+10%）を合わせて使う組み合わせで会心率を上げるのが主流です。

ライトボウガンなら4部位装備する（発症時に攻撃力+10、克服時に追加で+5）のもおすすめで、上記の構成だと渾身発動で会心率が10%、狂竜症克服時に35%（攻撃力+15）、そして弱点部位に攻撃すれば65%（傷口もあれば85%）になります。

そして今作は使える時に「蝕攻の装衣」（着用時に体力減少、会心率+10%。攻撃を当て続けて克服時は体力減少が止まり、会心率+20%、攻撃力+20）を使うのが強く、ライトボウガンなら装着するだけで速射ゲージが溜まるため、「開幕速射ゲージ使用→蝕攻の装衣で速射ゲージ回復→再度速射ゲージ使用」という連携が可能です。

そのほか、空きスロットとして①×5があるため、ここはお好みで調整して下さい。

無料タイトルアップデート第1弾後の最終装備

※空きスロット：①×3

無料タイトルアップデート第1弾でゾシア装備が追加され、弱点特攻と挑戦者を同時に使える装備が組みやすくなりました。

ゴア装備4部位の場合の追加効果（攻撃力+15）が無くなった代わりに、挑戦者Lv3（モンスター怒り時に基礎攻撃力+12、会心率+7）と渾身Lv3（効果発動時に会心率+30%）が発動するため、より会心率が高い構成になってます。

尚、シリーズスキル「超回復力I」については、体力が2秒に1回復する効果ですが、それほど効果的なスキルではないため、無いよりはあった方がいいぐらいのものです。

無料タイトルアップデート第2弾後の最終装備

無料タイトルアップデート第2弾でセルレギオスとラギアクルス装備が追加されましたが、ラギア装備のシリーズスキル「蒼雷一閃I」は発動させると会心率+15%となり、より会心率を上げられる装備を組めるようになりました。

ライトボウガンについてはまだゴア装備は必須な感じなので、ゴア装備にラギア装備を組み込む形で使っていくことになりそうです。

※空きスロット：①×5

尚、セルレギオスやラギアクルス狩猟用に裂傷耐性や雷耐性を付けたい場合は、上記の構成にすると組み込めます。

Ver.1.021アップデート後の最終装備

※空きスロット：武器スロット③×1、②×1、①×1、防具スロット①×4

Ver.1.021アップデートで護石ガチャが追加され、当たりの護石によって武器用のスキルである速射強化などが付けれるようになり、火力アップに繋げられるようになりました。（当たりの護石の例：速射強化Lv1 + 連撃Lv1 + 武器スロット① + 防具スロット①×2など）

これらの当たりの護石を使うためにも、可能な限り防具だけで弱点特効などを付けるようにした方がいいため、上記のような防具の組み合わせがおすすめです。

尚、護石ガチャを取得するための歴戦星9モンスターはワンパンで即死するような破壊力が高い技をもってたりするため、歴戦王の防具を組み合わせてグループスキルの「根性【果敢】」も合わせて付けた方がいいです。

※根性【果敢】：致命的な大ダメージを一度だけ軽減。発動前は攻撃力が上がり防御力が下がる。発動後は防御力と耐性値が上がる。

ライトボウガン用の護石ガチャの当たりについて

ライトボウガン用の護石ガチャの当たりとしては以下の通りです。

※レア7以下でも近いスキルのものは代用品として使えます。

対歴戦セルレギオス・歴戦レダウ用装備（星9護石集め用）

護石ガチャ集めでおすすめのクエストについては、隔ての砂原の星9の歴戦セルレギオスと歴戦レダウのペアの調査クエストになり、歴戦セルレギオスで苦戦しやすいため、その対策装備を使いましょう。

耐裂珠【1】を耐雷珠【1】に変えればレダウの対策装備にもなりますが、最悪無くてもなんとかなります。

ただし、星9クエストはワンパンで即死することがあるので、防具の強化をMAXにするのを忘れないことと、スキル「根性【果敢】（ヌシの魂）」を付けるのが大事です。

無料タイトルアップデート第3弾の対オメガ用装備

※アズズ飯が必須の構成です（チケットはタルコロで集めて下さい）。アズズ飯で火耐性20以上、回避性能Lv5にできます。

無料タイトルアップデート第3弾でFF14コラボのオメガ・プラネテスが追加されました！

通常個体クリア後は、イベントクエストから「零式オメガ・プラネテス検証戦」も受注可能です。

オメガに関してはマルチ推薦で、最低でもサポートハンター（クエスト受注の設定から、最大参加人数4、マルチプレイ環境をサポートハンターのみ、救難信号の自動発信をON、サポートハンターの選択で、1アレサ、2カイ、3ミナにしましょう）を連れていくのがおすすめです。

対オメガで必須のスキルは根性【果敢】、火耐性20以上、気絶耐性Lv3、回避距離UPLv3、回避性能Lv5で、それを実現するにはアズズ飯も使うのがおすすめです。

また、オメガは敵視を取っている状態が長いほど戦闘が楽になりますが、ライトボウガンは頭を狙いやすく敵視を取りやすい武器種のため、基本的には積極的に頭を狙って敵視を取り、タンク役をやるようにすると安定感が増します。

ただサポートハンターのアレサや、他のガードできる武器種（ランスや片手剣など）の人がタンク役をやる場合、ガードしてもHPを削られるため、周りが適宜フォローしてあげるのが大事になります。

そのため、広域化Lv5を付けたり、生命の大粉塵を調合分まで持って行くのも大事になります。

オメガ戦では途中でネルスキュラクローンのDPSチェックがあり、ライトボウガンであればアーティアライトの火炎弾を使う（速射がない場合は単発でいいので撃つ）ことで比較的楽に対応できるため、メインが他の武器種の方にもおすすめです。

また、第2エリアなどでパントクラトルモードになったら傷口を3回破壊しないと解除できないため、遠距離武器なら弱点の前脚を狙って傷つけを狙って下さい。

あと最終エリアなどで多弾頭ミサイルで乙る人が多いですが、回避性能Lv5を付けてタイミングを覚えて回避すれば対処できる（ただし、フィールドの段差には注意）ので、苦手な方は練習してみて下さい。

無料タイトルアップデート第4弾後の貫通ライト

※空きスロット：防具スロット①×5以上（各種耐性系などを積めます。）

無料タイトルアップデート第4弾でゴグマジオスが追加されました！

防具の限界突破や、巨戟アーティア武器の追加により、装備の組み合わせの幅が一気に広がったのが特徴的です。

ライトボウガン装備に関しては、まず巨戟アーティアのライトボウガンを属性激化（貫通弾速射）し、かつ復元ボーナス次第（理論値は「斬れ味・装填強化EX×2、基礎攻撃力強化EX×2、基礎攻撃力強化III×1」と思われます。）で、これまで使っていたレダウの貫通ライトを超える性能をしているため、まずはここからアップデートしましょう！

また、巨戟アーティアにシリーズスキル「黒蝕竜の力」、グループスキル「ヌシの魂」を付与できれば、ゴア装備も組み込んで大幅に会心率を上げることも可能です。

ゴグマジオス装備を採用した属性特化装備

武器（スロット）/ レア度 / 備考
荊冠のデストレータ（③③③）/ RARE8 / 属性激化（貫通弾速射）、シリーズスキル「巨戟龍の黙示録」、グループスキル「ヌシの魂」、パーツは「属性弾強化火薬」、「速射専用追加弾倉」、特殊弾は「圧着竜弾」、主な装飾品：初弾・︎︎属性珠【3】×1、属会・︎︎属性珠【3】×1、積弾・︎︎属性珠【3】×1
サブ武器（スロット）/ レア度 / 備考
–
防具（スロット）/ スキル
頭	ゴグヘルムα（③①）/ フルチャージLv2、属性吸収Lv2
胴	エグゾルスメイルγ（③③）/ 逆襲Lv2
手	ゴグアームα（②①）/ 渾身Lv2、挑戦者Lv1
腰	ゴグコイルα（②①①）/ 連撃Lv2、フルチャージLv1
脚	トゥナムルグリーヴγ（③①①）/ 納刀術Lv3、挑戦者Lv1
護石	跳躍の護石IIIなど（回避距離UPLv2 + 防具スロット②×1以上のもの）
装飾品
挑戦者【3】×3、渾身珠【2】×1、耐衝珠【1】×1
発動スキル
挑戦者Lv5、フルチャージLv3、渾身Lv3、回避距離UPLv3、納刀術Lv3、連撃Lv2、逆襲Lv2、属性吸収Lv2、ひるみ軽減Lv1、宣戦呼応II（巨戟龍の黙示録）、根性【果敢】（ヌシの魂）

※空きスロット：防具スロット③×1、②×1、①×5以上（各種耐性系などを積めます。また持っている護石の種類によっては防具の組み合わせを調整可能です。）

各種属性武器を持っていく必要があるモンスターに対しては、ゴグマジオス装備のシリーズスキル「宣戦呼応（巨戟龍の黙示録）」を使った装備が強いです。

※宣戦呼応I：戦闘中の大型モンスターが怒ると、属性攻撃値が上昇する。、宣戦呼応II：Ⅰの効果が上昇し、一定時間、ダメージを防ぐ防壁を得る。（防壁を得る効果は一定時間経過しないと再発動しません）

各種属性の巨戟アーティア武器を作り、かつシリーズスキル「巨戟龍の黙示録」、グループスキル「ヌシの魂」の付与が必要ですが、現状のゴール装備の一つには間違いないです。

最終アップデート後

武器（スロット）/ レア度 / 備考
荊冠のデストレータ（③③③）/ RARE8 / 属性激化（貫通弾速射）または攻撃激化（通常弾速射）、シリーズスキル「巨戟龍の黙示録」、グループスキル「ヌシの魂」、パーツは「属性弾強化火薬」、「速射専用追加弾倉」、特殊弾は「圧着竜弾」、主な装飾品：初弾・︎︎属性珠【3】×1、属会・︎︎属性珠【3】×1、積弾・︎︎属性珠【3】×1
サブ武器（スロット）/ レア度 / 備考
–
防具（スロット）/ スキル
頭	ゴグヘルムα（③①）/ フルチャージLv2、属性吸収Lv2
胴	シュバルカメイルγ（③②）/ 属性変換Lv3、属性やられ耐性Lv1
手	ゴグアームα（②①）/ 渾身Lv2、挑戦者Lv1
腰	ゴグコイルα（②①①）/ 連撃Lv2、フルチャージLv1
脚	シュバルカグリーヴγ（③③）/ 鎖刃刺撃Lv2、属性やられ耐性Lv2
護石	自由
装飾品
挑戦珠【3】×4、渾身珠【2】×1、耐衝珠【1】×1
発動スキル
挑戦者Lv5、フルチャージLv3、渾身Lv3、属性変換Lv3、属性やられ耐性Lv3、連撃Lv2、鎖刃刺撃Lv2、属性吸収Lv2、ひるみ軽減Lv1、宣戦呼応II（巨戟龍の黙示録）、加速再生I（鎖刃竜の飢餓）、根性【果敢】（ヌシの魂）

※空きスロット：防具の②スロ×2、①スロ×3（装飾品か護石で回避距離Lv3を付けて下さい）

最終アップデートでは星10の歴戦王アルシュベルドが追加されたほか、他の星10歴戦王クエストも追加されました。

厳選した巨戟アーティア武器（巨戟龍の黙示録 + ヌシの魂）、ゴグマジオス装備、歴戦王アルシュベルド装備を組み合わせることで、汎用的な装備として「宣戦呼応II + 加速再生I + 根性【果敢】+ 属性やられ耐性Lv3」を同時に発動させられます。

※宣戦呼応IIで発動する防壁の効果が非常に優秀（75ダメージ分の被ダメージを無効化でき、防壁発動後から2分50秒経過すれば再発動も可能）のため、星10クエストなどの強力なモンスターに対しては、宣戦呼応IIを発動させるのが安定です。

※空きスロット：防具の③スロ×1、①スロ×2

またナディアさんのサイドミッションが追加され、クリア後に作れる「クイーンα」装備を組み合わせることで、「黒蝕一体II + 根性【果敢】」を同時に発動させる装備の組み合わせの幅が増えてます。

最後に

今回はモンハンワイルズでおすすめのライトボウガン装備についてご紹介しました。

モンハン慣れしている方であれば攻撃力の高い武器だけ使えば上位のストーリークリアまではある程度簡単に駆け上がれると思いますが、これから初めてモンハンをプレイし始める方や、初めてライトボウガンを使ってみる方は、ぜひ参考にしてみて下さい。

こんにちは。Tomoyuki（@tomoyuki65）です。

ついに発売された期待の最新作「モンスターハンターワイルズ」ですが、約40時間ほどで上位のストーリーまでクリアできました。

今回ももちろん、いつも愛用している太刀を使ってすすめたので、この記事ではこれからモンハンワイルズを始める方向けに、おすすめの太刀装備をご紹介します。

モンハンワイルズでおすすめの太刀装備まとめ【MHWilds】

序盤〜下位ストーリークリアまで

モンハンワイルズの下位ストーリークリアまでについては、始めてモンハンをプレイする方向けのチュートリアル的な難易度になっているため、基本的には防御力だけ上げることを最重視すれば問題ありません。

太刀に関しては納刀術Lv3があると操作性が快適になる（ただしモンハンライズよりは納刀時間が遅いので注意）ため、上記の装備で付けられます。

※上記装備で防御力を上げたい場合は鎧玉で強化して下さい。

また、武器については現状麻痺太刀が強いため、最初から最後までラバラ・グレブを強化していけばいいです。

上位序盤〜上位のストーリークリアまで

上位からも基本的には防御力重視でいいと思いますが、太刀用に納刀術を付けたい場合は上記の通りです。

モンハンワイルズで火力を上げるのにおすすめのスキルの一つが連撃Lv1なので、上位序盤ではタリオスアームαを使うといいです。

また、上位のストーリークリアまでで一番強いのは終盤のゴアマガラなので、ゴアマガラの狩猟前には鎧玉で防御力を強化するか、別途防御力重視の装備に切り替えるのもありです。

上位クリア後

上位クリア後は弱点特攻Lv5を最優先で付けたいのと、護鎖刃竜アームβはLv1スロットが3個あって装飾品の速納珠【１】が3個あれば納刀術Lv3も簡単に付けられます。

そして、シリーズスキルも加速再生I（鎖刃竜の飢餓）と破壊衝動I（護鎖刃竜の命脈）の二つが付くため、上記は汎用的な剣士装備の一つとしておすすめです。

また、護石は自由なので好みのものを付けることが可能ですが、太刀で火力を上げるなら逆襲Lv3（ふきとばされた後に一定時間攻撃力アップ、太刀のスーパーアーマーでも発動する）や巧撃（モンスターの攻撃回避で一定時間攻撃力アップ）などがおすすめです。

尚、武器の装飾品には麻痺珠III【３】と特会珠II【２】（または特会珠【１】× 2）を付けて麻痺属性の効果を強化するのがおすすめです。

エンドコンテンツについて（アーティア武器）

モンハンワイルズのエンドコンテンツの一つとしてはアーティア武器の作成になります。

現状では会心率特化よりも、基礎攻撃力特化で作成する方が期待値が高いようなので、麻痺属性かつ基礎攻撃力増強×3、切れ味強化×1、基礎攻撃力強化×4の組み合わせで作成できるとよさそうです。

2025年3月時点の最終装備

※空きスロット：①×3

モンハンワイルズで会心率を上げたい場合、ゴア装備を2部位以上使うと発動する黒蝕一体（強制的に狂竜症を発症し、克服時に会心率+15%）と無我の境地Lv3（狂竜症を克服しやすくなり、克服時に会心率+10%）を合わせて使う組み合わせが主流です。

上記の構成だとデフォルトの会心率が17%、渾身発動で47%、狂竜症克服時に72%、そして弱点部位に攻撃すれば100%以上（弱点部位なら+30%、傷口もあれば+20%）にすることが可能になってます。（これぐらい会心率を上げると達人芸が活きます）

そして今作は使える時に「蝕攻の装衣」（着用時に体力減少、会心率+10%。攻撃を当て続けて克服時は体力減少が止まり、会心率+20%、攻撃力+20）を使うのが強かったりしますが、近接武器だと体力減少するのがちょっと面倒だったりするため、それを補ったり、ちょっとしたダメージを回復させるために加速再生I（継続して攻撃を当てると体力回復）を付けて快適性を上げています。

そのほか、空きスロットとして①×3があるため、ここはお好みで調整して下さい。

無料タイトルアップデート第1弾後の最終装備

※空きスロット：①×1

無料タイトルアップデート第1弾でゾシア装備が追加され、弱点特攻Lv5と挑戦者Lv5を同時に使える装備が組みやすくなりました。

挑戦者を優先すると逆襲や連撃が付けれませんが、それらよりも挑戦者Lv5（モンスター怒り時に基礎攻撃力+20、会心率+15）を付けた方が安定的に強いため、太刀の場合は今回の装備がおすすめです。

尚、シリーズスキル「超回復力I」については、体力が2秒に1回復する効果ですが、それほど効果的なスキルではないため、無いよりはあった方がいいぐらいのものです。

無料タイトルアップデート第2弾後の巧撃装備

※空きスロット：①×2

無料タイトルアップデート第2弾でセルレギオスとラギアクルス装備が追加され、太刀と相性が良い巧撃（回避時、タイミングよくモンスターの攻撃が重なると、一定時間攻撃力が上がる。）スキルを組み込みやすくなりました。

シリーズスキルの蒼雷一閃Iは発動させると会心率+15%、千刃の身躱しIは巧撃スキルの効果時間を延長させる効果があり、ゴア装備を外すなら代わりにラギア装備を使うというような選択肢が生まれました。

太刀であれば見切り斬りで巧撃を発動させやすいため、スキル「千刃の身躱し」と合わせて使うなら挑戦者より優先して付けてもよさそうです。

尚、セルレギオスやラギアクルス狩猟用に裂傷耐性や雷耐性を付けたい場合は、頭を「ラギアヘルムβ」に変更すると付けられます。

Ver.1.021アップデート後の最終装備

※空きスロット：武器スロット③×3、防具スロット②×1、①×2

Ver.1.021アップデートで護石ガチャが追加され、当たりの護石によって武器用のスキルである達人芸や業物などが付けれるようになり、火力アップに繋げられるようになりました。（当たりの護石の例：達人芸Lv1 + 挑戦者Lv1 + 武器スロット① + 防具スロット①×2など）

これらの当たりの護石を使うためにも、可能な限り防具だけで弱点特効や挑戦者を付けるようにした方がいいため、上記のような防具の組み合わせがおすすめです。

尚、護石ガチャを取得するための歴戦星9モンスターはワンパンで即死するような破壊力が高い技をもってたりするため、歴戦王の防具を組み合わせてグループスキルの「根性【果敢】」も合わせて付けた方がいいです。

※根性【果敢】：致命的な大ダメージを一度だけ軽減。発動前は攻撃力が上がり防御力が下がる。発動後は防御力と耐性値が上がる。

太刀用の護石ガチャの当たりについて

太刀用の護石ガチャの当たりとしては以下の通りです。

※レア7以下でも近いスキルのものは代用品として使えます。

対歴戦セルレギオス・歴戦レダウ用装備（星9護石集め用）

護石ガチャ集めでおすすめのクエストについては、隔ての砂原の星9の歴戦セルレギオスと歴戦レダウのペアの調査クエストになり、歴戦セルレギオスで苦戦しやすいため、その対策装備を使いましょう。

耐裂珠【1】を耐雷珠【1】に変えればレダウの対策装備にもなりますが、最悪無くてもなんとかなると思います。

ただし、星9クエストはワンパンで即死することがあるので、防具の強化をMAXにするのを忘れないことと、スキル「根性【果敢】（ヌシの魂）」を付けるのが大事です。

尚、太刀でセルレギオスを狩る際は、メインの攻撃方法としてはモンスターの突進攻撃に対して特殊納刀から居合抜刀気刃斬りをすることで、さらに抜刀攻撃後にRボタン長押しで溜め攻撃に派生させてからそれをキャンセルして特殊納刀すること（連続して居合抜刀気刃斬りができる）なので、これを知らない方はまず練習するのをおすすめします！

あと被弾した際はすぐにセクレトを読んで一時避難しながら回復するのも大事です。

無料タイトルアップデート第3弾の対オメガ用装備

※アズズ飯が必須の構成です（チケットはタルコロで集めて下さい）。アズズ飯で火耐性20以上、回避性能Lv5にできます。防具の空きスロットが③×3ありますが、零式オメガの場合は耐拘珠【1】×3で拘束耐性Lv3にして下さい。

無料タイトルアップデート第3弾でFF14コラボのオメガ・プラネテスが追加されました！

通常個体クリア後は、イベントクエストから「零式オメガ・プラネテス検証戦」も受注可能です。

オメガに関してはマルチ推薦で、最低でもサポートハンター（クエスト受注の設定から、最大参加人数4、マルチプレイ環境をサポートハンターのみ、救難信号の自動発信をON、サポートハンターの選択で、1アレサ、2カイ、3ミナにしましょう）を連れていくのがおすすめです。

対オメガで必須のスキルは根性【果敢】、火耐性20以上、気絶耐性Lv3、回避距離UPLv3、回避性能Lv5で、零式オメガならこれに加えて拘束耐性Lv3も欲しい（近接武器の場合のみ）ですが、それを実現するにはアズズ飯も使うのがおすすめです。

また、オメガの敵視を取ってタンク役をやってくれる人が特にガード系武器（ランスや片手剣など）の場合、ガードしてもHPを削られるため、周りが適宜フォローしてあげるのが大事になります。（誰かが敵視を取っている状態が長いほど、戦闘が楽になるため、まだ敵視を取ってない状態では武器種問わず頭を積極的に攻撃した方がいいです。）

そのため、広域化Lv5を付けたり、生命の大粉塵を調合分まで持って行くのも大事になります。

オメガ戦では途中でネルスキュラクローンのDPSチェックがあり、ガードできない武器では苦戦しやすいため、麻痺させている間に削るのが大事です。（フィールドに沸くモルボルやサボテンダーを上手く使うと倒しやすくできるので、仲間と連携を取れるなら火属性の武器を使うのがおすすめです）

近接武器でどうしてもDPSチェックをクリアできない場合は、ライトボウガンの火炎弾を使うのがおすすめなので、ぜひ試してみて下さい。

また、第2エリアなどでパントクラトルモードになったら傷口を3回破壊しないと解除できないため、近接武器なら弱点の後ろ脚を狙って傷つけを狙って下さい。

あと最終エリアなどで多弾頭ミサイルで乙る人が多いですが、回避性能Lv5を付けてタイミングを覚えて回避すれば対処できる（ただし、フィールドの段差には注意）ので、苦手な方は練習してみて下さい。

モンハンワイルズは居合抜刀気刃斬りが結構強い

モンハンワイルズの太刀で火力を出したい場合、特殊納刀から居合抜刀気刃斬りを出すのがおすすめみたいなので、その場合は武器スキルの抜刀術【技】Lv1を付ける構成がおすすめです。（特にセルレギオスのような突進系タイプ）

ただし、これはモンスター相性も絡み、居合抜刀気刃斬りを当てるタイミングが少ないモンスターなら弱点部位に対して赤刃ループなどで手数を稼ぐことになるため、武器スキルに業物を使うなら挑戦者特化、武器スキルに達人芸を使うなら弱点特効特化にするような構成にするのがおすすめになると思います。

無料タイトルアップデート第4弾後の無尽蔵装備

※空きスロット：防具スロット①×6（耐性系を積みやすくするため胴に護雷顎竜装備を採用しています。必要に応じて逆襲も削れます。）

無料タイトルアップデート第4弾でゴグマジオスが追加されました！

防具の限界突破や、巨戟アーティア武器の追加により、装備の組み合わせの幅が一気に広がったのが特徴的です。

太刀装備に関しては、ゴグマジオス装備によって簡単に「無尽蔵I（雷顎竜の闘志） + 根性【果敢】（ヌシの魂）」の組み合わせが実現できるようになり、基本的には無尽蔵装備（体術Lv5があれば見切り切りをしても渾身が切れない）を使っていくのが快適です。

※空きスロット：防具スロット①×3（必要に応じて逆襲も削れます。）

また、巨戟アーティア武器にシリーズスキル「黒蝕竜の力」、グループスキル「ヌシの魂」を付与できれば、ゴア装備も組み込んで大幅に会心率を上げることも可能です。

尚、これらの装備は主に属性を考慮しなくてもいいモンスター用であるため、まずは無属性系の武器種（無属性、麻痺、毒、睡眠、爆破など）で、一本だけシリーズスキル「黒蝕竜の力」、グループスキル「ヌシの魂」を付けられるといいです。

ゴグマジオス装備を採用した属性特化装備

武器（スロット）/ レア度 / 備考
斬罪のエルガンシオ（③③③）/ RARE8 / シリーズスキル「巨戟龍の黙示録」、グループスキル「ヌシの魂」、主な装飾品：︎︎属性・匠珠【3】×1、属会・匠珠【3】×1、飛燕・抜刀術【3】×1
サブ武器（スロット）/ レア度 / 備考
–
防具（スロット）/ スキル
頭	ゴグヘルムα（③①）/ フルチャージLv2、属性吸収Lv2
胴	エグゾルスメイルγ（③③）/ 逆襲Lv2
手	ゴグアームα（②①）/ 渾身Lv2、挑戦者Lv1
腰	ゴグコイルα（②①①）/ 連撃Lv2、フルチャージLv1
脚	トゥナムルグリーヴγ（③①①）/ 納刀術Lv3、挑戦者Lv1
護石	業物Lv3 + 挑戦者Lv1 + スロット①×2以上のものなど
装飾品
挑戦珠【3】×2、渾身珠【2】×1、逆襲珠【2】×1、耐衝珠【1】×1
発動スキル
挑戦者Lv5、フルチャージLv3、逆襲Lv3、渾身Lv3、納刀術Lv3、連撃Lv2、属性吸収Lv2、ひるみ軽減Lv1、宣戦呼応II（巨戟龍の黙示録）、根性【果敢】（ヌシの魂）

※空きスロット：防具スロット③×2、①×7

各種属性武器を持っていく必要があるモンスターに対しては、ゴグマジオス装備のシリーズスキル「宣戦呼応（巨戟龍の黙示録）」を使った装備が強いです。

※宣戦呼応I：戦闘中の大型モンスターが怒ると、属性攻撃値が上昇する。宣戦呼応II：Ⅰの効果が上昇し、一定時間、ダメージを防ぐ防壁を得る。（防壁を得る効果は一定時間経過しないと再発動しません）

各種属性の巨戟アーティア武器を作り、かつシリーズスキル「巨戟龍の黙示録」、グループスキル「ヌシの魂」の付与が必要ですが、現状のゴール装備の一つには間違いないです。

最終アップデート後

※空きスロット：防具の②スロ×1、①スロ×3（装飾品か護石で納刀術Lv3を付けて下さい）

最終アップデートでは星10の歴戦王アルシュベルドが追加されたほか、他の星10歴戦王クエストも追加されました。

厳選した巨戟アーティア武器（巨戟龍の黙示録 + ヌシの魂）、ゴグマジオス装備、歴戦王アルシュベルド装備を組み合わせることで、汎用的な装備として「宣戦呼応II + 加速再生I + 根性【果敢】+ 属性やられ耐性Lv3」を同時に発動させられます。

※宣戦呼応IIで発動する防壁の効果が非常に優秀（75ダメージ分の被ダメージを無効化でき、防壁発動後から2分50秒経過すれば再発動も可能）のため、星10クエストなどの強力なモンスターに対しては、宣戦呼応IIを発動させるのが安定です。

※空きスロット：防具の③スロ×2、①スロ×3（腰はシュバルカコイルγに変えることも可能です）

またナディアさんのサイドミッションが追加され、クリア後に作れる「クイーンα」装備を組み合わせることで、「無尽蔵I + 黒蝕一体I + 根性【果敢】+ 体術Lv5」を同時に発動させる装備の組み合わせの幅が増えてます。

最後に

今回はモンハンワイルズでおすすめの太刀装備についてご紹介しました。

モンハン慣れしている方であれば攻撃力の高い武器だけ使えば上位のストーリークリアまではある程度簡単に駆け上がれると思いますが、これから初めてモンハンをプレイし始める方や、初めて太刀を使ってみる方は、ぜひ参考にしてみて下さい。