ガイド

Claude Codeのコードレビュー完全ガイド【2026年最新】:コマンド・GitHub Actions・自動レビューまで徹底解説

室谷東吾
監修者室谷東吾(@0x__tom

株式会社MYUUU 代表取締役 / 日本最大級AIコミュニティ「.AI」創設者(累計2,000名超)/ セプテーニ・ホールディングス(電通グループ)と資本業務提携 / 著書「お金を使わず、AIを働かせる『Dify』活用」(ぱる出版、3刷)/ Xフォロワー約2万人

テキトー教師
監修者テキトー教師(@tekitoo_T_cher

.AI 認定講師 / 教育×AIの専門家 / 累計300名以上にAI活用を指導 / 「テキトーに学ぶ」がモットーの実践派講師 / Xアカウント

Claude Codeのコードレビュー完全ガイド【2026年最新】:コマンド・GitHub Actions・自動レビューまで徹底解説

Claude Codeのコードレビュー完全ガイド【2026年最新】:コマンド・GitHub Actions・自動レビューまで徹底解説

室谷室谷
今回はClaude Codeのコードレビュー機能の話をしましょう。これ、.AI(ドットエーアイ)コミュニティでも「PRのレビューどうやるの?」「claude code reviewerって何?」って毎週聞かれるんですよね。
テキトー教師テキトー教師
講座でも必ず出てくる質問ですね。「Claude Codeって会話しながらコード書くだけじゃないの?」って思っているコミュニティのメンバーさんが多いんですが、コードレビューの使い方はそれとは全然別の話で・・・
室谷室谷
そうなんですよ。大きく分けると3つのアプローチがあります。

ターミナルで直接レビューを頼む方法、GitHub Actionsに組み込む方法、それからAnthropicが提供しているCode Review機能(マネージドサービス)を使う方法です。
テキトー教師テキトー教師
この3つで用途がかなり違うので、自分のプロジェクトに何が合うかを把握するのが大事ですよね。個人開発者と、チームでGitHubを使っている人とでは全然違う選択になります。
室谷室谷
MYUUUでも実際に使い分けていて・・・個人のコード確認にはターミナルで直接やることが多いです。でもチームのPRレビューはGitHub Actions経由の方が圧倒的に便利です。
テキトー教師テキトー教師
この記事を読むと、3つのアプローチの違いと自分に合った使い方がわかります。では一番シンプルなターミナルでのレビューから順番に見ていきましょう。

ターミナルからClaude Codeにコードレビューを頼む基本

室谷室谷
まず一番シンプルなのが、ターミナルのClaude Codeに直接「このコードをレビューして」と頼む方法です。特別な設定も何も要らない。
テキトー教師テキトー教師
そうですね。claude コマンドでセッションを開いて、そのまま会話でレビューを依頼するだけです。

これが一番ハードルが低くて、コミュニティのメンバーさんに最初に覚えてもらう方法です。
室谷室谷
コマンドで言うと、こんな感じですね。

```bash

特定のファイルをレビューする

claude "src/auth.tsをレビューしてください。セキュリティ上の問題点と改善点を教えてください"

Gitの差分をレビューする

git diff HEAD~1 | claude "このdiffをレビューして。バグや問題がないか確認して"

PRの変更内容を一括レビューする

git diff main...feature-branch | claude "このブランチの変更をコードレビューしてください" ```

テキトー教師テキトー教師
git diff をパイプで渡す方法、これほんとに便利なんですよ。claude コマンドは標準入力でテキストを受け取れるので、Gitの差分をそのまま食べさせられます。
室谷室谷
非インタラクティブモードで使うのがポイントで。claude "プロンプト" とコマンドラインに直接書くか、パイプで繋ぐ方法です。
テキトー教師テキトー教師
レビューの粒度も指定できます。「バグだけ見て」「セキュリティ観点でレビューして」「命名規則のチェックをして」とか・・・指示次第でClaude Codeが焦点を変えてくれます。
室谷室谷
ここで一つ実用的な使い方があって。コミットする前にステージングされた変更をチェックする習慣をつけると、プッシュ前に問題を見つけられるんですよね。

```bash

コミット前のレビューをClaude Codeに流す

git diff --staged | claude "コミット前の確認です。問題点があれば指摘してください" ```

テキトー教師テキトー教師
講座でこれを教えると「毎回やるのが面倒」って言うコミュニティのメンバーさんがいるんですが・・・Claude Code Hooksを使えば自動化できますよね。
室谷室谷
そうです。PreToolUse フックで git commit の前に自動でレビューを走らせる設定もできます。

Claude Code reviewerとしての役割をCLAUDE.mdで設定する

テキトー教師テキトー教師
CLAUDE.md にレビューの基準を書いておくと、毎回細かく指示しなくていいですよね。
室谷室谷
これ、MYUUUでも使っています。例えばこんな感じで書いておくと・・・

```markdown

CLAUDE.md

コードレビューの基準

  • セキュリティ: SQLインジェクション、XSS、認証バイパスのリスクを必ず確認
  • パフォーマンス: N+1クエリ、不要なループ処理をチェック
  • 命名規則: キャメルケース(TypeScript)、スネークケース(Python)を統一
  • テスト: 新しい関数には必ずユニットテストが必要 ```
テキトー教師テキトー教師
こうしておくと「レビューして」と一言言うだけで、プロジェクト固有の基準に沿ったレビューをしてくれます。
室谷室谷
Claude Codeは CLAUDE.md を毎ターンシステムプロンプトとして読み込むので、一度書いておけばずっと有効なんですよね。これがClaude Codeの強みの一つです。

claude code reviewコマンドの実践的な使い方

テキトー教師テキトー教師
コマンドラインでのレビューをもう少し掘り下げましょう。単に「レビューして」だけじゃなく、出力をコントロールする方法も大事ですよね。
室谷室谷
出力フォーマットを制御するのは重要ですね。特にCIに組み込んだり、他のツールと連携するときに。

```bash

テキスト形式でファイルに保存

git diff HEAD~1 | claude "レビューして" > review-result.txt

JSON形式で出力(パースしやすい)

git diff HEAD~1 | claude --output-format json "レビューして。問題点をまとめて出力してください"

非インタラクティブモードで1回だけ実行

git diff HEAD~1 | claude --print "セキュリティ上の問題のみ指摘してください。問題がなければ「問題なし」と出力してください" ```

テキトー教師テキトー教師
--print フラグは非インタラクティブモードのフラグですね。これを使うとClaude Codeが1回だけ応答して終了します。

スクリプトに組み込むときに便利です。
室谷室谷
--output-format オプションは jsontextstream-json の3種類があります。自動化スクリプトで結果をパースするなら json が扱いやすいですね。
テキトー教師テキトー教師
ここで一つ気をつけるポイントがあって。差分が大きいPRだとコンテキストウィンドウを圧迫するんですよ。

コミュニティのメンバーさんが「レビューが途中で止まった」って相談してくれることがあります。
室谷室谷
その場合はファイルごとに分割してレビューするのが現実的です。git diff HEAD~1 -- src/auth/ みたいにディレクトリを絞るとか・・・
テキトー教師テキトー教師
変更量が多いPRほど、レビューの指示を絞った方が精度が上がりますよね。「全部見て」より「認証周りのセキュリティだけ」の方がClaude Codeも集中できます。

Pull RequestをClaude Codeでレビューするコマンド例

室谷室谷
GitHub上のPull Requestをレビューする方法も整理しておきましょう。GitHub CLI(gh)と組み合わせると便利です。

```bash

gh CLIでPRの差分を取得してClaude Codeに渡す

gh pr diff 123 | claude "このPRをレビューしてください"

PRのタイトルと本文も含めてレビュー

PR_TITLE=$(gh pr view 123 --json title --jq '.title') gh pr diff 123 | claude "PR名: ${PR_TITLE}。このPRの変更内容を見てレビューしてください" ```

テキトー教師テキトー教師
gh コマンドと組み合わせる発想、これはあまり知られていないんですよ。Claude CodeとGitHub CLIはかなり相性がいいです。
室谷室谷
Gitのワークフロー全般をClaude Codeが支援できるんで・・・レビューだけじゃなくて、コミットメッセージの生成、PRの説明文の作成、Changelogの更新まで一気通貫でできます。

GitHub ActionsでClaude Codeをコードレビューに使う

Claude Code GitHub Actionsの公式ドキュメントページ(公式サイトより)

室谷室谷
個人の開発環境を超えて、チーム全体でコードレビューを自動化するなら、GitHub Actionsに組み込むのが正攻法ですね。
テキトー教師テキトー教師
この仕組みを講座で説明するときに、受講生さんの反応が一番大きいのがここです。「PRに @claude とコメントするだけでレビューしてくれる」って言うと、みんな「え、それだけ?」ってなります(笑)
室谷室谷
そうなんですよ。Claude Code GitHub Actionsを設定しておくと、PRのコメントで @claude をメンションするだけでClaude Codeが動いてくれます。
テキトー教師テキトー教師
実際の動作を整理すると・・・
  • @claude とコメント → Claude Codeがレビューを実行してPRにコメントとして返す
  • @claude このバグを直して → コードを修正して新しいコミットを追加
  • @claude テストを書いて → テストファイルを生成してコミット
室谷室谷
「レビューするだけじゃなくて直してくれる」のが他のコードレビューツールとの大きな違いですよね。

GitHub Actionsワークフローの設定方法

テキトー教師テキトー教師
セットアップの手順を整理しましょう。Claude Code GitHub Actions v1.0以降では @v1 アクションを使うのが推奨です。
室谷室谷
ターミナルで claude を開いて /install-github-app を実行するのが一番簡単な方法です。リポジトリの管理者権限があれば、このコマンドがGitHub Appのインストールから設定まで全部ガイドしてくれます。
テキトー教師テキトー教師
手動でやる場合は、GitHubの .github/workflows/ ディレクトリにワークフローファイルを置く必要がありますね。

```yaml

.github/workflows/claude.yml

name: Claude Code

on: issue_comment: types: [created] pull_request_review_comment: types: [created]

jobs: claude: if: contains(github.event.comment.body, '@claude') runs-on: ubuntu-latest steps: - uses: anthropics/claude-code-action@v1 with: anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }} ```

室谷室谷
これが最小構成です。ANTHROPIC_API_KEY をリポジトリのSecretsに設定するだけで動きます。
テキトー教師テキトー教師
CLAUDE.md にプロジェクトのルールを書いておけば、@claude でのレビューもそのルールに従って実行されます。ここはターミナルでのレビューと同じ仕組みですね。
室谷室谷
claude_args でモデルや最大ターン数も指定できます。より深いレビューをしたいときは claude-opus-4-6 を指定するとか・・・

```yaml

  • uses: anthropics/claude-code-action@v1 with: anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }} claude_args: | --model claude-opus-4-6 --max-turns 20 --append-system-prompt "コードレビューでは必ずセキュリティ観点を含めてください" ```
テキトー教師テキトー教師
--append-system-prompt でレビューの指示を追加できるのがいいですね。CLAUDE.mdに書く内容とは別に、GitHub Actions用のプロンプトを設定できます。

ベータ版からv1.0への移行(Breaking Changes)

室谷室谷
これ、ベータ版から使っているチームは要注意です。v1.0でインターフェースが大きく変わっています。
テキトー教師テキトー教師
変更点を整理すると・・・
ベータ版のオプションv1.0の書き方
mode: "tag"削除(自動検出に変更)
direct_promptprompt
custom_instructionsclaude_args: --append-system-prompt
max_turnsclaude_args: --max-turns
modelclaude_args: --model
室谷室谷
mode の設定が消えたのが一番大きな変更ですね。v1.0はPRコメントかissueコメントかを自動検出してくれるようになりました。
テキトー教師テキトー教師
ベータ版ワークフローをそのまま使っていると動かなくなるので、GitHubのActionsのログを見てエラーを確認してください。

Code Review機能:Anthropic公式の自動PRレビューサービス

Claude Code Code Review機能のページ(公式サイトより)

室谷室谷
ここからが今回のハイライトで。AnthropicがCode Reviewという機能を出していて、これが従来のGitHub Actionsとは全然違う仕組みなんですよね。
テキトー教師テキトー教師
公式ドキュメントを読んで最初に驚いたのが「複数の専門エージェントが並列でレビューする」というアーキテクチャです。単一のAIが全部見るのとは根本的に違いますよね。
室谷室谷
そうなんですよ。Code Review機能は複数のエージェントが並列で動いて、それぞれ別のカテゴリの問題を探します。

ロジックエラー、セキュリティ脆弱性、エッジケース、回帰バグ・・・役割分担してチェックした後に、結果をまとめてPRのインラインコメントとして出力する仕組みです。
テキトー教師テキトー教師
これは「一人のエンジニアが全部チェックする」ではなく「複数のレビュアーが担当を分けてレビューする」チームレビューのシミュレーションですよね。

Code Reviewの重要度レベルと使い方

室谷室谷
出力される指摘には重要度レベルが付いていて・・・
マーカー重要度意味
🔴 Important重要マージ前に修正すべきバグ
🟡 Nit軽微修正推奨だがブロッキングではない
🟣 Pre-existing既存問題このPRで導入されたバグではない
テキトー教師テキトー教師
この分類が実用的ですよね。「このPRで新しく導入した問題」と「もともとコードベースにあった問題」を区別してくれるのは、既存プロジェクトに使うときに助かります。
室谷室谷
「Pre-existing」の指摘はマージをブロックしないけど、「Important」の指摘があったら修正推奨というスタンスです。Code Reviewは承認もブロックもしないので、既存のレビューワークフローを壊さないのもポイントですね。

Code Reviewのセットアップと料金

テキトー教師テキトー教師
セットアップはAnthropicの管理画面から行います。TeamプランかEnterpriseプランが必要で、個人のProプランでは使えません。
室谷室谷
手順としては、 を開いて Code Review セクションから設定します。GitHubのOrganizationに対してClaude GitHub Appをインストールするフローが走ります。
テキトー教師テキトー教師
リポジトリごとにレビューのトリガーを設定できます。整理すると・・・
  • PR作成時に1回: PRを開いたとき1回だけレビュー
  • プッシュごとに毎回: 新しいコミットが来るたびにレビュー(コスト高め)
  • 手動: @claude review とコメントしたときだけ
室谷室谷
料金についても公式ドキュメントに明示されていて、1レビューあたり平均15〜25ドルとのことです。PRのサイズとコードベースの複雑さで変動します。
テキトー教師テキトー教師
これはトークン課金なので、通常のClaude Codeプランの使用量とは別に計上されます。Anthropicの請求画面に Claude Code Review として別途出てきます。
室谷室谷
コスト管理は大事で。「プッシュごとに毎回」トリガーにすると、アクティブに開発しているPRは何十回もレビューが走ることになる・・・そのままにしておくと意外と高くなります。
テキトー教師テキトー教師
「PR作成時に1回」か「手動」から始めて、費用対効果を見てから「プッシュごと」に変えるのがいいですよね。

@claude reviewコマンドの使い方

Code Reviewの手動トリガー方法(公式サイトより)

室谷室谷
Code Reviewの手動トリガーは2種類あります。
コマンド動作
@claude reviewレビューを開始 + 以後のプッシュでも自動レビュー
@claude review onceこのPRのみ1回レビュー(以後のプッシュには反応しない)
テキトー教師テキトー教師
@claude review once が便利で。「ちょっと今の状態を一回見てほしい」というときに使うと、以後のプッシュには反応しないので余計なコストが発生しません。
室谷室谷
長期間開発しているPR、頻繁にコミットするPRには @claude review once の方が現実的ですよね。

REVIEW.mdでレビュー基準をカスタマイズする

テキトー教師テキトー教師
Code Reviewのカスタマイズには CLAUDE.md と REVIEW.md の2つを使えます。
室谷室谷
CLAUDE.md はClaude Code全体に適用されるので、レビューに特化したルールは REVIEW.md に書くのが推奨されています。

```markdown

REVIEW.md

Always check

  • 新しいAPIエンドポイントには必ずインテグレーションテストが必要
  • データベースのマイグレーションは後方互換性があること
  • エラーメッセージにユーザー向けの内部詳細は出さないこと

Style

  • ネストした条件分岐よりアーリーリターンを優先
  • ログはf文字列ではなく構造化ログを使う

Skip

  • src/gen/ 以下の生成コード
  • *.lock ファイルのフォーマットのみの変更 ```
テキトー教師テキトー教師
REVIEW.md はリポジトリのルートに置くだけで、Claude Codeが自動で見つけてくれます。特別な設定ファイルへの記載は不要です。
室谷室谷
CLAUDE.md との使い分けで言うと、「Claude Codeとのインタラクティブセッションでも使うルール」はCLAUDE.md、「PRレビューでのみ適用したいルール」はREVIEW.mdという切り分けです。

GitLab CI/CDでのClaude Codeレビュー

テキトー教師テキトー教師
GitHubだけじゃなくてGitLabを使っているチームも結構いますよね。GitLab CI/CDでもClaude Codeを使えます。
室谷室谷
GitLabの場合は Claude Code GitHub Actionsのような専用アクションはないんですが、Claude Code CLIをパイプラインに組み込む形になります。

```yaml

.gitlab-ci.yml の例

claude-review: stage: review image: node:20 script: - npm install -g @anthropic-ai/claude-code - git diff origin/main...HEAD | claude --print "このMRをレビューしてください。問題点を指摘してください" only: - merge_requests variables: ANTHROPIC_API_KEY: $ANTHROPIC_API_KEY ```

テキトー教師テキトー教師
GitLabの場合、claude --print で出力をキャプチャして、GitLab APIでMRにコメントとして投稿するスクリプトを追加すれば完成します。
室谷室谷
GitHubに比べると手間がかかりますが、基本的な仕組みは同じです。差分をClaude Codeに渡してレビューさせて、結果をMRにコメントする、という流れです。

Azure DevOpsやその他のCI/CDとの連携

テキトー教師テキトー教師
Azure DevOpsでの利用についても聞かれることがありますね。azure devops claude code review というキーワードで検索する方が多いようです。
室谷室谷
Azure DevOpsは公式のGitHub Actionsのような統合はまだないんですが、Claude Code CLIをAzure DevOpsパイプラインのエージェントで実行することはできます。

```yaml

azure-pipelines.yml の例

  • script: | npm install -g @anthropic-ai/claude-code git diff origin/$(System.PullRequest.TargetBranch)...HEAD | claude --print "このプルリクエストをレビューしてください" displayName: 'Claude Code Review' env: ANTHROPIC_API_KEY: $(ANTHROPIC_API_KEY) condition: and(succeeded(), eq(variables['Build.Reason'], 'PullRequest')) ```
テキトー教師テキトー教師
環境変数でAPIキーを渡せるので、AzureのKey Vaultとの連携も可能です。GitHubほど統合されていないですが、CLIベースで動くので原理的にはどのCI/CDでも使えますよね。

Claude Codeのコードレビューを使いこなすベストプラクティス

室谷室谷
実際にClaude Codeのレビューを本番で使っていて気づいたポイントをまとめましょう。
テキトー教師テキトー教師
教えていて一番効果が高いのは「レビューの粒度を小さくする」ことですね。大きなPRを一回でレビューさせるより、小さな単位で複数回レビューする方が品質が上がります。
室谷室谷
完全に同意です。MYUUUでは「1PRは原則500行以内」というルールを設けているんですが、これがClaude Codeのレビュー精度にもプラスに働いています。
テキトー教師テキトー教師
あと、「何をチェックしてほしいか」を明示的に指定するのも大事で。「セキュリティだけ」「パフォーマンスだけ」「命名規則だけ」と絞ることで、より深い指摘をもらえます。
室谷室谷
CLAUDE.mdの活用も欠かせなくて。プロジェクト固有のコーディング規約、使用フレームワークの慣習、避けるべきパターンなどをCLAUDE.mdに書いておくと、一般的なレビューでは気づかないプロジェクト特有の問題を指摘してくれます。
テキトー教師テキトー教師
セキュリティレビューについては特に効果を感じますよね。「SQLインジェクションの可能性を確認して」と一言追えば、かなり細かく見てくれます。
室谷室谷
海外の開発チームでも「Claude CodeをSecurity Reviewの担当として使う」というユースケースが出てきていて・・・コスト面でも、フルタイムのセキュリティエンジニアを雇うより現実的な選択肢になっています。

コードレビューとClaude Code Hooksの組み合わせ

テキトー教師テキトー教師
Claude Code Hooksと組み合わせると、ローカルでも自動レビューのワークフローが作れますよね。
室谷室谷
PostToolUse フックを使って、git commit が実行されたタイミングでステージングの差分を自動レビューする設定を入れているチームもいます。

```json { "hooks": { "PostToolUse": [ { "matcher": "Bash", "hooks": [ { "type": "command", "command": "if echo '$TOOL_INPUT' | grep -q 'git commit'; then git diff HEAD~1 | claude --print 'コミット内容のクイックレビュー。重大な問題があれば指摘してください'; fi" } ] } ] } } ```

テキトー教師テキトー教師
ローカルでのフック設定とGitHub Actionsでのチームレビューを組み合わせると、「個人レベルで問題を事前に潰す」「チームレベルで最終確認する」という2段階の品質管理ができますよね。
室谷室谷
MYUUUのチームでも、Claude Codeのレビューを通過したPRはチームメンバーのレビュー時間が大幅に短縮できています。人間のレビュアーが「AIがすでに確認した上で問題なかったもの」を見るので、集中すべきポイントが絞れるんですよね。

FAQ:Claude Codeのコードレビューでよくある疑問

テキトー教師テキトー教師
講座でよく聞かれる質問をまとめましょう。
室谷室谷
まず一番多いのが「Claude Codeのレビューは信頼できるの?」という質問です。
テキトー教師テキトー教師
正直に言うと「人間のシニアエンジニアと同等か、それ以上の場面もある」です。特にセキュリティの観点とエッジケースの発見は得意です。

ただし、プロジェクトのビジネスコンテキストや長期的なアーキテクチャの判断はCLAUDE.mdに補足情報を書かないと難しいです。
室谷室谷
「Cursorのコードレビューとどう違うの?」という質問も多いですね。
テキトー教師テキトー教師
Cursorは主にIDEの中で動くのに対して、Claude CodeはGitHub Actions経由でCI/CDパイプラインに組み込める点が大きく違います。@claude メンションで動くのはClaude Code固有の機能です。

あと、Code Review機能のような「複数エージェントによる並列レビュー」はClaude Codeにしかない仕組みです。
室谷室谷
「can claude code review prs」は「Claude CodeはPRをレビューできるの?」という質問ですね。答えはYesで・・・今回の記事で説明した通り、GitHub ActionsかCode Review機能を使えばPRの自動レビューができます。
テキトー教師テキトー教師
「Code ReviewはTeam/Enterpriseだけで使えるの?」という質問もありますね。これはYesで、個人のProプランではCode Review機能(マネージドサービス)は使えません。

ただしGitHub Actions経由でのレビューはAPIキーがあれば使えます。
室谷室谷
料金感覚をざっくり言うと・・・GitHub Actions経由はAPI従量課金、Code Review機能は1レビュー15〜25ドルの別途課金です。規模が小さいチームはGitHub Actions、大規模なチームでコスト管理をしっかりやりたいならCode Reviewのスペンドキャップ設定をうまく使う、という選び方が現実的です。

まとめ:自分のプロジェクトに合ったアプローチを選ぼう

テキトー教師テキトー教師
3つのアプローチを改めて整理しましょう。
アプローチ向いているケースプラン要件
ターミナルで直接個人開発・スポット的なチェックPro以上
GitHub Actionsチーム開発・@claudeでのレビュー依頼APIキー必要
Code Review機能本格的な自動化・並列エージェントレビューTeam/Enterprise必須
室谷室谷
最初にターミナルで試して、チームで使うようになったらGitHub Actionsへ、本格的な品質管理を自動化したいならCode Review機能へ、という順番でステップアップするのが現実的ですね。
テキトー教師テキトー教師
Code Review機能はTeam/Enterpriseプランが必要なので、個人開発者はターミナル+GitHub Actionsの組み合わせで十分です。コミュニティのメンバーさんには「まずgit diffをパイプで渡すことから始めましょう」と伝えています。
室谷室谷
最終的に「レビューを自動化することで何を目指すか」を明確にするのが大事で。バグの早期発見なのか、セキュリティの強化なのか、チームのレビュー負担軽減なのか・・・目的によって最適なアプローチが変わります。
テキトー教師テキトー教師
どのアプローチを選ぶにしても、CLAUDE.mdとREVIEW.mdの整備が品質を決める鍵になりますね。これを丁寧に書いているプロジェクトとそうでないプロジェクトでは、レビューの精度が全然違います。
室谷室谷
Claude Codeのコードレビュー、使い始めるとエンジニアチームの働き方が変わりますよ。最初は「AIにレビューしてもらうの?」って懐疑的なメンバーがいても、一度使うと戻れなくなります。

出典

.AI TIMES一覧に戻る