Symfony Security 2026年版:Voters、ファイアウォール、技術面接で問われるポイント

Symfonyセキュリティコンポーネントの全体像を解説します。ファイアウォール設定、Voterによるきめ細かなアクセス制御、IsGranted属性、AccessTokenHandler、Decision Strategy、UserChecker、そして技術面接で頻出する質問と回答を網羅した実践ガイドです。

Symfony security voters firewalls architecture

Symfonyのセキュリティコンポーネントは、認証(Authentication)と認可(Authorization)という2つの柱で構成されています。認証は「このユーザーは誰か」を判定し、認可は「このユーザーに何が許可されているか」を制御します。この分離がSymfonyセキュリティの設計思想の根幹であり、ファイアウォール、Voter、IsGranted属性といった各要素はこの原則に沿って連携します。

2026年の本番プロジェクトでは、Symfony 7.4 LTSが標準的な選択肢となっています。セキュリティコンポーネントは6.0以降の大幅な刷新を経て安定期に入り、統一されたAuthenticatorシステム、ネイティブのIsGranted属性、Profiler上でのアクセス判定デバッグなど、実用性の高い機能が揃っています。技術面接においても、Symfonyセキュリティの理解はシニアレベルの必須条件です。

この記事では、ファイアウォールの設定からVoterの実装、単体テスト、セキュリティ強化まで、実践的なコードとともに体系的に解説します。

Symfony 7.4 LTSとセキュリティ

Symfony 7.4 LTSは2025年11月にリリースされ、2029年11月までサポートが継続されます。6.0以降のセキュリティコンポーネントの変更がすべて統合されており、統一Authenticatorシステム、ネイティブのIsGranted属性、ProfilerおよびTwigでのアクセス判定デバッグ、Voterシステムの改善が含まれます。2026年の本番プロジェクトおよび技術面接において、基準となるバージョンです。

ファイアウォール:最初の防御ライン

ファイアウォールは、受信リクエストに対してどの認証メカニズムを適用するかを決定する最初のゲートです。security.yamlでファイアウォールを定義する際、宣言の順序が極めて重要です。Symfonyは上から順にパターンを評価し、最初にマッチしたファイアウォールのみが適用されます。

yaml
# config/packages/security.yaml
security:
    firewalls:
        dev:
            pattern: ^/(_(profiler|wdt))/
            security: false

        api:
            pattern: ^/api/
            stateless: true
            custom_authenticators:
                - App\Security\ApiTokenHandler

        main:
            lazy: true
            provider: app_user_provider
            form_login:
                login_path: app_login
                check_path: app_login
            logout:
                path: app_logout

    access_control:
        - { path: ^/api/public, roles: PUBLIC_ACCESS }
        - { path: ^/api/, roles: ROLE_API_USER }
        - { path: ^/admin, roles: ROLE_ADMIN }
        - { path: ^/dashboard, roles: ROLE_USER }

この設定には3つのファイアウォールが定義されています。devファイアウォールは開発ツール(Profiler、Web Debug Toolbar)向けで、セキュリティを完全に無効化しています。apiファイアウォールはAPIエンドポイント用で、ステートレス認証とカスタムトークンハンドラーを使用します。mainファイアウォールはWebアプリケーション用で、フォームログインとセッションベースの認証を処理します。

access_controlセクションでは、URLパターンに基づいたロールベースのアクセス制限を設定します。ここでも順序が重要で、^/api/public^/api/より先に記述されている点に注目してください。PUBLIC_ACCESSは特別な定数で、認証なしのアクセスを許可しつつ、ファイアウォール自体は有効に保ちます。これにより、セキュリティリスナーやイベントは引き続き動作します。

API ルートでの security: false に注意

security: falseはセキュリティコンポーネントを完全に無効化します。本番環境のルートには絶対に使用しないでください。認証不要のエンドポイントであっても、ファイアウォールを有効に保ったままaccess_controlPUBLIC_ACCESSを指定する方法が正しいアプローチです。security: falseを使用すると、セキュリティイベント、レートリミット、監査ログなどの保護機能がすべて失われます。

ステートレス認証 vs ステートフル認証

Symfonyでは、認証パラダイムをステートレスとステートフルの2種類から選択できます。この選択はファイアウォールのstatelessパラメータで制御されます。

