浅野直樹の学習日記

この画面は、簡易表示です

令和3(2021)年司法試験予備試験論文再現答案憲法

再現答案

 以下日本国憲法についてはその条数のみを示す。

第1 表現の自由一般

 21条1項で表現の自由が保障されている。表現の自由の保障は、絶対無制約ではないが、一旦失われると民主的過程を通じて回復するのが困難なので、経済的自由権と比べて厳重に保障される。

第2 内容規制と内容中立規制

 表現内容に応じた制約は、公権力の主体たる国や公共団体によってし意的な運用がなされるおそれが大きいので、やむにやまれぬ利益のための必要最小限の制約のみ許されると解する。表現内容に関係なく時間や場所によってなされる内容中立規制の場合は、そのようなおそれが小さいので、重要な目的のために実質的に関係している手段による制約が許されると解する。

 本件では、広告物の掲示については、C地区という場所に着目した制約にも見えるが、市長が「特別規制区域の歴史的な環境を向上させるものと認められる」として許可を与える場合には、広告物を掲示することができるので、内容規制である。印刷物の配布については、C地区という場所に着目した内容中立規制である。

第3 パブリックフォーラム論

 路上でのビラ配布などは、安価に表現をする手段であり、伝統的に財力に乏しい人たちによって利用されてきた手段であるから、表現の自由の制約には慎重にならなければならないというパブリックフォーラム論が存在する。本件ではそれに該当し、内容中立規制であっても、重要な目的のために他のより制限的な手段が存在しない場合に限って表現の自由を制約することが許されると解する。

第4 不明確な制約

 表現の自由が不明確な形で制約されると、自分がしようとしている表現が制約されるものであるかどうかの判断がしづらく、それならばやめておこうかとい縮しがちである。特に刑罰が課される場合はそうである。表現の自由に対する不明確な制約は、それ自体で違憲であると解する。不明確であるかどうかは一般人を基準にして判断する。

第5 結論

 B市歴史的環境保護条例(以下「条例」という。)により、特別規制区域内で広告物を新たに掲示することが禁止され、表現の自由が制約される。先述したように、これは内容規制である。よって、やむにやまれぬ利益のための必要最小限の制約のみ許される。C地区の歴史的な環境を維持し向上させるという条例の目的は、重要なものとは言えるが、やむにやまれぬ利益であるとは言えない。以上より、条例の広告物に関する部分は違憲である。

 条例により、特別規制区域内の路上での印刷物の配布が原則禁止され、表現の自由が制約されている。これは内容中立規制であり、先述のパブリックフォーラム論から、重要な目的のために他のより制限的な手段が存在しない場合に限って表現の自由を制約することが許されると解する。先に検討したように、条例の目的は重要である。しかし、そのためにビラ配布自体を禁止するということは、過剰な制約である。ビラの配布行為自体を観察すると、そのビラの内容に関わらず、C地区の歴史的な環境を損なうとは考え難い。例えば、ビラが捨てられることによりC地区の歴史的な環境が損なわれるのであれば、ビラ配布自体ではなく、ビラを捨てることを禁止することで目的を達成できる。よって、印刷物の配布に関する部分も違憲である。

 また、「店舗の関係者」や「自己の営業を宣伝する」という文言は一般人を基準にして不明確であり、違反者は罰金刑に処せられるので、不明確な制約として、その点でも違憲である。

以上

 

感想

 たまには統治から出題されるかとも思いましたが、2年連続で表現の自由の直球的な問いかけでした。今年はそれらしく書いたつもりですが、これでよいのか自信はありません。



laravelのnotificationでfacebookを使う(PSIDの取得と紐付け)

1.前置き

laravelは便利ですね。facebookを利用したソーシャルログインなども簡単に導入できます。

 

通知(notification)にfacebookを使うのも、Laravel Notification Channelsでfacebookが用意されているから、簡単にできるだろうとたかをくくっていました。

 

確かにこれを利用すればlaravel側の設定はさほど難しくないのですが、上記リンク先で$this->user->fb_messenger_idとされている部分をどうすればよいかに悩みました。

 

