浅野直樹の学習日記

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

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

再現答案

以下刑法についてはその条数のみを示す。

第1 乙の罪責

 乙は、某月30日、殺意をもって、両手でXの首を強く締め付け続けた。その結果、Xは窒息死した。乙は、Xが本心では死を望んでいないことを認識しており、この行為の直前にも「あれはうそだ。やめてくれ」と言われている。よって、同意殺人罪(202条)ではなく殺人罪(199条)が成立する。

 

第2 甲の罪責

1.本件ダンボール箱をY宅から持ち出した行為

 この行為につき、窃盗罪(235条)の成否を検討する。

 「他人の財物」とは、「他人が占有する財物」のことである。一応平穏に占有しているという事実的な状態を保護すべきだからである。本件ダンボール箱は、甲が所有する物であるが、Yが占有していた物であり、「他人の財物」に当たる。

 「窃取」とは、強制的に占有を自己に移転させることである。本件では、本件ダンボール箱をY宅から持ち出した時点で、甲は占有を確保して自己に移転させたと言え、窃取したと言える。

 窃盗罪が成立するためには、器物損壊罪(261条)との区別から、その物の経済的用法に従って利用処分するという不法領得の意思が必要であるところ、本件では得意先との取引に本件ダンボール箱の中に入っている本件帳簿が必要だったとのことであるため、不法領得の意思が認められる。

 以上より、窃盗罪の構成要件を満たす。

 次に、正当防衛(36条)が成立するかどうかを検討する。

 「急迫不正の侵害」とは、法益の侵害が現に存在するか間近に迫っていることである。本件でYが「返してほしければ100万円を持ってこい」と言うことは、恐喝罪(249条1項)に該当する行為であり、法益の侵害が現に存在しているため、急迫不正の侵害があると言える。

 甲は、自己の権利を防衛するためにこの行為に及んでいる。

 「やむを得ずにした行為」とは、その行為が相当であることである。本件において、この行為には、相当性が全くない。

 以上より、2項の過剰防衛も含めて、甲には36条の正当防衛は成立しない。

 よって、甲には窃盗罪が成立する。

2.本件帳簿にライターで火をつけてドラム缶の中に投入した行為

 この行為につき、建造物等以外放火罪(110条2項)の成否を検討する。

 本件帳簿にライターで火をつけて炎が発生しているので、放火して焼損したと言える。

 110条1項の「公共の危険」とは、108条及び109条に規定される物に延焼させることに限られず、周囲の物に燃え移るなどして不特定又は多数者の生命等に危険を生じさせることも含まれる。本件では、漁網が燃え上がり、5名の釣り人が発生した煙に包まれているので、公共の危険が発生したと言える。

 この公共の危険が発生することについての認識・認容までは必要ないが、周囲の物に燃え移る可能性についての認識・認容は必要である。甲は、漁網、原動機付自転車、釣り人5名の存在をいずれも認識していなかったので、故意(38条1項)が阻却される。

 以上より、甲には、建造物等以外放火罪は成立しない。

3.乙を制止せずにその場から立ち去ったこと

 まず何罪が成立し得るか考える。甲は、Xが本心から死を望んでいると思っていたので、殺人罪は成立せず、同意殺人罪が成立し得るにとどまる。また、甲はXが死亡することについての認識・認容があったので、遺棄等致死罪(219条)は成立しない。

 同意殺人罪は作為の形式で定められており、このような場合に不作為により罪が成立するためには、法律などにより作為義務が存在し、その作為が容易であって、作為に及んでいたら高い可能性で結果を防止できたという、作為と同視できる条件が必要である。本件では、甲はXの子であり、民法上扶養義務が認められ、Xが死なないようにする義務があった。そして、甲にとって容易に採り得る措置を講じた場合には、乙の犯行を直ちに止めることができた可能性が高く、直ちに乙の犯行を止めてXの救命治療を要請していれば、Xを救命できたことは確実であった。乙を制止せずにその場から立ち去ったことは、それ自体は積極的な行動であり作為であるが、同意殺人罪にとっては意味をなさず不作為である。よって、甲には同意殺人罪が成立する。*

 なお、共同正犯(60条)が成立するためには意思連絡が相互に必要であり、乙は甲が帰宅したことに気付いていなかったので、共同正犯とはならない。

 また、甲は正犯となるので、従犯(62条1項)にはならない。