ステートフル認証は、セッションを使用してユーザーの認証状態を維持します。ブラウザベースのWebアプリケーションに適しており、フォームログイン後にセッションCookieが発行され、後続のリクエストではセッションからユーザー情報が復元されます。mainファイアウォールのlazy: true設定は、セキュリティ情報が実際に必要になるまでセッションの読み込みを遅延させ、パフォーマンスを最適化します。

ステートレス認証は、リクエストごとにトークン(Bearer Token、API Key、JWTなど)を送信する方式です。セッションを使用しないため、RESTful APIやマイクロサービス間通信に適しています。サーバー側に状態を持たないことで、水平スケーリングが容易になり、ロードバランサー間でのセッション共有の問題も回避できます。

一般的な構成では、APIルートにステートレス認証、Webフロントエンドにステートフル認証を組み合わせます。上記のYAML設定がまさにこのパターンを示しています。

AccessTokenHandlerによるAPI認証

Symfony 6.2で導入されたAccessTokenHandlerInterfaceは、トークンベースのAPI認証を実装するための標準的なインターフェースです。

src/Security/ApiTokenHandler.phpphp
namespace App\Security;

use App\Repository\ApiTokenRepository;
use Symfony\Component\Security\Core\Exception\BadCredentialsException;
use Symfony\Component\Security\Http\AccessToken\AccessTokenHandlerInterface;
use Symfony\Component\Security\Http\Authenticator\Passport\Badge\UserBadge;