上記リンク先でも説明されているように、各ユーザーのfacebookのPSIDが必要になります。

 

そのfacebookのPSIDを入手し、さらにPSIDを自サイトで管理しているユーザーと紐付けるのに相当苦労しました。

 

わかりやすく解説しているページもざっと見た限りなかったので、ここにまとめます。

 

2.facebookにおけるIDの概念

具体的な手順に入る前に、facebookにおけるIDの概念を理解するのが近道です。

 

開発者にとって重要なのは、ASID(Application Scoped ID)とPSID(Page Scoped ID)です。

 

これらは、開発者が作成するアプリのIDやページのIDとは違い、ユーザーごとに異なる値です。

 

ただし、facebookにログインして自分の名前をクリックした際にURL欄に表示されるユーザーIDとも異なり、アプリやページごとに限定されたIDです。

 

ASIDはユーザーがfacebookログインをした際に開発者サイドで取得することができます。

 

PSIDはユーザーがfacebookのmessengerを利用した際にeventとしてwebhookに送信されます。

 

以上より、laravelのnotificationでfacebookを使うためには、次の手順を考えることになります。

 

(1) ユーザーがfacebookログインをした際にASIDをusersテーブルに保存する。

(2) ユーザーにmessengerを利用してもらい、eventとしてwebhookに送信されるPSIDを取得する。

(3) (2)で取得したPSIDと(1)で保存したASIDを紐付けする。

 

このIDの概念と流れを理解できたら具体的な手順に入りましょう。

 

3.手順

(1) ASIDの保存

Socialiteを用いたfacebookログインは実装できているという前提で、ここでは詳しく説明しません。

 

callbackでSocialite::driver(‘facebook’)->user()->getId()でASIDを取得できます。

 

これをusersテーブルの適当なカラム(fb_app_user_idなど)に保存してください。

 

migrationを使ってカラムを作成する方法は割愛します。

 

(2) PSIDの取得

まず、Facebook Messenger appを作成し、PAGE_ACCESS_TOKENを生成します。

 

次に、webhookのコールバックURLを設定します。localhostでテストするためにはngrokでトンネルを掘る必要があります。

 

Webhookの設定 – MessengerプラットフォームではNode.jsで説明されていますが、laravelならrouteとcontrollerを使ってgetとpostの設定をすればよいです。

 

getで行うWebhook認証のほうは、requestのqueryで送られてくるhub_challengeをreturnすればよいだけです。つまり、getのcontrollerは「return $request->input(‘hub_challenge’);」の一行だけでOKです。「hub.challenge」ではなく「hub_challenge」だということに気づかずハマりました。

 

次に、先ほど設定したWebhookを編集して、Message Delivered eventsをsubscribeするためにmessage_deliveriesにチェックを入れます。何らかの事情で初回アクセス時のイベントでPSIDを取得できなかったときのために、messagesにもチェックを入れておいたほうがよいです。

 

こうすることで、ユーザーがhttp://m.me/<PAGE_NAME>をクリックしたときに発生するMessage Delivered eventsから、そのユーザーのPSIDを取得することができます。具体的には、$request->input(‘entry.0.messaging.0.sender.id’)です。

 

これはpostで受け取りますので、VerifyCsrfTokenMiddlewareの除外設定を忘れないようにしてください。

 

(3) PSIDとASIDの紐付け

そのものズバリ、IDマッチングAPI – Messengerプラットフォームというページがあります。ID Matching API – Messengerプラットフォームもほぼ同じ内容です。

 

これらに沿って進めます。

 

ビジネスマネージャの概要からfacebookのビジネスを作成します。

 

仕事用メールアドレスの認証を経てビジネスを作成することができます。

 

そのビジネスに、facebookログインを実装する際に作成したアプリと、messengerのために先ほど作成したページの両方を登録します。

 

PSIDからASIDを取得したいので、以下のAPI呼び出しになります。

 

https://graph.facebook.com/v2.6/<ID>/ids_for_apps?app=<OPTIONAL_APP_ID>&access_token=<ACCESS_TOKEN>&appsecret_proof=<APP_SECRET_PROOF>

 

<ID>は先ほど取得したPSIDです。

 