4.罪数関係

 以上より、甲には窃盗罪と同意殺人罪が成立し、これらは併合罪(45条)となる。

 

*に以下を挿入

 甲は、客観的には殺人罪を実行し、主観的には同意殺人罪の故意であったが、そのような錯誤は構成要件が重なり合う範囲では阻却されない。

以上

 

感想

 乙の罪責の記述があまりにも短くて不安になりました。本件帳簿にライターで火をつけてドラム缶の中に投入した行為については、他にも検討すべき罪があるような気がしましたが、時間の関係であれだけの記述にしました。



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

再現答案

 以下行政事件訴訟法についてはその条数のみを示す。

〔設問1〕

第1 本件条件の法的性質

 本件条件の法的性質は、その根拠となった廃棄物の処理及び清掃に関する法律(以下「法」という。)14条の4第11項の文言から、本件許可処分に付された講学上の負担である。本件条件単独で効力が発生することはなく、本件許可処分と一体となってはじめて効力を発するものである。

第2 考えられる取消訴訟

1.本件許可処分の取消

 第1で述べたことからすると、本件許可処分の取消訴訟を提起すべきだと思われる。この取消判決の効力は、本件許可処分がなかったことになるというものである。つまり、Aの事業範囲の変更がされず、ポリ塩化ビフェニル廃棄物(以下「PCB廃棄物」という。)の積替え・保管を除く収集運搬業のままになるということである。これだとAの希望には沿わない。

2.本件条件部分のみの取消

 そこで、本件条件部分のみの取消訴訟について検討する。このような処分の一部の取消訴訟が可能かどうか問題となり得るも、その必要性があり、論理的に考えて処分全体の取消ができるのであればその一部の取消もできるはずであるから、可能であると解する。この取消判決の効力は、事業範囲の変更が制約なしに認められるというものであり、PCB廃棄物の積替え・保管もできるようになるので、Aの希望を満たすことができる。

 

〔設問2〕

 Aは、取消訴訟において、本件条件の違法性について、裁量権の逸脱・濫用及び信義則違反の主張をすべきである。

1.裁量権の逸脱・濫用

 30条に沿って検討する。

 本件条件は、その根拠となった法14条の4第11項に「生活環境の保全上必要な条件を付することができる」という文言からしても、また生活環境の保全のためには地域に応じた専門技術性が要求されるという性質からも、行政庁であるB県知事に裁量が認められる。

 B県は、近隣の県では本件条件のような内容の条件は付されていないとしても、本件条件はその裁量の範囲内であり、申請書類に記載されていないことを考慮することも許されると反論することが想定される。

 これに対し、Aとしては、近隣の県では本件条件のような内容の条件は付されていないことからして他者搬搬入・搬出をしないことが生活環境の保全のために必須の条件であるわけではなく、それを踏まえてもAが適切にPCB廃棄物を処理することができるかどうかを検討しなかったのは考慮不尽であり裁量権の逸脱・濫用であると主張すべきである。また、申請書類に記載されていないことを考慮することが直ちに違法となることはないにしても、もっぱらそのことだけを考慮するのは、他事考慮として裁量権の逸脱・濫用であるとも主張すべきである。

2.信義則違反

 まず、行政庁の処分にも、信義則といった一般条項が適用される。

 本件では、Aは、積替え・保管施設の建設に関し、他者搬入・搬出も目的としていることを明確に伝えた上でB県の関係する要綱等に従って複数回にわたり事前協議を行い、B県内のA所有地に高額な費用を投じ、B県知事から協議終了通知を送付されている。この時点で、Aには、他者搬入・搬出を含めてPCB廃棄物の収集運搬業を適法に営むことができるという期待が発生しており、この期待は保護されるべきである。にもかかわらず本件条件を付したのは信義則違反であると主張する。

 これに対し、B県としては、事前協議後に従来の運用を変更するという事情変動が生じており、その新しい運用に従って公平に判断したと反論することが想定される。

 Aは、そのような扱いは、それまでの経過を考慮すると、公平な扱いではないと再反論すべきである。

以上

 

感想

 〔設問1〕では問題文の指示から義務付け訴訟は検討すべきでないと判断し、これしかないかなと思って書きました。〔設問2〕はわざわざ収録されている施行規則をに全く触れられず、記述が薄いような気がします。

 



令和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をどこまで使いこなせるかです。

 

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

 

 

 




top