final readonly class ApiTokenHandler implements AccessTokenHandlerInterface
{
    public function __construct(
        private ApiTokenRepository $repository,
    ) {}

    public function getUserBadgeFrom(#[\SensitiveParameter] string $accessToken): UserBadge
    {
        $token = $this->repository->findOneByValue($accessToken);

        if ($token === null || !$token->isValid()) {
            throw new BadCredentialsException('Invalid or expired token.');
        }

        return new UserBadge($token->getUser()->getUserIdentifier());
    }
}

AccessTokenHandlerInterfacegetUserBadgeFromという単一のメソッドを定義しており、単一責任の原則に従った簡潔な設計です。このメソッドはリクエストヘッダーから抽出されたトークン文字列を受け取り、対応するユーザーのUserBadgeを返します。トークンが無効または期限切れの場合はBadCredentialsExceptionをスローします。

#[\SensitiveParameter]属性はPHP 8.2で導入されたもので、スタックトレースやエラーログにトークンの値が出力されることを防ぎます。本番環境でのセキュリティ漏洩リスクを軽減する重要なプラクティスです。

Voters:アクセス制御のきめ細かな仕組み

Voterは、Symfonyにおけるきめ細かなアクセス制御の中核です。access_controlがURLパターンとロールの組み合わせによる粗い制御であるのに対し、Voterはエンティティの所有権、公開状態、ユーザーの権限を組み合わせた複雑なビジネスロジックを表現できます。

src/Security/Voter/PostVoter.phpphp
namespace App\Security\Voter;

use App\Entity\Post;
use Symfony\Component\Security\Core\Authentication\Token\TokenInterface;
use Symfony\Component\Security\Core\Authorization\Voter\Vote;
use Symfony\Component\Security\Core\Authorization\Voter\Voter;
use Symfony\Component\Security\Core\User\UserInterface;

final class PostVoter extends Voter
{
    public const EDIT = 'POST_EDIT';
    public const DELETE = 'POST_DELETE';
    public const PUBLISH = 'POST_PUBLISH';

    protected function supports(string $attribute, mixed $subject): bool
    {
        return in_array($attribute, [self::EDIT, self::DELETE, self::PUBLISH])
            && $subject instanceof Post;
    }

    protected function voteOnAttribute(
        string $attribute,
        mixed $subject,
        TokenInterface $token,
        ?Vote $vote = null,
    ): bool {
        $user = $token->getUser();
        if (!$user instanceof UserInterface) {
            $vote?->addReason('User is not authenticated.');
            return false;
        }

        /** @var Post $post */
        $post = $subject;

        return match ($attribute) {
            self::EDIT => $this->canEdit($post, $user, $vote),
            self::DELETE => $this->canDelete($post, $user, $vote),
            self::PUBLISH => $this->canPublish($post, $user, $vote),
            default => false,
        };
    }

    private function canEdit(Post $post, UserInterface $user, ?Vote $vote): bool
    {
        if ($post->getAuthor() === $user) {
            $vote?->addReason('User is the author of the post.');
            return true;
        }

        $vote?->addReason('User is not the author.');
        return false;
    }

    private function canDelete(Post $post, UserInterface $user, ?Vote $vote): bool
    {
        if (in_array('ROLE_ADMIN', $user->getRoles())) {
            $vote?->addReason('User has ROLE_ADMIN.');
            return true;
        }

        if ($post->getAuthor() === $user && !$post->isPublished()) {
            $vote?->addReason('Author can delete unpublished posts.');
            return true;
        }

        $vote?->addReason('Only admins or authors of unpublished posts can delete.');
        return false;
    }

    private function canPublish(Post $post, UserInterface $user, ?Vote $vote): bool
    {
        if (in_array('ROLE_EDITOR', $user->getRoles())) {
            $vote?->addReason('User has ROLE_EDITOR.');
            return true;
        }

        $vote?->addReason('Only editors can publish posts.');
        return false;
    }
}

supportsメソッドは、このVoterが処理対象とする属性とサブジェクトの組み合わせを定義します。条件に合致しない場合、Voterは棄権(ABSTAIN)し、他のVoterに判定を委ねます。

voteOnAttributeメソッドでは、PHP 8.0のmatch式を使用して属性ごとの判定ロジックに分岐しています。canDeleteメソッドが示すように、ロールベースの権限(ROLE_ADMIN)とオブジェクトの所有権・状態(著者かつ未公開)を組み合わせた複合的な判定が可能です。

Symfony 7.1で導入されたVoteパラメータは、判定理由をデバッグ情報として記録する機能を提供します。$vote?->addReason()で追加された理由はProfilerに表示され、「なぜこのアクセスが許可/拒否されたか」のトレーサビリティが大幅に向上します。

Symfonyの面接対策はできていますか?

インタラクティブなシミュレーター、flashcards、技術テストで練習しましょう。

IsGranted属性による宣言的アクセス制御

Voterの判定をコントローラーで使用する際、IsGranted属性により宣言的かつ明確な記述が可能です。

src/Controller/PostController.phpphp
namespace App\Controller;

use App\Entity\Post;
use App\Security\Voter\PostVoter;
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Attribute\Route;
use Symfony\Component\Security\Http\Attribute\IsGranted;

#[Route('/post')]
final class PostController extends AbstractController
{
    #[Route('/{id}/edit', methods: ['GET', 'POST'])]
    #[IsGranted(PostVoter::EDIT, subject: 'post', message: 'You cannot edit this post.')]
    public function edit(Post $post): Response
    {
        // User is guaranteed to have edit permission at this point
        return $this->render('post/edit.html.twig', [
            'post' => $post,
        ]);
    }

    #[Route('/{id}/publish', methods: ['POST'])]
    #[IsGranted(PostVoter::PUBLISH, subject: 'post')]
    public function publish(Post $post): Response
    {
        // Only editors reach this code
        $post->setPublished(true);
        // ...
        return $this->redirectToRoute('post_show', ['id' => $post->getId()]);
    }
}

#[IsGranted]属性は、コントローラーメソッドが実行される前にアクセス権限をチェックします。subjectパラメータにはメソッド引数の名前を文字列で指定し、Symfonyが自動的にParamConverterで解決されたエンティティを渡します。権限がない場合はAccessDeniedExceptionがスローされ、messageパラメータで指定したカスタムメッセージが使用されます。

このアプローチにより、コントローラーのメソッド本体には認可ロジックが一切含まれず、ビジネスロジックのみに集中できます。権限チェックが属性として宣言されることで、コードの可読性と保守性が向上します。

Decision Strategy:unanimous、affirmative、consensus

複数のVoterが同じ属性に対して投票する場合、AccessDecisionManagerがどの戦略で最終判定を下すかをstrategyで設定します。

yaml
# config/packages/security.yaml
security:
    access_decision_manager:
        strategy: unanimous
        allow_if_all_abstain: false

affirmative(デフォルト)は、1つでもGRANTEDを返すVoterがあればアクセスを許可します。consensusは、GRANTEDの票数がDENIEDの票数を上回る場合に許可します。unanimousは、すべてのVoterがGRANTEDを返した場合のみ許可し、最も厳格な戦略です。

allow_if_all_abstain: falseは、すべてのVoterが棄権した場合にアクセスを拒否する設定です。セキュリティの観点からは、明示的な許可がない限りデフォルトで拒否するこの設定が推奨されます。

本番環境では、用途に応じて戦略を選択します。一般的なWebアプリケーションではデフォルトのaffirmativeで十分ですが、金融システムや医療システムなど、複数の条件をすべて満たす必要がある場面ではunanimousが適切です。

Twigでのアクセス判定デバッグ(Symfony 7.4)

テンプレート内でのアクセス制御はis_granted関数で行います。Symfony 7.4では、開発環境でのデバッグを支援するis_granted_debug関数が追加されました。

twig
{# templates/post/show.html.twig #}
{% if is_granted('POST_EDIT', post) %}
    <a href="{{ path('post_edit', {id: post.id}) }}">Edit</a>
{% endif %}

{% if is_granted('POST_DELETE', post) %}
    <form method="post" action="{{ path('post_delete', {id: post.id}) }}">
        <button type="submit">Delete</button>
    </form>
{% endif %}

{% if app.debug %}
    {# Symfony 7.4: access decision debugging in Twig #}
    {% set decision = is_granted_debug('POST_EDIT', post) %}
    <details>
        <summary>Access Decision Debug</summary>
        <ul>
            {% for voter_detail in decision.voterDetails %}
                <li>
                    {{ voter_detail.class }}:
                    {{ voter_detail.result > 0 ? 'GRANTED' : (voter_detail.result < 0 ? 'DENIED' : 'ABSTAIN') }}
                    {% for reason in voter_detail.reasons %}
                        <br>&rarr; {{ reason }}
                    {% endfor %}
                </li>
            {% endfor %}
        </ul>
    </details>
{% endif %}

is_granted_debug関数は、各Voterの投票結果(GRANTED、DENIED、ABSTAIN)と、Voteパラメータで追加された判定理由を返します。これにより、テンプレート上で「なぜこのボタンが表示されないのか」を即座に確認でき、開発効率が大幅に向上します。本番環境ではapp.debugガードにより表示されません。

Voterの単体テスト

VoterはPHPUnitで容易にテストできます。外部依存がないため、モックなしで純粋なユニットテストが記述可能です。

tests/Security/Voter/PostVoterTest.phpphp
namespace App\Tests\Security\Voter;

use App\Entity\Post;
use App\Entity\User;
use App\Security\Voter\PostVoter;
use PHPUnit\Framework\TestCase;
use Symfony\Component\Security\Core\Authentication\Token\UsernamePasswordToken;
use Symfony\Component\Security\Core\Authorization\Voter\VoterInterface;

final class PostVoterTest extends TestCase
{
    private PostVoter $voter;

    protected function setUp(): void
    {
        $this->voter = new PostVoter();
    }

    public function testAuthorCanEditOwnPost(): void
    {
        $user = new User();
        $post = (new Post())->setAuthor($user);
        $token = new UsernamePasswordToken($user, 'main', ['ROLE_USER']);

        $this->assertSame(
            VoterInterface::ACCESS_GRANTED,
            $this->voter->vote($token, $post, [PostVoter::EDIT]),
        );
    }

    public function testNonAuthorCannotEditPost(): void
    {
        $author = new User();
        $otherUser = new User();
        $post = (new Post())->setAuthor($author);
        $token = new UsernamePasswordToken($otherUser, 'main', ['ROLE_USER']);

        $this->assertSame(
            VoterInterface::ACCESS_DENIED,
            $this->voter->vote($token, $post, [PostVoter::EDIT]),
        );
    }

    public function testAdminCanDeleteAnyPost(): void
    {
        $admin = new User();
        $post = (new Post())->setAuthor(new User());
        $token = new UsernamePasswordToken($admin, 'main', ['ROLE_ADMIN']);

        $this->assertSame(
            VoterInterface::ACCESS_GRANTED,
            $this->voter->vote($token, $post, [PostVoter::DELETE]),
        );
    }

    public function testAuthorCanDeleteUnpublishedPost(): void
    {
        $user = new User();
        $post = (new Post())->setAuthor($user)->setPublished(false);
        $token = new UsernamePasswordToken($user, 'main', ['ROLE_USER']);

        $this->assertSame(
            VoterInterface::ACCESS_GRANTED,
            $this->voter->vote($token, $post, [PostVoter::DELETE]),
        );
    }

    public function testAuthorCannotDeletePublishedPost(): void
    {
        $user = new User();
        $post = (new Post())->setAuthor($user)->setPublished(true);
        $token = new UsernamePasswordToken($user, 'main', ['ROLE_USER']);

        $this->assertSame(
            VoterInterface::ACCESS_DENIED,
            $this->voter->vote($token, $post, [PostVoter::DELETE]),
        );
    }

    public function testOnlyEditorCanPublish(): void
    {
        $user = new User();
        $post = (new Post())->setAuthor($user);
        $token = new UsernamePasswordToken($user, 'main', ['ROLE_EDITOR']);

        $this->assertSame(
            VoterInterface::ACCESS_GRANTED,
            $this->voter->vote($token, $post, [PostVoter::PUBLISH]),
        );
    }

    public function testVoterAbstainsOnUnsupportedAttribute(): void
    {
        $user = new User();
        $post = new Post();
        $token = new UsernamePasswordToken($user, 'main', ['ROLE_USER']);

        $this->assertSame(
            VoterInterface::ACCESS_ABSTAIN,
            $this->voter->vote($token, $post, ['UNSUPPORTED']),
        );
    }
}

テストケースでは、許可されるケース、拒否されるケース、棄権するケースの3パターンを網羅しています。特にcanDeleteのように複数条件を組み合わせたメソッドでは、管理者による削除、著者による未公開記事の削除、著者による公開済み記事の削除(拒否)など、各分岐を個別に検証することが重要です。

セキュリティイベント

Symfonyはセキュリティの各ステップでイベントをディスパッチします。主なイベントとしてAuthenticationSuccessEventLoginSuccessEventLogoutEventSwitchUserEventAccessDeniedEventがあります。これらのイベントは、ログ記録、通知送信、追加のセキュリティチェックに活用されます。特にAccessDeniedEventをリッスンすることで、不正アクセスの試行を監視システムに送信し、セキュリティインシデントの早期検知に役立てることができます。

セキュリティ強化:UserCheckerとベストプラクティス

UserCheckerInterfaceを実装することで、認証プロセスにカスタムのチェックロジックを追加できます。認証の前後それぞれのタイミングで検証を実行し、条件を満たさないユーザーのアクセスを遮断します。

src/Security/UserEnabledChecker.phpphp
namespace App\Security;

use App\Entity\User;
use Symfony\Component\Security\Core\Exception\CustomUserMessageAccountStatusException;
use Symfony\Component\Security\Core\User\UserCheckerInterface;
use Symfony\Component\Security\Core\User\UserInterface;

final class UserEnabledChecker implements UserCheckerInterface
{
    public function checkPreAuth(UserInterface $user): void
    {
        if (!$user instanceof User) {
            return;
        }

        if ($user->isBanned()) {
            throw new CustomUserMessageAccountStatusException(
                'Your account has been banned. Contact support.'
            );
        }
    }

    public function checkPostAuth(UserInterface $user): void
    {
        if (!$user instanceof User) {
            return;
        }

        if (!$user->isVerified()) {
            throw new CustomUserMessageAccountStatusException(
                'Please verify your email address before logging in.'
            );
        }
    }
}

checkPreAuthはパスワード検証の前に実行されるため、BAN済みユーザーに対して不要なパスワードハッシュ比較を回避できます。checkPostAuthは認証成功後に実行され、メール未認証のユーザーをブロックします。

UserChecker以外にも、本番環境でのセキュリティ強化には以下のベストプラクティスが推奨されます。

  • レートリミット#[RateLimiter]属性またはSymfonyのRateLimiterコンポーネントを使用して、ログイン試行やAPI呼び出しの頻度を制限します
  • CSRF保護:フォーム送信には必ずCSRFトークンを含め、CsrfTokenManagerで検証します
  • パスワードハッシュPasswordHasherInterfaceでbcryptまたはsodiumを使用し、平文パスワードは決してDBに保存しません
  • シークレットローテーションAPP_SECRETやAPIキーは定期的にローテーションし、Symfony Vaultまたは環境変数で管理します
  • セキュリティヘッダーContent-Security-PolicyX-Frame-OptionsStrict-Transport-SecurityなどのHTTPヘッダーをNelmioSecurityBundleで設定します

技術面接で頻出するセキュリティ質問

以下は、Symfony開発者の技術面接で頻繁に問われるセキュリティ関連の質問と、期待される回答のポイントです。

Q1: 認証(Authentication)と認可(Authorization)の違いは何ですか?

認証は「このリクエストを送っているのは誰か」を判定するプロセスです。ログインフォーム、APIトークン、OAuthなどの手段で実現されます。認可は「この認証済みユーザーに何が許可されているか」を判定するプロセスです。ロール、Voter、access_controlで制御されます。Symfonyではこの2つが明確に分離されており、ファイアウォールが認証を、AccessDecisionManagerが認可を担当します。

Q2: Voterはどのように動作し、access_controlとの使い分けはどうしますか?

Voterはsupportsメソッドで処理対象かどうかを判定し、voteOnAttributeメソッドでGRANTED/DENIEDを返します。access_controlはURLパターンとロールの単純な組み合わせで、ルーティングレベルの粗い制御に適しています。一方、Voterはエンティティの所有権や状態に基づくきめ細かな制御が必要な場面で使用します。「この投稿を編集できるのは著者のみ」のようなビジネスルールはVoterで実装します。

Q3: Symfony 7.1で導入されたVoteパラメータの役割は何ですか?

Voteパラメータは、Voterの判定理由を構造化されたデータとして記録する仕組みです。$vote->addReason()で追加された理由はSymfony ProfilerおよびTwigのis_granted_debug関数からアクセスでき、「なぜアクセスが拒否されたか」のデバッグが容易になります。nullableパラメータとして定義されているため、後方互換性が維持されています。

Q4: ステートレスAPIをSymfonyでどのように保護しますか?

ファイアウォールにstateless: trueを設定し、AccessTokenHandlerInterfaceを実装したカスタムハンドラーを登録します。トークンはAuthorizationヘッダーのBearerスキームで送信され、ハンドラーがトークンの検証とユーザーの解決を行います。JWTを使用する場合はLexikJWTAuthenticationBundleが一般的です。レートリミット、HTTPS強制、#[\SensitiveParameter]によるトークン値の保護も併せて実装します。

Q5: Voterを網羅的にテストするにはどうしますか?

Voterは純粋なPHPクラスであり、外部依存がないためPHPUnitで容易にテストできます。テスト対象は3つのカテゴリに分かれます。許可されるケース(著者が自分の投稿を編集)、拒否されるケース(著者でないユーザーが編集を試みる)、棄権するケース(サポートしない属性が渡される)です。複合条件を持つメソッドでは各分岐を個別にテストし、ロール、所有権、エンティティの状態の組み合わせを網羅します。

今すぐ練習を始めましょう!

面接シミュレーターと技術テストで知識をテストしましょう。

まとめ

  • ファイアウォールはリクエストの入り口で認証メカニズムを選択する最初の防御ラインであり、宣言の順序が判定結果を左右します
  • ステートレス認証はAPIに、ステートフル認証はWebアプリケーションに適しており、同一プロジェクトで共存可能です
  • AccessTokenHandlerInterfaceは、単一責任の原則に従ったトークンベースAPI認証の標準的な実装方法です
  • Voterはエンティティの所有権・状態・ロールを組み合わせたきめ細かなアクセス制御を実現し、Voteパラメータによりデバッグ性が向上しています
  • IsGranted属性はコントローラーから認可ロジックを分離し、宣言的で読みやすいコードを実現します
  • Decision Strategyは複数Voterの判定結果を統合する方式を制御し、セキュリティ要件に応じて選択します
  • UserCheckerは認証プロセスにカスタム検証を追加し、BAN済みユーザーや未認証メールのブロックに活用されます
  • 単体テストではGRANTED、DENIED、ABSTAINの3パターンと各分岐条件を網羅的に検証します

今すぐ練習を始めましょう!

面接シミュレーターと技術テストで知識をテストしましょう。

タグ

#symfony
#security
#php
#voters
#firewall
#authentication
#interview

共有

関連記事