同じビジネス内で複数のアプリを開発しているなら、<OPTIONAL_APP_ID>にアプリIDを入れます。

 

<ACCESS_TOKEN>は(2)の最初で作ったPAGE_ACCESS_TOKENです。

 

<APP_SECRET_PROOF>は、グラフAPIリクエストの保護で説明されているように、phpならhash_hmac(‘sha256’, \$access_token, \$app_secret)で生成します。

 

\$access_tokenはPAGE_ACCESS_TOKENです。\$app_secretは、facebookログインを実装する際に必要となるsecretの値です。

 

API呼び出しから返される結果から、そのPSIDユーザーのASIDを引っ張ってくることができます。

 

これをusersテーブルのfb_messenger_idカラムに格納すれば完成です。

 

あとは自由にそのユーザーに対してPSIDを使ってfacebookのmessageを送ることができます。

 

laravelのコードをまとめると次のようになります。

 

web.php

(略)
Route::get('/facebook/webhook', 'MessagingWebhookController@confirmFacebookMessaging');
Route::post('/facebook/webhook', 'MessagingWebhookController@receiveFacebookMessagingEvent');
(略)

 

VerifyCsrfToken.php

(略)
protected $except = [
    'facebook/*',
];
(略)

 

MessagingWebhookController.php

(略)
use GuzzleHttp\Client;
use App\User;
(略)

//facebookのwebhook認証
public function confirmFacebookMessaging(Request $request) {
    return $request->input('hub_challenge');
}

//facebookのイベントwebhook
public function receiveFacebookMessagingEvent(Request $request) {
    $psid = $request->input('entry.0.messaging.0.sender.id');
    $access_token = config('services.facebook.page-token');
    $app_id = config('services.facebook.client_id');
    $app_secret = config('services.facebook.client_secret');
    $appsecret_proof = hash_hmac('sha256', $access_token, $app_secret);
    $url = "https://graph.facebook.com/v2.6/$psid/ids_for_apps?app=$app_id&access_token=$access_token&appsecret_proof=$appsecret_proof";
    $client = new Client();
    $json = $client->request("GET", $url)->getBody();
    $data = json_decode($json, true);
    $asid = $data['data'][0]['id'];
    User::where('fb_app_user_id', $asid)->update(['fb_messenger_user_id' => $psid]);
}
(略)

 

便宜上、Controllerにざっとコードを書いています。

 

エラーチェックやすでにPSIDとASIDの紐付けがされている場合の処理などは省略しています。

 

4.感想

FacebookのMessengerプラットフォームのドキュメントを熟読するしかないのですが、英語で表示されたり日本語で表示されたり、微妙に内容が違っていたりで混乱しました。

 

アカウントのリンク – Messengerプラットフォームを使ったほうがよいのかと思って実験してみたりもしましたが、ボタンがよくわからず、結局上で説明したやり方に落ち着きました。

 

これでやりたいことは実現できたのでよしとします。

 

 

 



Webサイト制作の個人史2

Webサイト制作の個人史の続きです。

 

一言で表現するなら、perlからpythonに移行してdjangoを触り、それからlaravelをメインにしたという話です。

 

1.python

Webサイト制作の個人史にも書きましたが、Automate the Boring Stuff with Pythonを読んで感動しました。

 

ちょうどそれを読んだ頃には小さい会社で事務全般の仕事をしていたため、退屈な業務をpythonで自動化しました。

 

別の人がexcelで作ったシフト表から、親会社に提出する勤怠フォーマットに手作業で入力するのが苦痛でなりませんでした。

 

入職してすぐにVBAである程度楽にしましたが、思い通りに動かすためにはpythonのほうがやりやすかったです。最終的にはほぼ完全に自動化できました。

 

その他、既存のexcelフォーマットから欲しいデータ形式にするためのグルーコードもpythonでたくさん書きました。

 

プライベートでも、スプレッドシートからtexファイルへの変換など、これまでperlでしていたことをpythonでやるようになりました。

 

卒論で使うためにと頼まれたtwitterからのデータ取得や、趣味で日課にしているjstageの新着論文取得も、pythonでしています。

 

Automate the Boring Stuff with Pythonを読んでから、オライリーの『入門 Python 3』を読み、Python Data Science Handbook | Python Data Science Handbookでデータ処理や機械学習のさわりを学びました。

 

余裕ができたら機械学習をもっと触ってみたいです。

 

2.django

pythonを使うのであればWebフレームワークとしてdjangoにたどり着くのは自然な流れでしょう。

 

はじめに · HonKitDjango ドキュメント目次 | Django ドキュメント | Djangoを見ながらプライベートのローカル環境で試行錯誤し、『現場で使える Django の教科書』やDjango for Beginners: Build websites with Python and Djangoを読んで少しずつ理解を進めました。

 

フォルダ構成まで自動で作ってくれるのは楽である反面、どこがどうなって動いているかわからず、気持ち悪くも感じました。

 

前述の職場でdjangoを活用しました。

 

特別な業務をした際に時間や内容などを各職員がexcelファイルに入力していたのですが、これが使いづらく、しょっちゅうデータが壊され、直そうとしても複雑に関数が参照されるなどしていたので苦労しました。

 

djangoを使えばブラウザからデータを入力できるのでパソコンに不慣れな職員でも大丈夫だろうと判断しました。ブラウザを使うといっても、機密資料を扱っていたため、インターネットには接続せず、シェルスクリプトをダブルクリックするとローカルサーバが立ち上がるようにしていました。

 

また、データはsqliteでusbメモリに保存して鍵のかかるロッカーに保存するようにしました。

 

3.laravel

PSGI/Plackで作りかけていたウェブサービスの内容を、経営上の方針転換により、大きく作り変えることになりました。

 

また、将来的に複数人で開発するつもりがあるなら、PSGI/Plackよりもlaravelがよいと言われました。

 

そこで心機一転してlaravelで一から作りました。

 

振り返ると、この判断は正しかったです。

 

PSGI/Plackでセッション管理などに苦労したログイン周りの実装が、ソーシャルログインも含めて、laravelではとても簡単にできました。

 

Laravel – The PHP Framework For Web Artisansの公式ドキュメントを熟読するに限りますね。

 

わからないことがあれば検索して何人かの記述を読めばだいたいわかります。

 

Laravel: Up & Running: A Framework for Building Modern PHP Appsも読みました。

 

お約束としてfat controllerに悩まされることになり、Eric EvansのDomain-Driven Design: Tackling Complexity in the Heart of Softwareを読んで、自分でもいろいろ考えながら、クリーンアーキテクチャも意識するようになりました。

 

javascript部分は、jqueryを使うとこんなに簡単にできるのかと感心して使っていたら、jqueryはもう古く、vue.jsのほうがよいという記述を見かけました。

 

そこで、JavaScript Primer – 迷わないための入門書 #jsprimerを読んでjavascriptの知識をアップデートしてから、Vue.jsを読み、自分で手を動かして、ようやく大まかな動きが理解できました。

 

laravelのbladeで書ける部分はそれで書き、javascriptで動かす必要のあるところだけvue.jsを使うようにしました。そうするとデータの受け渡しが必要になり、vuexも必然的に導入することになりました。

 

vue.jsを使うとlaravelに標準搭載されているduskではテストするのが難しくなり、cypressを導入しました。

 

4.まとめ

これでようやくほぼ最新の情勢についていけるようになったのではないかと思います。

 

あとはサードパーティのAPIをどこまで使いこなせるかです。

 

公式ドキュメントを熟読し、エラーが発生したらきちんろメッセージやログを読むという基本の大切さを痛感しました。

 

 

 



令和2年司法試験予備試験成績通知(論文)

令和2年司法試験予備試験論文の成績通知を公開します。過去の結果は以下のリンクにあります。

 

 

 

試験科目 順位ランク
憲法 F
行政法 F
民法 D
商法 A
民事訴訟法 A
刑法 E
刑事訴訟法 F
一般教養科目 B
法律実務基礎科目 B
合計点 211.45
順位 812

 

再現答案も過去の記事にありますので、ご参考になれば幸いです。

 

相変わらず手応えと結果があまり対応しないのが悩みです。

 




top