Wikibooks:談話室

<mediawiki xmlns="http://www.mediawiki.org/xml/export-0.10/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.mediawiki.org/xml/export-0.10/ http://www.mediawiki.org/xml/export-0.10.xsd" version="0.10" xml:lang="ja">
  <siteinfo>
    <sitename>Wikibooks</sitename>
    <dbname>jawikibooks</dbname>
    <base>https://ja.wikibooks.org/wiki/%E3%83%A1%E3%82%A4%E3%83%B3%E3%83%9A%E3%83%BC%E3%82%B8</base>
    <generator>MediaWiki 1.39.0-wmf.21</generator>
    <case>first-letter</case>
    <namespaces>
      <namespace key="-2" case="first-letter">メディア</namespace>
      <namespace key="-1" case="first-letter">特別</namespace>
      <namespace key="0" case="first-letter" />
      <namespace key="1" case="first-letter">トーク</namespace>
      <namespace key="2" case="first-letter">利用者</namespace>
      <namespace key="3" case="first-letter">利用者・トーク</namespace>
      <namespace key="4" case="first-letter">Wikibooks</namespace>
      <namespace key="5" case="first-letter">Wikibooks・トーク</namespace>
      <namespace key="6" case="first-letter">ファイル</namespace>
      <namespace key="7" case="first-letter">ファイル・トーク</namespace>
      <namespace key="8" case="first-letter">MediaWiki</namespace>
      <namespace key="9" case="first-letter">MediaWiki・トーク</namespace>
      <namespace key="10" case="first-letter">テンプレート</namespace>
      <namespace key="11" case="first-letter">テンプレート・トーク</namespace>
      <namespace key="12" case="first-letter">ヘルプ</namespace>
      <namespace key="13" case="first-letter">ヘルプ・トーク</namespace>
      <namespace key="14" case="first-letter">カテゴリ</namespace>
      <namespace key="15" case="first-letter">カテゴリ・トーク</namespace>
      <namespace key="100" case="first-letter">Transwiki</namespace>
      <namespace key="101" case="first-letter">Transwiki‐ノート</namespace>
      <namespace key="710" case="first-letter">TimedText</namespace>
      <namespace key="711" case="first-letter">TimedText talk</namespace>
      <namespace key="828" case="first-letter">モジュール</namespace>
      <namespace key="829" case="first-letter">モジュール・トーク</namespace>
      <namespace key="2300" case="first-letter">Gadget</namespace>
      <namespace key="2301" case="first-letter">Gadget talk</namespace>
      <namespace key="2302" case="case-sensitive">Gadget definition</namespace>
      <namespace key="2303" case="case-sensitive">Gadget definition talk</namespace>
    </namespaces>
  </siteinfo>
  <page>
    <title>Wikibooks:談話室</title>
    <ns>4</ns>
    <id>30</id>
    <revision>
      <id>205755</id>
      <parentid>205583</parentid>
      <timestamp>2022-07-24T05:50:00Z</timestamp>
      <contributor>
        <username>Shokupan</username>
        <id>23730</id>
      </contributor>
      <comment>/* ウィキブックスの整理 */ 返信</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="225010" xml:space="preserve">{{談話室}}
ある程度時間のたった議論は[[/過去ログ]]に移動されます。最新の過去ログは [{{fullurl:{{NAMESPACE}}:{{BASEPAGENAME}}|oldid=176963}} 2021年4月15日 (木) 14:30の版] です（確認日: 2021年4月15日）。過去ログ化の方法については[[Wikibooks:過去ログ化のガイドライン]]を参照ください。

{{/告知}}

== Moving Wikimania 2021 to a Virtual Event ==

&lt;div class=&quot;mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;
[[File:Wikimania_logo_with_text_2.svg|right|alt=Wikimania's logo.|75px]]

''{{int:Hello}}. Apologies if you are not reading this message in your native language. {{Int:Please-translate}}. {{Int:Feedback-thanks-title}}''

[[:m:Wikimania 2021|Wikimania will be a virtual event this year]], and hosted by a wide group of community members. Whenever the next in-person large gathering is possible again, [[:m:ESEAP Hub|the ESEAP Core Organizing Team]] will be in charge of it. Stay tuned for more information about how ''you'' can get involved in the planning
process and other aspects of the event. [https://lists.wikimedia.org/pipermail/wikimedia-l/2021-January/096141.html Please read the longer version of this announcement on wikimedia-l]. 

''ESEAP Core Organizing Team, Wikimania Steering Committee, Wikimedia Foundation Events Team'', 2021年1月27日 (水) 15:15 (UTC) 
&lt;/div&gt;
&lt;!-- User:Elitre (WMF)@metawiki が https://meta.wikimedia.org/w/index.php?title=User:Elitre_(WMF)/Wikimania21&amp;oldid=21014617 のリストを使用して送信したメッセージ --&gt;
== ビデオゲームの攻略本について ==

攻略本を解説書として執筆することは許可されているのでしょうか？

さっき英語版WIKIBOOKSに「ビデオゲームの執筆の許可」という趣旨のページを見つけました。日本語版ではどうなっているのでしょうか。
== Project Grant Open Call ==

This is the announcement for the [[m:Grants:Project|Project Grants program]] open call that started on January 11, with the submission deadline of February 10, 2021.&lt;br&gt; This first open call will be focussed on Community Organizing proposals. A second open call focused on research and software proposals is scheduled from February 15 with a submission deadline of March 16, 2021.&lt;br&gt;

For the Round 1 open call, we invite you to propose grant applications that fall under community development and organizing (offline and online) categories. Project Grant funds are available to support individuals, groups, and organizations to implement new experiments and proven ideas, from organizing a better process on your wiki, coordinating a campaign or editathon series to providing other support for community building.  We offer the following resources to help you plan your project and complete a grant proposal:&lt;br&gt;

* Weekly proposals clinics via Zoom during the Open Call. Join us for [[m:Grants:Project|#Upcoming_Proposal_Clinics|real-time discussions]] with Program Officers and select thematic experts and get live feedback about your Project Grants proposal. We’ll answer questions and help you make your proposal better. We also offer these support pages to help you build your proposal:
* [[m:Grants:Project/Tutorial|Video tutorials]] for writing a strong application&lt;br&gt;
* General [[m:Grants:Project/Plan|planning page]] for Project Grants &lt;br&gt;
* [[m:Grants:Project/Learn|Program guidelines and criteria]]&lt;br&gt;

Program officers are also available to offer individualized proposal support upon request. Contact us if you would like feedback or more information.&lt;br&gt;

We are excited to see your grant ideas that will support our community and make an impact on the future of Wikimedia projects. Put your idea into motion, and [[m:Grants:Project/Apply|submit your proposal]] by February 10, 2021!&lt;br&gt;

Please feel free to get in touch with questions about getting started with your grant application, or about serving on the Project Grants Committee. Contact us at projectgrants{{at}}wikimedia.org. Please help us translate this message to your local language. [[利用者:MediaWiki message delivery|MediaWiki message delivery]] ([[利用者・トーク:MediaWiki message delivery|トーク]]) 2021年1月28日 (木) 08:00 (UTC)
&lt;!-- User:RSharma (WMF)@metawiki が https://meta.wikimedia.org/w/index.php?title=Distribution_list/Global_message_delivery&amp;oldid=20808431 のリストを使用して送信したメッセージ --&gt;

== Wiki Loves Folklore 2021 is back! ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; class=&quot;mw-content-ltr&quot;&gt;

{{int:please-translate}}

[[File:Wiki Loves Folklore Logo.svg|right|150px|frameless]]
You are humbly invited to participate in the '''[[:c:Commons:Wiki Loves Folklore 2021|Wiki Loves Folklore 2021]]''' an international photography contest organized on Wikimedia Commons to document folklore and intangible cultural heritage from different regions, including, folk creative activities and many more. It is held every year from the 1st till the 28th of February.

You can help in enriching the folklore documentation on Commons from your region by taking photos, audios, videos, and [https://commons.wikimedia.org/w/index.php?title=Special:UploadWizard&amp;campaign=wlf_2021 submitting] them in this commons contest.

Please support us in translating the [[:c:Commons: Wiki Loves Folklore 2021|project page]] and a [https://meta.wikimedia.org/wiki/Special:Translate?group=Centralnotice-tgroup-wikiloveslove2020&amp;language=en&amp;filter=%21translated&amp;action=translate|one-line banner message] to help us spread the word in your native language.

'''Kind regards,'''

'''Wiki loves Folklore International Team'''

[[利用者:MediaWiki message delivery|MediaWiki message delivery]] ([[利用者・トーク:MediaWiki message delivery|トーク]]) 2021年2月6日 (土) 13:25 (UTC)
&lt;/div&gt;
&lt;!-- User:Tiven2240@metawiki が https://meta.wikimedia.org/w/index.php?title=User:Tiven2240/wll&amp;oldid=21073884 のリストを使用して送信したメッセージ --&gt;

== Proposal: Set two-letter project shortcuts as alias to project namespace globally ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;
{{int:please-translate}}

Hello everyone,

I apologize for posting in English. I would like to inform everyone that I created a new global request for comment (GRFC) at Meta Wiki, which may affect your project: [[:m:Requests for comment/Set short project namespace aliases by default globally]].

In this GRFC, I propose that two-project shortcuts for project names will become a default alias for the project namespace. For instance, on all Wikipedias, WP will be an alias to the Wikipedia: namespace (and similar for other projects). Full list is available in the GRFC.

This is already the case for Wikivoyages, and many individual projects asked for this alias to be implemented. I believe this makes it easier to access the materials in the project namespace, as well as creating shortcuts like &lt;tt&gt;WP:NPOV&lt;/tt&gt;, as well as helps new projects to use this feature, without having to figure out how to request site configuration changes first.

As far as I can see, {{SITENAME}} currently does not have such an alias set. This means that such an alias will be set for you, if the GRFC is accepted by the global community.

I would like to ask all community members to participate in the request for comment at Meta-Wiki, see [[:m:Requests for comment/Set short project namespace aliases by default globally]].

Please feel free to [[:m:User talk:Martin Urbanec|ask me]] if you have any questions about this proposal.

Best regards,&lt;br /&gt;
--[[:m:User:Martin Urbanec|Martin Urbanec]] ([[:m:User talk:Martin Urbanec|talk]]) 2021年2月18日 (木) 14:12 (UTC)
&lt;/div&gt;
&lt;!-- User:Martin Urbanec@metawiki が https://meta.wikimedia.org/w/index.php?title=User:Martin_Urbanec/MassMessage&amp;oldid=21125035 のリストを使用して送信したメッセージ --&gt;

== Wikifunctions logo contest ==

&lt;div class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;ja&quot; dir=&quot;ltr&quot;&gt;
{{Int:Hello}}. 新規開設のウィキファンクションというウィキについて、ロゴのデザイン構想をまとめようとしています。ぜひ選考過程にご協力いただけませんか。投票は本日から受付を開始、投票期間は2週間です。皆さん、どうか Meta-Wiki にて'''[[m:Special:MyLanguage/Abstract Wikipedia/Wikifunctions logo concept/Vote|このまま詳細と投票方法をご確認の上]]'''、ふるってご参加ください。 {{Int:Feedback-thanks-title}} --[[m:User:Quiddity (WMF)|Quiddity (WMF)]]&lt;/div&gt; 2021年3月2日 (火) 01:45 (UTC)
&lt;!-- User:Quiddity (WMF)@metawiki が https://meta.wikimedia.org/w/index.php?title=Distribution_list/Global_message_delivery&amp;oldid=21087740 のリストを使用して送信したメッセージ --&gt;

== 一斉配信されるメッセージを別のページに分離したい ==

談話室に一斉配信されるメッセージには興味がなく鬱陶しく感じます。見通しも悪くなりますし別ページに配信するようにしてほしいと感じます。 --[[利用者:Naggy Nagumo|Naggy Nagumo]] ([[利用者・トーク:Naggy Nagumo|トーク]]) 2021年3月25日 (木) 04:39 (UTC)

== MITライセンスのコンテンツを持ち込むことの是非 ==

[[WinSock/MSDNのソケットコードの保管場所]]というページでは、外部のコンテンツを丸ごと転載している様子です。著作権侵害ではないかと懸念し、調べたところ、転載元は https://github.com/MicrosoftDocs/win32 内にあることを突き止めました（[https://github.com/MicrosoftDocs/win32/blob/0e611cdff84ff9f897c59e4e1d2b2d134bc4e133/desktop-src/WinSock/complete-client-code.md]と[https://github.com/MicrosoftDocs/win32/blob/0e611cdff84ff9f897c59e4e1d2b2d134bc4e133/desktop-src/WinSock/complete-server-code.md]）。そこにあるファイル、LICENSEおよびLICENSE-CODEの内容はそれぞれCC-BY 4.0とMIT Licenseでした。基本的にはCC-BY 4.0であり、ただしプログラムのソースコード部分はMIT Licenseだということだと思います。

そこで、掲題のとおりMITライセンスのコンテンツをWikibooksに持ち込むことは問題ないか？という疑問に至りました。主な選択肢は以下のようになると思うのですが、どのように考えるべきでしょうか？皆さんの意見をうかがいたいです。

* MITライセンスの持ち込みは不可であり、削除依頼を出すべき。
* MITライセンスの持ち込みは可であり、削除する対象にはならない。
* MITライセンスの持ち込みは可であるものの、当該コンテンツにはCC-BY 4.0が適用される可能性を否定しきれない。WikibooksのページはCC-BY-SA 3.0のため持ち込めない（バージョンが低くなるので互換性がない）ので、削除依頼を出すべき。

著作権侵害にかかわる問題のため、広く意見を募るべきと思い、当該ページのノートではなく、こちらに話題を起こすことにしました。ご容赦ください。--[[利用者:Wdpp|Wdpp]] ([[利用者・トーク:Wdpp|トーク]]) 2021年4月3日 (土) 18:35 (UTC)
:私は著作権やライセンスに関する知識はあまりないのですが、とはいえ Web活動では特定のライセンスを利用したり公言することはあるのですが、しかしそれは何となく有用だと思えるから何となく採用しているだけで、詳しくちゃんと理解しているわけではないんですよ。それにここのページの下部には、&lt;blockquote&gt;テキストはクリエイティブ・コモンズ 表示-継承ライセンス (CC BY-SA 3.0) の下で利用可能です。追加の条件が適用される場合があります。詳細は利用規約[https://foundation.wikimedia.org/wiki/Terms_of_Use/ja]を参照してください。&lt;/blockquote&gt;と書いてありますけど、この利用規約[https://foundation.wikimedia.org/wiki/Terms_of_Use/ja]を詳読すればかなりの見解を持つことができると思いますが、このことに関して多くの時間や精力を費やす気はないのであくまでも談話室での無責任なおしゃべりとして書かせてもらいます。

:まずここでウィキメディア以外からの転載が許されるのは、
:#著作権者が許可した
:#パブリックドメイン
:#著作権法上保護されないと見なされるもの
:だと思うんですが、特定のライセンスを持っているものは、転載しないほうがいい、非推奨ってことになりますよね…。ただ何らかの理由で、過去書かれたものがあったとしたら、それはその掲載元のライセンスで上書きされていると見なすといいかもしれませんね…。ですからそのライセンスの指定にしたがって転載されていたらOK、そうでなかったらアウトってことなんですが…。

:いやー単なる思い付きを書いただけで、大したことは言えないんですが…。--[[利用者:Honooo|Honooo]] ([[利用者・トーク:Honooo|トーク]]) 2021年4月5日 (月) 20:42 (UTC)

:{{コメント2|コメント}} MITライセンスは条件が緩いライセンスであって、MIT→CC-BY-SA 3.0 への互換性は問題ないように思います。したがって受け入れ可だと思いますが、細かい条件があるかもしれないので、結局は個別に確認するしかなさそうです。ウィキブックスのコンテンツを外部利用するケースを考えると、ライセンス条件が異なる部分がある場合は本文中に表示した方がよいかもしれません。問題のページに関しては、転載元が明確でないならばライセンス違反だと思います。 --[[利用者:Naggy Nagumo|Naggy Nagumo]] ([[利用者・トーク:Naggy Nagumo|トーク]]) 2021年4月9日 (金) 11:18 (UTC)

::（コメント∧返信）互換性という言葉が出ていますが、そもそも掲載元のライセンスを乗り換え、変更することは元のライセンスに指定がない以上は不可能ではないですかね…。ですから対処としては、ここに他のライセンスの文章を持ち込むなよな、って口で言う以外特にやること思いつかなくて…。ですからそういうページがあって、問題があると考えられる場合は、誰かが妥当な記述に書き換えるか、あるいは削除依頼を提出するかですよね…。著作権の問題は即時削除にならないと明記されていますし…。罪と罰なんて言葉がありますが、罪があると見なされたとしても、では誰がそれを指摘して非難して、罰を与えて物事を正すか？ 私自身は今後もすじにく氏の文章を再編集して上書きする気はありますが、それはあくまで内容が良くなくて不適切だと思うからで、著作権の問題で深くかかわる気はないんです…。それに彼自身がここで著作権や転載引用の問題を教科書として執筆しているわけですから、あまりにもわかりやすい明確な逸脱をすることはないようにも思えますし…。ここでこのことを話し合うことで何らかの合意は得られるかもしれませんが、しかし合意以前に一般通念としてどう考えればいいのか？ウィキメディア財団としての見解はないのか？なんか非常に扱いづらい話ですねー。あとコモンズではどうなっているんですか？一番そういう事が問題になっている場にも見えますが…--[[利用者:Honooo|Honooo]] ([[利用者・トーク:Honooo|トーク]]) 2021年4月9日 (金) 22:35 (UTC)

:::見解とも違いますが、[[Wikibooks:著作権]]には「外部からの引用については原則として行わないでください。」とあります。引用ですらそうなら、転載はなおのこと推奨されない行為ではないかと思います。この点も、削除依頼すべきなのかなと考えさせられる要因の1つです。--[[利用者:Wdpp|Wdpp]] ([[利用者・トーク:Wdpp|トーク]]) 2021年4月12日 (月) 15:44 (UTC)

::::ああーそういう記述もありますね…。いずれにせよこの辺の話は込み入ってるから、場合場合でよくわからないことが多いんですよね&lt;s&gt;(^^;)&lt;/s&gt;。それにしても世の中の人は著作権を後生大事に、目の覚めるほど重要なものだと思ってるようですが、もちろん私自身も著作権法やその理念は大事にしますし、ウィキメディア財団やプロジェクトに打撃を与えたいとは思っていませんが、しかし実際の運用ではそんな大したこと起こっていない、基本的には人数と金が絡んでいる連中が、がーがー理屈言って、自分たちの利益を死守しているだけで、世の創作物なんて、多くは普遍的にはネガティブな性質と価値しかないのにやたら金を生むものが幅を利かせて、その金と満たされた欲望に多数派のサルが群がってるだけだよね？……と、言ってしまうのはさすがに無茶苦茶な言い分ですが…。^^;

::::それはともかくこの事に関する私の主張は以下ですね。

::::#まず他ライセンスのコンテンツ持ち込みは引用と同様推奨されない。
::::#仮にそういうページがあったら、ウィキメディアのクリエイティブコモンズ云々の記述があるにもかかわらず、掲載元のライセンスの記述だと見なすしかない。
::::#もしそのページに問題があると感じるなら、自分自身の判断と責任で再編集するか削除依頼を提出する。-- [[利用者:Honooo|Honooo]] ([[利用者・トーク:Honooo|トーク]]) 2021年4月13日 (火) 11:34 (UTC)
::::: ”無責任なおしゃべり”ということで、私の解釈を書きます。結論から言えば、受け入れることはできるでしょう。ここで、受け入れられるライセンスというのは編集画面の「変更内容を保存すると、あなたは利用規約に同意するとともに、&lt;u&gt;自分の投稿内容を CC BY-SA 3.0 ライセンスおよび GFDL のもとで公開することに同意したことになります。&lt;/u&gt;〔後略〕」や、フッターの「テキストはクリエイティブ・コモンズ 表示-継承ライセンスのもとで利用できます。追加の条件が適用される場合があります。」に表示されている通り、CC BY-SA 3.0ということにほかなりません。前置きが長くなりましたが本題。MITライセンスは、原著作者の表示およびライセンスそれ自身の表示を義務付けます。CC BY-SAも、原著作者の表示を義務付けます。我々は原著作者の表示はURLで十分と同意 (※編集画面の注釈) しているため、我々は要約欄に派生元URLを貼付したりします。さて、ここで問題です。我々はどのようにMITライセンスの要求を満たせば良いでしょうか？答えの一つは原著作者と、MITライセンスの全文が乗ったURLを添付することです。もう一つ問題です。MITライセンスはCC BY-SA 3.0とGFDLに組み込めるでしょうか？肯。https://licenses.opensource.jp/MIT/MIT.html によれば、「〔前略〕本ソフトウェアおよび関連文書のファイル（以下「ソフトウェア」）の複製を取得するすべての人に対し、ソフトウェアを無制限に扱うことを無償で許可します。〔後略〕」とあるため、従って'''異なるライセンスのコンポーネントにMITライセンスのコンポーネントを組み込んでも法的問題は生じない'''ものと考えられます。しかしながら、一般論として、引き写しは単なるコピー本にしかならないため、自身の文章で執筆したほうがこのようなやっかいごとなども生じずに済むでしょう。--[[利用者:Semi-Brace|Semi-Brace]] ([[利用者・トーク:Semi-Brace|トーク]]) 2021年4月13日 (火) 12:14 (UTC)

== ユニバーサルな行動規範 第2フェーズ ==

[[:wmf:Special:MyLanguage/Universal Code of Conduct|'''ユニバーサルな行動規範 (UCoC)''']] はウィキメディア運動とそのプロジェクト群全般に適用し、ユニバーサル (普遍的) な容認できる行動の基本線を提示します。現在、このプロジェクトは第2フェーズに入り、明確な施行経路の概要を示しています。プロジェクト全体の詳細は[[:m:Special:MyLanguage/Universal Code of Conduct|'''プロジェクトのページ''']]をご参照ください。

=== 草稿委員会：立候補の受付中 ===

ウィキメディア財団ではボランティアとして規範の施行方法の草稿をまとめる委員会への参加者を募集中です。ボランティアの委員は4月後半から7月に、また10月から11月にかけて週に2から6時間、時間をとっていただきます。委員会は多様性と包括性を重んじ、初学者から経験者まで、嫌がらせの被害者や対策をした人、間違えて加害者扱いされた人などさまざまな経歴の委員を揃えるよう目指しています。

選考過程と応募の詳細は、[[:m:Special:MyLanguage/Universal Code of Conduct/Drafting committee|Universal Code of Conduct/Drafting committee]] (ユニバーサルな行動規範/草稿委員会) をご参照ください。

=== 2021年コミュニティとの協議：お知らせとボランティア / 翻訳者の募集 ===

2021年4月5日 – 同5月5日にわたり、多数のウィキメディアのプロジェクトで UCoC 施行の方法についてコミュニティと協議します。ボランティアとして、主要な題材の翻訳者と合わせてそれぞれの言語版もしくはプロジェクトで指定の[[:m:Special:MyLanguage/Universal Code of Conduct/2021 consultations/Discussion|主要な設問]]について協議進行の補佐役を募集します。これらのボランティアのいずれかに関心がある皆さんは、ぜひいつもお使いの言語で[[:m:Talk:Universal Code of Conduct/2021 consultations|ご連絡ください]]。

この過程とその他の会話の詳細は、[[:m:Special:MyLanguage/Universal Code of Conduct/2021 consultations|Universal Code of Conduct/2021 consultations]] (ユニバーサルな行動規範/2021年コミュニティとの協議) をご参照ください。

-- [[User:Xeno (WMF)|Xeno (WMF)]] ([[User talk:Xeno (WMF)|トークページ]]) 2021年4月5日 (月) 21:19 (UTC)
&lt;!-- User:SOyeyele (WMF)@metawiki が https://meta.wikimedia.org/w/index.php?title=User:SOyeyele_(WMF)/Announcements/Japanese&amp;oldid=21301359 のリストを使用して送信したメッセージ --&gt;

== Line numbering coming soon to all wikis ==

&lt;div class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;ja&quot; dir=&quot;ltr&quot;&gt;  

[[File:Technical_Wishes_–_Line_numbering_-_2010_wikitext_editor.png|thumb|使用例]]
4月15日より特定の種類のウィキ文エディタでは行番号が表示できるようになります -今のところ、テンプレート名前空間で、まもなくより多くの名前空間になります。これは改行を見つけやすくしたり、協議で特定の行を示す時に役立ちます。行番号を表示するには、構文強調機能（[[mw:Special:MyLanguage/Extension:CodeMirror|CodeMirror 拡張機能]]）を有効にする必要があり、ウィキ文エディタの[[mw:Special:MyLanguage/Extension:WikiEditor|2010年版]]と[[mw:Special:MyLanguage/2017 wikitext editor|2017年版]]が対応しています。 

詳細情報は[[m:WMDE Technical Wishes/Line Numbering|こちらのプロジェクトページ]]をご参照ください。皆さんも機能のテストにぜひ参加して、[[m:talk:WMDE Technical Wishes/Line Numbering|このトークページ]]でフィードバックを投稿してみませんか。
&lt;/div&gt; -- [[m:User:Johanna Strodt (WMDE)|Johanna Strodt (WMDE)]] 2021年4月12日 (月) 15:08 (UTC)
&lt;!-- User:Johanna Strodt (WMDE)@metawiki が https://meta.wikimedia.org/w/index.php?title=WMDE_Technical_Wishes/Technical_Wishes_News_list_all_village_pumps&amp;oldid=21329014 のリストを使用して送信したメッセージ --&gt;

== Suggested Values ==

&lt;div class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;ja&quot; dir=&quot;ltr&quot;&gt;  

4月29日より、テンプレートのパラメータの推奨値を提案できるようになりました。[[mw:Special:MyLanguage/Help:TemplateData|テンプレートデータ]]に登録された推奨値は[[mw:Special:MyLanguage/Help:VisualEditor/User guide|ビジュアルエディター]]でドロップダウンの一覧として表示されます。すると編集者は適切な値を素早く選択できるようになります。これによりエラーを未然に防ぎ、またテンプレートに値を入力する労力を軽減できます。なお、引き続き入力欄に直接、推奨値以外の値を記すことも可能です。

対応しているパラメータの種別や推奨値の作成方法など、詳細は[[mw:Help:TemplateData#suggestedvalues|[1]]] [[m:WMDE_Technical_Wishes/Suggested_values_for_template_parameters|[2]]]でご確認いただけます。皆さんもこの機能をぜひ試してみて、[[m:Talk:WMDE Technical Wishes/Suggested values for template parameters|トークページ]]にフィードバックをお寄せください。

&lt;/div&gt; [[m:User:Timur Vorkul (WMDE)|Timur Vorkul (WMDE)]] 2021年4月22日 (木) 14:08 (UTC)
&lt;!-- User:Timur Vorkul (WMDE)@metawiki が https://meta.wikimedia.org/w/index.php?title=WMDE_Technical_Wishes/Technical_Wishes_News_list_all_village_pumps&amp;oldid=21361904 のリストを使用して送信したメッセージ --&gt;

== Universal Code of Conduct News – Issue 1 ==

&lt;section begin=&quot;ucoc-newsletter&quot;/&gt;
&lt;div style = &quot;line-height: 1.2&quot;&gt;
&lt;span style=&quot;font-size:200%;&quot;&gt;'''ユニバーサルな行動規範ニュース'''&lt;/span&gt;&lt;br&gt;
&lt;span style=&quot;font-size:120%; color:#404040;&quot;&gt;'''第1号 - 2021年6月'''&lt;/span&gt;&lt;span style=&quot;font-size:120%; float:right;&quot;&gt;[[m:Special:MyLanguage/Universal Code of Conduct/Newsletter/1|'''ニュースレター全文はこちら''']]&lt;/span&gt;
----
[[m:Special:MyLanguage/Universal Code of Conduct|ユニバーサルな行動規範]]ニュースの創刊号にようこそ！ このニュースレターは ウィキメディアンの皆さんに新しいコードの開発に関与し続ける手助けとなり、UCoC 関連のニュースや調査、今後のイベントを配信します。

この号はUCoC ニュースレターの創刊号であり、購読者ならびにプロジェクト群に配信しイニシアティブを発表するものです。将来の号を受信するには、利用者のトークページや井戸端あるいは適切と判断されるいずれのページにするか[[m:Special:MyLanguage/Global message delivery/Targets/UCoC Newsletter Subscription|こちらで購読手続き]]をお願いします。

ニュースを皆さんがお使いの言語で広め、新しい行動規範の意識を創出できるように、私たちが大切にするコミュニティが誰にどっても安全安心であるように、ニュースレターの各号について翻訳をお願いできないでしょうか。草稿がまとまったお知らせを受信し発行前に翻訳に取り掛かるには[[m:Special:MyLanguage/Universal Code of Conduct/Newsletter/Participate|こちらに署名]]してください。皆さんのご参加を期待しご協力に感謝します。
&lt;/div&gt;&lt;div style=&quot;margin-top:3px; padding:10px 10px 10px 20px; background:#fffff; border:2px solid #808080; border-radius:4px; font-size:100%;&quot;&gt;

* '''提携団体の聞き取り調査''' – 規模の大小や種別を超え、提携団体には2021年3、4月にわたり UCoC 提携団体聞き取り調査に参加を呼びかけました。 ([[m:Special:MyLanguage/Universal Code of Conduct/Newsletter/1#sec1|続きはこちら]])
* '''2021年主要課題の聞き取り調査''' – ウィキメディア財団は2021年4、5月に実施の主要な課題の聞き取り調査を行い、ウィキメディアのコミュニティからより広く UCoC 実施に関するインプットをお願いしています。 ([[m:Special:MyLanguage/Universal Code of Conduct/Newsletter/1#sec2|続きはこちら]])
* '''円卓会議''' – UCoC 聞き取り調査チームでは90分単位の公開円卓会議を2回、2021年5月に開き、UCoC 実施 に関する重要な質問について話し合いました。会話の今後の日程をご参照ください。([[m:Special:MyLanguage/Universal Code of Conduct/Newsletter/1#sec3|続きはこちら]])
* '''第2フェーズ草案委員会''' – UCoC の第2フェーズに対応する草案委員会は2021年5月12日に作業を始めています。詳細をご参照ください。([[m:Special:MyLanguage/Universal Code of Conduct/Newsletter/1#sec4|続きはこちら]])
* '''&lt;span lang=&quot;en&quot; dir=&quot;ltr&quot; class=&quot;mw-content-ltr&quot;&gt;Diff blogs&lt;/span&gt;''' – ブログには UCoC 調整役から投稿があり、2021年第1四半期に実施したローカルのプロジェクト聞き取り調査から、それぞれのコミュニティで出会った出来事や洞察を記しています。 ([[m:Special:MyLanguage/Universal Code of Conduct/Newsletter/1#sec5|続きはこちら]])&lt;/div&gt;&lt;section end=&quot;ucoc-newsletter&quot;/&gt;
&lt;/div&gt;
--[[利用者:MediaWiki message delivery|MediaWiki message delivery]] ([[利用者・トーク:MediaWiki message delivery|トーク]]) 2021年6月11日 (金) 22:41 (UTC)
&lt;!-- User:SOyeyele (WMF)@metawiki が https://meta.wikimedia.org/w/index.php?title=User:SOyeyele_(WMF)/Announcements/Japanese&amp;oldid=21301359 のリストを使用して送信したメッセージ --&gt;

== 日本語版独自ロゴへの変更提案 ==
現行のウィキブックス日本語版のロゴは、英語版のものからスローガン（？）を抜いた[[:File:Wikibooks-logo-en-noslogan.svg]]を使用しているようですが、例えば中国語版では[[:File:Wikibooks-logo-zh.svg]]、朝鮮語版では[[:File:Wikibooks-logo-ko-new.svg]]などと、多くの他言語版では各言語毎に独自のロゴ（文字の部分を変更したもの）が使用されています。日本語版でもウィキペディアやウィキニュース、ウィキバーシティでは独自ロゴが使用されています。このウィキブックス日本語版でも、ロゴを変更してみてはどうでしょうか。是非ご意見をお願いします。--[[利用者:TKsdik8900|TKsdik8900]] ([[利用者・トーク:TKsdik8900|トーク]]) 2021年6月12日 (土) 10:08 (UTC)
:いやー別に変更するならするでいいのですが，ハングルについてはよくわからないのですが，中国語版の後半は音の訳ではなく意訳ですよね。教科書って書いていますから，books，ブックスではなく，つまり，nerveを神経と訳したようなもので…。WIKIBOOKS→ウィキブックスの変更があまり意味のあるものだとは思えなくて…。と，いうかむしろ，WIKIBOOKSのほうが望ましいようにも見えるんですよね…。でも変更する，作るなら作るでもいいですよ。--[[利用者:Honooo|Honooo]] ([[利用者・トーク:Honooo|トーク]]) 2021年6月18日 (金) 11:38 (UTC)
*{{コメント2|反対}} Honoooさんがおっしゃるように、あまり意味があるようなものではないと思います。Wikibooksの広義の意味を維持するためにも、現状のままがいいと思います。--[[利用者:Mario1257|Mario1257]] ([[利用者・トーク:Mario1257|トーク]]) 2021年6月21日 (月) 16:48 (UTC)

== Wikimania 2021: Individual Program Submissions ==

[[File:Wikimania logo with text 2.svg|right|200px]]
Dear all,

Wikimania 2021 will be [[:wikimania:2021:Save the date and the Core Organizing Team|hosted virtually]] for the first time in the event's 15-year history. Since there is no in-person host, the event is being organized by a diverse group of Wikimedia volunteers that form the [[:wikimania:2021:Organizers|Core Organizing Team]] (COT) for Wikimania 2021.

'''Event Program''' - Individuals or a group of individuals can submit their session proposals to be a part of the program. There will be translation support for sessions provided in a number of languages. See more information [[:wikimania:2021:Submissions/Guidelines#Language Accessibility|here]].

Below are some links to guide you through;
* [[:wikimania:2021:Submissions|Program Submissions]]
* [[:wikimania:2021:Submissions/Guidelines|Session Submission Guidelines]]
* [[:wikimania:2021:FAQ|FAQ]]

Please note that the deadline for submission is 18th June 2021. 

'''Announcements'''- To keep up to date with the developments around Wikimania, the COT sends out weekly updates. You can view them in the Announcement section [[:wikimania:2021:Announcements|here]]. 

'''Office Hour''' - If you are left with questions, the COT will be hosting some office hours (in multiple languages), in multiple time-zones, to answer any programming questions that you might have.  Details can be found [[:wikimania:2021:Organizers#Office hours schedule|here.]]

Best regards,

[[利用者:MediaWiki message delivery|MediaWiki message delivery]] ([[利用者・トーク:MediaWiki message delivery|トーク]]) 2021年6月16日 (水) 04:18 (UTC)

On behalf of Wikimania 2021 Core Organizing Team
&lt;!-- User:Bodhisattwa@metawiki が https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/VisualEditor/Newsletter/Wikis_with_VE&amp;oldid=21597568 のリストを使用して送信したメッセージ --&gt;

== Editing news 2021 #2 ==

&lt;div class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;ja&quot; dir=&quot;ltr&quot;&gt;
&lt;em&gt;[[m:Special:MyLanguage/VisualEditor/Newsletter/2021/June|他の言語で読む]] • [[m:VisualEditor/Newsletter|多言語ニュースレター配信に登録する]]&lt;/em&gt;

[[File:Reply Tool A-B test comment completion.png|alt=導入されている全ウィキペディアにおける編集初心者のコメント完了率|thumb|296x296px|初心者が返信ツールを使用してトークページに投稿しようとした際、コメント投稿に成功した割合。([https://wikimedia-research.github.io/Reply-tools-analysis-2021/ 出典])]]

今年の年初め、編集チームは[[mw:Talk pages project/Replying|返信ツール]]の大規模研究を行いました。 主な目的としては、返信ツールが[[mw:Talk pages project/Glossary|編集初心者]]のウィキにおけるコミュニケーションに役立っているかどうかを調べることが挙げられます。2つ目の目的は、新人編集者がこのツールを使って投稿したコメントが既存のwikitextエディタによるコメントよりも不適切なものが多いか調べることでした。

主な結果 :

* &lt;span lang=&quot;en&quot; dir=&quot;ltr&quot; class=&quot;mw-content-ltr&quot;&gt;Newer editors who had automatic (&quot;default on&quot;) access to the Reply tool were [https://wikimedia-research.github.io/Reply-tools-analysis-2021/ more likely] to post a comment on a talk page.&lt;/span&gt;
* また、編集初心者が返信ツールで行ったコメントは、ページ編集でのコメントよりも取り消し・巻き戻しされる可能性が[https://wikimedia-research.github.io/Reply-tools-analysis-2021/ 低い]という結果が出ました。

この結果により、Editingチームはこのツールが役立っていると確信しました。

&lt;strong&gt;今後の予定&lt;/strong&gt;

チームは今後数ヶ月で、返信ツールをオプトアウトで全員が利用できるように計画しています。この機能はアラビア語・チェコ語・ハンガリー語版ウィキペディアで先行的に実装されています。

&lt;span lang=&quot;en&quot; dir=&quot;ltr&quot; class=&quot;mw-content-ltr&quot;&gt;The next step is to [[phab:T280599|resolve a technical challenge]]. Then, they will deploy the Reply tool first to the [[phab:T267379|Wikipedias that participated in the study]].  After that, they will deploy it, in stages, to the other Wikipedias and all WMF-hosted wikis.&lt;/span&gt;

現在、ベータ機能として「{{int:discussiontools-preference-label}}」を有効にできます。返信ツールを導入した後は、[[Special:Preferences#mw-prefsection-editing-discussion]]でいつでも設定を変更することができます。

–[[User:Whatamidoing (WMF)|Whatamidoing (WMF)]] ([[User talk:Whatamidoing (WMF)|トーク]])
&lt;/div&gt; 2021年6月24日 (木) 14:14 (UTC)
&lt;!-- User:Elitre (WMF)@metawiki が https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/VisualEditor/Newsletter/Wikis_with_VE&amp;oldid=21624491 のリストを使用して送信したメッセージ --&gt;

== Server switch ==

&lt;div class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;ja&quot; dir=&quot;ltr&quot;&gt;&lt;div class=&quot;plainlinks&quot;&gt;

[[:m:Special:MyLanguage/Tech/Server switch 2020|他の言語で読む]]  •  [https://meta.wikimedia.org/w/index.php?title=Special:Translate&amp;group=page-Tech%2FServer+switch+2020&amp;language=&amp;action=page&amp;filter= {{int:please-translate}}]

[[foundation:|ウィキメディア財団]]ではメインと予備のデータセンターの切り替えテストを行います。  災害が起こった場合でも、ウィキペディアとその他のウィキメディア・ウィキが確実にオンラインとなるようにするための措置です。 ウィキメディアの技術部門では計画的にテストを行って、すべてが正常に動作することを確認する必要があります。今回のテストでは、あるデータセンターから他のデータセンターへ確実に切り替えられるかどうかを確かめます。そのため、多くのチームでテストや想定外の問題に対処できるよう準備を行う必要があります。 &lt;!--

 '''2020年10月27日（火）'''にすべての通信をメインのデータセンターへ戻します。 --&gt;

残念ながら [[mw:Manual:What is MediaWiki?|MediaWiki]] の技術的制約により、切り替え作業中はすべての編集を停止する必要があります。  ご不便をおかけすることをお詫びします。なお、将来的には制限を最小限にとどめられるよう取り組んでいます。 

'''閲覧は可能ですが、すべてのウィキにおいて短時間、編集ができない状態になります。'''

*2021年6月29日（火）には、最大1時間ほど編集できない時間が発生します。 テストは以下の時刻に開始します：[https://zonestamp.toolforge.org/1624975200 14:00 UTC]（つまり日本時間23:00、インド時間19:30、中央ヨーロッパ時間16:00、西ヨーロッパ時間15:00、米東部時間10:00、米太平洋時間07:00。ニュージーランドでは6月30日（水）のニュージーランド時間02:00。）
*この時間帯に編集や保存を行おうとした場合、エラーメッセージが表示されます。  その間に行われた編集が失われないようには努めますが、保証することはできません。  エラーメッセージが表示された場合、通常状態に復帰するまでお待ちください。  その後、編集の保存が可能となっているはずです。  しかし念のため、保存ボタンを押す前に、編集内容のコピーをとっておくことをお勧めします。

''その他の影響''：

*バックグラウンドジョブが遅くなり、場合によっては失われることもあります。 赤リンクの更新が通常時よりも遅くなる場合があります。 特に他のページからリンクされているページを作成した場合、そのページは通常よりも「赤リンク」状態が長くなる場合があります。 実行に長時間を要するスクリプトは、停止しなければなりません。
*6月28日の週は、コード変更を凍結する予定です。  必須ではないコードの展開は行われません。

必要に応じてこの計画は延期されることがあります。  [[wikitech:Switch_Datacenter#Schedule_for_2021_switch|wikitech.wikimedia.org で工程表を見る]]ことができます。 変更はすべて工程表で発表しますので、ご参照ください。  この件に関しては今後、更にお知らせの内容を追加するかもしれません。 作業開始の30分前から、すべてのウィキで画面にバナーを表示する予定です。 '''この情報を皆さんのコミュニティで共有してください。'''&lt;/div&gt;&lt;/div&gt; [[user:SGrabarczuk (WMF)|SGrabarczuk (WMF)]] 2021年6月27日 (日) 01:19 (UTC)
&lt;!-- User:SGrabarczuk (WMF)@metawiki が https://meta.wikimedia.org/w/index.php?title=Distribution_list/Global_message_delivery&amp;oldid=21463754 のリストを使用して送信したメッセージ --&gt;

== 利用者:A3aaaaa33333の紹介ページについて ==

こんにちは。	--A3aaaaa33333です。利用者:A3aaaaa33333の紹介ページを公開しようとすると
&quot;エラー: 行なった操作は、有害であると自動的に判断されたため実行できませんでした。 確かに建設的な操作であると考える場合は、行なおうとしていた操作について管理者にお知らせください。 操作に対して発動した違反規則の概略は以下の通りです: LTA from JAWP&quot;
と表示され公開できないのですが、どうすればいいでしょうか。ご意見よろしくお願いします。	--[[利用者:A3aaaaa33333|A3aaaaa33333]] ([[利用者・トーク:A3aaaaa33333|トーク]]) 2021年7月28日 (水) 00:35 (UTC)
:私は管理者でもないしこのwikiシステムについてもそれほど知らないので大したことは書けませんが、おそらくウィキペディアで，Long-term abuse(LTA:長期にわたる不適切行為)を行う人物に対処するため制限がかけられているIPアドレスからアクセスしているからではないですかね…。あなた自身がそのLTAerとどういう関係、あるいはまったく関係ないかは私には結局判断はできないのですが…。あるいはもうちょっと簡単に、何らかのユーザー側の操作間違いがあるのかもしれません。どちらにしろここでこのことを表明した以上、管理者の方から何らかのアクセスがある、あるいはもうすでにあったかもしれませんが、いやあるいはアクセスがないかもしれませんが、その場合も私は何故そうなるかはよくわからないんですよ…。--[[利用者:Honooo|Honooo]] ([[利用者・トーク:Honooo|トーク]]) 2021年7月28日 (水) 13:24 (UTC)
[[利用者:Honooo|Honooo]]さん、ありがとうございます。
	--[[利用者:A3aaaaa33333|A3aaaaa33333]]

== Install Extension:Quiz ==
:{{コメント2|対処}} '''[[phab:T289383]] [[利用者:4nn1l2|4nn1l2]] ([[利用者・トーク:4nn1l2|トーク]]) 2021年8月26日 (木) 19:01 (UTC)'''
Hello. Sorry for writing in English. Please help translating this message.

In order to install [[mw:Extension:Quiz]] on the Japanese Wikibooks, I need to build a consensus here. This extension is already installed on many language editions of Wikibooks including English, French, German, Spanish, Italian, Russian and many others. You can check [[:en:Special:Version]] (Ctrl+F: quiz) or see phabricator tickets such as [[phab:T157513]]. There are some nice examples at [[:en:Help:Quizzes]]. [[User:Roozitaa]] wants to make her Persian tutorials on the Japanese Wikibooks (such as [[ペルシア語]]) more illustrative using this extension. You can see [[:en:Dutch/Lesson_1#Quiz]] as an example. [[利用者:4nn1l2|4nn1l2]] ([[利用者・トーク:4nn1l2|トーク]]) 2021年7月28日 (水) 02:01 (UTC)
* {{コメント2|賛成}}、提案者として [[利用者:4nn1l2|4nn1l2]] ([[利用者・トーク:4nn1l2|トーク]]) 2021年7月28日 (水) 02:01 (UTC)
* {{コメント2|賛成}} --[[利用者:Roozitaa|Roozitaa]] ([[利用者・トーク:Roozitaa|トーク]]) 2021年7月29日 (木) 23:06 (UTC)

:{{コメント2|賛成}} この機能を活用すれば従来の紙の教科書よりも学習効率の高い教材を作成できると思います。--[[利用者:Nermer314|Nermer314]] ([[利用者・トーク:Nermer314|トーク]]) 2021年8月7日 (土) 14:39 (UTC)

== ネコはヤギが好き ==

あのー談話室なんだから、多少の雑談は許されると思うのですが、今日ふときづいたのですが、ここの検索のページの文字列に、&quot;ネコはヤギが好き&quot;って書かれてる…、これウィキペディア以外のプロジェクトには大抵この文字列なんですが、何かの含蓄があるんですかね^^?。知っている人がいたら教えてほしい(^^)/--[[利用者:Honooo|Honooo]] ([[利用者・トーク:Honooo|トーク]]) 2021年8月9日 (月) 16:43 (UTC)

== Wikimedia Foundation Election 2021 is now stated ==

Voting for the [[m:Special:MyLanguage/Wikimedia Foundation elections/2021/Voting|2021 Board of Trustees election]] is now open. Candidates from the community were asked to submit their candidacy. After a three week long Call for Candidates, there are [[m:Special:MyLanguage/Wikimedia Foundation elections/2021/Candidates#Candidate%20Table|19 candidates for the 2021 election]].

The [[m:Special:MyLanguage/Wikimedia Foundation Board of Trustees|Wikimedia Foundation Board of Trustees]] oversees the Wikimedia Foundation's operations. The Board wants to improve their competences and diversity as a team. They have shared the [[m:Special:MyLanguage/Wikimedia Foundation elections/2021/Candidates#Skills|areas of expertise]] that they are hoping to cover with new trustees.

The Wikimedia movement has the opportunity to select candidates who have the qualities to best serve the needs of the movement for the next several years. The Board is expected to select the four most voted candidates to serve as trustees. This term starts in September and lasts for three years. [[Commons:File:Wikimedia_Foundation_Board_of_Trustees.webm|Learn more about the Board of Trustees in this short video]].

Vote now until August 31.

Below is some useful information about the election process.

;Learn more about the candidates
[[m:Special:MyLanguage/Wikimedia Foundation elections/2021#Candidate%20Table|Candidates from across the movement have submitted their candidatures]]. Learn about each candidate to inform your vote. The community submitted questions for the candidates to answer during the campaign. [[m:Special:MyLanguage/Wikimedia Foundation elections/2021/Candidates/CandidateQ&amp;A|Candidates answered the list of community questions]] collated by the [[m:Special:MyLanguage/Wikimedia Foundation elections committee|Elections Committee]] on Meta.

;Vote
Voting for the 2021 Board of Trustees election opened on 18 August 2021 and closes on 31 August 2021. The Elections Committee chose [[m:Special:MyLanguage/Wikimedia_Foundation_elections/Single_Transferable_Vote|Single Transferable Vote]] for the voting system. The benefit of this is voters can rank their choices in order of preference. Learn more about [[m:Special:MyLanguage/Wikimedia Foundation elections/2021/Voting#Voting_eligibility|voting requirements]], [[m:Special:MyLanguage/Wikimedia_Foundation_elections/2021/Voting|how to vote]], and [[m:Special:MyLanguage/Wikimedia_Foundation_elections/2021/Voting#Voting_FAQ|frequently asked questions about voting]].

Please help in the selection of those people who best fit the needs of the movement at this time. Vote and spread the word so more people can vote for candidates. Those selected will help guide the Wikimedia Foundation and support the needs of the movement over the next few years.

Best,

The Elections Committee
-- [[User:YKo (WMF)]] via [[利用者:MediaWiki message delivery|MediaWiki message delivery]] ([[利用者・トーク:MediaWiki message delivery|トーク]]) 2021年8月18日 (水) 04:21 (UTC)
&lt;!-- User:YKo (WMF)@metawiki が https://meta.wikimedia.org/w/index.php?title=User:YKo_(WMF)/javp&amp;oldid=21897428 のリストを使用して送信したメッセージ --&gt;

== 2021年理事会選挙 ==

↑上の英文でおそらく書かれているのでしょうが、投票権のある皆様は、投票されたでしょうか？

私は以前英語でメールもらったときは、無理無理、そもそも英語のメールなんて最後まで読まんよ&gt;&lt;、などと思ったのですが、先日日本語でメールもらいまして、じゃあせっかくだから投票しようと思って、今ログインして投票してきました。

基本的に私の人間を見る目の一つとして、「笑ってる奴は信用できん!!(^^;;)」というのがあるので、結局、パレスチナのFarahさんに投票しましたよ(^^)/。--[[利用者:Honooo|Honooo]] ([[利用者・トーク:Honooo|トーク]]) 2021年8月27日 (金) 16:14 (UTC)

== The 2022 Community Wishlist Survey will happen in January ==

&lt;div class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;en&quot; dir=&quot;ltr&quot;&gt;
Hello everyone,

We hope all of you are as well and safe as possible during these trying times! We wanted to share some news about a change to the Community Wishlist Survey 2022. We would like to hear your opinions as well.

Summary:

&lt;div style=&quot;font-style:italic;&quot;&gt;
We will be running the [[m:Special:MyLanguage/Community Wishlist Survey|Community Wishlist Survey]] 2022 in January 2022. We need more time to work on the 2021 wishes. We also need time to prepare some changes to the Wishlist 2022. In the meantime, you can use a [[m:Special:MyLanguage/Community Wishlist Survey/Sandbox|dedicated sandbox to leave early ideas for the 2022 wishes]].
&lt;/div&gt;

=== Proposing and wish-fulfillment will happen during the same year ===

In the past, the [[m:Special:MyLanguage/Community Tech|Community Tech]] team has run the Community Wishlist Survey for the following year in November of the prior year. For example, we ran the [[m:Special:MyLanguage/Community Wishlist Survey 2021|Wishlist for 2021]] in November 2020. That worked well a few years ago. At that time, we used to start working on the Wishlist soon after the results of the voting were published.

However, in 2021, there was a delay between the voting and the time when we could start working on the new wishes. Until July 2021, we were working on wishes from the [[m:Special:MyLanguage/Community Wishlist Survey 2020|Wishlist for 2020]].

We hope having the Wishlist 2022 in January 2022 will be more intuitive. This will also give us time to fulfill more wishes from the 2021 Wishlist.

=== Encouraging wider participation from historically excluded communities ===

We are thinking how to make the Wishlist easier to participate in. We want to support more translations, and encourage under-resourced communities to be more active. We would like to have some time to make these changes.

=== A new space to talk to us about priorities and wishes not granted yet ===

We will have gone 365 days without a Wishlist. We encourage you to approach us. We hope to hear from you in the [[m:Special:MyLanguage/Talk:Community Wishlist Survey|talk page]], but we also hope to see you at our bi-monthly Talk to Us meetings! These will be hosted at two different times friendly to time zones around the globe.

We will begin our first meeting '''September 15th at 23:00 UTC'''. More details about the agenda and format coming soon!

=== Brainstorm and draft proposals before the proposal phase ===

If you have early ideas for wishes, you can use the [[m:Special:MyLanguage/Community Wishlist Survey/Sandbox|new Community Wishlist Survey sandbox]]. This way, you will not forget about these before January 2022. You will be able to come back and refine your ideas. Remember, edits in the sandbox don't count as wishes!

=== Feedback ===
* What should we do to improve the Wishlist pages?
* How would you like to use our new [[m:Special:MyLanguage/Community Wishlist Survey/Sandbox|sandbox?]]
* What, if any, risks do you foresee in our decision to change the date of the Wishlist 2022?
* What will help more people participate in the Wishlist 2022?

Answer on the [[m:Special:MyLanguage/Talk:Community Wishlist Survey|talk page]] (in any language you prefer) or at our Talk to Us meetings.
&lt;/div&gt;

[[user:SGrabarczuk (WMF)|SGrabarczuk (WMF)]] ([[user talk:SGrabarczuk (WMF)|talk]]) 2021年9月7日 (火) 00:23 (UTC)
&lt;!-- User:SGrabarczuk (WMF)@metawiki が https://meta.wikimedia.org/w/index.php?title=Distribution_list/Global_message_delivery&amp;oldid=21980442 のリストを使用して送信したメッセージ --&gt;

== Participate in the Universal Code of Conduct Roundtable ==

The Movement Strategy and Governance facilitation team is hosting '''[[m:Special:MyLanguage/Universal Code of Conduct/2021_consultations/Roundtable_discussions|Roundtable discussions]] on 18 September 2021 at 03:00 UTC and 15:00 UTC''' for Wikimedians to talk together about how to enforce the [[m:Special:MyLanguage/Universal Code of Conduct|Universal Code of Conduct]] . These calls are part of the Universal Code of Conduct project Phase 2 [[m:Special:MyLanguage/Universal_Code_of_Conduct/Enforcement_draft_guidelines_review|Enforcement draft guidelines review (EDGR)]].

Each session will last for 90 to 120 minutes and translation support for various languages will be provided. Also, sessions in specific languages may also be held depending on demand. Community members are encouraged to sign up in advance and add the topic to discuss during roundtable session.

If you are not able to make the roundtable session, you can provide the comments are at [[m:Talk:Universal Code of Conduct/Enforcement draft guidelines review|the draft review talk page]] in any language, [[m:Special:PrefixIndex/Talk:Universal Code of Conduct/Enforcement draft guidelines review|talk pages of translations]], and [[m:Special:MyLanguage/Universal Code of Conduct/Discussions|local discussions]].

For more information, please visit [[m:Special:MyLanguage/Universal Code of Conduct/2021_consultations/Roundtable_discussions|roundtable discussion information page at Meta-wiki]].
--[[利用者:MediaWiki message delivery|MediaWiki message delivery]] ([[利用者・トーク:MediaWiki message delivery|トーク]]) 2021年9月10日 (金) 04:30 (UTC)
&lt;!-- User:YKo (WMF)@metawiki が https://meta.wikimedia.org/w/index.php?title=User:YKo_(WMF)/javp&amp;oldid=21897428 のリストを使用して送信したメッセージ --&gt;

== Server switch ==

&lt;div class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;ja&quot; dir=&quot;ltr&quot;&gt;&lt;div class=&quot;plainlinks&quot;&gt;

[[:m:Special:MyLanguage/Tech/Server switch|他の言語で読む]] • [https://meta.wikimedia.org/w/index.php?title=Special:Translate&amp;group=page-Tech%2FServer+switch&amp;language=&amp;action=page&amp;filter= {{int:please-translate}}]

[[foundation:|ウィキメディア財団]]ではメインと予備のデータセンターの切り替えテストを行います。 災害が起こった場合でも、ウィキペディアとその他のウィキメディア・ウィキが確実にオンラインとなるようにするための措置です。 ウィキメディアの技術部門では計画的にテストを行って、すべてが正常に動作することを確認する必要があります。今回のテストでは、あるデータセンターから他のデータセンターへ確実に切り替えられるかどうかを確かめます。そのため、多くのチームでテストや想定外の問題に対処できるよう準備を行う必要があります。 

'''2021年9月14日（火）'''にすべての通信をメインのデータセンターへ戻します。

残念ながら [[mw:Manual:What is MediaWiki?|MediaWiki]] の技術的制約により、切り替え作業中はすべての編集を停止する必要があります。 ご不便をおかけすることをお詫びするとともに、将来的にはそれが最小限にとどめられるよう努めます。 

'''閲覧は可能ですが、すべてのウィキにおいて編集ができないタイミングが短時間あります。'''

*2021年9月14日（火）には、最大1時間ほど編集できない時間が発生します。 テストは以下の時刻に開始します：[https://zonestamp.toolforge.org/1631628049 14:00 UTC]（つまり日本時間23:00、インド時間19:30、中央・東ヨーロッパ時間16:00、西ヨーロッパ・英国時間15:00、米東部時間10:00、米太平洋時間07:00。ニュージーランドでは6月15日（水）のニュージーランド時間02:00。）
*この間に編集や保存を行おうとした場合、エラーメッセージが表示されます。 その間に行われた編集が失われないようには努めますが、保証することはできません。 エラーメッセージが表示された場合、通常状態に復帰するまでお待ちください。 その後、編集の保存が可能となっているはずです。 しかし念のため、保存ボタンを押す前に、行った変更のコピーをとっておくことをお勧めします。

''その他の影響'':

*バックグラウンドジョブが遅くなり、場合によっては失われることもあります。 赤リンクの更新が通常時よりも遅くなる場合があります。 特に他のページからリンクされているページを作成した場合、そのページは通常よりも「赤リンク」状態が長くなる場合があります。 長時間にわたって実行されるスクリプトは、停止しなければなりません。
* コードの実装は通常の週と同様に行う見込みです。 しかしながら、作業上の必要性に合わせ、ケースバイケースでいずれかのコードフリーズが計画時間に発生することもあります。

必要に応じてこの計画は延期されることがあります。  [[wikitech:Switch_Datacenter|wikitech.wikimedia.org で工程表を見る]]ことができます。 変更はすべて工程表で発表しますので、ご参照ください。 この件に関しては今後、さらにお知らせを掲示するかもしれません。 作業開始の30分前から、すべてのウィキで画面にバナーを表示する予定です。 '''この情報を皆さんのコミュニティで共有してください。'''&lt;/div&gt;&lt;/div&gt; [[user:SGrabarczuk (WMF)|SGrabarczuk (WMF)]] ([[user talk:SGrabarczuk (WMF)|&lt;span class=&quot;signature-talk&quot;&gt;{{int:Talkpagelinktext}}&lt;/span&gt;]]) 2021年9月11日 (土) 00:45 (UTC)
&lt;!-- User:SGrabarczuk (WMF)@metawiki が https://meta.wikimedia.org/w/index.php?title=Distribution_list/Global_message_delivery&amp;oldid=21980442 のリストを使用して送信したメッセージ --&gt;

== Talk to the Community Tech ==

[[File:Magic Wand Icon 229981 Color Flipped.svg|{{dir|{{pagelang}}|left|right}}|frameless|50px]]

[[:m:Special:MyLanguage/Community Wishlist Survey/Updates/2021-09 Talk to Us|Read this message in another language]] • [https://meta.wikimedia.org/w/index.php?title=Special:Translate&amp;group=page-Community_Wishlist_Survey/Updates/2021-09_Talk_to_Us&amp;language=&amp;action=page&amp;filter= {{int:please-translate}}]

Hello!

As we have [[m:Special:MyLanguage/Community Wishlist Survey/Updates|recently announced]], we, the team working on the [[m:Special:MyLanguage/Community Wishlist Survey|Community Wishlist Survey]], would like to invite you to an online meeting with us. It will take place on [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20210915T2300 '''September 15th, 23:00 UTC'''] on Zoom, and will last an hour. [https://wikimedia.zoom.us/j/89828615390 '''Click here to join'''].

'''Agenda'''

* [[m:Special:MyLanguage/Community Wishlist Survey 2021/Status report 1#Prioritization Process|How we prioritize the wishes to be granted]]
* [[m:Special:MyLanguage/Community Wishlist Survey/Updates|Why we decided to change the date]] from November 2021 to January 2022
* Update on the [[m:Special:MyLanguage/Community Wishlist Survey 2021/Warn when linking to disambiguation pages|disambiguation]] and the [[m:Special:MyLanguage/Community Wishlist Survey 2021/Real Time Preview for Wikitext|real-time preview]] wishes
* Questions and answers

'''Format'''

The meeting will not be recorded or streamed. Notes without attribution will be taken and published on Meta-Wiki. The presentation (first three points in the agenda) will be given in English.

We can answer questions asked in English, French, Polish, and Spanish. If you would like to ask questions in advance, add them [[m:Talk:Community Wishlist Survey|on the Community Wishlist Survey talk page]] or send to sgrabarczuk@wikimedia.org.

[[m:Special:MyLanguage/User:NRodriguez (WMF)|Natalia Rodriguez]] (the [[m:Special:MyLanguage/Community Tech|Community Tech]] manager) will be hosting this meeting.

'''Invitation link'''

* [https://wikimedia.zoom.us/j/89828615390 Join online]
* Meeting ID: 898 2861 5390
* One tap mobile
** +16465588656,,89828615390# US (New York)
** +16699006833,,89828615390# US (San Jose)
* [https://wikimedia.zoom.us/u/kctR45AI8o Dial by your location]

See you! [[User:SGrabarczuk (WMF)|SGrabarczuk (WMF)]] ([[User talk:SGrabarczuk (WMF)|&lt;span class=&quot;signature-talk&quot;&gt;{{int:Talkpagelinktext}}&lt;/span&gt;]]) 2021年9月11日 (土) 03:03 (UTC)
&lt;!-- User:SGrabarczuk (WMF)@metawiki が https://meta.wikimedia.org/w/index.php?title=Distribution_list/Global_message_delivery&amp;oldid=21980442 のリストを使用して送信したメッセージ --&gt;

== 指導要領の改訂にともなうWikibooks ==

高等学校(や中学校)のWikibooksの教科書の大半は旧課程(2003年度実施)をもとに構成されていますが、現行課程(2013年度実施)や、新課程(来年度の2022年度から実施)に対応した教科書の作成は進んでいません。内容の移行はありますが、教える事自体はあまり変わらないので、旧課程のWikibooksの教科書を再利用して作成することが現実的かと思いますが、その場合、移行作業は具体的にどのように行うのでしょうか。--[[利用者:Nermer314|Nermer314]] ([[利用者・トーク:Nermer314|トーク]]) 2021年9月17日 (金) 15:56 (UTC)
:現行課程や新課程の枠組みに変更がないならば、特に断ることなく、そのまま上書きしてもらって良いかと思います。編集合戦等が生じた場合は、基本的に新たな課程の記載が優先されることとなるでしょう。しかしながら、既存の記事については参考として残してもいいかもしれません（大部になる場合はサブページ化するなど）。改定で削った内容について、改定後の考え方などを応用し出題することはよくあることなので。--[[利用者:Tomzo|Tomzo]] ([[利用者・トーク:Tomzo|トーク]]) 2021年9月17日 (金) 18:15 (UTC)
:この件は私も以前から興味があるというか、問題意識を持っていまして、何度か議論提起をさせていただいています。が、あまりリプライがつかず議論が盛り上がらなかったり、反応をいただけた際も私の根気のなさもあり結局話をまとめられずにグダグダで終わってしまったりで、そのままここまで来てしまっています。力不足で申し訳ありません。直近で提起した議論は [[トーク:高等学校の学習/旧課程#旧課程教科書の今後の在り方について]] でして、ここでも結局私がほったらかしてしまったのですが、その中でこれまでの経緯のまとめと先行議論へのリンクをつけてありますので、ご参考にしていただければ幸いです。簡単に申し上げると、私個人としてはどんどん新課程に衣替えして加筆していくのが望ましいと考えるのですが、旧課程教科書の保存や加筆（個人的にはかなり疑問符なのですが）がなされるべきであるとされる方は案外いらっしゃるので、そのあたりきちんと調整しながら進める必要があるようです。私はそこまでの根気がなく、投げ出してしまっています。--[[利用者:K.ito|K.ito]] ([[利用者・トーク:K.ito|トーク]]) 2021年9月18日 (土) 06:22 (UTC)
:旧課程と新課程で内容が移行される場合、例えば、旧課程の数学IIの「いろいろな関数」は現行課程と新課程では「三角関数」と「指数関数・対数関数」に分かれていますが、この場合は、 高等学校数学II/ のサブページにそれぞれ作成するのが適切でしょうか？また元の「いろいろな関数」のページはどうするのが適切でしょうか？元のページを消してしまうと履歴の継承が行われなくなってしまうと思います。またベクトルは内容には変化はなく、現行課程では数学Bで、新課程では数学Cで教えられますが、この場合は、(現行課程の学生が卒業する2023年度までは)どちらのサブページに設置するのが適切ですか？ [[利用者:Nermer314|Nermer314]] ([[利用者・トーク:Nermer314|トーク]]) 2021年9月20日 (月) 14:23 (UTC)

== Movement Charter Drafting Committee - Community Elections to take place October 11 - 24 ==

&lt;section begin=&quot;announcementcontent&quot;/&gt;Dear fellow Wikimedians,

This is an update from the Movement Charter process. We have closed the call for candidates on September 14 for the Drafting Committee and now have a pool of candidates with diverse backgrounds to choose from.

The 15 member committee will be selected with a [[m:Special:MyLanguage/Movement Charter/Drafting Committee/Set Up Process|3-step process]]:
* Election process for project communities to elect 7 members of the committee.
* Selection process for affiliates to select 6 members of the committee.
* Wikimedia Foundation process to appoint 2 members of the committee.

;Communities elect 7 members: This announcement is related to the community elections, which will take place in a time period of 2 weeks from October 11 to October 24. We look forward to a wide participation across the communities to create the committee to curate the writing of the Movement Charter. The Election Results will be published on November 1.

;Affiliates select 6 members: Parallel to the election process, all affiliates asked to contribute as well: All affiliates were divided into eight geographic and one ‘thematic’ region (check the list), and each region chooses one person who will act as a selector for that region. These 9 selectors will come together to select 6 of the committee (from the same pool of candidates). The selection results will be published on November 1.

; Wikimedia Foundation appoints 2 members: Finally, the Wikimedia Foundation will appoint two members to the committee by November 1.

All three processes will be concluded by November 1, 2021, so that the Movement Charter Drafting Committee can start working by then. 

For the full context of the Movement Charter, its role, as well the process for its creation, please [[:m:Special:MyLanguage/Movement Charter|have a look at Meta]]. You can also contact us at any time on Telegram or via email (wikimedia2030@wikimedia.org). 

Best regards,&lt;section end=announcementcontent/&gt;--[[利用者:MediaWiki message delivery|MediaWiki message delivery]] ([[利用者・トーク:MediaWiki message delivery|トーク]]) 2021年9月22日 (水) 02:31 (UTC)
&lt;!-- User:YKo (WMF)@metawiki が https://meta.wikimedia.org/w/index.php?title=User:YKo_(WMF)/javp&amp;oldid=21897428 のリストを使用して送信したメッセージ --&gt;

== デスクトップ版の改善について協議 ==

[[File:Annotated Wikipedia Vector interface (logged-out).png|thumb]]
こんにちは！

実はウィキによって[[mw:Special:MyLanguage/Reading/Web/Desktop Improvements|デスクトップ版のインターフェースが異なる]]と気づいていましたか？ 次にどう変わるか、関心は？ 設計や技術面で、もしかして質問したいことや提案がありませんか？

デスクトップの改良に取り組むチームと、オンラインのミーティングの参加者を募集中です。開催日時は[https://www.timeanddate.com/worldclock/fixedtime.html?iso=20211012T1600 10月12日16:00 UTC]、Zoomで実施します。1時間の予定です。'''[https://wikimedia.zoom.us/j/82936701376 参加登録はこちら]'''。

'''議題'''
* 直近の開発について報告
* [[mw:Special:MyLanguage/Reading/Web/Desktop Improvements/Features/Sticky Header|常駐ヘッダー]] - デモ版の発表
* 質疑応答、協議
'''方式'''

ミーティングは録画や生配信をしません。議事録は[https://docs.google.com/document/d/1G4tfss-JBVxyZMxGlOj5MCBhOO-0sLekquFoa2XiQb8/edit# Google ドキュメント ファイル]で記す予定です。発表の部分 (議題の1と2) は英語で行います。

質疑応答は英語、フランス語、ポーランド語、スペイン語で質問を受け付けます。 事前に質問を伝えるには、[[mw:Talk:Reading/Web/Desktop Improvements|トークページに投稿]]またはメールでsgrabarczuk@wikimedia.org まで送信してください。

ミーティングの主催者は[[user:OVasileva (WMF)|Olga Vasileva]] (オルガ・バシレバ、チーム管理者) です。

'''参加募集のリンク'''
* [https://wikimedia.zoom.us/j/82936701376 オンラインで参加]
* 会議 ID: &lt;span dir=ltr&gt;829 3670 1376&lt;/span&gt;
* [https://wikimedia.zoom.us/u/kB5WUc7yZ 所在地別のフリーダイヤル番号]
では当日、お待ちしています！ [[User:SGrabarczuk (WMF)|SGrabarczuk (WMF)]] ([[User talk:SGrabarczuk (WMF)|talk]]) 2021年10月5日 (火) 02:12 (UTC)
&lt;!-- User:SGrabarczuk (WMF)@metawiki が https://meta.wikimedia.org/w/index.php?title=User:SGrabarczuk_(WMF)/sandbox/MM/Varia&amp;oldid=22122242 のリストを使用して送信したメッセージ --&gt;

== Universal Code of Conduct Draft Enforcement Guidelines review still needs your ideas and opinions ==

Hello, this is just a reminder that the [[:m:Special:MyLanguage/Universal Code of Conduct/Enforcement draft guidelines review|Universal Code of Conduct Draft Enforcement Guidelines]] are open for review and comment.  The Drafting Committee will start working on revisions and improvement in '''less than two weeks (October 17)''', so it is important that you give them your ideas and opinions soon!

There is now [[m:Special:MyLanguage/Universal Code of Conduct/Enforcement draft guidelines review/Abstract|a short, simple version of the Draft Guidelines]] here to make your review easier. If possible, also help translate the short version into more languages!

We will also hold [[m:Special:MyLanguage/Universal_Code_of_Conduct/2021_consultations/Roundtable_discussions|one last conversation hour]] on October 15, 2021 03:00 and 14:00 UTC.

On behalf of the [[m:Universal_Code_of_Conduct/Drafting_committee#Phase_2|Drafting Committee]], much thanks to everyone who has given ideas so far.  We hope to hear from more of you - the Guidelines will be much stronger if more opinions are included.
&lt;!-- User:YKo (WMF)@metawiki が https://meta.wikimedia.org/w/index.php?title=User:YKo_(WMF)/javp&amp;oldid=21897428 のリストを使用して送信したメッセージ --&gt;

== The Community election of Movement Charter Drafting committee is now open! ==

Voting for the election for the members for the Movement Charter drafting committee is now open. In total, 70 Wikimedians from around the world are running for 7 seats in these elections.

'''Voting is open from October 12 to October 24, 2021.'''

The committee will consist of 15 members in total: The online communities vote for 7 members, 6 members will be selected by the Wikimedia affiliates through a parallel process, and 2 members will be appointed by the Wikimedia Foundation. The plan is to assemble the committee by November 1, 2021.

Learn about each candidate to inform your vote in the language that you prefer: &lt;https://meta.wikimedia.org/wiki/Special:MyLanguage/Movement_Charter/Drafting_Committee/Candidates&gt;

Learn about the Drafting Committee: &lt;https://meta.wikimedia.org/wiki/Special:MyLanguage/Movement_Charter/Drafting_Committee&gt;

We are piloting a voting advice application for this election. Click yourself through the tool and you will see which candidate is closest to you! Check at &lt;https://mcdc-election-compass.toolforge.org/&gt;

Read the full announcement: &lt;https://meta.wikimedia.org/wiki/Special:MyLanguage/Movement_Charter/Drafting_Committee/Elections&gt;

'''Go vote at SecurePoll on:''' &lt;https://meta.wikimedia.org/wiki/Special:MyLanguage/Movement_Charter/Drafting_Committee/Elections&gt;

Best,
--[[利用者:MediaWiki message delivery|MediaWiki message delivery]] ([[利用者・トーク:MediaWiki message delivery|トーク]]) 2021年10月13日 (水) 06:54 (UTC)
&lt;!-- User:YKo (WMF)@metawiki が https://meta.wikimedia.org/w/index.php?title=User:YKo_(WMF)/jazh&amp;oldid=22182674 のリストを使用して送信したメッセージ --&gt;

== 運動戦略実施助成金が運動戦略計画をどのように支援するかを学ぶ ==

&lt;section begin=&quot;announcement-content&quot;/&gt;運動戦略実施助成金は現在、運動戦略計画を実行に移すために2,000ドル以上を提供しています。詳細は[[:m:Special:MyLanguage/Grants:MSIG/About|運動戦略実施助成金の条件および応募方法]]についてを参照してください。&lt;section end=&quot;annoumcent-content&quot;/&gt;

[[利用者:MNadzikiewicz (WMF)|MNadzikiewicz (WMF)]] ([[利用者・トーク:MNadzikiewicz (WMF)|トーク]]) 2021年10月24日 (日) 09:09 (UTC)

== Meet the new Movement Charter Drafting Committee members ==

:''&lt;div class=&quot;plainlinks&quot;&gt;[[m:Special:MyLanguage/Movement Charter/Drafting Committee/Elections/Results/Announcement|{{int:interlanguage-link-mul}}]] • [https://meta.wikimedia.org/w/index.php?title=Special:Translate&amp;group=page-{{urlencode:Movement Charter/Drafting Committee/Elections/Results/Announcement}}&amp;language=&amp;action=page&amp;filter= {{int:please-translate}}]&lt;/div&gt;''
The Movement Charter Drafting Committee election and selection processes are complete.
* The [[m:Special:MyLanguage/Movement Charter/Drafting Committee/Elections/Results|election results have been published]]. 1018 participants voted to elect seven members to the committee: '''[[m:Special:MyLanguage/Movement Charter/Drafting Committee/Candidates#Richard_Knipel_(Pharos)|Richard Knipel (Pharos)]]''', '''[[m:Special:MyLanguage/Movement Charter/Drafting Committee/Candidates#Anne_Clin_(Risker)|Anne Clin (Risker)]]''', '''[[m:Special:MyLanguage/Movement Charter/Drafting Committee/Candidates#Alice_Wiegand_(lyzzy)|Alice Wiegand (Lyzzy)]]''', '''[[m:Special:MyLanguage/Movement Charter/Drafting Committee/Candidates#Micha%C5%82_Buczy%C5%84ski_(Aegis_Maelstrom)|Michał Buczyński (Aegis Maelstrom)]]''', '''[[m:Special:MyLanguage/Movement Charter/Drafting Committee/Candidates#Richard_(Nosebagbear)|Richard (Nosebagbear)]]''', '''[[m:Special:MyLanguage/Movement Charter/Drafting Committee/Candidates#Ravan_J_Al-Taie_(Ravan)|Ravan J Al-Taie (Ravan)]]''', '''[[m:Special:MyLanguage/Movement Charter/Drafting Committee/Candidates#Ciell_(Ciell)|Ciell (Ciell)]]'''.
* The [[m:Special:MyLanguage/Movement_Charter/Drafting_Committee/Candidates#Affiliate-chosen_members|affiliate process]] has selected six members: '''[[m:Special:MyLanguage/Movement Charter/Drafting Committee/Candidates#Anass_Sedrati_(Anass_Sedrati)|Anass Sedrati (Anass Sedrati)]]''', '''[[m:Special:MyLanguage/Movement Charter/Drafting Committee/Candidates#%C3%89rica_Azzellini_(EricaAzzellini)|Érica Azzellini (EricaAzzellini)]]''', '''[[m:Special:MyLanguage/Movement Charter/Drafting Committee/Candidates#Jamie_Li-Yun_Lin_(Li-Yun_Lin)|Jamie Li-Yun Lin (Li-Yun Lin)]]''', '''[[m:Special:MyLanguage/Movement Charter/Drafting Committee/Candidates#Georges_Fodouop_(Geugeor)|Georges Fodouop (Geugeor)]]''', '''[[m:Special:MyLanguage/Movement Charter/Drafting Committee/Candidates#Manavpreet_Kaur_(Manavpreet_Kaur)|Manavpreet Kaur (Manavpreet Kaur)]]''', '''[[m:Special:MyLanguage/Movement Charter/Drafting Committee/Candidates#Pepe_Flores_(Padaguan)|Pepe Flores (Padaguan)]]'''.
* The Wikimedia Foundation has [[m:Special:MyLanguage/Movement_Charter/Drafting_Committee/Candidates#Wikimedia_Foundation-chosen_members|appointed]] two members: '''[[m:Special:MyLanguage/Movement_Charter/Drafting_Committee/Candidates#Runa_Bhattacharjee_(Runab_WMF)|Runa Bhattacharjee (Runab WMF)]]''', '''[[m:Special:MyLanguage/Movement_Charter/Drafting_Committee/Candidates#Jorge_Vargas_(JVargas_(WMF))|Jorge Vargas (JVargas (WMF))]]'''.

The committee will convene soon to start its work. The committee can appoint up to three more members to bridge diversity and expertise gaps.

If you are interested in engaging with [[m:Special:MyLanguage/Movement Charter|Movement Charter]] drafting process, follow the updates [[m:Special:MyLanguage/Movement Charter/Drafting Committee|on Meta]] and join the [https://t.me/joinchat/U-4hhWtndBjhzmSf Telegram group].

With thanks from the Movement Strategy and Governance team--[[利用者:MediaWiki message delivery|MediaWiki message delivery]] ([[利用者・トーク:MediaWiki message delivery|トーク]]) 2021年11月2日 (火) 04:42 (UTC)
&lt;!-- User:YKo (WMF)@metawiki が https://meta.wikimedia.org/w/index.php?title=User:YKo_(WMF)/javp&amp;oldid=21897428 のリストを使用して送信したメッセージ --&gt;

== コミュニティ技術との対話を ==

[[File:Magic Wand Icon 229981 Color Flipped.svg|100px|right]]
{{int:Hello}}

[[m:Special:MyLanguage/Community Wishlist Survey|コミュニティ要望アンケート]]の担当チーム一同より、皆さんをオンライン会議にお誘いします。期日は[https://www.timeanddate.com/worldclock/fixedtime.html?iso=20211130T1700 '''{{#time:j xg|2021-11-30}} ({{#time:l|2021-11-30}})、{{#time:H:i e|17:00|ja|1}}''']、Zoom, を使用し1時間にわたる予定です。[https://wikimedia.zoom.us/j/82035401393 '''参加申し込みはこちら''']。

'''議題'''

* コミュニティ要望アンケート2022が変わります。決定にご助力をお願いします。
* コミュニティ要望アンケート (CWS) の大使になりませんか。皆さんのコミュニティで、CWS に関する情報発信をしてください。
* 質疑応答

'''方式'''

ミーティングは録画せず、ストリーム配信もしません。発言者名をつけない記録は取り、メタウィキにて公表の予定です。プレゼンテーション (質疑応答を除く議題の全内容) は英語で行います。

ご質問は英語、フランス語、ポーランド語、スペイン語、ドイツ語、イタリア語でお答えできます。事前に質問をお寄せいただくには、[[m:Talk:Community Wishlist Survey|コミュニティ要望アンケート のトークページ]]に投稿、もしくはメールにて sgrabarczuk@wikimedia.org宛にお送り願います。

ミーティングの主催は[[m:Special:MyLanguage/User:NRodriguez (WMF)|Natalia Rodriguez]] ([[m:Special:MyLanguage/Community Tech|コミュニティ技術]]部長) の予定です。

'''参加募集のリンク'''

* [https://wikimedia.zoom.us/j/82035401393 オンラインで参加]
* 会議 ID: &lt;span dir=ltr&gt;82035401393&lt;/span&gt;
* [https://wikimedia.zoom.us/u/keu6UeRT0T 所在地別のフリーダイヤル番号]
では当日、お待ちしています！ [[User:SGrabarczuk (WMF)|SGrabarczuk (WMF)]] ([[User talk:SGrabarczuk (WMF)|会話]]) 2021年11月27日 (土) 00:41 (UTC)
&lt;!-- User:SGrabarczuk (WMF)@metawiki が https://meta.wikimedia.org/w/index.php?title=User:SGrabarczuk_(WMF)/sandbox/MM/Other_TOP20/ja&amp;oldid=22381336 のリストを使用して送信したメッセージ --&gt;

== ウィキメディア財団理事会/ご意見募集：2022年理事会選挙/理事会選挙に関するご意見募集のご案内 ==

 理事会選挙に関するご意見募集の予告 
&lt;section begin=&quot;announcement-content /&gt;
:''このメッセージはMeta-wikiで他の言語に翻訳されています。''
:''&lt;div class=&quot;plainlinks&quot;&gt;[[m:Special:MyLanguage/Wikimedia Foundation Board of Trustees/Call for feedback:2022 Board of Trustees election/Upcoming Call for Feedback about the Board of Trustees elections|{{int:interlanguage-link-mul}}]] • [https://meta.wikimedia.org/w/index.php?title=Special:Translate&amp;group=page-{{urlencode:Wikimedia Foundation Board of Trustees/Call for feedback:2022 Board of Trustees election/Upcoming Call for Feedback about the Board of Trustees elections}}&amp;language=&amp;action=page&amp;filter= {{int:please-translate}}]&lt;/div&gt;''

理事会は、2022年1月7日から2月10日まで行われる理事会選挙について、ご意見を募る準備をしています。

詳細は募集の前週に決定されますが、今回の募集では少なくとも2つの質問が確定していますので、ご意見をお願いします。

* 新興コミュニティから公平に理事会に代表を送るには、どのような方法がありますか？

* 候補者は、選挙期間にどのように（コミュニティと）かかわるべきでしょうか？

質問は追加される可能性がありますが、運動戦略・ガバナンス（組織統治）チームでは募集の開始前に確定した設問をお伝えすることで、コミュニティや提携団体の皆さんに事前に読んでアイデアを準備していただく時間を設けたいと考えました。現時点で設問の一覧が完全でないことをお詫びいたします。今後、増えるのは1問または2問だけの見込みです。コミュニティの皆さんにご負担にならないよう、意義のある設問を事前にお知らせしておき、ぜひご意見をいただけないかと考えます。

'''この募集の期間中、地域での対話のまとめ役を引き受けていただける方はおられませんか？'''

Meta (メタ)、[https://t.me/wmboardgovernancechat Telegram] (テレグラムのチャット)、またはメール（msg[[File:At sign.svg|16x16px|link=|(_AT_)]]wikimedia.org）で[[m:Special:MyLanguage/Movement Strategy and Governance|運動戦略とガバナンス（組織統治）チーム]]にご連絡ください。

ご質問やご不明な点がございましたら、お気軽にお問い合わせください。運動戦略とガバナンス（組織統治）チームは、1月3日まで最小限の人員で運営されます。この期間中は、対応が遅れますことをご了承ください。また、コミュニティや提携団体の皆さんには、12月の連休中はオフラインにしておられることも承知しています。せっかくの休暇中に私たちがメッセージをお送りしてしまった節には、たいへん失礼しました。

草々

運動戦略とガバナンス（組織統治）チーム一同&lt;section end=&quot;announcement-content&quot; /&gt;--[[利用者:YShibata (WMF)|YShibata (WMF)]] ([[利用者・トーク:YShibata (WMF)|トーク]]) 2021年12月28日 (火) 10:19 (UTC)

== Webで起きていること ==

あのー私はこういうことについてはほとんど知らないし，情報も持っていないのですが，でもツイッターなんかの発言では時々見るんだけど，なんか，Web上ではあらゆるところで，特定の政治立場や経済利益を手に入れるために，お金をもらって，その勢力に都合いい記述を書きまくっている人物がいるようですね。私自身は完全に趣味で，遊びで，もちろんこういうサイトですからそれなりに公益や学問的な確かさを考慮して書きますが，そうじゃない，馬鹿ばかしい邪念と金のために書いている奴がかなりいるらしいって聞いたことがあるけど…。その辺どうでしょうかね？皆さんはどう思います？--[[利用者:Honooo|Honooo]] ([[利用者・トーク:Honooo|トーク]]) 2022年1月7日 (金) 17:30 (UTC)

== Wiki Loves Folklore is back! ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; class=&quot;mw-content-ltr&quot;&gt;

{{int:please-translate}}

[[File:Wiki Loves Folklore Logo.svg|right|150px|frameless]]
You are humbly invited to participate in the '''[[:c:Commons:Wiki Loves Folklore 2022|Wiki Loves Folklore 2022]]''' an international photography contest organized on Wikimedia Commons to document folklore and intangible cultural heritage from different regions, including, folk creative activities and many more. It is held every year from the '''1st till the 28th''' of February.

You can help in enriching the folklore documentation on Commons from your region by taking photos, audios, videos, and [https://commons.wikimedia.org/w/index.php?title=Special:UploadWizard&amp;campaign=wlf_2022 submitting] them in this commons contest.

You can also [[:c:Commons:Wiki Loves Folklore 2022/Organize|organize a local contest]] in your country and support us in translating the [[:c:Commons:Wiki Loves Folklore 2022/Translations|project pages]] to help us spread the word in your native language.

Feel free to contact us on our [[:c:Commons talk:Wiki Loves Folklore 2022|project Talk page]] if you need any assistance. 

'''Kind regards,'''

'''Wiki loves Folklore International Team'''

--[[利用者:MediaWiki message delivery|MediaWiki message delivery]] ([[利用者・トーク:MediaWiki message delivery|トーク]]) 2022年1月9日 (日) 13:15 (UTC)
&lt;/div&gt;
&lt;!-- User:Tiven2240@metawiki が https://meta.wikimedia.org/w/index.php?title=User:Tiven2240/wlf&amp;oldid=22560402 のリストを使用して送信したメッセージ --&gt;

== 2022年コミュニティ要望アンケート ==

[[File:Community Wishlist Survey Lamp.svg|right|200px]]
'''[[m:Special:MyLanguage/Community Wishlist Survey 2022|2022年コミュニティ要望アンケート]]'''が始まりました！'''

この調査はコミュニティによって[[m:Special:MyLanguage/Community Tech|コミュニティ技術]]チームが来年度に取り組む課題を決めるプロセスです。〆切の'''1月23日'''までに提案を行うか、他の提案内容について改善のためのコメントを行ってください。 

提案に対する投票期間は1月28日から2月11日までです。

コミュニティ技術チームは経験を積んだウィキメディア編集者向けツールの開発に専念します。 提案は何語で書いても問題ありません。こちらで皆さんに代わって翻訳します。投稿をお待ちしていますので、どうぞよろしくお願いします！ [[User:SGrabarczuk (WMF)|SGrabarczuk (WMF)]] ([[User talk:SGrabarczuk (WMF)|talk]]) 2022年1月10日 (月) 19:05 (UTC)
&lt;!-- User:SGrabarczuk (WMF)@metawiki が https://meta.wikimedia.org/w/index.php?title=User:SGrabarczuk_(WMF)/sandbox/MM/Other_TOP20/ja&amp;oldid=22381336 のリストを使用して送信したメッセージ --&gt;

== 理事会選挙に関するご意見募集が始まりました  ==

&lt;section begin=&quot;announcement-content&quot; /&gt;:''[[m:Special:MyLanguage/Wikimedia Foundation Board of Trustees/Call for feedback: Board of Trustees elections/Call for Feedback about the Board of Trustees elections is now open/Short|Meta-wikiで他の言語にも翻訳されています。]]''
:''&lt;div class=&quot;plainlinks&quot;&gt;[[m:Special:MyLanguage/Wikimedia Foundation Board of Trustees/Call for feedback: Board of Trustees elections/Call for Feedback about the Board of Trustees elections is now open/Short|{{int:interlanguage-link-mul}}]] • [https://meta.wikimedia.org/w/index.php?title=Special:Translate&amp;group=page-{{urlencode:Wikimedia Foundation Board of Trustees/Call for feedback: Board of Trustees elections/Call for Feedback about the Board of Trustees elections is now open/Short}}&amp;language=&amp;action=page&amp;filter= {{int:please-translate}}]&lt;/div&gt;''

ご意見募集: 理事会選挙2022年2月7日まで募集をしています。 

このご意見募集で、運動戦略と組織統治チームは、これまでと異なる手法を取ることにしました。2021年の経緯について、コミュニティから学ぶのです。こちらから提案をするのではありません。理事会から提示された２点の質問を軸にしています。2021年に理事会選挙が行われました。皆さんの意見をもとに、次の選挙を進めていく予定です。

[[m:Special:MyLanguage/Wikimedia Foundation Board of Trustees/Call for feedback: Board of Trustees elections|対話に参加する]]

敬具

運動戦略と組織統治&lt;section end=&quot;announcement-content/&gt;

&lt;languages/&gt;
== 運動戦略と組織統治ニュース – 記事 5 ==

&lt;section begin=&quot;ucoc-newsletter&quot;/&gt;
&lt;div style = &quot;line-height: 1.2&quot;&gt;
&lt;span style=&quot;font-size:200%;&quot;&gt;'''運動戦略と組織統治ニュース'''&lt;/span&gt;&lt;br&gt;
&lt;span style=&quot;font-size:120%; color:#404040;&quot;&gt;'''記事　5 - 2022年1月'''&lt;/span&gt;&lt;span style=&quot;font-size:120%; float:right;&quot;&gt;[[m:Special:MyLanguage/Movement Strategy and Governance/Newsletter/5|'''ニュースレター全文はこちら''']]&lt;/span&gt;
----
運動戦略と組織統治ニュース（旧称：ユニバーサル行動規範ニュース）第5号へようこそ! この刷新されたニュースレターでは、運動憲章、ユニバーサル行動規範、運動戦略実施のための助成金、理事会選挙、その他MSGに関連するニュースやイベントをお知らせしています。

このニュースレターは四半期ごとに配信されますが、より頻度の高いアップデートは、毎週または隔週で配信される予定です。配信を希望される方は、[[:m:Special:MyLanguage/Global message delivery/Targets/MSG Newsletter Subscription|こちら]]を忘れずにご登録ください。
&lt;/div&gt;&lt;div style=&quot;margin-top:3px; padding:10px 10px 10px 20px; background:#fffff; border:2px solid #808080; border-radius:4px; font-size:100%;&quot;&gt;

*'''理事選挙に関するご意見募集''' - 次回のウィキメディア財団WMF理事選挙に関するご意見を募集しています。このご意見募集は2022年1月10日に公開され、2022年2月7日に締め切られる予定です。([[:m:Special:MyLanguage/Movement Strategy and Governance/Newsletter/5#Call for Feedback about the Board elections|続きを読む]])
*'''ユニバーサル行動規範の批准''' - 2021年、WMFはユニバーサル行動規範の方針文の施行方法についてコミュニティに質問しました。執行ガイドラインの改訂草案は、3月コミュニティの投票に間に合うはずです。([[:m:Special:MyLanguage/Movement Strategy and Governance/Newsletter/5#Universal Code of Conduct Ratification|続きを読む]])
*'''運動戦略実施のための助成金'''-興味深い提案の審査を続ける中で、運動戦略の提言から特定のイニシアチブをターゲットにした提案やアイデアをより奨励し、歓迎します。([[:m:Special:MyLanguage/Movement Strategy and Governance/Newsletter/5#Movement Strategy Implementation Grants|続きを読む]])
*'''ニュースレターの新しい方向性''' - UCoCニュースレターがMSGニュースレターに移行するにあたり、ファシリテーションチームと共に、このニュースレターの新しい方向性を思い描き、決めていきます。([[:m:Special:MyLanguage/Movement Strategy and Governance/Newsletter/5#The New Direction for the Newsletter|続きを読む]])
*'''Diff Blogs'' - MSGに関する最新の出版物をウィキメディア・ディフでチェックしましょう。([[:m:Special:MyLanguage/Movement Strategy and Governance/Newsletter/5#Diff Blogs|続きを読む]])&lt;/div&gt;&lt;section end=&quot;ucoc-newsletter&quot;/&gt;

== Subscribe to the This Month in Education newsletter - learn from others and share your stories ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; class=&quot;mw-content-ltr&quot;&gt;
Dear community members, 

Greetings from the EWOC Newsletter team and the education team at Wikimedia Foundation. We are very excited to share that we on tenth years of Education Newsletter ([[m:Education/News|This Month in Education]]) invite you to join us by [[m:Global message delivery/Targets/This Month in Education|subscribing to the newsletter on your talk page]] or by [[m:Education/News/Newsroom|sharing your activities in the upcoming newsletters]]. The Wikimedia Education newsletter is a monthly newsletter that collects articles written by community members using Wikimedia projects in education around the world, and it is published by the EWOC Newsletter team in collaboration with the Education team. These stories can bring you new ideas to try, valuable insights about the success and challenges of our community members in running education programs in their context. 

If your affiliate/language project is developing its own education initiatives, please remember to take advantage of this newsletter to publish your stories with the wider movement that shares your passion for education. You can submit newsletter articles in your own language or submit bilingual articles for the education newsletter. For the month of January the deadline to submit articles is on the 20th January. We look forward to reading your stories.

Older versions of this newsletter can be found in the [[outreach:Education/Newsletter/Archives|complete archive]].

More information about the newsletter can be found at [[m:Education/News/Publication Guidelines|Education/Newsletter/About]].

For more information, please contact spatnaik{{@}}wikimedia.org.
------
&lt;div style=&quot;text-align: center;&quot;&gt;&lt;div style=&quot;margin-top:10px; font-size:90%; padding-left:5px; font-family:Georgia, Palatino, Palatino Linotype, Times, Times New Roman, serif;&quot;&gt;[[m:Education/Newsletter/About|About ''This Month in Education'']] · [[m:Global message delivery/Targets/This Month in Education|Subscribe/Unsubscribe]] · [[m:MassMessage|Global message delivery]] · For the team: [[User:ZI Jony|&lt;span style=&quot;color:#8B0000&quot;&gt;'''ZI Jony'''&lt;/span&gt;]] [[User talk:ZI Jony|&lt;sup&gt;&lt;span style=&quot;color:Green&quot;&gt;&lt;i&gt;(Talk)&lt;/i&gt;&lt;/span&gt;&lt;/sup&gt;]], {{&lt;includeonly&gt;subst:&lt;/includeonly&gt;#time:l G:i, d F Y|}} (UTC)&lt;/div&gt;&lt;/div&gt;
&lt;/div&gt;
&lt;!-- User:ZI Jony@metawiki が https://meta.wikimedia.org/w/index.php?title=User:ZI_Jony/MassMessage/Awareness_of_Education_Newsletter/List_of_Village_Pumps&amp;oldid=21244129 のリストを使用して送信したメッセージ --&gt;

== 理事会選挙ボランティア募集のお知らせ ==

今年の理事会選挙でボランティアをしませんか？
:することは、以下の３つのうちの一つでも結構です。
# 夏に行われる理事会選挙を日本語コミュニティの中ですすめる
# 理事会選挙についての対話を実行する
# 理事会選挙についての翻訳
:興味のある方は[https://ja.wikipedia.org/wiki/%E5%88%A9%E7%94%A8%E8%80%85%E2%80%90%E4%BC%9A%E8%A9%B1:YShibata_(WMF)#c-RottenApple777-2022-01-17T17%3A57%3A00.000Z-%E8%B2%A1%E5%9B%A3%E3%81%AE%E9%83%A8%E9%96%80%E3%81%AE%E4%B8%80%E8%A6%A7%E3%80%81%E2%80%932019%E5%B9%B4%EF%BC%88%E6%83%85%E5%A0%B1%EF%BC%89]か、yshibata-ctr@wikimedia.orgにご連絡ください！
他の地域での参加もできます。
[https://meta.wikimedia.org/wiki/Wikimedia_Foundation_elections/2022/Meetings/New_Year_Conversation_with_Election_Volunteers ]--[[利用者:YShibata (WMF)|YShibata (WMF)]] ([[利用者・トーク:YShibata (WMF)|トーク]]) 2022年1月18日 (火) 15:48 (UTC)

== 提携団体の役割についてのご意見募集: 理事会選挙 ==
&lt;section begin=&quot;announcement-content&quot; /&gt;:''[[m:Special:MyLanguage/Wikimedia Foundation Board of Trustees/Call for feedback: Board of Trustees elections/Question_about_the_Affiliates%27_role_for_the_Call_for_Feedback:_Board_of_Trustees_elections|このメッセージはMeta-wikiで他の言語に翻訳されています。]]''
:''&lt;div class=&quot;plainlinks&quot;&gt;[[m:Special:MyLanguage/Wikimedia Foundation Board of Trustees/Call for feedback: Board of Trustees elections/Question_about_the_Affiliates%27_role_for_the_Call_for_Feedback:_Board_of_Trustees_elections|{{int:interlanguage-link-mul}}]] • [https://meta.wikimedia.org/w/index.php?title=Special:Translate&amp;group=page-{{urlencode:Wikimedia Foundation Board of Trustees/Call for feedback: Board of Trustees elections/Question_about_the_Affiliates%27_role_for_the_Call_for_Feedback:_Board_of_Trustees_elections}}&amp;language=&amp;action=page&amp;filter= {{int:please-translate}}]&lt;/div&gt;''

みなさん、こんにちは。

ご意見募集にご参加いただいた皆様、ありがとうございます。理事会選挙にご参加いただいた皆様、ありがとうございます。運動戦略と組織統治チームは、もう一つの質問がまだ検討中であるとお伝えしていました。本日付で、その重要な質問を発表します。

提携団体はどのように選挙に参加すべきでしょうか？

提携団体は、ウィキメディアの運動の重要な構成要素です。今年補充される理事会の2議席は、2019年に提携団体枠として選出された議席です。 [https://foundation.wikimedia.org/w/index.php?title=Bylaws&amp;type=revision&amp;diff=123603&amp;oldid=123339 細則の変更により、コミュニティと提携団体の枠の区別がなくなりました]。したがって重要な疑問が生じます。新しい議席の選定に提携団体はどのように関与すべきでしょうか？ 

この質問は、寄せられるご意見がこの2議席についてだけでなく、任期中であるコミュニティや提携団体としての枠で選ばれた議席についても及ぶであろうという前提です。理事会は、提携団体の関与を高め、実際的な権限を与えるとともに、最高のスキル、経験、多様性、幅広いコミュニティの支持を有する人物を選ぶという意味で、最大の成果を見出したいと考えています。 

理事会は、この質問について、特に提携団体からのご意見を必要としています。が、他の方々のご意見も必要です。どなたでもご意見を共有し、ご意見募集というチャンネルでの対話に参加することができます。オンラインでのご意見募集に加え、運動戦略と組織統治チームは、提携団体メンバーとのオンラインミーティングを数回企画し、ご意見を募集する予定です。これは様々な時間帯に行われ、理事会メンバーも参加します。

この3つ目の追加質問が予定より遅れたため、募集期間を2月16日まで延長します。

[[m:Special:MyLanguage/Wikimedia_Foundation_Board_of_Trustees/Call_for_feedback:_Board_of_Trustees_elections/Discuss_Key_Questions|対話に参加]]

敬具

運動戦略と組織統治

== 編集者 Honooo  へのクレーム ==
トークページで彼からこう言われました。「なんか色々記述を移動させてるねー。以前もあんたその手使ったよね。まあ工学はあんたの専門分野だからね，最後の砦としては妥当だろう。俺も別にあんたを殺すのが目的でここにいる訳じゃあないんだけど，どうしてもついつい目にするとものすごく不快で具合悪くてね，どうしてもかかわらざるを得なくなっちゃうんだよ。今後どうなるかねー。俺がここを去るという道もあるけど，ウィキメディアの仕様自体が，それを難しくしてるんだよ。Honooo (トーク) 2022年1月24日 (月) 14:35 (UTC)」

何か私の編集移動がwiki規約に違反してるとかなら文句をつけられるのは仕方無いと思いますが、しかし工学専攻の私が専門知識に基づいて工学の記事を編集するのを、専門外の彼に文句を言われるのは意味不明です。

そもそも、移動前の「ゲームプログラミング」にあった工学的内容は、もともと工業高校の機械設計あたりの教科書に書いてあった設計図の内容をベースにしている内容ですので、それを私は工学のページに「設計の理論」という新規ページに移動しただけです。設計図書など、工業高校の機械設計用に考えていた内容ですし、もともと市販の工学書などに在った話題です。

彼は形式的にはトークページで対話をしていますが、しかし建設的な提案をしませんので、彼へのトークではなく談話室でクレームを述べさせてもらいます。

あと、「俺がここを去るという道もあるけど，ウィキメディアの仕様自体が，それを難しくしてるんだよ。」とか言われても、私からは「知らんがな」としか言えません。そもそも彼ってウィキペディアの管理人か何かなんですか。彼の今までのトークなどの発言内容が到底、ウィキメディア管理職とは思えません。--[[利用者:すじにくシチュー|すじにくシチュー]] ([[利用者・トーク:すじにくシチュー|トーク]]) 2022年1月24日 (月) 14:49 (UTC)

:俺は管理職じゃあないよ。単なる一参加者。工学とか理学とか，専門分野とかいう前に，人間としてあんたの態度，考え方がおかしいと思うから文句言ってるの。一番建設的な話題だよ。「知らんがな」と言うのなら，俺はお前の存在自体が「知らんがな」だね。--[[利用者:Honooo|Honooo]] ([[利用者・トーク:Honooo|トーク]]) 2022年1月24日 (月) 14:56 (UTC)
:別に設計の理論で純粋に工学的な話題を展開するなら，何も文句ないし，むしろ俺も読みたいくらいだよ。だけどあんた今までそうじゃあなかったよね。なんだかんだで，人間と社会に関するありえない暴論をぶっこんで来たよね？この辺考え方の違いとか言われると俺も返答難しいんだけど，しかし俺から見ると地獄の100丁目でね，ありえなく不快だからついつい口出ししたくなっちゃうんだよ。だからそうなりたくないから，トークページで釘さしておいただけだよ。--[[利用者:Honooo|Honooo]] ([[利用者・トーク:Honooo|トーク]]) 2022年1月24日 (月) 15:16 (UTC)

== デスクトップビュー改善の情報更新と事務局時間へのご招待 ==

{{int:Hello}}. [[mw:Special:MyLanguage/Reading/Web/Desktop_Improvements|デスクトップビュー改善]]プロジェクト（Desktop Improvements）の更新について、ウィキメディア財団ウェブチームより情報共有をしたいと考えます。

当プロジェクトでは閲覧者も経験を積んだ利用者も、誰でも今よりもっとインターフェースを便利に使えるように目指します。 プロジェクトは一連の機能の改善で構成され、閲覧と編集をしやすくしたり、ページ内の移動、他言語への切り替え、記事のタブや利用者メニューの使用その他を対象にします。

これらの改良点は、すでに24件のウィキで閲覧者と編集者に既定で表示しており、ウィキペディアの [[:fr:|フランス語版]]、[[:pt:|ポルトガル語版]]、[[:fa:|ペルシャ語版]]も対象です。 

これらの変更点を反映するのは[{{fullurl:{{FULLPAGENAMEE}}|useskin=vector}} ベクター]外装限定です。[{{fullurl:{{FULLPAGENAMEE}}|useskin=monobook}} モノブック]と [{{fullurl:{{FULLPAGENAMEE}}|useskin=timeless}} Timeless] の利用者に影響はありません。

=== 前回の更新以降、展開した機能類 ===
* 目標としては、ユーザーリンクの構造と目的を強調して見せるなど、ナビゲーションを直観的に操作できるようにします。
* [[mw:Special:MyLanguage/Reading/Web/Desktop_Improvements/Features/Sticky Header|常駐ヘッダー]]（Sticky header）- ページ最上部まで画面をロールしなくても、利用者が重要な機能（ログインとログアウト、変更履歴、トークページなど）を利用できるようにします。

当プロジェクトが対象とする機能の一覧は、当チームの[[mw:Special:MyLanguage/Reading/Web/Desktop_Improvements|プロジェクトページ]]をご参照ください。[[mw:Special:MyLanguage/Reading/Web/Desktop_Improvements/Updates|更新情報のページ]]もご案内します。.
[[File:Table_of_contents_shown_on_English_Wikipedia_02.webm|thumb|600px|center]]
&lt;br clear=all&gt;
=== 改良点を反映するには ===
[[File:Desktop Improvements - how to enable globally.png|thumb|[[Special:GlobalPreferences#mw-prefsection-rendering|{{int:globalpreferences}}]]]]
* ウィキ単位で有効にするには、それぞれの[[Special:Preferences#mw-prefsection-rendering|個人設定ページを開き〈表示〉タブ]]の「{{int:prefs-vector-enable-vector-1-label}}」のボックスのチェックを外してください。（白色にします。） さらに[[Special:GlobalPreferences#mw-prefsection-rendering|グローバルな個人設定]]を指定すると、すべてのウィキで選択が一意に有効になります。
* 本ウィキにおいてこれが閲覧者や編集者全員にふさわしく、既定にしてよいとお考えの場合は、ぜひコミュニティとの合意形成に取り掛かったり私へのご連絡をご検討ください。
* ウィキによっては変更点を既定で全員に開示しており、その場合もログイン利用者は選択肢をいつでも旧来のベクター（Legacy Vector）に戻すことができます。 新しいベクター外装のサイドバーには、見つけやすいリンクを置いてあります。

=== 情報交換とイベントの告知 ===
本プロジェクトの進捗を今後も知りたいとお考えなら、[[mw:Special:Newsletter/28/subscribe|ニュースレターを購読]]してください。

[[mw:Special:MyLanguage/Reading/Web/Desktop_Improvements|プロジェクトのページ]]（複数）を閲覧、[[mw:Special:MyLanguage/Reading/Web/Desktop_Improvements/Frequently_asked_questions|専用のよくある質問]]をチェック、[[mw:Talk:Reading/Web/Desktop_Improvements|プロジェクトのトークページ]]に投稿、さらにオンラインのミーティングに参加（[https://www.timeanddate.com/worldclock/fixedtime.html?iso=20220127T1500 '''{{#time:xgj日|2022-01-27}} （{{#time:l|2022-01-27}}）{{#time:H:i e|15:00|ja|1}}''']）など皆さんをお待ちしています。

オンライン会議に参加するには

* [https://wikimedia.zoom.us/j/89205402895 オンラインで参加]
* 会議 ID: &lt;span dir=ltr&gt;89205402895&lt;/span&gt;
* [https://wikimedia.zoom.us/u/kdPQ6k2Bcm 所在地別のフリーダイヤル番号]

{{int:Feedback-thanks-title}}

ウィキメディア財団ウェブチーム一同になりかわり、[[User:SGrabarczuk (WMF)|SGrabarczuk (WMF)]] ([[User talk:SGrabarczuk (WMF)|会話]]) 2022年1月25日 (火) 06:25 (UTC)
&lt;!-- User:SGrabarczuk (WMF)@metawiki が https://meta.wikimedia.org/w/index.php?title=User:SGrabarczuk_(WMF)/sandbox/MM/Other_TOP20/ja&amp;oldid=22381336 のリストを使用して送信したメッセージ --&gt;

== ユニバーサル行動規範Universal Code of Conduct(UCoC)/施行ガイドライン査読の更新 ==
&lt;section begin=&quot;announcement-content&quot; /&gt;
:''[[m:Special:MyLanguage/Universal Code of Conduct/Enforcement guidelines/2022-02-02 Announcement/Short|このメッセージはMeta-wikiで他の言語に翻訳されています。]]''
:''&lt;div class=&quot;plainlinks&quot;&gt;[[m:Special:MyLanguage/Universal Code of Conduct/Enforcement guidelines/2022-02-02 Announcement/Short|{{int:interlanguage-link-mul}}]] • [https://meta.wikimedia.org/w/index.php?title=Special:Translate&amp;group=page-{{urlencode:Universal Code of Conduct/Enforcement guidelines/2022-02-02 Announcement/Short}}&amp;language=&amp;action=page&amp;filter= {{int:please-translate}}]&lt;/div&gt;''
皆さん、こんにちは。

'''[[m:Universal Code of Conduct/Enforcement guidelines|ユニバーサル行動規範Universal Code of Conduct (UCoC) 施行ガイドライン]]''' が2022年1月24日に公開されました。これまでの話し合いに沿い、[[m:Universal Code of Conduct|ユニバーサル行動規範Universal Code of Conduct]] を運動全てに適用させるためです。ガイドラインについてのコメントは [[m:Talk:Universal Code of Conduct/Enforcement guidelines|the Meta-wiki talk page]]こちらにご記入ください。

Zoomでの質疑応答が、2022年2月4日15:00 UTC(日本時間深夜0:00)、2022年2月25日12:00 UTC(日本時間21:00)、2022年3月4日15:00 UTC(日本時間深夜0:00)に行われます。 '''[[m:Special:MyLanguage/Universal Code of Conduct/Conversations|ガイドラインや投票手続きについて、UCoCプロジェクトチームや起草委員会メンバーと話し合う]]。'''

 [[m:Universal Code of Conduct/Project#Timeline|日程表はMeta-wikiでご覧ください]]。投票期間は3月7日から21日です。'''[[m:Universal Code of Conduct/Enforcement guidelines/Voting|詳細はこちらをご覧ください]]。'''

ご参加いただきありがとうございます。

厚意と心をこめて、

運動戦略と組織統治Movement Strategy and Governance&lt;br/&gt;
ウィキメディア財団Wikimedia Foundation&lt;section end=&quot;announcement-content&quot; /&gt;

== 編集合戦が起きたので報告 ==
記事『[[病理学/炎症]]』で編集合戦が起きたので、報告します。なお、この井戸端に投稿した編集者「すじにくシチュー」は、編集合戦の当事者の片方です。ログインユ－ザーによる第三者の意見をお待ちしております。なお、この意見招来の要望はwikipedia日本語版の慣習にしたがったものです。wikipedia日本語版でも議論のあるページなどでは、井戸端などに議論のあることを報告し、意見を招来するものと考えます。なお現在、記事の状態は、編集合戦の起きる前に長らく放置されていた状態の版をベースに、議論のある事だけを追記した状態にしてあります。--[[利用者:すじにくシチュー|すじにくシチュー]] ([[利用者・トーク:すじにくシチュー|トーク]]) 2022年2月6日 (日) 09:04 (UTC)

:すじにくさん，私は最近は貴方に本当に愛想が尽きたので，基本的には今回の議論は，ほぼ静観，傍観です。はっきり言って，IPv6さんがあなたを上手に料理して，貴方をWikibooks から葬り去ってくれることを期待しているよ。
:貴方もそろそろ自分自身の愚かさに気づいて，自覚，反省したほうがいいよ。俺に言わせりゃあ，人類史上本当に賢い人間なんて一人もいないよ。
:今回の病理学，炎症に関しては確かに私も興味あるけど，貴方の文章は，あなたの性格の悪さ，歪みが如実に表れてるので，まあ読みたくないね。Wikipediaにも，それ以外のWebにも，有益な文章はいっぱいあるよ。お金出して書籍購入してもいいしね。
:はっきり言うけど貴方の文章は，お金もらっても読みたくない部類だね。ここで私がゲームや学習法を上書きしてるのは，このサイトの参加者である以上やらざるを得ないからやってるんであって，貴方に対してはマイナスの評価しかない。
:さて，今後どうなるかね…。しかしあなたもほんと変わり者だね。俺も相当変人の自覚あるけど，貴方はそれをはるかに超えてるよ。--[[利用者:Honooo|Honooo]] ([[利用者・トーク:Honooo|トーク]]) 2022年2月6日 (日) 10:43 (UTC)
::申し訳ありませんが、私「もう疲れたよパトラッシュ……_(:3」∠)_」状態です。すじにく大先生のお言葉の蟲毒に耐えられません(白目)。到底、大先生を葬り去るなんてできません。いや、普通の人は、あそこまで書けば少なくとも自省するんですけどね……。
::すじにく大先生の最大の業績は「良いものは金を出して買え。無料にロクなものはない」というのを各ページでアピールしていることではないかと思います。--[[特別:投稿記録/2404:7A86:8800:1C00:597A:C4F6:CDF:B28C|2404:7A86:8800:1C00:597A:C4F6:CDF:B28C]] 2022年2月6日 (日) 12:25 (UTC)
:::そうですか…。実は私も最近はパトラッシュと語ることが多くて^^;;;。悪いけどすじ肉先輩には業績なんてないと思う。確かに無料のものは怪しいもの多いけど，お金出したのに酷い内容や酷い事する人は本当に多いよ。まあそれはともかく，今日は私はもう寝ます(^^)/。ではではZzzzzzzz…--[[利用者:Honooo|Honooo]] ([[利用者・トーク:Honooo|トーク]]) 2022年2月6日 (日) 12:39 (UTC)
::::Wikipediaみたいに、管理者も多くの執筆者も活動が活発なら葬れるんですけどねぇ……(白目)。すじにく大先生の業績?　ないですね(きっばり)。さっきのはご存じかと思いますが、嫌味です(苦笑)。確かに、金返せと言いたくなるものもありますしね。私も、自分のことがありますのでこれにてm(__)m。--[[特別:投稿記録/2404:7A86:8800:1C00:597A:C4F6:CDF:B28C|2404:7A86:8800:1C00:597A:C4F6:CDF:B28C]] 2022年2月6日 (日) 12:47 (UTC)


== &lt;section begin=&quot;announcement-header&quot; /&gt;リーダーシップ開発タスクフォース: ぜひ、ご意見をお聞かせください！&lt;section end=&quot;annoncement-header&quot; /&gt; ==

&lt;section begin=&quot;announcement-content&quot; /&gt;:''[[m:Special:MyLanguage/Leadership Development Task Force/Call for Feedback Announcement|このメッセージはMeta-wikiで他の言語に翻訳されています。]]''
:''&lt;div class=&quot;plainlinks&quot;&gt;[[m:Special:MyLanguage/Leadership Development Task Force/Call for Feedback Announcement|{{int:interlanguage-link-mul}}]] • [https://meta.wikimedia.org/w/index.php?title=Special:Translate&amp;group=page-{{urlencode:Leadership Development Task Force/Call for Feedback Announcement}}&amp;language=&amp;action=page&amp;filter= {{int:please-translate}}]&lt;/div&gt;''

ウィキメディア財団のコミュニティ開発チームは、グローバルな、コミュニティ主導のリーダーシップ開発タスクフォースの策定を支援しています。タスクフォースの目的はリーダーシップ開発作業についてのアドバイスです。

チームは、リーダーシップ開発タスクフォースについてのご意見を募集しています。このMETAページでは、[[m:Special:MyLanguage/Leadership Development Task Force|リーダーシップ開発タスクフォース]]のための提案と、どのようにして[[m:Special:MyLanguage/Leadership Development Task Force/Participate|支援するか]]について共有します。ご意見の募集期間は2022年2月7日から25日までです。&lt;section end=&quot;announcement-content&quot; /&gt;

== &lt;section begin=&quot;announcement-header&quot; /&gt;UCoCについての対話にご参加ください。批准のための投票もお願いいたします。&lt;section end=&quot;announcement-header&quot; /&gt; ==
&lt;section begin=&quot;announcement-content&quot; /&gt;
:''[[m:Universal Code of Conduct/Enforcement guidelines/Voting/Announcement|このメッセージはMeta-wikiで他の言語に翻訳されています。]]''
:''&lt;div class=&quot;plainlinks&quot;&gt;[[m:Special:MyLanguage/Universal Code of Conduct/Enforcement guidelines/Voting/Announcement|{{int:interlanguage-link-mul}}]] • [https://meta.wikimedia.org/w/index.php?title=Special:Translate&amp;group=page-{{urlencode:Universal Code of Conduct/Enforcement guidelines/Voting/Announcement}}&amp;language=&amp;action=page&amp;filter= {{int:please-translate}}]&lt;/div&gt;''

皆さん、こんにちは。

ユニバーサル行動規範Universal Code of Conduct（UCoC）施行ガイドラインの批准プロセスの一環として、[[m:Special:MyLanguage/Universal_Code_of_Conduct/Enforcement_guidelines/Voting|'''2022年3月7日から21日までSecurePollで投票''']]があります。投票資格のある方は、是非、投票をお願い致します。反対の場合はコメントもご記入ください。[[EG2|投票者情報・参加資格の詳細]]。ガイドラインとは、世界共通の規範を各地域でどのように実地するのか、という案です。

[[EG3|ユニバーサル行動規範Universal Code of Conduct]](UCoC)は、最低限の規範です。2022年1月24日、この規範を実施する方法の案として[[m:Special:MyLanguage/Universal_Code_of_Conduct/Enforcement_guidelines|改訂版施行ガイドライン]]が発表されました。 [[m:Special:MyLanguage/Wikimedia_Foundation_Board_noticeboard/January_2022_-_Board_of_Trustees_on_Community_ratification_of_enforcement_guidelines_of_UCoC|ウィキメディア財団理事会声明]]では、投票でUCoC施行ガイドラインの採用について支持、または反対する機会[[m:Special:MyLanguage/Universal_Code_of_Conduct/Enforcement_guidelines/Voting|承認プロセス]]を必要としています。ウィキメディアンは[[m:Special:MyLanguage/Universal_Code_of_Conduct/Enforcement_guidelines/Voter_information/Volunteer|重要な情報の翻訳と共有]]に是非、ご参加ください。UCoCについての詳細は、Meta-wikiの[[m:Special:MyLanguage/Universal Code of Conduct/Project|プロジェクトページ]]と[[m:Special:MyLanguage/Universal Code of Conduct/FAQ|よくある質問]]をご覧ください。

話し合うためのイベントもあります。
* 2022年2月18日15:00 UTCに開催される[[m:Special:MyLanguage/Universal_Code_of_Conduct/Conversations/Panel_Q&amp;A|コミュニティパネル]]では、小規模コミュニティの視点が特に必要です。
* [[m:Movement Strategy and Governance|運動戦略と組織統治Movement Strategy and Governance]](MSG)チームは、2022年2月25日 12:00 UTC と 2022年3月4日 15:00 UTC に話し合いの時間を開催します。ぜひ[[m:Special:MyLanguage/Universal_Code_of_Conduct/Conversations|'''参加''']]して、プロジェクトチームや起草委員会と、更新される施行ガイドラインや批准プロセスについて話し合ってください。2022年2月4日の終了回については[[m:Special:MyLanguage/Universal_Code_of_Conduct/2022_conversation_hour_summaries|話し合いの時間概略]]をご覧ください。

メタウィキのトークページには、どの言語でもコメントすることができます。また、電子メールで連絡することができます。msgemail または ucocproject[[File:At sign.svg|16x16px|link=|(_AT_)]]wikimedia.org です。

今後ともよろしくお願い申し上げます。

運動戦略とガバナンス（組織統治）チーム一同 &lt;br /&gt;
ウィキメディア財団 &lt;br /&gt;&lt;section end=&quot;announcement-content&quot; /&gt;--[[利用者:YShibata (WMF)|YShibata (WMF)]] ([[利用者・トーク:YShibata (WMF)|トーク]]) 2022年2月17日 (木) 08:45 (UTC)

== ビデオゲームの攻略本について ==

攻略本を解説書として執筆することは許可されているのでしょうか？

さっき英語版WIKIBOOKSに「ビデオゲームの執筆の許可」という趣旨のページを見つけました。日本語版ではどうなっているのでしょうか。
-{{Unsigned2|Funa-enpitu|2022年2月20日(日)03:03(UTC)|[[利用者:Honooo|Honooo]] ([[利用者・トーク:Honooo|トーク]])}}
:Funaさん，トーク系のページでは，末尾に署名してください。（ &lt;nowiki&gt;--~~~~&lt;/nowiki&gt; と書く）。個人的にはゲームの攻略本はここのコンテンツとしては認めたくありませんね。ただ英語版でどういう議論があるのかは気になるので，良ければ，対象ページへのリンクか，ページタイトルを示していただければありがたいのですが…--[[利用者:Honooo|Honooo]] ([[利用者・トーク:Honooo|トーク]]) 2022年2月20日 (日) 04:59 (UTC)

:[[:en:Wikibooks:Reading_room/Proposals#Start_allowing_game_strategies|ウィキブックス:読書室/提案 - ウィキブック、オープンワールドのためのオープンブック (wikibooks.org)]]--[[利用者:Funa-enpitu|Funa-enpitu]] ([[利用者・トーク:Funa-enpitu|トーク]]) 2022年2月20日 (日) 07:41 (UTC)

:[[:en:Wikibooks:Reading_room/Proposals#Start_allowing_game_strategies|このリンクです]]

--[[利用者:Funa-enpitu|Funa-enpitu]] ([[利用者・トーク:Funa-enpitu|トーク]]) 2022年2月20日 (日) 07:39 (UTC)

:上部に「ウィキブックスコミュニティは、このウィキのビデオゲーム戦略ガイドを受け入れました!新しく作成された戦略ゲームのポリシーについては、ウィキブック:ストラテジーガイドを参照してください。皆様のご寄付をお待ちしております。」とあります。--[[利用者:Funa-enpitu|Funa-enpitu]] ([[利用者・トーク:Funa-enpitu|トーク]]) 2022年2月20日 (日) 07:42 (UTC)
::日本語版では今のところゲーム攻略本は不可です。日本語版の「[[{{ns:project}}:ウィキブックスは何でないか]]」には「テレビゲームの攻略本ではありません。ウィキブックスの求めるものは教本であり、攻略本ではありません。」と書かれていますので、今のところウィキブックス日本語版にゲーム攻略本を作ることは明確に禁じられています。単なる攻略本ではなく eスポーツ選手養成のための本格的な教材を編纂しようという話なら、受け入れられる可能性はあり得るかと思いますが。 --[[利用者:Kanjy|Kanjy]] ([[利用者・トーク:Kanjy|トーク]]) 2022年2月20日 (日) 09:32 (UTC)
::Funaさん，ある程度明文化された規定がすでにあるようですね。しかしそれはともかくリンクの提示ありがとうございます。[[b:en:Wikibooks:Reading room/Proposals]],[[b:en:Wikibooks:Strategy guides]]あたりですねー。Strategy guides が攻略本って事かな？まあどっちにしろ英語は凄く苦手でね，大したことは分からないんですが^^;;;…。--[[利用者:Honooo|Honooo]] ([[利用者・トーク:Honooo|トーク]]) 2022年2月20日 (日) 10:00 (UTC)

== Wiki Loves Folklore is extended till 15th March ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; class=&quot;mw-content-ltr&quot;&gt;{{int:please-translate}}

[[File:Wiki Loves Folklore Logo.svg|right|frameless|180px]]
Greetings from Wiki Loves Folklore International Team,

We are pleased to inform you that [[:c:Commons:Wiki Loves Folklore|Wiki Loves Folklore]] an international photographic contest on Wikimedia Commons has been extended till the '''15th of March 2022'''. The scope of the contest is focused on folk culture of different regions on categories, such as, but not limited to, folk festivals, folk dances, folk music, folk activities, etc.

We would like to have your immense participation in the photographic contest to document your local Folk culture on Wikipedia. You can also help with the [[:c:Commons:Wiki Loves Folklore 2022/Translations|translation]] of project pages and share a word in your local language.

Best wishes,

'''International Team'''&lt;br /&gt;
'''Wiki Loves Folklore'''

[[利用者:MediaWiki message delivery|MediaWiki message delivery]] ([[利用者・トーク:MediaWiki message delivery|トーク]]) 2022年2月22日 (火) 04:50 (UTC)
&lt;/div&gt;
&lt;!-- User:Rockpeterson@metawiki が https://meta.wikimedia.org/w/index.php?title=Distribution_list/Global_message_delivery&amp;oldid=22754428 のリストを使用して送信したメッセージ --&gt;

== 記事削除依頼 ==

本人からの申し出と、記事内容に虚偽が含まれている事から、下記記事の削除を依頼いたします。
https://ja.wikipedia.org/wiki/%E6%A6%8E%E5%B6%8B%E5%A4%A7%E8%B2%B4{{Unsigned|YuyaAkasaka|2022-02-24T13:57:21|[[利用者:Tomzo|Tomzo]] ([[利用者・トーク:Tomzo|トーク]])}}
:ウィキペディア記事に対して、こちらでは、何らの対応も致しかねます。--[[利用者:Tomzo|Tomzo]] ([[利用者・トーク:Tomzo|トーク]]) 2022年2月24日 (木) 09:03 (UTC)

== 新しい規範が世界的に実行される前にご意見をお聞かせください。 ==

おはようございます！こんにちは！こんばんは！
ウィキメディア財団、運動戦略と組織統治チームの柴田由美子[[https://meta.wikimedia.org/wiki/Movement_Strategy_and_Governance/Team/ja]]と申します。

新しい規範[[https://meta.wikimedia.org/wiki/Universal_Code_of_Conduct/ja]]が導入されたのですが、これまでの様々な「決まりごとや道徳」と決定的に違うのは'''実行'''させようとしていること[[https://meta.wikimedia.org/wiki/Universal_Code_of_Conduct/Enforcement_guidelines/ja]]です。

新しい規範自体は、「相手を尊重しましょう」など、基礎的なものです。


2022年3月７日～21日、'''この実行方法'''について、'''投票'''[[https://meta.wikimedia.org/wiki/Universal_Code_of_Conduct/Enforcement_guidelines/Voter_information/ja]]があります。


投票'''前に'''、ご意見をこちらにご記入いただければありがたいです。(投票のときにも意見を記入することができます。が、全ての利用者、というわけではありません)

*日本語[[https://meta.wikimedia.org/wiki/Talk:Universal_Code_of_Conduct/Enforcement_guidelines/ja#%E3%83%A6%E3%83%8B%E3%83%90%E3%83%BC%E3%82%B5%E3%83%AB%E8%A1%8C%E5%8B%95%E8%A6%8F%E7%AF%84Universal_Code_of_Conduct%28UCoC%29%2F%E6%96%BD%E8%A1%8C%E3%82%AC%E3%82%A4%E3%83%89%E3%83%A9%E3%82%A4%E3%83%B3%E3%80%8C%E3%81%AB%E5%AF%BE%E3%81%99%E3%82%8B%E3%81%94%E6%84%8F%E8%A6%8B%E3%80%81%E8%B3%AA%E5%95%8F%E3%81%AA%E3%81%A9%E3%80%8D%E3%82%92%E3%81%94%E8%A8%98%E5%85%A5%E3%81%8A%E9%A1%98%E3%81%84%E3%81%84%E3%81%9F%E3%81%97%E3%81%BE%E3%81%99]]
*英語[[https://meta.wikimedia.org/wiki/Talk:Universal_Code_of_Conduct/Enforcement_guidelines]]


「実行させようとする」方法の、第一段階は管理者の方々です。管理者、といっても、普通のボランティアの方々です。負担増加が懸念されるので、オンラインミーティングを行いました。日本語ウィキペディアが成立しているのは、管理者の方々がボランティアとして'''見えない'''仕事をしてくださっているからです。
井戸端ではこの点について話し合いがもたれています。暫定まとめ[[https://ja.wikipedia.org/wiki/Wikipedia:%E4%BA%95%E6%88%B8%E7%AB%AF/subj/%E3%83%A6%E3%83%8B%E3%83%90%E3%83%BC%E3%82%B5%E3%83%AB%E8%A1%8C%E5%8B%95%E8%A6%8F%E7%AF%84%E3%81%AB%E3%82%88%E3%81%A3%E3%81%A6%E3%82%A6%E3%82%A3%E3%82%AD%E3%83%9A%E3%83%87%E3%82%A3%E3%82%A2%E6%97%A5%E6%9C%AC%E8%AA%9E%E7%89%88%E3%81%AF%E8%A1%B0%E9%80%80%E3%81%95%E3%81%9B%E3%82%89%E3%82%8C%E3%82%8B%E3%81%AE%E3%81%A7%E3%81%AF%E3%81%AA%E3%81%84%E3%81%8B%EF%BC%9F/%E6%9A%AB%E5%AE%9A%E3%81%BE%E3%81%A8%E3%82%8120220223]]

日本語ウィキペディアの存続にかかわることになりかねないのでご一読いただければありがたいです。

ゆとりのないお知らせで申し訳ございません。お忙しいところご迷惑をおかけいたします。
--[[利用者:YShibata (WMF)|YShibata (WMF)]] ([[利用者・トーク:YShibata (WMF)|トーク]]) 2022年2月26日 (土) 05:56 (UTC)

== Coming soon ==

&lt;div class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;ja&quot; dir=&quot;ltr&quot;&gt;
=== もうすぐ導入：テンプレート数件の改善 ===

こんにちは、3月9日より皆さんのウィキでテンプレート数件に改善を導入の予定です。
* [[Mw:Special:MyLanguage/Help:VisualEditor/User guide#Editing templates|ビジュアルエディタのテンプレートダイアログ]]を根本的に改善 (VisualEditor [[m:WMDE Technical Wishes/VisualEditor template dialog improvements|1]]、[[special:MyLanguage/m:WMDE Technical Wishes/Removing a template from a page using the VisualEditor|2]])、
* ページにテンプレートを導入しやすくする改善 ([[m:WMDE Technical Wishes/Finding and inserting templates|3]]) (対象は[[Mw:Special:MyLanguage/Help:VisualEditor/User guide#Editing templates|VisualEditor]] (ビジュアルエディタ)、[[Mw:Special:MyLanguage/Extension:WikiEditor#/media/File:VectorEditorBasic-en.png|2010 Wikitext]] (2010年版ウィキテキスト)、[[Mw:Special:MyLanguage/2017 wikitext editor|New Wikitext Mode]] (新ウィキテキストモード) におけるテンプレートダイアログ)、
* さらに構文ハイライト拡張機能  [[Mw:Special:MyLanguage/Extension:CodeMirror|CodeMirror]] (コードミラー) ([[m:WMDE Technical Wishes/Improved Color Scheme of Syntax Highlighting|4]]、[[m:WMDE Technical Wishes/Bracket Matching|5]]) (対応のウィキは右書きつまり横書きの時に左から右方向に書くタイプ。)

これらの変更はすべて[[m:WMDE Technical Wishes|ウィキメディア・ドイツ協会技術要望]]（WMDE Technical Wishes）の行う「[[m:WMDE Technical Wishes/Templates|テンプレート]]」プロジェクトの配下にあります。皆さんの作業でこれらがお役に立つよう願っており、またこれらのプロジェクトそれぞれのトークページでぜひ皆さんの意見感想をお聞きしたく、お待ちしています。 &lt;/div&gt; - [[m:User:Johanna Strodt (WMDE)|Johanna Strodt (WMDE)]] 2022年2月28日 (月) 12:38 (UTC)
&lt;!-- User:Johanna Strodt (WMDE)@metawiki が https://meta.wikimedia.org/w/index.php?title=WMDE_Technical_Wishes/Technical_Wishes_News_list_all_village_pumps&amp;oldid=22907463 のリストを使用して送信したメッセージ --&gt;


== 荒らし報告 ==
（すじにくシチューによるコメント）編集者 Honooo による荒らし行為を報告します。[https://ja.wikibooks.org/w/index.php?title=%E3%83%88%E3%83%BC%E3%82%AF:%E4%B8%AD%E5%AD%A6%E6%A0%A1%E5%9B%BD%E8%AA%9E_%E5%8F%A4%E6%96%87/%E6%9E%95%E8%8D%89%E5%AD%90&amp;oldid=194980  『トーク:中学校国語 古文/枕草子』2022年3月2日 (水) 13:38時点による版]

&lt;pre&gt;
== すじ肉先輩へ ==

あのさー，これ書くとまた削除されるかもしれないけど，あんた結局最近の更新で嫌がらせしてない?俺みたいな馬鹿は，Wikibooksの方針文読んでるのがつきづきしって言われてる気がするんだけど?--[[利用者:Honooo|Honooo]] ([[利用者・トーク:Honooo|トーク]]) 2022年3月2日 (水) 13:38 (UTC)
&lt;/pre&gt;

Honoooの上記の投稿は中学国語と、何の関係もない意見表明です。

他のページでも編集者 Honooo は類似の行為を行っています。削除されましたが、『トーク:高等学校国語総合/土佐日記』で彼は荒らしを行いました。

そのため、該当のトークページを開くと、下記のように表示されます。

&lt;pre&gt;
警告: 以前削除されたページを再作成しようとしています。

このページの編集を続行するのが適切かどうかご確認ください。 参考までに、このページの削除と移動の記録を以下に示します:

    2022年2月28日 (月) 18:31 Tomzo トーク 投稿記録 がページ「トーク:高等学校国語総合/土佐日記」を削除しました (WB:SD 荒らし・落書き・ブロック中ユーザーによる編集: 投稿者:Honooo 内容: 「== もがも == もがなって，タモリさんのハナモゲラに共通するとこない? 無いか^^;;;--Honooo (トーク) 2022年2月28日 (月) 13:24 (UTC)」) (感謝)
&lt;/pre&gt;

以上、報告。--[[利用者:すじにくシチュー|すじにくシチュー]] ([[利用者・トーク:すじにくシチュー|トーク]]) 2022年3月2日 (水) 13:51 (UTC)

:ほんとに汚いやつだなー。あらしあらしって，俺はあんたの道義的な不正行為，とみられるものを非難しているだけだよ。そもそも俺のあてずっぽうは当たってるの?違うの?それぐらいは真面目に返答しろよ。--[[利用者:Honooo|Honooo]] ([[利用者・トーク:Honooo|トーク]]) 2022年3月2日 (水) 13:55 (UTC)
:まあまだ色々腑に落ちないことはあるんだけど，それはともかく，すじにく氏は以前，俺が談話室を捏造していると書いていたよね。これどういう意味かなーってずっと考えていたんだけど，ようするにIPv6氏とFUNA氏が俺で，自作自演を疑ってるわけだ?これは断言するけど，両氏は俺ではない。現実世界での知り合いでもない。インターネット上ではやり取りあったかもしれないけど，この世界は自己同一性がめちゃくちゃだからね^^;;;詳しいことは分からないよ。--[[利用者:Honooo|Honooo]] ([[利用者・トーク:Honooo|トーク]]) 2022年3月2日 (水) 14:33 (UTC)

== &lt;section begin=&quot;announcement-header&quot; /&gt;理事会選挙に関するご意見募集が終了しました &lt;section end=&quot;announcement-header&quot; /&gt; ==
&lt;section begin=&quot;announcement-content&quot; /&gt;:''[[m:Special:MyLanguage/Wikimedia Foundation Board of Trustees/Call for feedback: Board of Trustees elections/Call for Feedback is now closed|このメッセージはMeta-wikiで他の言語に翻訳されています。]]''
:''&lt;div class=&quot;plainlinks&quot;&gt;[[m:Special:MyLanguage/Wikimedia Foundation Board of Trustees/Call for feedback: Board of Trustees elections/Call for Feedback is now closed|{{int:interlanguage-link-mul}}]] • [https://meta.wikimedia.org/w/index.php?title=Special:Translate&amp;group=page-{{urlencode:Wikimedia Foundation Board of Trustees/Call for feedback: Board of Trustees elections/Call for Feedback is now closed}}&amp;language=&amp;action=page&amp;filter= {{int:please-translate}}]&lt;/div&gt;''
[[m:Wikimedia Foundation Board of Trustees/Call for feedback: Board of Trustees elections|ご意見募集: 理事会選挙]]は終了しました。この募集は1月10日から実施され、2022年2月16日に締め切られました。この呼びかけは[[m:Wikimedia Foundation Board of Trustees/Call for feedback: Board of Trustees elections/Discuss Key Questions#Questions|3つの重要な質問]]に焦点を当て、[[m:Talk:Wikimedia Foundation Board of Trustees/Call for feedback: Board of Trustees elections/Discuss Key Questions|メタウィキ]]や提携団体との話し合い、様々なコミュニティの会話の中で幅広い議論を得ました。コミュニティも提携団体も、多くの提案を提供してくれました。[[m:Wikimedia Foundation Board of Trustees/Call for feedback: Board of Trustees elections/Reports|報告書]]はMeta-wikiに掲載されています。

いただいたご意見は、理事会および選挙管理委員会と共有され、次回の理事会選挙に向けて検討されます。その後、理事会で審議された後、発表されます。

理事会選挙プロセス改善のための「ご意見の募集」にご参加いただいた皆様、ありがとうございました。 

敬具

運動戦略と組織統治&lt;br /&gt;&lt;section end=&quot;announcement-content&quot; /&gt;

[[Category:CfF Board of Trustees elections]]--[[利用者:YShibata (WMF)|YShibata (WMF)]] ([[利用者・トーク:YShibata (WMF)|トーク]]) 2022年3月3日 (木) 06:21 (UTC)

== Wikibooks日本語版ってピラミッドだね ==

しかしすじ肉の別人格（まあこれも定かな指摘ではないけどね、あてずっぽうだよ）たちが、いくら自らの邪な心をセーブして、偏執的に記事を積み上げていっても、すじ肉みたいな汚い発想でWikiの質を充実させたいという方法の主導（現実には絶対うまくいかないけどね）があるこの場って、本当に価値があるかね?まあ価値があろうとなかろうと、もう少し俺はここに居座って、やろうと思ったことをやっていく予定だよ。--[[利用者:Honooo|Honooo]] ([[利用者・トーク:Honooo|トーク]]) 2022年3月4日 (金) 14:38 (UTC)

でもよく考えたら，うまくいかないって書いたけど，商業の世界ではそんなのばっかだね^^;;;。そして実際そのやり方で大儲けしている^^;;;。まあそれは仕方ないとして，せめてウィキメディアでは，別の論理でコンテンツが出来ていってほしいな。--[[利用者:Honooo|Honooo]] ([[利用者・トーク:Honooo|トーク]]) 2022年3月4日 (金) 14:46 (UTC)

== &lt;section begin=&quot;announcement-header&quot; /&gt;ユニバーサル行動規範Universal Code of Conduct 施行ガイドライン 批准投票 （終了しました）2022年3月7日から21日&lt;section end=&quot;announcement-header&quot; /&gt; ==

&lt;section begin=&quot;announcement-content&quot; /&gt;
:''[[m:Special:MyLanguage/Universal Code of Conduct/Enforcement guidelines/Vote|このメッセージはMeta-wikiで他の言語に翻訳されています。]]
:''&lt;div class=&quot;plainlinks&quot;&gt;[[m:Special:MyLanguage/Universal Code of Conduct/Enforcement guidelines/Vote|{{int:interlanguage-link-mul}}]] • [https://meta.wikimedia.org/w/index.php?title=Special:Translate&amp;group=page-{{urlencode:Universal Code of Conduct/Enforcement guidelines/Vote}}&amp;language=&amp;action=page&amp;filter= {{int:please-translate}}]&lt;/div&gt;''

皆さん、こんにちは。

 [[m:Special:MyLanguage/Universal Code of Conduct|ユニバーサル行動規範Universal Code of Conduct]] (UCoC) の [[m:Special:MyLanguage/Universal Code of Conduct/Enforcement guidelines|査読後の施行ガイドライン]] 批准投票が始まりました! '''[[m:Special:MyLanguage/Universal Code of Conduct/Enforcement guidelines/Voting| SecurePollで投票]]'''します。  2022年3月7日 に始まり、2022年3月21日に終了します。 [[m:Universal Code of Conduct/Enforcement guidelines/Voter information|投票についての詳細と有権者かどうかを確かめるページをご覧ください]]。

ユニバーサル行動規範（UCoC）は、運動全体にとって許容される行動の最低値を示します。この方針を実行させる案として、2022年1月24日に施行ガイドラインの改訂版を発表しました。UCoCプロジェクトについては[[m:Special:MyLanguage/Universal Code of Conduct/Project| UCoC プロジェクトについて]]をご覧ください。

また、Meta-wikiのトークページには、どの言語でもコメントすることができます。メールでの連絡も可能です。ucocproject[[File:At sign.svg|16x16px|link=|(_AT_)]]wikimedia.org

今後ともよろしくお願い申し上げます。

運動戦略とガバナンス（組織統治）チーム一同

ウィキメディア財団&lt;section end=&quot;announcement-content&quot; /&gt;--[[利用者:YShibata (WMF)|YShibata (WMF)]] ([[利用者・トーク:YShibata (WMF)|トーク]]) 2022年3月7日 (月) 06:15 (UTC)

== &lt;section begin=&quot;announcement-header&quot; /&gt;ハブのイベントへにご参加ください: グローバルカンバセーション（終了しました） 2022年3月12日 UTC13:00 日本時間 22:00&lt;section end=&quot;announcement-header&quot; /&gt; == 
:''[[m:Special:MyLanguage/Hubs/Global Conversations March 12, 2022/Invitation|このメッセージはMeta-wikiで他の言語に翻訳されています。]]''
:''&lt;div class=&quot;plainlinks&quot;&gt;[[m:Special:MyLanguage/Hubs/Global Conversations March 12, 2022/Invitation|{{int:interlanguage-link-mul}}]] • [https://meta.wikimedia.org/w/index.php?title=Special:Translate&amp;group=page-{{urlencode:Hubs/Global Conversations March 12, 2022/Invitation}}&amp;language=&amp;action=page&amp;filter= {{int:please-translate}}]&lt;/div&gt;''

&lt;section begin=&quot;announcement-content&quot; /&gt;こんにちは！ 

ウィキメディア財団の運動戦略ガバナンスチームが主催する「地域・テーマ別ハブ」イベントに是非、ご参加ください。ウィキメディア運動は、地域・テーマ別ハブのあるべき姿を模索しています。11月のワークショップは良いスタートでした（[[m:Special:MyLanguage/Hubs/Documentation/27 November Workshop|レポートを読む]]）が、まだ終わってはいません。 

この数週間、私たちはそれぞれの状況下でハブの設立に取り組んでいるグループに対して約16回のインタビューを行いました（[[m:Special:MyLanguage/Hubs/Dialogue|ハブダイアログ]]をご覧ください）。インタビューは、3月12日に行われるディスカッションの土台となる報告書に反映されました。この報告書は、3月9日に発行される予定です。

3月12日13:00～16:00（UTC）にZoomで開催されます。通訳は、フランス語、スペイン語、アラビア語、ロシア語、ポルトガル語で行われます。参加登録は3月10日までです。ご興味のある方は、ぜひご参加ください。'''[[m:Special:MyLanguage/Hubs/Global Conversations March 12, 2022|メタウィキのイベント情報]]'''

よろしくお願いします。

[[m:User:KVaidla (WMF)|Kaarel Vaidla]]&lt;br /&gt;運動戦略
&lt;section end=&quot;announcement-content&quot; /&gt;--[[利用者:YShibata (WMF)|YShibata (WMF)]] ([[利用者・トーク:YShibata (WMF)|トーク]]) 2022年3月8日 (火) 11:33 (UTC)

== オンラインミーティング日本語のみ3月18日（終了しました） ==

おはようございます！こんにちは！こんばんは！
ウィキメディア財団、運動戦略と組織統治チームの柴田由美子[[https://meta.wikimedia.org/wiki/Movement_Strategy_and_Governance/Team/ja]]と申します。約三か月前から所属しております。

3月18日 金曜　22:00 - 23:00　ミーティングを行います！

カメラオフ、ミュートで構いません。録音・録画はしません。議題はありません。しいていえば、「自分の他の利用者さんってどんな人？」と思う方、ご参加ください。顔は分からなくても、声は聞こえなくても、チャットの機能で「他の利用者さん」に話しかけてみてください！

参加してくださる方はお手数をおかけしますが署名をお願いします。
:署名のページ[[https://ja.wikipedia.org/wiki/%E5%88%A9%E7%94%A8%E8%80%85:YShibata_(WMF)/%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%82%B3%E3%83%9F%E3%83%A5%E3%83%8B%E3%83%86%E3%82%A3%E3%83%9F%E3%83%BC%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0/20220318]]
:後日ウィキメールでオンラインミーティングのIDを送信します。(したがってメールの受信を許可している場合に限られます)
Zoomで行いますので、お名前は署名と同じお名前をZoomの名前としてくださるようお願いします。

本来、「どなたでも」が理想ですが、「荒らし」と言われている状態になったことがあります。他の方々に迷惑をかけてしまいました。残念でならないのですが、事前に確認、という手順を取らざるをえなくなってしまいました。99.99%の利用者様にはお詫び申し上げます。

「googleからログアウトしておけば好きな名前でmeet参加できる」と教えて頂いたのですが、気がついたのがIDをとった後だったので、教えてくださった方、もうしわけありません！
--[[利用者:YShibata (WMF)|YShibata (WMF)]] ([[利用者・トーク:YShibata (WMF)|トーク]]) 2022年3月10日 (木) 13:23 (UTC)

== ウィキメディア財団や理事会にモノ申す機会です。21日までです（終了しました） ==

新しい規範[[https://meta.wikimedia.org/wiki/Universal_Code_of_Conduct/ja]]の施行方法[[https://meta.wikimedia.org/wiki/Universal_Code_of_Conduct/Enforcement_guidelines/ja]]について、反対/賛成の投票が行われています。
: 投票用紙は日本語です。[[https://meta.wikimedia.org/wiki/Universal_Code_of_Conduct/Enforcement_guidelines/Voting/ja]]日本語で意見を記入できます。
: 投票の秘密は守られるシステムで、たとえ財団職員でも、誰が賛成/反対なのか、どんな意見を書いたのか、知ることができません。もちろん財団職員やコントラクターが翻訳するわけでは無いので、安心して、日ごろの不満など、ご記入ください。
: 編集回数などの投票資格は[[https://meta.toolforge.org/accounteligibility/62]]に利用者名を入力すると瞬時にわかります。

この施行方法について、あまりにも不完全なので問題が多々生じています。
: 井戸端[[https://ja.wikipedia.org/wiki/Wikipedia:%E4%BA%95%E6%88%B8%E7%AB%AF/subj/%E3%83%A6%E3%83%8B%E3%83%90%E3%83%BC%E3%82%B5%E3%83%AB%E8%A1%8C%E5%8B%95%E8%A6%8F%E7%AF%84%E3%81%AB%E3%82%88%E3%81%A3%E3%81%A6%E3%82%A6%E3%82%A3%E3%82%AD%E3%83%9A%E3%83%87%E3%82%A3%E3%82%A2%E6%97%A5%E6%9C%AC%E8%AA%9E%E7%89%88%E3%81%AF%E8%A1%B0%E9%80%80%E3%81%95%E3%81%9B%E3%82%89%E3%82%8C%E3%82%8B%E3%81%AE%E3%81%A7%E3%81%AF%E3%81%AA%E3%81%84%E3%81%8B%EF%BC%9F/%E6%9A%AB%E5%AE%9A%E3%81%BE%E3%81%A8%E3%82%8120220223]]
: 施行方法（日本語）のトークページ[[https://meta.wikimedia.org/wiki/Talk:Universal_Code_of_Conduct/Enforcement_guidelines/ja#%E3%83%A6%E3%83%8B%E3%83%90%E3%83%BC%E3%82%B5%E3%83%AB%E8%A1%8C%E5%8B%95%E8%A6%8F%E7%AF%84Universal_Code_of_Conduct%28UCoC%29%2F%E6%96%BD%E8%A1%8C%E3%82%AC%E3%82%A4%E3%83%89%E3%83%A9%E3%82%A4%E3%83%B3%E3%80%8C%E3%81%AB%E5%AF%BE%E3%81%99%E3%82%8B%E3%81%94%E6%84%8F%E8%A6%8B%E3%80%81%E8%B3%AA%E5%95%8F%E3%81%AA%E3%81%A9%E3%80%8D%E3%82%92%E3%81%94%E8%A8%98%E5%85%A5%E3%81%8A%E9%A1%98%E3%81%84%E3%81%84%E3%81%9F%E3%81%97%E3%81%BE%E3%81%99]]

上記「井戸端」の
: アイディアの中「ウィキペディア日本語版を分かっている人を誰か送り込む。例えば、財団職員になるなど」について財団の求人情報[[https://wikimediafoundation.org/about/jobs/#section-1]]を是非ウォッチしてください。
:: スタッフは正社員のような立場です。
:: コントラクターは時給で働いています。柴田は週20時間ですが、30時間の人、40時間の人などがいます。学生さんも多いです。

: その他の中「基本的に従うしかないのでは」
:: 様々なことの決定は、職員ではなく、世界各地の利用者があらゆる機会に手をあげて、グループを作り、彼らが行います。新しい規範も、施行方法も、これから作る上位決定機関もです。どなたか決める側に参加しませんか。--[[利用者:YShibata (WMF)|YShibata (WMF)]] ([[利用者・トーク:YShibata (WMF)|トーク]]) 2022年3月14日 (月) 10:15 (UTC)

== &lt;section begin=&quot;announcement-header&quot; /&gt;リーダーシップ開発ワーキンググループ: 応募しませんか! (応募期間2022年3月14日から4月10日)&lt;section end=&quot;announcement-header&quot; /&gt; ==
&lt;section begin=&quot;announcement-content&quot; /&gt;
:''[[m:Special:MyLanguage/Leadership Development Working Group/Participate/Announcement|このメッセージはMeta-wikiで他の言語に翻訳されています。]]''
:''&lt;div class=&quot;plainlinks&quot;&gt;[[m:Special:MyLanguage/Leadership Development Working Group/Participate/Announcement|{{int:interlanguage-link-mul}}]] • [https://meta.wikimedia.org/w/index.php?title=Special:Translate&amp;group=page-{{urlencode:Leadership Development Working Group/Participate/Announcement}}&amp;language=&amp;action=page&amp;filter= {{int:please-translate}}]&lt;/div&gt;''

皆さん、こんにちは。

[[m:Special:MyLanguage/Leadership Development Working Group|リーダーシップ開発ワーキンググループ]]は何をするべきかについてフィードバックを送ってくださった皆様、ありがとうございました。メタウィキに[[m:Special:MyLanguage/Leadership Development Working Group/Participate#5. Summary of Call for Feedback|フィードバックのまとめ]]が掲載されています。このフィードバックはワーキンググループで共有され、作業に反映されます。ワーキンググループへの参加は現在募集中で、2022年4月10日に締め切られます。ぜひ[[m:Special:MyLanguage/Leadership_Development_Working_Group/Purpose_and_Structure#3._How_is_the_working_group_formed_and_structured?|ワーキンググループの情報を見て]]、興味を持ちそうなコミュニティメンバーをご存知でしたら、''[[m:Special:MyLanguage/Leadership_Development_Working_Group/Participate#1._How_to_participate|興味があれば応募する]]''ように伝えてください。

よろしくお願いします。

コミュニティ開発チーム&lt;br /&gt;&lt;section end=&quot;announcement-content&quot; /&gt;--[[利用者:YShibata (WMF)|YShibata (WMF)]] ([[利用者・トーク:YShibata (WMF)|トーク]]) 2022年3月14日 (月) 13:22 (UTC)

== Wiki Loves Folklore 2022 ends tomorrow ==

[[File:Wiki Loves Folklore Logo.svg|right|frameless|180px]]
International photographic contest [[:c:Commons:Wiki Loves Folklore 2022| Wiki Loves Folklore 2022]] ends on 15th March 2022 23:59:59 UTC. This is the last chance of the year to upload images about local folk culture, festival, cuisine, costume, folklore etc on Wikimedia Commons. Watch out our social media handles for regular updates and declaration of Winners. 

([https://www.facebook.com/WikiLovesFolklore/ Facebook] , [https://twitter.com/WikiFolklore Twitter ] , [https://www.instagram.com/wikilovesfolklore/ Instagram])

The writing competition Feminism and Folklore will run till 31st of March 2022 23:59:59 UTC. Write about your local folk tradition, women, folk festivals, folk dances, folk music, folk activities, folk games, folk cuisine, folk wear, folklore, and tradition, including ballads, folktales, fairy tales, legends, traditional song and dance, folk plays, games, seasonal events, calendar customs, folk arts, folk religion, mythology etc. on your local Wikipedia. Check if your [[:m:Feminism and Folklore 2022/Project Page|local Wikipedia is participating]]

A special competition called '''Wiki Loves Falles''' is organised in Spain and the world during 15th March 2022 till 15th April 2022 to document local folk culture and [[:en:Falles|Falles]] in Valencia, Spain. Learn more about it on  [[:ca:Viquiprojecte:Falles 2022|Catalan Wikipedia project page]].

We look forward for your immense co-operation.

Thanks 
Wiki Loves Folklore international Team
[[利用者:MediaWiki message delivery|MediaWiki message delivery]] ([[利用者・トーク:MediaWiki message delivery|トーク]]) 2022年3月14日 (月) 14:40 (UTC)
&lt;!-- User:Rockpeterson@metawiki が https://meta.wikimedia.org/w/index.php?title=Distribution_list/Global_message_delivery&amp;oldid=22754428 のリストを使用して送信したメッセージ --&gt;

== &lt;section begin=&quot;announcement-header&quot; /&gt; コミュニティ レジリエンスとサスティナビリティ チーム主催の対話に是非ご参加ください。マギー・デニスが質問に答えます。 &lt;section end=&quot;annoncement-header&quot; /&gt; ==
:''[[m:Special:MyLanguage/Leadership Development Working Group/Participate/Announcement|このメッセージはMeta-wikiで他の言語に翻訳されています。]]''
:''&lt;div class=&quot;plainlinks&quot;&gt;[[m:Special:MyLanguage/IRC office hours/Office hours 2022-03-24/Announcement|{{int:interlanguage-link-mul}}]] • [https://meta.wikimedia.org/w/index.php?title=Special:Translate&amp;group=page-{{urlencode:IRC office hours/Office hours 2022-03-24/Announcement}}&amp;language=&amp;action=page&amp;filter= {{int:please-translate}}]&lt;/div&gt;''
ウィキメディア財団の [[m:Community Resilience and Sustainability|コミュニティ レジリエンスとサスティナビリティ]] チームは、チームのバイス プレジデントである [[m:User:Mdennis (WMF)|マギー・デニス]]との対話の時間を行います。 

話し合いの内容は、運動戦略、理事会のガバナンス、信頼と安全、ユニバーサル行動規範、コミュニティ開発、人権です。ご質問やご意見を、是非お聞かせください。事前に質問をお送りいただくことも可能です。

2022年3月24日 15:00 UTC ([https://zonestamp.toolforge.org/1648134035 日本時間 日付が24日から25日に替わる深夜0:00]).

[[m:IRC office hours/Office hours 2022-03-24|Meta-wikiで詳細]].--[[利用者:YShibata (WMF)|YShibata (WMF)]] ([[利用者・トーク:YShibata (WMF)|トーク]]) 2022年3月20日 (日) 09:47 (UTC)

== ウィキメディア財団や理事会にモノ申す機会、日本時間22日朝8:59までです （終了しました）==

新しい規範[[https://meta.wikimedia.org/wiki/Universal_Code_of_Conduct/ja]]の施行方法[[https://meta.wikimedia.org/wiki/Universal_Code_of_Conduct/Enforcement_guidelines/ja]]について、反対/賛成の投票が行われています。

: 投票用紙は日本語です。[[https://meta.wikimedia.org/wiki/Universal_Code_of_Conduct/Enforcement_guidelines/Voting/ja]]日本語で意見を記入できます。

: 投票の秘密は守られるシステムで、たとえ財団職員でも、誰が賛成/反対なのか、どんな意見を書いたのか、知ることができません。もちろん財団職員やコントラクターが翻訳するわけでは無いので、'''安心して、日ごろの不満など'''、ご記入ください。
理事会メンバー（ウィキメディア財団の上部組織の構成員）が全て読みます。
--[[利用者:YShibata (WMF)|YShibata (WMF)]] ([[利用者・トーク:YShibata (WMF)|トーク]]) 2022年3月22日 (火) 10:06 (UTC)

== &lt;section begin=&quot;announcement-header&quot; /&gt;ユニバーサル行動規範Universal Code of Conduct 施行ガイドライン 批准投票は締め切りとなりました。&lt;section end=&quot;announcement-header&quot; /&gt; ==

&lt;section begin=&quot;announcement-content&quot; /&gt;
:''[[m:Special:MyLanguage/Universal Code of Conduct/Enforcement guidelines/Voter information/Announcement|このメッセージはMeta-wikiで他の言語に翻訳されています。]]''
:''&lt;div class=&quot;plainlinks&quot;&gt;[[m:Special:MyLanguage/Universal Code of Conduct/Enforcement guidelines/Vote/Closing message|{{int:interlanguage-link-mul}}]] • [https://meta.wikimedia.org/w/index.php?title=Special:Translate&amp;group=page-{{urlencode:Universal Code of Conduct/Enforcement guidelines/Vote/Closing message}}&amp;language=&amp;action=page&amp;filter= {{int:please-translate}}]&lt;/div&gt;''
ご挨拶申し上げます

 [[m:Special:MyLanguage/Universal Code of Conduct|ユニバーサル行動規範]](UCoC)の[[m:Special:MyLanguage/Universal Code of Conduct/Enforcement guidelines|査読後施行ガイドライン]]の批准投票は、協定世界時2022年3月21日に締め切りとなりました。{{#expr:2300}}人を超えるウィキメディアンが世界中で投票しました。運動の一環であるこのプロセスに参加した皆さん、ありがとうございました。 現在、精査グループが投票を検証しています。作業が終わるまで最大2週間ほどかかります。

投票による最終結果は、関連統計やコメントのまとめとともに、発表され次第、[[m:Special:MyLanguage/Universal Code of Conduct/Enforcement guidelines/Voting/Results|こちら]]に掲載されます。次のステップについては [[m:Special:MyLanguage/Universal Code of Conduct/Enforcement guidelines/Voter information|投票インフォメーションページ]] をご覧ください。プロジェクトのトークページ [[m:Talk:Universal Code of Conduct/Enforcement guidelines|on Meta-wiki]] には、どの言語でもコメントを書くことができます。また、UCoCプロジェクトチームへの電子メールによる連絡も可能です。ucocproject[[File:At sign.svg|16x16px|link=|(_AT_)]]wikimedia.org

よろしくお願いいたします。

運動戦略と組織統治&lt;br /&gt;&lt;section end=&quot;announcement-content&quot; /&gt;--[[利用者:YShibata (WMF)|YShibata (WMF)]] ([[利用者・トーク:YShibata (WMF)|トーク]]) 2022年3月22日 (火) 08:23 (UTC)

== 財団がこれから行おうとしていることについて日本語Zoomミーティング4月1日金曜22:00～23:00 ==

おはようございます！こんにちは！こんばんは！ 
ウィキメディア財団、運動戦略と組織統治チームの柴田由美子[https://meta.wikimedia.org/wiki/Movement_Strategy_and_Governance/Team/ja]と申します。
表題のお題は以下の通りです。

1. 新しい規範の施行についての投票の報告[https://meta.wikimedia.org/wiki/Universal_Code_of_Conduct/Enforcement_guidelines/Voting/Results/ja]
:1) 日本語コミュニティ有権者数 = 3375 (英語、ドイツ語、フランス語についで第三位。第四位以下、ロシア語、スペイン語)
:2) 日本語コミュニティ投票者数 = 81 (世界中で2352人が投票。日本語コミュニティはこのうち3.444%　中国語も全く同じ%で、両言語7番目)
:3) 言語別投票者数降順：英語、ドイツ語、フランス語、ロシア語、ポーランド語、スペイン語、中国語と日本語が同数、イタリア語
:4) 投票した人/有権者 = 2.400%  (言語別で世界最小。日本語コミュニティの次に低いのがウクライナ語)(上記リンクが存在しなかったとき、柴田は% of electorateをEligible who votedと勘違いしていました。18日ミーティングなどで5%と表してしまいました。もうしわけありません)

システム上、投票者名・賛成/反対・コメントの三つは切り離されて集計されています。

2. 今後の予定[https://meta.wikimedia.org/wiki/Movement_Strategy/Initiatives/ja]
:1) 投票結果発表(3月31日まで精査)[https://meta.wikimedia.org/wiki/Universal_Code_of_Conduct/Project/ja]
:2) 理事会(財団の上位組織)選挙 (今年の夏に投票 詳細は来月末？に理事会が発表)
:3) 運動憲章　Movement Charter[https://meta.wikimedia.org/wiki/Movement_Charter/ja](上記の「新しい規範」は安全と包括性を確保するため、「運動憲章」は意思決定に公平さを確保するため )
:4) ハブ　Hubs [https://meta.wikimedia.org/wiki/Hubs/ja] (意思決定に公平さを確保するため )
:5) リーダーシップ開発ワーキンググループ[https://meta.wikimedia.org/wiki/Leadership_Development_Working_Group/ja#3._Timeline]
:6) ウィキマニア 8月11日 -14日 「primarily virtual, with support for local gatherings and events where possible」

3. 助成金 Grants[https://meta.wikimedia.org/wiki/Grants:Start/ja]


カメラオフ、ミュートで構いません。録音・録画はしません。

参加してくださる方はお手数をおかけしますが署名をお願いいたします。
:署名のページ[[https://ja.wikipedia.org/wiki/%E5%88%A9%E7%94%A8%E8%80%85:YShibata_(WMF)/UCoC%E3%83%9F%E3%83%BC%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0/20220401]]

:後日ウィキメールでオンラインミーティングのIDを送信します。(したがってメールの受信を許可している場合に限られます)
Zoomで行いますので、お名前は署名と同じお名前をZoomの名前としてくださるようお願いいたします。
--[[利用者:YShibata (WMF)|YShibata (WMF)]] ([[利用者・トーク:YShibata (WMF)|トーク]]) 2022年3月23日 (水) 07:42 (UTC)


===上記「今後の予定」が決まった過程===
[[metawiki:Strategy/Wikimedia_movement/2018-20/Reports/Movement_Strategy_Playbook/ja|利用者さんたちの話し合いの過程はこちら]]--[[利用者:YShibata (WMF)|YShibata (WMF)]] ([[利用者・トーク:YShibata (WMF)|トーク]]) 2022年3月25日 (金) 12:36 (UTC)


===新年度の計画===

ウィキメディア財団の会計年度は7月に始まり、6月に終わります。

現在、新年度の計画を立てています。以下は次期計画の基礎です。

* [[foundationsite:about/financial-reports/#a1-2021-2022|ファイナンシャル報告]]（2005年～2021年）
* [[metawiki:Wikimedia_Foundation_Medium-term_plan_2019/Annual_Plan_2021-2022/ja|年次計画2021-2022]]
* [[c:File:Wikimedia_Foundation's_2021-2022_Annual_Plan_Overview.pdf|英語pdf]]
* [[metawiki:Wikimedia_Foundation_Medium-term_plan_2019/ja|2019年中期事業計画]]

おまけ
* [https://www.submarinecablemap.com/landing-point/marseille-france 世界中の海底ケーブル地図]（テックチームが上層部への説明に使用したそうです）
* [[foundationsite:about/jobs/|求人情報]]「急募3年間オーストラリアに住む人renewable contract with a good salary and other incentives」
--[[利用者:YShibata (WMF)|YShibata (WMF)]] ([[利用者・トーク:YShibata (WMF)|トーク]]) 2022年3月26日 (土) 08:23 (UTC)

== &lt;section begin=&quot;announcement-header&quot; /&gt;リーダーシップ開発ワーキンググループ: 応募期間中です。2022年4月10日まで。日本語コミュニティから複数人数応募であれば日本語だけのグループになることもできます。&lt;section end=&quot;announcement-header&quot; /&gt; ==
&lt;section begin=&quot;announcement-content&quot; /&gt;
:''[[m:Special:MyLanguage/Leadership Development Working Group/Participate/Announcement/Reminder|このメッセージはMeta-wikiで他の言語に翻訳されています。]]''
:''&lt;div class=&quot;plainlinks&quot;&gt;[[m:Special:MyLanguage/Leadership Development Working Group/Participate/Announcement/Reminder|{{int:interlanguage-link-mul}}]] • [https://meta.wikimedia.org/w/index.php?title=Special:Translate&amp;group=page-{{urlencode:Leadership Development Working Group/Participate/Announcement/Reminder}}&amp;language=&amp;action=page&amp;filter= {{int:please-translate}}]&lt;/div&gt;''
皆さん、こんにちは。

ウィキメディア財団コミュニティ開発チームは、コミュニティ主導の[[m:Special:MyLanguage/Leadership Development Working Group|リーダーシップ開発ワーキンググループ]]の設立を支援しています。このワーキンググループの目的は、各コミュニティを活発にすることです。2022年2月にフィードバックが集められ、[[m:Special:MyLanguage/Leadership Development Working Group/Participate#5. Summary of Call for Feedback|フィードバックのまとめ]]がMeta-wikiに掲載されています。ワーキンググループへの参加募集は、2022年4月10日に締め切られます。ぜひ[[m:Special:MyLanguage/Leadership Development Working Group/Purpose and Structure#3. How is the working group formed and structured?|ワーキンググループの情報を確認]]して、興味を持ちそうなコミュニティメンバーに伝えてください。もちろん、[[m:Special:MyLanguage/Leadership Development Working Group/Participate#1. How to participate|興味のある方は応募]]してください。各言語ごとに活動を行うという計画になりました。編集を教えていらっしゃる方々、新しいことを考えていらっしゃる方々、是非、ご応募ください。 

よろしくお願いします。 

コミュニティ開発チームより&lt;br/&gt;&lt;section end=&quot;announcement-content&quot; /&gt;--[[利用者:YShibata (WMF)|YShibata (WMF)]] ([[利用者・トーク:YShibata (WMF)|トーク]]) 2022年3月30日 (水) 06:17 (UTC)

== &lt;section begin=&quot;announcement-header /&gt;ユニバーサル行動規範Universal Code of Conduct(UCoC)施行ガイドライン批准投票結果&lt;section end=&quot;announcement-header&quot; /&gt; ==
&lt;section begin=&quot;announcement-content&quot; /&gt;
: ''[[m:Special:MyLanguage/Universal Code of Conduct/Enforcement guidelines/UCoC Phase 2 Ratification Results Announcement|このメッセージはMeta-wikiで他の言語に翻訳されています。]]''
: ''&lt;div class=&quot;plainlinks&quot;&gt;[[m:Special:MyLanguage/Universal Code of Conduct/Enforcement guidelines/UCoC Phase 2 Ratification Results Announcement|{{int:interlanguage-link-mul}}]] • [https://meta.wikimedia.org/w/index.php?title=Special:Translate&amp;group=page-{{urlencode:Universal Code of Conduct/Enforcement guidelines/UCoC Phase 2 Ratification Results Announcement}}&amp;language=&amp;action=page&amp;filter= {{int:please-translate}}]&lt;/div&gt;''

こんにちは、

先日行われた [[m:Special:MyLanguage/Universal Code of Conduct/Enforcement guidelines|Enforcement Guidelines for the Universal Code of Conduct (UCoC)]] のコミュニティ投票に参加した2,300人以上のウィキメディアンに感謝いたします。 ボランティアである精査グループが投票の正確性について検証を終えました。[[m:Special:MyLanguage/Universal Code of Conduct/Enforcement guidelines/Voting/Results|''最終結果はMeta-wikiで入手できます'']]。簡単な要約は以下の通りです。 

* 58.6% Yes, 41.4% No
* 貢献者の方々は、128 home wikis から投票しました
* 30を超える言語で行われました

この結果が意味していること、それは理事会がこの文書を見直す可能性に十分な支持があるということです。施行ガイドラインが自動的に完成したというわけではないということです。

したがってプロジェクトチームは、投票プロセスで提供されたコメントを照合・要約し、メタウィキ上で公開します。施行ガイドラインは、理事会に提出され、その審議に付されます。理事会は、投票時に寄せられた意見を検討し、ガイドラインにさらなる改良が必要な点を検討します。これらのコメントと、メタウィキや他のコミュニティとの対話を通じて提供された意見はガイドラインを改訂するための出発点となります。 

理事会が批准に踏み切った場合、UCoCプロジェクトチームは、ガイドラインの具体的な提案の支援を開始する予定です。その中には、コミュニティメンバーと共にU4C構築委員会を立ち上げること、研修に関する協議を開始すること、報告システムの改善に関する話し合いをサポートすることなどが含まれます。まだまだやるべきことはたくさんありますが、次のフェーズに進むことができそうです。

この方針と施行ガイドラインがコミュニティのためにどのように機能するかを考えるために、多くの人々が参加しました。この一年間さまざまな形でプロジェクトに関わったウィキメディアンが提示した、ガイドラインに概説された強力な提案の詳細について、引き続き共同作業を行います。 

改めて、本施行ガイドラインの投票にご参加いただいた皆様に感謝申し上げます。

詳細は [[m:Special:MyLanguage/Universal Code of Conduct/Enforcement guidelines/Voting/Results|the Results page]]をご覧ください。 

これからもよろしくお願いいたします、

[[User:SNg (WMF)]]

 UCoC プロジェクトチームを代表してStella Ng

Senior Manager, Trust and Safety Policy&lt;br/&gt;&lt;section end=&quot;announcement content&quot; /&gt;


翻訳と投稿--[[利用者:YShibata (WMF)|YShibata (WMF)]] ([[利用者・トーク:YShibata (WMF)|トーク]]) 2022年4月6日 (水) 07:11 (UTC)

== [[User:LINE VITMAX]]という方について ==

あのー，つい最近，この方がブロックされて，ブックスで2本，バーシティで一本この方の不適切投稿を目にしたのですが，まあバーシティのほうはともかく，こっちの方では何故一本しか管理者の方は差し戻ししないのでしょうか^^;;;?。私はこの投稿を最初に見た時，ゲームの方ね，もう面倒だし面白いから，このままにしておこうかなんて思ったんですが^^;;;，でも管理者の方は立場が違いますよね?まあその意図も分からないではないけど^^;;;。でも私も生活がいろいろあって，そんなにこのサイトにがっぷり関わってはいられないので，しばらくはここ，差し戻しとか更新しませんよ。だから対策考えるとしたら，次に本文直してアップする時になりますね。ではでは，以上業務連絡でした。(^^)/--[[利用者:Honooo|Honooo]] ([[利用者・トーク:Honooo|トーク]]) 2022年4月6日 (水) 16:54 (UTC)

あっそうだ，よく考えたら，つい最近すじにく氏の動向に変化有ったので，ゲームはしばらく休んで経済行こうかなーとも思っていたんですよ。どっちにしろ，継続して2分野にしかかかわらない，2ページですね，メインとしてはですが…。だから方針変えて，ゲームの方は差し戻ししておきます。ではでは。--[[利用者:Honooo|Honooo]] ([[利用者・トーク:Honooo|トーク]]) 2022年4月6日 (水) 17:01 (UTC)

== &lt;section begin=&quot;announcement-header&quot; /&gt;運動戦略と組織統治ニュース – 記事 6&lt;section end=&quot;announcement-header&quot;/&gt; == 

&lt;section begin=&quot;ucoc-newsletter&quot;/&gt;
&lt;div style = &quot;line-height: 1.2&quot;&gt;
&lt;span style=&quot;font-size:200%;&quot;&gt;'''運動戦略と組織統治ニュース'''&lt;/span&gt;&lt;br&gt;
&lt;span style=&quot;font-size:120%; color:#404040;&quot;&gt;'''2022年4月　記事6'''&lt;/span&gt;&lt;span style=&quot;font-size:120%; float:right;&quot;&gt;[[m:Special:MyLanguage/Movement Strategy and Governance/Newsletter/6|'''ニュースレター全文はこちら''']]&lt;/span&gt;
----

運動戦略と組織統治ニュース第6号へようこそ。この刷新されたニュースレターでは、運動憲章、輸入、運動戦略を実施するための助成金、理事会選挙、その他MSGに関連するニュースやイベントを配信しています。

このニュースレターは四半期ごとに配信され、より頻度の高いアップデートも毎週配信される予定です。本ニュースレターの配信を希望される方は、[[m:Special:MyLanguage/Global message delivery/Targets/MSG Newsletter Subscription|こちら]]にご登録下さい。
&lt;/div&gt;&lt;div style=&quot;margin-top:3px; padding:10px 10px 10px 20px; background:#fffff; border:2px solid #808080; border-radius:4px; font-size:100%;&quot;&gt;

*'''リーダーシップ開発 -''' ワーキンググループが結成されます! 2022年4月10日に募集を締め切った「リーダーシップ開発ワーキンググループ」に、最大12名のコミュニティメンバーが参加することが決定しました。([[:m:Special:MyLanguage/Movement Strategy and Governance/Newsletter/6#A1|続きを読む]])
*'''ユニバーサル行動規範の批准結果発表 -''' 3月7日から21日にかけて、SecurePollによるUCoCの施行に関するグローバルな意思決定プロセスが行われました。少なくとも128のホームプロジェクトから2,300人以上の有権者が意見・コメントを寄せました。([[:m:Special:MyLanguage/Movement Strategy and Governance/Newsletter/6#A2|続きを読む]])
*'''ハブをめぐる運動論議-''' 3月12日（土）、地域・テーマ別ハブに関するグローバル対話イベントが開催され、運動全体から84名の多様なウィキメディアンが参加しました。([[:m:Special:MyLanguage/Movement Strategy and Governance/Newsletter/6#A3|続きを読む]])
*'''運動戦略のための助成金、引き続き募集中! -''''' 今年に入ってから、6件、総額約8万ドルの提案が承認されています。運動戦略プロジェクトのアイデアはありませんか？声をかけてください。([[:m:Special:MyLanguage/Movement Strategy and Governance/Newsletter/6#A4|続きを読む]])
*運動憲章起草委員会が発足しました。-''' 2021年10月に選出された15名の委員からなる委員会は、その活動に不可欠な価値観や方法について合意し、運動憲章草案の概要作成に着手しています。([[:m:Special:MyLanguage/Movement Strategy and Governance/Newsletter/6#A5|続きを読む]])
*'''週刊運動戦略のご紹介 -'''。投稿と購読をお願いします - MSGチームは、メタウィキ上の様々な運動戦略ページに接続された更新ポータルを立ち上げたところです。購読していただくと、現在進行中の様々なプロジェクトに関する最新のニュースを入手することができます。([[:m:Special:MyLanguage/Movement Strategy and Governance/Newsletter/6#A6|続きを読む]])
*'''Diff Blogs -'''Wikimedia DiffでUCoCに関する最新の出版物をチェックしてください。 ([[:m:Special:MyLanguage/Movement Strategy and Governance/Newsletter/6#A7|続きを読む]])
&lt;/div&gt;&lt;section end=&quot;ucoc-newsletter&quot;/&gt;読んでくださってありがとうございます--[[利用者:YShibata (WMF)|YShibata (WMF)]] ([[利用者・トーク:YShibata (WMF)|トーク]]) 2022年4月13日 (水) 06:44 (UTC)

== &lt;section begin=&quot;announcement-header&quot; /&gt;ウィキメディア財団の年次計画をめぐり、マリアナ・イスカンダーと話しませんか&lt;section end=&quot;announcement-header&quot; /&gt; ==
&lt;section begin=&quot;announcement-content&quot; /&gt; 
:[[m:Special:MyLanguage/Wikimedia Foundation Annual Plan/2022-2023/Conversations/Announcement|''このメッセージはメタウィキ（Meta-wiki）で他の言語に翻訳されています。'']]
:''&lt;div class=&quot;plainlinks&quot;&gt;[[m:Special:MyLanguage/Wikimedia Foundation Annual Plan/2022-2023/Conversations/Announcement|{{int:interlanguage-link-mul}}]] • [https://meta.wikimedia.org/w/index.php?title=Special:Translate&amp;group=page-{{urlencode:Wikimedia Foundation Annual Plan/2022-2023/Conversations/Announcement}}&amp;language=&amp;action=page&amp;filter= {{int:please-translate}}]&lt;/div&gt;''

こんにちは

[[m:Special:MyLanguage/Movement Communications|運動意思疎通]]チーム&lt;sup&gt;※1&lt;/sup&gt;と[[m:Special:MyLanguage/Movement Strategy and Governance|運動戦略・組織統治]]チーム&lt;sup&gt;※2&lt;/sup&gt;では、'''[[m:Special:MyLanguage/Wikimedia Foundation Annual Plan/2022-2023/draft|2022-23年ウィキメディア財団年次計画]]'''すなわちウィキメディア財団のPOR&lt;sup&gt;※3&lt;/sup&gt;（訳注：利害関係者の同意が必要な活動計画）をめぐり、皆さんと協議したいと考えます。（※：1＝Movement Communications。2＝Movement Strategy and Governance。3＝plan of record。）

これらの対話は、[[m:User:MIskander-WMF|マリアナ・イスカンダー]]（Maryana Iskander）が進めてきた[[m:Special:MyLanguage/Wikimedia Foundation Chief Executive Officer/Maryana’s Listening Tour|ウィキメディア財団最高経営責任者の聴き取りツアー]]の延長線上にあります。 

対話では次の質問を取り上げます。
* [[m:Special:MyLanguage/Wikimedia 2030|2030年ウィキメディア運動戦略]]では、方向性として「サービスとしての知識」ならびに「知識の公平さ」を提唱しています。財団はこれら2つのゴールに従って計画を立てようとしています。財団がその業務において、これらをどのように適合させるべきでしょうか？
* 財団は地域レベルでの働きかけにもっと優れた方法がないか探し続けています。たとえば助成金、新しい機能、コミュニティとの対話などの領域で地域単位に注目ポイントを増やしてきました。うまくいっているのはどれでしょう？ 改善できるとしたら、何かですか？
* ウィキメディアの運動戦略過程にはどなたでも貢献ができます。皆さんの活動や発想、要望、実地に体験から学んだことを出し合いませんか。運動戦略の活動を進めているボランティアや提携団体の皆さんを、どうやったらウィキメデア財団はもっとうまくサポートできそうでしょうか？

日時は [[m:Special:MyLanguage/Wikimedia Foundation Annual Plan/2022-2023/draft/Your Input|'''Meta-wiki''']]でご覧ください。

情報は複数言語で提供します。どの会議もどなたでも参加できます。中には逐次通訳を用意する会議もあります。

どうぞよろしくお願いいたします。&lt;br /&gt;&lt;section end=&quot;announcement-content&quot; /&gt;--[[利用者:YShibata (WMF)|YShibata (WMF)]] ([[利用者・トーク:YShibata (WMF)|トーク]]) 2022年4月15日 (金) 08:44 (UTC)

==財団の新年度計画についてトップと話しませんか。4月24日日曜16:00(プロの同時通訳が付く予定です)==

直前の節をご覧いただければありがたいです。日本語コミュニティのために力をおかしください。

[[metawiki:Wikimedia_Foundation_Annual_Plan/2022-2023/draft/Goals/ja|「多言語にわたる740以上のウィキメディア・プロジェクトが増え続ける中、財団の現在の支援にどのように優先順位をつけるべきか」]]&lt;blockquote&gt;上記リンクの中には「 偽情報とどう戦うか」「世界のさまざまな地域の～中略～耳を傾けることから1年をスタートさせます」「優先順位の議論」「財団全体での翻訳・通訳サービス」「今後数ヶ月の間に」と書かれています。&lt;/blockquote&gt;
[[metawiki:Wikimedia_Foundation_Chief_Executive_Officer/Maryana’s_Listening_Tour/ja|トップ]]は約六カ月前に就任しました。「[[metawiki:Wikimedia_Foundation_Chief_Executive_Officer/Maryana’s_Listening_Tour/External_Trends/ja|人々が検索するものが変わってきています。利用者は、検索クエリに対する答えをリッチコンテンツ（画像、ビデオ、オーディオ形式など）に求めるようになってきています。]]」&lt;blockquote&gt;上記リンクの中で、以下の内容などについて'''ご意見を記入'''できます。

「従来のテキスト検索によるトラフィックのほとんどに依存しているプラットフォームとして、検索行動のこれらのシフトは、私たちの現在および将来にとって何を意味するのでしょうか？」

「自分の言語には無いコンテンツを検索するユーザーは、機械翻訳されたウェブサイトコンテンツ（ウィキペディアを含む）を目にする機会が増えています」

「ウィキメディアのプロジェクトは、どのようにすれば関連するローカル言語の知識のギャップを確実に埋めることができるでしょうか。 他のプラットフォームとは異なる、私たちのコミュニティ主導のコンテンツ作成モデルについて、どのように認識を高め続けることができるでしょうか」

「偽情報と誤報が増加」

「Google と Facebook は、ウィキペディアのホバーカードを使用して、誤解を招く可能性のある情報に対してより多くのコンテキストを提供」

「誤報や偽情報がウィキメディア・プロジェクトや他のプラットフォーム上の情報の質を脅かしている中、より広い知識のエコシステムにおける偽情報への対処において、ウィキメディア運動が果たすべき役割があるとすれば、それは何でしょうか」&lt;/blockquote&gt;


年次計画についてのご意見はこちらにお願いいたします[https://meta.wikimedia.org/wiki/Talk:Wikimedia_Foundation_Annual_Plan/2022-2023/draft]

'''参加方法'''　24日については、事前の登録は不要です。下にある全日程のリンクをクリックし、●右をクリックするとズームにつながります。--[[利用者:YShibata (WMF)|YShibata (WMF)]] ([[利用者・トーク:YShibata (WMF)|トーク]]) 2022年4月18日 (月) 08:39 (UTC)


[[metawiki:Wikimedia_Foundation_Annual_Plan/2022-2023/draft/Your_Input/ja|4月24日を含む全日程]]&lt;blockquote&gt;
21日の理事との話し合いについて、日本語コミュニティの一人から通訳の依頼が担当者にあったそうです。その担当者から、「YShibata ではないですね」という確認がありました。私は内部でいろいろな機会をとらえては日本語のチャンスを頼んできましたが、他の多くの言語でも同様です。そのため、利用者の方々からの働きかけが最も効果的です。私ではないと分かったので通訳派遣会社に依頼をするそうです。

日本語コミュニティ利用者の方々の働きかけの大きさが発揮されたのがユニバーサル行動規範の施行ガイドライン投票です。どなたが何を書いたのかは誰にもわかりませんが、日本語コミュニティから８１人が投票しました。全体として賛成が反対を上回った（わずか）にもかかわらず、文言修正（コメントを参照しながら)になりました。

&lt;/blockquote&gt;[[metawiki:Wikimedia_Foundation_Chief_Executive_Officer/Maryana’s_Listening_Tour/Overview/ja|すべてのメッセージをMaryanaに伝えます（必要に応じて翻訳もします）]]。(お手数をおかけしますがスクロールダウンをして真ん中あたりです)

[[metawiki:Wikimedia_Foundation_Chief_Executive_Officer/Maryana’s_Listening_Tour/Overview/ja|もし、トップのMaryanaをイベントに招待したい場合]]は、movementcomms@wikimedia.orgでご連絡ください。なお、Maryanaはできるだけ多くの人に会うようにしていますが、すべてのイベントに参加できない可能性があります。

--[[利用者:YShibata (WMF)|YShibata (WMF)]] ([[利用者・トーク:YShibata (WMF)|トーク]]) 2022年4月15日 (金) 08:45 (UTC)

== &lt;section begin=&quot;announcement-header&quot; /&gt;次のステップ: ユニバーサル行動規範（Universal Code of Conduct略UCoC）およびUCoC施行ガイドライン&lt;section end=&quot;announcement-header&quot; /&gt; ==
&lt;section begin=&quot;announcement-content&quot; /&gt;
:''&lt;div class=&quot;plainlinks&quot;&gt;[[m:Special:MyLanguage/Wikimedia Foundation Board noticeboard/April 2022 - Board of Trustees on Next steps: Universal Code of Conduct (UCoC) and UCoC Enforcement Guidelines|{{int:interlanguage-link-mul}}]] • [https://meta.wikimedia.org/w/index.php?title=Special:Translate&amp;group=page-{{urlencode:Wikimedia Foundation Board noticeboard/April 2022 - Board of Trustees on Next steps: Universal Code of Conduct (UCoC) and UCoC Enforcement Guidelines}}&amp;language=&amp;action=page&amp;filter= {{int:please-translate}}]&lt;/div&gt;''

ウィキメディア財団理事会のコミュニティアフェアーズ委員会は、先日行われた「ユニバーサル行動規範（UCoC）」の施行ガイドラインについてコミュニティの投票に参加された皆様に感謝いたします。 

ボランティア精査班が投票の正確性の検証を終えました。総投票数は2,283票でした。2,283票のうち、1,338人（58.6%）が施行ガイドラインに賛成、945人（41.4%）が反対です。また、658名の方からコメントをいただき、そのうち77％が英語でのコメントでした。

敵対的で有害な行為を止めさせるため、また、そのような行為の標的となった人々を支援し、ウィキメディアのプロジェクトにおいて善意の人々が生産的になるよう、安全で歓迎すべき文化を創造するためにコミュニティメンバーが示した情熱と献身に感謝いたします。 

寄せられたコメントには、ガイドラインが未完成な段階であるとも述べられています。理事会が検討するのに必要な支持率に達しましたが、コミュニティの懸念に対応するため、さらなる編集を開始することが望ましいと思われる場合には、賛否にかかわらず、修正が必要だと思われる要素とその理由についてご意見を提供するよう、有権者に呼び掛けていました。 

その結果、コミュニティアフェアーズ委員会として、財団に草案作成委員会を再開し、先日の投票で寄せられたコミュニティの意見をもとに、施行ガイドラインを改良するため、再度コミュニティ参加を行うよう要請することを決定しました。 

ご意見は4つのセクションに分類しています。

# 研修の種類、目的、適用範囲を明確にすること。
# 専門家でない人が翻訳や理解をしやすいように、言葉を単純化すること。
# affirmation（訳注：日本語コミュニティでも多くのご意見が出ました）という概念について、その是非を含めて探求すること。
# プライバシー/被害者保護と聞く権利の相反する役割を見直すこと。

対話の中で、また特に施行ガイドラインの草案が進化する中で、他の問題が浮上するかもしれませんが、これらを有権者が懸念する主要な分野と見なし、これらの問題の検討を促進するよう、委員会はスタッフに求めています。さらなる関与の後、財団は、改訂された施行を評価するためにコミュニティ投票を再度行い、新しい文書が公式に批准する準備ができているかどうかを確認する必要があります。

さらに、ユニバーサル行動規範方針（Policy）の注釈（note）3.1に対する懸念も認識しています。年末に予定されている方針全体の見直しを待たずに、方針が安全で包括的なコミュニティを支援するという目的を満たすよう、文言の見直しを促進するよう委員会は財団に指示しています。

参加された皆様には、このような重要かつ困難な課題について考えていただき、運動全体でより良い協力関係を築くために貢献していただいたことに、改めて感謝いたします。&lt;br /&gt;&lt;section end=&quot;announcement-content&quot; /&gt;

これからもよろしくお願いいたします

Rosie

Rosie Stephenson-Goodknight (she/her) コミュニティ事案委員会長代理 ウィキメディア財団　理事会

（当初、上記署名が翻訳フォーマットに無かったため混乱させてしまったことをお詫び申し上げます。）訳・掲載[[利用者:YShibata (WMF)|YShibata (WMF)]] ([[利用者・トーク:YShibata (WMF)|トーク]]) 2022年4月18日 (月) 23:54 (UTC)

== &lt;section begin=&quot;announcement-header&quot; /&gt;2022年理事会選挙候補者の募集&lt;section end=&quot;announcement-header&quot; /&gt; ==
&lt;section begin=&quot;announcement-content&quot; /&gt; 
:''[[m:Special:MyLanguage/Wikimedia Foundation elections/2022/Announcement/Call for Candidates/Short|このメッセージはMeta-wikiで他の言語に翻訳されています。]]''
:''&lt;div class=&quot;plainlinks&quot;&gt;[[m:Special:MyLanguage/Wikimedia Foundation elections/2022/Announcement/Call for Candidates/Short|{{int:interlanguage-link-mul}}]] • [https://meta.wikimedia.org/w/index.php?title=Special:Translate&amp;group=page-{{urlencode:Wikimedia Foundation elections/2022/Announcement/Call for Candidates/Short}}&amp;language=&amp;action=page&amp;filter= {{int:please-translate}}]&lt;/div&gt;''

理事会は2022年理事選挙の候補者を募集しています。[[m:Special:MyLanguage/Wikimedia_Foundation_elections/2022/Announcement/Call_for_Candidates|'''続きはメタウィキをご参照ください''']]。

[[m:Special:MyLanguage/Wikimedia Foundation elections/2022|2022年理事会選挙]]はこちら！ 理事への立候補をご検討ください。

ウィキメディア財団理事会は、ウィキメディア財団の運営を監督します。コミュニティおよび提携団体から選ばれた理事と、理事会が任命した理事が理事会を構成します。各理事の任期は3年です。ウィキメディアコミュニティには、投票によりコミュニティ兼提携団体出身の理事を選ぶ機会があります。

ウィキメディアコミュニティは、2022年に理事会の2つの議席を埋めるために投票を行います。チームとしての理事会の代表性、多様性、専門性を向上させるチャンスです。

どのような人が候補になるのでしょうか？ ご自身はいかがでしょうか？ 詳しくは[[m:Special:MyLanguage/Wikimedia Foundation elections/2022/Apply to be a Candidate|立候補のページ]]でご確認ください。

ご協力ありがとうございます。 

選挙管理委員会と理事会に代わり、運動戦略と組織統治チーム一同&lt;br /&gt;&lt;section end=&quot;announcement-content&quot; /&gt;
[[Category:Wikimedia Foundation Board of Trustees]]
[[Category:Wikimedia Foundation elections 2022]]
--[[利用者:YShibata (WMF)|YShibata (WMF)]] ([[利用者・トーク:YShibata (WMF)|トーク]]) 2022年4月26日 (火) 14:30 (UTC)

== Coming soon: Improvements for templates ==

&lt;div class=&quot;plainlinks mw-content-ltr&quot; lang=&quot;ja&quot; dir=&quot;ltr&quot;&gt;
&lt;!--T:11--&gt;
[[File:Overview of changes in the VisualEditor template dialog by WMDE Technical Wishes.webm|thumb|テンプレートのダイアログに根本的な変更を施します。]]
こんにちは、まもなく皆さんのウィキに以下のテンプレート系の変更を展開する予定ですのでお知らせします。

[[mw:Special:MyLanguage/Help:VisualEditor/User guide#Editing templates|ビジュアルエディターには'''テンプレートのダイアログ ''']]（VisualEditor）を、[[mw:Special:MyLanguage/2017 wikitext editor|2017年ウィキ文エディター]]（ベータ版）には'''根本からの改善を'''それぞれご用意しています。
これはテンプレートに書き込むべきこと、テンプレートの各部の読み方やそれぞれの変数の追加方法&lt;!-- how to navigate the template, and how to add parameters. --&gt;について、利用者の皆さんの理解を助けるものです。
* それぞれのリンクは[[metawiki:WMDE Technical Wishes/VisualEditor template dialog improvements|プロジェクトページ]]、[[metawiki:Talk:WMDE Technical Wishes/VisualEditor template dialog improvements|トークページ]]をご参照ください。

'''構文強調表示'''機能([[mw:Special:MyLanguage/Extension:CodeMirror|CodeMirror]] 拡張機能) では、利用者設定にて'''色覚にやさしい'''配色を選べるようになりました。
* リンクはそれぞれ[[metawiki:WMDE Technical Wishes/Improved Color Scheme of Syntax Highlighting#Color-blind_mode|プロジェクトページ]]、[[metawiki:Talk:WMDE Technical Wishes/Improved Color Scheme of Syntax Highlighting|トークページ]]をご参照ください。

展開は5月10日を予定しています。これは[[m:WMDE Technical Wishes|WMDE 技術要望]]（ウィキメディア・ドイツ協会）発信では「[[m:WMDE Technical Wishes/Templates|テンプレート]]」系改善の一連の最後になります。 

ぜひ皆さんからのフィードバックをトークページにてお聞かせください。
&lt;/div&gt; -- [[m:User:Johanna Strodt (WMDE)|Johanna Strodt (WMDE)]] 2022年4月29日 (金) 11:13 (UTC)
&lt;!-- User:Johanna Strodt (WMDE)@metawiki が https://meta.wikimedia.org/w/index.php?title=WMDE_Technical_Wishes/Technical_Wishes_News_list_all_village_pumps&amp;oldid=23222263 のリストを使用して送信したメッセージ --&gt;

== 編集機能ニュース 2022年第1号 ==

&lt;section begin=&quot;message&quot;/&gt;&lt;i&gt;[[metawiki:VisualEditor/Newsletter/2022/April|他の言語で読む]] • [[m:VisualEditor/Newsletter|この多言語版ニュースレターの購読者名簿]]&lt;/i&gt;
[[File:Junior Contributor New Topic Tool Completion Rate.png|thumb|編集初学者はこの新しいツールを使ったほうが編集の失敗が減りました。]]

[[mw:Special:MyLanguage/Help:DiscussionTools#New discussion tool|新しい主題ツール]]&lt;!-- New topic tool --&gt;を使うと、編集者が議論のページに新しい &lt;nowiki&gt;==節（見出し）==&lt;/nowiki&gt; を作りやすくなります。  この新しいツールを使うと、編集初学者の編集が保持されやすくなります。  &lt;span class=&quot;mw-translate-fuzzy&quot;&gt;状況報告は[[mw:Talk pages project/New topic#21 April 2022|こちら]]にあります。&lt;/span&gt;  間もなく編集チームはこの試験に参加する20個のウィキペディアの編集者全員にこのことを要請します。  無効にするには[[Special:Preferences#mw-prefsection-editing-discussion|個人設定]]で指定してください。&lt;section end=&quot;message&quot;/&gt;

[[User:Whatamidoing (WMF)|Whatamidoing (WMF)]] 2022年5月2日 (月) 18:55 (UTC)
&lt;!-- User:Quiddity (WMF)@metawiki が https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/VisualEditor/Newsletter/Wikis_with_VE&amp;oldid=22019984 のリストを使用して送信したメッセージ --&gt;

== &lt;section begin=&quot;announcement-header&quot; /&gt;ウィキメディア財団理事会2022年選挙 - ボランティア募集&lt;section end=&quot;announcement-header&quot; /&gt; ==
&lt;section begin=&quot;announcement-content&quot; /&gt;
:''[[m:Special:MyLanguage/Movement Strategy and Governance/Election Volunteers/2022/Call for Election Volunteers|このメッセージはMeta-wikiで他の言語に翻訳されています。]]''
:''&lt;div class=&quot;plainlinks&quot;&gt;[[m:Special:MyLanguage/Movement Strategy and Governance/Election Volunteers/2022/Call for Election Volunteers|{{int:interlanguage-link-mul}}]] • [https://meta.wikimedia.org/w/index.php?title=Special:Translate&amp;group=page-{{urlencode:Movement Strategy and Governance/Election Volunteers/2022/Call for Election Volunteers}}&amp;language=&amp;action=page&amp;filter= {{int:please-translate}}]&lt;/div&gt;''
運動戦略と組織統治チームでは、理事会選挙の選挙ボランティアとしてローカルで活動していただける方々を募集しています。

選挙ボランティアのアイデアは、2021年ウィキメディア理事会選挙で出てきました。効果がありました。選挙ボランティアのおかげで2017年と比較し、投票者は1,753人増加しました。 全体の投票率は1.1ポイント増の10.13%でした。214のウィキが選挙に反映されました。 

2017年に参加しなかった合計74のウィキから、2021年の選挙では投票者があらわれました。今年も投票者を増やすために力を貸していただけませんか？

選挙ボランティアは、以下のような分野で活躍します。
* 短いメッセージを翻訳し、ご自身のコミュニティで進行中の選挙プロセスを告知。
* 任意。ご自身のコミュニティでのコメントや質問のモニター

ボランティアは、

* 対話やイベントの際に、フレンドリーな空間ポリシーを維持させます。
* ガイドラインや投票情報を中立的な立場でコミュニティーに提示します。

選挙ボランティアになり、ご自身のコミュニティが投票で反映されるようにしませんか？[[m:Special:MyLanguage/Movement Strategy and Governance/Election Volunteers/About|こちら]] に登録して最新情報を受け取りましょう。翻訳に関する質問は、[[m:Special:MyLanguage/Talk:Movement Strategy and Governance/Election Volunteers/About|トークページ]]をご利用ください。&lt;br /&gt;&lt;section end=&quot;announcement-content&quot; /&gt;--[[利用者:YShibata (WMF)|YShibata (WMF)]] ([[利用者・トーク:YShibata (WMF)|トーク]]) 2022年5月6日 (金) 10:48 (UTC)

== ウィキブックスの整理 ==

もう実行されているものもあるかもしれませんが

# &lt;code&gt;&lt;nowiki&gt;{{UserAN}}&lt;/nowiki&gt;&lt;/code&gt;テンプレートの作成
# CU、OS、その他管理者の下位権限（巻き戻し者，削除者、インターフェース管理者など）の方針の明記
# 依頼関連の整備
# [[Wikibooks:コメント依頼]]の作成

最後に，これが1番の難題ですが

: 5. 利用者の増加

1については、ブロックを実行しやすくするためです。[[w:WP:AN/I]]で採用されているものは，「ブロック」リンクがついています。

2は、ソックパペットの確認、機密情報の秘匿化などを実施するためです。Wikipediaに準じたものでいいと思います。下位権限などは必要であればといったところでしょうか。

3は投稿ブロック依頼，削除依頼などですね。依頼ごとに個別のサブページを作り，合意が形成されればその通りに対処を行う。削除依頼などには合意形成がなされているのに未対処という案件も少々あります。また、サブページを作れば依頼の可読性がアップします。投稿ブロック依頼などにはサブページを作ったり作らなかったりとまちまちです。

4はコメント依頼の必要性です。特に利用者の行為については，会話ページ，ノートページなどで議論するわけにも行きません。ですが先述の通り，コメント依頼は赤リンクです。合意形成，またトラブルの円滑な処理、[[w:Wikipedia:論争の解決]]の観点から見てもコメント依頼は必要であると感じます。

5番は難しいですが，まあ今いる我々がプロジェクトをでかくしていけば自然に参加する人も増えてくると思います。--[[利用者:スタリオン箕浦|スタリオン箕浦]] &lt;small&gt;([[利用者・トーク:スタリオン箕浦|会話]]/[[特別:投稿記録/スタリオン箕浦|投稿記録]]/[[特別:Log/スタリオン箕浦|ログ]]/[[特別:メール送信/スタリオン箕浦|メール]])&lt;/small&gt; 2022年5月8日 (日) 04:26 (UTC)

:こんばんはー。私はルール関係の整備にはあまり興味なくて，むしろあいまいなほうが書きやすいなーなどとも思っています。参加人員はどうですかね。むかしはここ，もう少し盛況だったんですが，様々な理由で活動休止された方が多くなってしまいましたね…。ところでサイト形式の整備はいいんですが，例えば私と先輩のブロック依頼なんて，構造が複雑になってしまって，あまり良くない状態ですよ…。そうですね，目指している版削除が仮になされれば，少しすっきり纏められるでしょうけどね…。まあ仕方ないですね，どっちにしろブロック依頼もコメント依頼もあまりこの先進展有るようにも見えませんしね…--[[利用者:Honooo|Honooo]] ([[利用者・トーク:Honooo|トーク]]) 2022年5月8日 (日) 09:36 (UTC)
::（返信）　利用者が少ないゆえに綿密な対応ができないのが1番の課題ですね。--[[利用者:スタリオン箕浦|スタリオン箕浦]] &lt;small&gt;([[利用者・トーク:スタリオン箕浦|会話]]/[[特別:投稿記録/スタリオン箕浦|投稿記録]]/[[特別:Log/スタリオン箕浦|ログ]]/[[特別:メール送信/スタリオン箕浦|メール]])&lt;/small&gt; 2022年5月8日 (日) 10:13 (UTC)
:::綿密な対応ってそんな重要?--[[利用者:Honooo|Honooo]] ([[利用者・トーク:Honooo|トーク]]) 2022年5月8日 (日) 10:18 (UTC)
::::（返信）利用者が多ければその分視点が広がるので，緻密な対応が可能でしょう。対応がきめ細かければ，トラブルも円滑に処理できるのではないでしょうか。--[[利用者:スタリオン箕浦|スタリオン箕浦]] &lt;small&gt;([[利用者・トーク:スタリオン箕浦|会話]]/[[特別:投稿記録/スタリオン箕浦|投稿記録]]/[[特別:Log/スタリオン箕浦|ログ]]/[[特別:メール送信/スタリオン箕浦|メール]])&lt;/small&gt; 2022年5月8日 (日) 13:22 (UTC)
:::::うーん，そう，かも，知れないですね…。ただ私の感覚では人数が多かろうが少なかろうが，駄目なものは駄目，通るものは通る。トラブルから完全に逃れて生きる事も出来ないしね…。--[[利用者:Honooo|Honooo]] ([[利用者・トーク:Honooo|トーク]]) 2022年5月8日 (日) 16:15 (UTC)
:一応，コメント依頼は私がWikipediaを参考に作ります。1週間待って異論が出なければ実行に移ります。--[[利用者:スタリオン箕浦|スタリオン箕浦]] &lt;span style=&quot;font-family:Times&quot;&gt;&lt;small&gt;([[利用者・トーク:スタリオン箕浦|会話]]/[[特別:投稿記録/スタリオン箕浦|投稿記録]]/[[特別:Log/スタリオン箕浦|ログ]]/[[特別:メール送信/スタリオン箕浦|メール]])&lt;/small&gt;&lt;/span&gt; 2022年5月9日 (月) 23:33 (UTC)
::WikibooksよりはWikipediaの方が盛況ですしね、、、、--[[利用者:ドラみそブックス|ドラみそブックス]] ([[利用者・トーク:ドラみそブックス|トーク]]) 2022年5月10日 (火) 01:26 (UTC)
::{{コメント2|コメント}} 同じ提案は過去にもなされたことがありますが、結局合意には至っておりません。スタリオン箕浦さんも「1週間待って」ではなく過去の議論も参考にし、まさに「合意形成」がされてから実行に移った方がよいと思います。--[[利用者:Shokupan|Shokupan]] ([[利用者・トーク:Shokupan|トーク]]) 2022年5月15日 (日) 10:19 (UTC)
:::{{コメント2|返信}} [[User:Shokupan|Shokupan]]様、過去の提案がいくら探しても見つかりません。--[[利用者:スタリオン箕浦|スタリオン箕浦]] &lt;span style=&quot;font-family:Times&quot;&gt;&lt;small&gt;([[利用者・トーク:スタリオン箕浦|会話]]/[[特別:投稿記録/スタリオン箕浦|投稿記録]]/[[特別:Log/スタリオン箕浦|ログ]]/[[特別:利用者権限/スタリオン箕浦|権限]]/[[特別:メール送信/スタリオン箕浦|メール]])&lt;/small&gt;&lt;/span&gt; 2022年7月18日 (月) 02:59 (UTC)
::::{{コメント2|返信}} 談話室での2019年3月3日 (日) 14:40 (UTC)付けの提案です。また、そこに書かれている意見についてもスタリオン箕浦さんにはよくお読みいただきたいと思います。--[[利用者:Shokupan|Shokupan]] ([[利用者・トーク:Shokupan|トーク]]) 2022年7月24日 (日) 05:50 (UTC)

== 資金の分配を決める委員を募集中（日本語コミュニティを含むアジア太平洋地域を担当） ==

エディタソンなどを行う際の交通費などへの助成等、決定権限は、[[metawiki:Grants:Committees/ja|それぞれの地域の地域委員会]]に属します。日本語コミュニティからの申請を[[metawiki:Grants:Regions/ESEAP/ja|審査する委員（利用者）一覧]] は現在、５人ですが新たな方を募集中です。

交通費などの他、日本語コミュニティからの委員がいれば重要な書類・ミーティングでの通訳について翻訳会社・通訳会社へとの契約を確実にすることができます。

担当者が「ウィキメディア運動の意義を理解する方、文化的・言語的・性的多様性の観点から募集しています 」とのことで、多様性の点で、日本語コミュニティの参加が無いことを心配しています。費用の請求フォーマット、公式ウェブサイト、年度計画、収支報告書など、重要な文書に日本語版がありません。柴田は財団内部で大勢の人に掛け合っていますが、お金の使い方など、重要なことは利用者による委員会が決めます。財団内部の人間ではありません。

興味を持ってくださる方は、ESEAP シニア プログラム オフィサーのジャクリーン・チェン（上記担当者、二番目のリンクに写真が載っています）; jchen@wikimedia.orgにご連絡ください。

締め切りは 31 May 2022年５月31日です。--[[利用者:YShibata (WMF)|YShibata (WMF)]] ([[利用者・トーク:YShibata (WMF)|トーク]]) 2022年5月10日 (火) 15:29 (UTC)

== 移動依頼 ==

どなたか記事[[エスニックジョーク]]を[[ジョーク集/エスニックジョーク]]へ移動お願いします。--[[特別:投稿記録/240F:7A:EA2E:1:7865:36BF:53E8:693E|240F:7A:EA2E:1:7865:36BF:53E8:693E]] 2022年5月15日 (日) 10:36 (UTC)

:基本的には、合意の必要のない整備は、気づいた人が自分でやるのが基本です。各種ヘルプを参照すれば、たいていの人は大抵のことが出来る。それでもできないのであれば仕方ないですが…--[[利用者:Honooo|Honooo]] ([[利用者・トーク:Honooo|トーク]]) 2022年5月19日 (木) 15:13 (UTC)
:私が作った記事なので、移動したいですが、--[[利用者:ドラみそ|ドラみそ]] ([[利用者・トーク:ドラみそ|トーク]]) 2022年6月24日 (金) 10:13 (UTC)
* {{cmt|報告}} - &lt;del&gt;依頼者は自動承認されていないので&lt;code&gt;move&lt;/code&gt;権限がありません。&lt;/del&gt;初版立項者のアカウントから「移動したい」との意思表示が&lt;ins&gt;あり、なおかつ他に編集された方がいなかった&lt;/ins&gt;ため代わりに移動しておきました。--[[利用者:春春眠眠|春春眠眠]] ([[利用者・トーク:春春眠眠|トーク]]) 2022年6月24日 (金) 10:44 (UTC)&lt;small&gt;一部修正--[[利用者:春春眠眠|春春眠眠]] ([[利用者・トーク:春春眠眠|トーク]]) 2022年6月24日 (金) 10:49 (UTC)&lt;/small&gt;&lt;small&gt;1部撤回&lt;/small&gt;
* 移動の残骸ですが、即時削除するか残すかは[[利用者:ドラみそ|ドラみそ]]さんにお任せします。即時削除するにせよ、こちらに関しては私はドラみそさんの意向を支持します。--[[利用者:春春眠眠|春春眠眠]] ([[利用者・トーク:春春眠眠|トーク]]) 2022年6月24日 (金) 11:26 (UTC)
* よくよく確認したところ[[利用者:ドラみそ|ドラみそ]]さんは自動承認されているようでした。今回依頼したのはやり方が分からなかったからだと考えます。ですので、[[:w:ja:Help:ページの移動]]をご覧下さいとのご案内を致します。--[[利用者:春春眠眠|春春眠眠]] ([[利用者・トーク:春春眠眠|トーク]]) 2022年6月24日 (金) 12:25 (UTC)
*:わかりました。--[[利用者:ドラみそ|ドラみそ]] ([[利用者・トーク:ドラみそ|トーク]]) 2022年6月27日 (月) 01:37 (UTC)

== ユニバーサル行動規範Universal Code of Conduct(UCoC)施行ガイドライン批准投票でのコメントについて報告します  ==

こんにちは、

ユニバーサル行動規範（UCoC）プロジェクトチームは、批准投票に伴うコメントの分析を完了しました。 

2022年にUCoC施行ガイドライン草案が完成した後、ガイドラインについてウィキメディアン・コミュニティが投票しました。投票者は137のコミュニティにわたり、上位9つのコミュニティは英語、ドイツ語、フランス語、ロシア語、ポーランド語、スペイン語、中国語、日本語、イタリア語のウィキペディア、メタウィキです。 

投票の際、草案の内容に対してコメントを提供する機会がありました。658名の参加者がコメントを残しました。コメントの77%は英語でした。投票者は24の言語でコメントを書き、最も多かったのは英語（508人）、ついでドイツ語（34人）、日本語（28人）、フランス語（25人）、ロシア語（12人）でした。 

この報告書は改訂起草委員会に送られ、委員会は最近行われた投票から得られたコミュニティのご意見をもとに、施行ガイドラインを改良します。報告書の公開版は [[m:Special:MyLanguage/Universal Code of Conduct/Enforcement guidelines/Voting/Results#Summary|'''このMeta-wiki で公開''']] です。 この報告書はメタウィキで翻訳版が公開されています。 {{int:please-translate}} 

投票や議論に参加された方々に改めて感謝申し上げます。是非、今後のコミュニティとの話し合いにご参加ください。ユニバーサル行動規範と施行ガイドラインの詳細については [[m:Special:MyLanguage/Universal Code of Conduct/Project|on Meta-wiki]] をご覧ください。

ユニバーサル行動規範プロジェクトチームを代表して&lt;br /&gt; (翻訳と投稿)--[[利用者:YShibata (WMF)|YShibata (WMF)]] ([[利用者・トーク:YShibata (WMF)|トーク]]) 2022年5月20日 (金) 07:18 (UTC)

== イベントなどの費用の請求の仕方 ==

ウィキ'''ペ'''ディアに限らず、ウィキに関するエディタソンや講義、大学や学校での活動、ウィキペディアタウン、その他、費用請求の仕方についてご一読ください。

2022年4月15日に、請求の仕方が大幅に変わりました。以下は2022年5月31日の情報です。文書は英語が多く申し訳ないのですが、記入は日本語でかまいません。


=== 助成金 ===

個人でも、団体でも申請できます。

: 1. [https://meta.wikimedia.org/wiki/Grants:Programs/Wikimedia_Community_Fund/ja ウィキメディアコミュニティ基金]
:: エディタソンやコンテスト、写真ウォーク、促進キャンペーンの運営に必要な一般的な経費として、作業場・集会室賃料、サービス経費、賞品、普及活動、オンラインのイベントへのアクセスを支える通信費用、主催者の旅費滞在費と参加費、グラフィックデザイン、トレーニング、託児サービス、翻訳、プロジェクト管理、ウィキメディアン・イン・レジデンスなど、ボランティア活動に取って代わるものではない役割に対する報酬など。
:: '''[https://wmf.fluxx.io/user_sessions/new 申請する]'''日本語記入でかまいません。
::: ⋆随時助成金 = 短期、低予算（平均支給額 500 - 5,000 USD）
::: ⋆カンファレンスとイベント基金 = ウィキメディアンが集い経験の共有や技能開発、ネットワーク作りをする場を提供するもの（平均支給額 10,000 - 90,000 USD）
::: ⋆一般支援基金 = より規模の大きなプロジェクトもしくはプログラム、戦略計画を開発しそれぞれの目的達成のために増額した投資を長期に必要とするもの。複数年助成金支給も考慮（平均支給額10,000 - 300,000 USD）

: 2. [https://meta.wikimedia.org/wiki/Grants:Programs/Wikimedia_Alliances_Fund/ja ウィキメディアアライアンス基金]
:: 知識を入手することが困難な地域に住む人のためのプロジェクト

: 3. [https://meta.wikimedia.org/wiki/Grants:Programs/Wikimedia_Research_%26_Technology_Fund/ja ウィキメディア研究技術基金]
:: ⋆Research Fund終了
:: ⋆Technology Fund2022年中に開始

: 4. [https://meta.wikimedia.org/wiki/Grants:MSIG/About/ja 運動戦略を施行するための助成金]
:: [https://meta.wikimedia.org/wiki/Movement_Strategy/Initiatives/ja 45のイニシアチブ]のいずれか一つを推進するため。（申請額は25,000USDまでを条件として募集します。これを超える金額の申請には、手続きを開始する前に運動戦略チームにご連絡をお願いします）
:: '''[https://meta.wikimedia.org/wiki/Grants:MSIG/Apply/ja 申請する]'''

: 5. [https://wikimania.wikimedia.org/wiki/Scholarships 奨学金（2022年8月から）]

: 6. [https://meta.wikimedia.org/wiki/Knowledge_Equity_Fund 知識の公平性のための基金]
::: 「racial equity」のための基金です。

: 7. ウィキメディア・ハッカソン 助成金（終了）

: 8. [https://outreach.wikimedia.org/wiki/Education/Tools_%26_Resources ウィキペディア教育のための助成金]

上記1から8までをまとめたページは[https://meta.wikimedia.org/wiki/Grants:Start/ja こちら]です。

=== より多くの方々に支給されるであろう「1.ウィキメディアコミュニティ基金」の[[metawiki:Grants:FAQ/ja|助成金の審査の過程]] は次の通りです ===

:* 第1：応募
:* 第2：適格性の審査
:* 第3：プログラム管理者（複数）による審査
:* 第4：地域委員会による熟慮
:* 第5：地域委員会が審査結果を発表
:* 第6：助成金の支給


: 決定権限は、[[metawiki:Grants:Committees/ja|それぞれの地域の地域委員会]]に属します。地域委員会は各国語の利用者から構成されます。日本語コミュニティが属するEast, Southeast Asia, and Pacific (ESEAP)には現在5名の委員（利用者）がいます。

: 手続きとしては、「4. 運動戦略を施行するための助成金」の方が簡単です。

: 助成金の申請は、必要とする「一人の個人」または「グループ（代表者）」がしなければなりません。「グループ」は数人のグループでかまいません。

: 財団から口座に直接、お金が振り込まれます。「運動戦略の」助成金の場合(上記4)、申請から受け取りまで、法律上の氏名住所を伝える必要はありません。口座の名義人を公開しません。名義は任意団体でもかまいません。送金のためファイナンスのチームにのみ、個人データを開示する必要があります。--[[利用者:YShibata (WMF)|YShibata (WMF)]] ([[利用者・トーク:YShibata (WMF)|トーク]]) 2022年6月1日 (水) 00:53 (UTC)

== &lt;section begin=&quot;announcement-header&quot; /&gt; 2022年理事選挙候補者の募集&lt;section end=&quot;announcement-header&quot; /&gt; ==
&lt;section begin=&quot;announcement-content&quot; /&gt;
:''[[m:Special:MyLanguage/Wikimedia Foundation elections/2022/Announcement/2022 Candidates for the Board of Trustees|このメッセージはMeta-wikiで他の言語に翻訳されています。]]''
:''&lt;div class=&quot;plainlinks&quot;&gt;[[m:Special:MyLanguage/Wikimedia Foundation elections/2022/Announcement/2022 Candidates for the Board of Trustees|{{int:interlanguage-link-mul}}]] • [https://meta.wikimedia.org/w/index.php?title=Special:Translate&amp;group=page-{{urlencode:Wikimedia Foundation elections/2022/Announcement/2022 Candidates for the Board of Trustees}}&amp;language=&amp;action=page&amp;filter= {{int:please-translate}}]&lt;/div&gt;''

[[m:Special:MyLanguage/Wikimedia Foundation elections/2022|2022 理事会選挙]]候補者の募集は締め切りました。この募集により、コミュニティーから12名の候補者が応募しました。[[m:Special:MyLanguage/Wikimedia Foundation elections/2022/Candidates|2022 理事会選挙 候補者]]をご覧ください。

監査委員会は、今後、理事会から提供された技能などに関する基準により、候補者の申請書を検討します。理事会は、理事会の能力を向上させるために、一定の技能と能力を求めています。監査委員会が検討を終えた後、各候補者のランクが公表される予定です。これらのランクは、情報提供のみを目的としています。

2022年の理事会選挙について、タイムライン、投票情報、参加方法など [[m:Special:MyLanguage/Wikimedia Foundation elections/2022|Meta-wiki]] をご覧ください。

ご協力ありがとうございます。

選挙管理委員会と理事会に代わり、運動戦略と組織統治チーム一同 &lt;br /&gt;&lt;section end=&quot;announcement-content&quot; /&gt;(翻訳と投稿)--[[利用者:YShibata (WMF)|YShibata (WMF)]] ([[利用者・トーク:YShibata (WMF)|トーク]]) 2022年6月2日 (木) 01:58 (UTC)

== Results of Wiki Loves Folklore 2022 is out! ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; class=&quot;mw-content-ltr&quot;&gt;
{{int:please-translate}}
[[File:Wiki Loves Folklore Logo.svg|right|150px|frameless]]

Hi, Greetings

The winners for '''[[c:Commons:Wiki Loves Folklore 2022|Wiki Loves Folklore 2022]]''' is announced!

We are happy to share with you winning images for this year's edition. This year saw over 8,584 images represented on commons in over 92 countries. Kindly see images '''[[:c:Commons:Wiki Loves Folklore 2022/Winners|here]]'''

Our profound gratitude to all the people who participated and organized local contests and photo walks for this project.

We hope to have you contribute to the campaign next year.

'''Thank you,'''

'''Wiki Loves Folklore International Team'''

--[[利用者:MediaWiki message delivery|MediaWiki message delivery]] ([[利用者・トーク:MediaWiki message delivery|トーク]]) 2022年7月4日 (月) 16:12 (UTC)

&lt;/div&gt;
&lt;!-- User:Tiven2240@metawiki が https://meta.wikimedia.org/w/index.php?title=Distribution_list/Non-Technical_Village_Pumps_distribution_list&amp;oldid=23454230 のリストを使用して送信したメッセージ --&gt;

== &lt;span lang=&quot;en&quot; dir=&quot;ltr&quot; class=&quot;mw-content-ltr&quot;&gt; Upcoming activities for the 2022 Board of Trustees election&lt;/span&gt; ==

&lt;div lang=&quot;en&quot; dir=&quot;ltr&quot; class=&quot;mw-content-ltr&quot;&gt;
&lt;section begin=&quot;announcement-content&quot; /&gt;
:''[[m:Special:MyLanguage/Wikimedia Foundation elections/2022/Announcement/Upcoming Activities| You can find this message translated into additional languages on Meta-wiki.]]''
:''&lt;div class=&quot;plainlinks&quot;&gt;[[m:Special:MyLanguage/Wikimedia Foundation elections/2022/Announcement/Upcoming Activities|{{int:interlanguage-link-mul}}]] • [https://meta.wikimedia.org/w/index.php?title=Special:Translate&amp;group=page-{{urlencode:Wikimedia Foundation elections/2022/Announcement/Upcoming Activities}}&amp;language=&amp;action=page&amp;filter= {{int:please-translate}}]&lt;/div&gt;''

Hi all,

This message covers two upcoming activities for the 2022 Board of Trustees election.

The Board of Trustees election will have an Election Compass to support voters in their decision-making process. Eligible voters can propose statements in July and vote on which statements are used in the Election Compass in late July. Please visit the [[m:Special:MyLanguage/Wikimedia Foundation elections/2022/Community Voting/Election Compass|Election Compass page]] for more information.

Join conversations with the 2022 Board of Trustees candidates July 27 to August 7. Each candidate will have a one hour conversation with the community. Each conversation will be recorded and made available for future viewing. Live interpretation will be available. Languages available will be announced when the dates are set. These conversations will be scheduled with the candidates once the results of the Affiliate Selection are available. That information will be shared on the [[m:Special:MyLanguage/Wikimedia Foundation elections/2022/Events|2022 Board of Trustees election campaign events]] page.

Best,

Movement Strategy and Governance on behalf of the Board Selection Task Force and the Elections Committee&lt;br /&gt;&lt;section end=&quot;announcement-content&quot; /&gt;
&lt;/div&gt;

[[User:RamzyM (WMF)|RamzyM (WMF)]] 2022年7月11日 (月) 01:23 (UTC)
&lt;!-- User:RamzyM (WMF)@metawiki が https://meta.wikimedia.org/w/index.php?title=Distribution_list/Global_message_delivery/ja&amp;oldid=22374876 のリストを使用して送信したメッセージ --&gt;

== Announcing the six candidates for the 2022 Board of Trustees election ==

&lt;section begin=&quot;announcement-content&quot;/&gt;
:''[[m:Special:MyLanguage/Wikimedia Foundation elections/2022/Announcement/Announcing the six candidates for the 2022 Board of Trustees election| You can find this message translated into additional languages on Meta-wiki.]]''
:''&lt;div class=&quot;plainlinks&quot;&gt;[[m:Special:MyLanguage/Wikimedia Foundation elections/2022/Announcement/Announcing the six candidates for the 2022 Board of Trustees election|{{int:interlanguage-link-mul}}]] • [https://meta.wikimedia.org/w/index.php?title=Special:Translate&amp;group=page-{{urlencode:Wikimedia Foundation elections/2022/Announcement/Announcing the six candidates for the 2022 Board of Trustees election}}&amp;language=&amp;action=page&amp;filter= {{int:please-translate}}]&lt;/div&gt;''

Hi everyone, 

I'm Vivien from the Movement Strategy and Governance team. My apologies for posting this in English; If any of you would be so kind to help translate the message to Japanese, we would really appreciate it! If you have any questions or concerns, please do not hesitate to reach out to us.

I'm writing to inform you the Affiliate voting process has concluded. Representatives from each Affiliate organization learned about the candidates by reading candidates’ statements, reviewing candidates’ answers to questions, and considering the candidates’ ratings provided by the Analysis Committee. The selected 2022 Board of Trustees candidates are:

* Tobechukwu Precious Friday ([[m:User:Tochiprecious|Tochiprecious]])
* Farah Jack Mustaklem ([[m:User:Fjmustak|Fjmustak]])
* Shani Evenstein Sigalov ([[m:User:Esh77|Esh77]])
* Kunal Mehta ([[User:Legoktm|Legoktm]])
* Michał Buczyński ([[m:User:Aegis Maelstrom|Aegis Maelstrom]])
* Mike Peel ([[m:User:Mike Peel|Mike Peel]])

You may see more information about the [[m:Special:MyLanguage/Wikimedia Foundation elections/2022/Results|Results]] and [[m:Special:MyLanguage/Wikimedia Foundation elections/2022/Stats|Statistics]] of this Board election.

'''The next part of the Board election process is the community voting period.''' [[m:Special:MyLanguage/Wikimedia Foundation elections/2022#Timeline|You may view the Board election timeline here]]. To prepare for the community voting period, there are several things community members can engage with in the following ways:

* [[m:Special:MyLanguage/Wikimedia Foundation elections/2022/Candidates|Read candidates’ statements]] and [[m:Special:MyLanguage/Wikimedia_Foundation_elections/2022/Affiliate_Organization_Participation/Candidate_Questions|read the candidates’ answers to the questions posed by the Affiliate Representatives]].
* [[m:Special:MyLanguage/Wikimedia_Foundation_elections/2022/Community_Voting/Questions_for_Candidates|Propose and select the 6 questions for candidates to answer during their video Q&amp;A]].
* See the [[m:Special:MyLanguage/Wikimedia Foundation elections/2022/Candidates|Analysis Committee’s ratings of candidates on each candidate’s statement]].
* [[m:Special:MyLanguage/Wikimedia Foundation elections/2022/Community Voting/Election Compass|Propose statements for the Election Compass]] voters can use to find which candidates best fit their principles.
* Encourage others in your community to take part in the election.

Thank you,

Movement Strategy and Governance 

''This message was sent on behalf of the Board Selection Task Force and the Elections Committee''
&lt;/div&gt;&lt;section end=&quot;announcement-content&quot;/&gt;--[[利用者:VChang (WMF)|VChang (WMF)]] ([[利用者・トーク:VChang (WMF)|トーク]]) 2022年7月20日 (水) 12:43 (UTC)</text>
      <sha1>g4hrg9jkl8b8jm3kymmduh713pnnmf1</sha1>
    </revision>
  </page>
  <page>
    <title>BASIC</title>
    <ns>0</ns>
    <id>1885</id>
    <revision>
      <id>205747</id>
      <parentid>204325</parentid>
      <timestamp>2022-07-24T01:33:03Z</timestamp>
      <contributor>
        <username>Ef3</username>
        <id>694</id>
      </contributor>
      <comment>/* 古いBASICの入手方法 */ 文体の統一；中学校・高等学校の情報科や技術・家庭科で取り扱われる３言語は、JavaScript、PythonそれにVisual Basic for Applications（ビジュアルベーシック・フォー・アプリケーションズ、VBA）ですが、VBAは古いBASICの範疇ではありません。</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="47962" xml:space="preserve">&lt;small&gt;[[情報技術]] &gt; [[プログラミング]] &gt; BASIC&lt;/small&gt;
----

プログラミング言語[[w:BASIC|BASIC]]（ベーシック）の使用法

== はじめに ==
=== BASICの分類 ===

BASICには大きくわけて、
* [[w:MS-DOS|MS-DOS]]（エムエス ドス）時代までの「古いBASIC」 （[[w:N88-BASIC|N88-BASIC]]や[[w:F-BASIC|F-BASIC]]、[[w:MSX-BASIC|MSX-BASIC]]などを想定）
*「JIS規格BASIC」(JIS X3003-1993)や[[w:QuickBASIC|QuickBASIC]]（クイック ベーシック）以降の、「新しいBASIC」
* [[w:Microsoft Visual Basic|マイクロソフト社 Visual Basic]]（ビジュアル ベーシック）以降の、[[w:GUI|GUI]]に特化したBASIC

の3種類があります。ここでは最初の2種類のBASICを対象にしますが、ほとんどの構文については3つ目の種類のBASICにも「新しいBASIC」と同じことが通用します。違いについてはその都度、注記します。

本wikibooksの本ページ『BASIC』では、おもに、古いBASICやJIS規格BASICを基準に、文法を説明しています。その理由は、古いBASICは文法が単純であり、入門しやすく、また、古くからあるため、よって古いBASICが他のプログラム言語にも応用しやすいからです。

=== GUI対応のBASICについて ===
いっぽう、Visual BasicなどのGUI対応したBASICは、文法と操作性が、古いBASICとは、かなり異なります。GUI対応BASICは、マウス入力に対応したGUIプログラミングに対応するために、新しい機能を大量に追加してあるため、キーボード入力を中心にあつかう古いBASICとは、大幅に違っています。

GUI対応したBasicには、歴史的な経緯から、『BASIC』から派生した名前がついていますが、実態は、ほとんど別のプログラミング言語だと思ったほうが良いでしょう。

なお、2017年の現在、（GUIに特化している）Visual Basicを出しているマイクロソフト社が、入門者用に機能を簡易化した small basic というものを出しているので、GUIプログラミングの初心者は Visual Basic ではなく small basic （スモール ベーシック）で入門したほうが、学びやすいでしょう。

いまや Visual Basic は、入門用のプログラムを動作させるまでに、覚えることがとても多くなってしまい、そのため、マイクロソフト社が、もはやVisual Basicは入門用には適さないと判断して、近年になって small basic を出すということになった次第です。

=== 古いBASICの入手方法 ===
BASICの実行環境ソフトは、Vector（ベクター; https://www.vector.co.jp/ ）などインターネット上のフリー ソフトウェア配布サイトから無償または有償でダウンロードすることができます。

日本で主流だったN-BASICやF-BASICを製造していた会社は、BASIC言語の開発・販売を終了しています。これは、
* ワープロソフト、表計算ソフト、はがき印刷ソフトなど、用途別のアプリケーションソフトが販売され、一般消費者がわざわざプログラミング言語を習得する必要がなくなった。
* ビジネスでプロブラムを作る人は、より生産性の高い言語を使うようになった。
* 主流となる環境が、ROM BASIC/Disk BASIC/MS-DOSから Windows/Macintosh やOS/2に移行し、BASICの以前の実行環境がなくなった。
などの理由が考えられます。このため、現在（令和4年7月）では、BASICは專ら趣味で使われる程度になってしまいました&lt;ref&gt;中学校・高等学校の情報科や技術・家庭科で取り扱われる３言語は、[[JavaScript]]、[[Python]]それに[[Visual Basic for Applications]]（ビジュアルベーシック・フォー・アプリケーションズ、VBA）ですが、VBAは古いBASICの範疇ではありません。&lt;/ref&gt;。

その代わり、他の企業や個人が昔のBASICの実行環境を再現したアプリケーションを作り、フリー ソフトウェア配布サイトで公開しています。

Microsoft Quick BASIC（MS-DOS時代）互換のオープン ソース ソフトウェアなどがあり、それを利用することもできます。
* FreeBASIC
* QB64
* その他
特に、QB64にはエミュレーション機能があり、昔ながらの方法で多少のプログラミングが可能です。

== 古いBASICでのプログラムの入力 ==
まず、使用するBASIC（ベーシック）を選び、起動して下さい。

BASICで画面に文字を表示するためには &lt;code&gt;PRINT&lt;/code&gt; 文を使います。ただし、新しいBASICでは、まったく別のコマンド文になります。

BASICが起動すると、「Ok」「Ready」など（BASICや機種によって異なります）の文字の下に「■」（カーソル）が出ます。カーソルはカーソルキーの上下左右で移動できます。このカーソルが出ているときに、BASICのプログラムを編集できます。

では最初に、PRINT文を使って、画面に文字を表示させてみましょう。
:&lt;syntaxhighlight lang=basic&gt;
PRINT &quot;Hello  BASIC&quot;
&lt;/syntaxhighlight&gt;

と入力してみてください。入力時の文字モードは、直接入力モードで入力してください。Windowsの場合、右下に、文字入力モードの切り替えのタブがあるので、そこをクリックして、直接入力モードを選んでから、上記のPRINT文を入力してください。

このように上記のPRINT文を入力し、RUN（「ラン」という。「起動せよ」の意味）を実行すると（実行方法は機種によって異なりますので、それぞれの機種を参考にしてください）、画面に '''Hello BASIC''' と表示されます。

同様に、新しい行で、画面の左端にカーソルがある状態で、
:&lt;syntaxhighlight lang=basic&gt;
PRINT 2+3
&lt;/syntaxhighlight&gt;

のように入力してみて（最後にEnterキーを入力して改行します。機種によってはRETURNキー、CRキーとも言います。以下、同じなので省略します）、RUNを実行すると（実行方法はそれぞれの機種を参考にしてください）、'''5''' と計算の結果が表示されます。


このように、PRINT命令は、その直後にあるものを画面に表示します。

また、BASICでは、命令を実行することをRUN（ラン）と言います。英語の「走る」 RUN と同じ単語です。ランニング（走り）やランナー（走者）のランと同じです。

いっぽう、
:&lt;syntaxhighlight lang=basic&gt;
PRINT &quot;2+3&quot;
&lt;/syntaxhighlight&gt;

をRUNで実行すると、画面に&quot;2+3&quot;とそのまま表示されます。

つまり、二重引用符 &quot; &quot; は、「引用符内の文字列を、画面にそのまま表示しろ」という意味の記号です。


他のプログラミング言語でも、「print」という語をテキスト表示命令に用いるプログラミング言語は多いです。また、他のプログラミング言語でも、文字列を表示する場合は、二重引用符 &quot; &quot; で くくるのが、普通になっています。

もし、二重引用符でくくらないと、
;エラーが出る例:&lt;syntaxhighlight lang=basic&gt;
PRINT Hello BASIC
&lt;/syntaxhighlight&gt;
は「エラーのある文なので実行不可能」的な報告を コンピューターから報告されたり、あるいは、まったく予期せぬ数値や文字が表示されるなどのエラーを起こします（例えばundefined）。


=== 行番号 ===
古いBASICでは、プログラムは「行番号＋命令」の形でかかれます。行番号をつけないで入力すると、前述のように｢命令を即実行して、終了」します。先頭に行番号をつけることで初めて、命令を組み合わせた「プログラム」として実行できるようになります。0未満の数や小数、分数は行番号にできません。

;簡単なプログラムの例:&lt;syntaxhighlight lang=basic&gt;
 5 CLS
10 PRINT &quot;3+5=&quot;;
20 PRINT 3+5
30 END
&lt;/syntaxhighlight&gt;

各行の最初についている数字が行番号です。10からはじめて10ずつ増やしていくのが一般的です。こうすれば、後から簡単に行を挿入することができます（ただし9行まで）。PRINT は前節で説明した通り画面に文字を出力する命令です。最後の END はプログラムの終了を表す命令で、省略可能なBASICも多いですが、そうでなければ必ず入れるようにします。

入力したら
:&lt;syntaxhighlight lang=basic&gt;
RUN
&lt;/syntaxhighlight&gt;
と（行番号なしで）入力すると実行します。
このプログラムを実行させると、画面に「3+5= 8」と表示されます。

10行の最後についている ''';''' は、「改行'''しない'''」ことをコンピューターに通知します。これを取り除くと、実行したときに「3+5=」と「8」が別の行に表示されてしまいます。これを利用して、一行分空白にすることができます。

なお、古いBASICでは「：」を用いると次のようにも書けますが、現在では推奨されません。

:&lt;syntaxhighlight lang=basic&gt;
 5 CLS
10 PRINT &quot;3+5=&quot;;:PRINT 3+5
20 END
&lt;/syntaxhighlight&gt;

現在、一部の(再現)BASICでは、

:&lt;syntaxhighlight lang=basic&gt;
 5 CLS
10 PRINT &quot;3+5=&quot;;3+5
20 END
&lt;/syntaxhighlight&gt;

のように記述することができます。


なお、ENDはプログラムの終了を表す命令でしたので、たとえば、

:&lt;syntaxhighlight lang=basic&gt;
 5 END
10 PRINT &quot;3+5=&quot;;3+5
20 END
&lt;/syntaxhighlight&gt;
のようなプログラムだと、「3+5=」を表示する前に、いきなり終了します。


=== 行番号が順番どおりでない場合 ===

:&lt;syntaxhighlight lang=basic&gt;
20 PRINT(&quot;aaa20&quot;)
10 PRINT (&quot;bbb10&quot;)
&lt;/syntaxhighlight&gt;

のように、行番号が順番どおりではない場合、どの行を優先して実行するのでしょうか？

現代のGUI対応のBASICでは、行番号のないものが多いのですが、その理由のひとつも、おそらく、このような、行番号と順序のちがう場合の混乱を防ぐためなど、それなりの理由があるのでしょう。

さて、たいていの古いBASICの場合、行番号の小さい順から先に実行すると思います（いくつかの再現BASICソフトで確認）。この場合、特にエラーメッセージなどは、出されません。

おそらく、古いBASICでは、ソフトウェアの内部では、プログラムの実行のさいしょに（つまりRUN命令の直後に）、まず行番号にもとづいて並べ替えを行って、

:&lt;syntaxhighlight lang=basic&gt;
10 PRINT (&quot;bbb10&quot;)
20 PRINT(&quot;aaa20&quot;)
&lt;/syntaxhighlight&gt;

のように並べ替えてから、それからやっと、上から順に実行をしているのでしょう。

つまり、これらの古いBASICは、プログラムを最初に実行する際、まず並べ替えを行っているのです。

もし、行数が10行ていどの少ないプログラムなら、それでもかまいませんし、気の利いた便利な機能でしょう。

しかし、もし百行や千行もあるプログラムを並べ替えるとなると、並べ替えには時間が掛かるので、プログラムの実行が終わるまでの時間が長引いてしまいます。


反対に言うと、行番号のないBASICの場合、そのぶん高速化をしている可能性があります（並べ替えの時間が省けるので）。

さらに言うと、行番号のあるBASICの使い道は、処理に時間が掛かってもいいので、処理の順序を確実にまちがいなく、自分以外の他のプログラマーにも伝えたいようなプログラムを書くときには、もしかしたら行番号のあるBASICが便利かもしれません。


=== プログラムの編集 ===
エディタのない古いBASICでは、

:&lt;syntaxhighlight lang=basic&gt;
LIST
&lt;/syntaxhighlight&gt;
と入力すると、プログラム（プログラムリスト）を先頭の行からから表示します。

:&lt;syntaxhighlight lang=basic&gt;
LIST 10
&lt;/syntaxhighlight&gt;
と入力すると10行目だけを、

:&lt;syntaxhighlight lang=basic&gt;
LIST 20-
&lt;/syntaxhighlight&gt;
と入力すると20行目以降すべてを、

:&lt;syntaxhighlight lang=basic&gt;
LIST -20
&lt;/syntaxhighlight&gt;
と入力すると先頭の行から20行目までを、

:&lt;syntaxhighlight lang=basic&gt;
LIST 20-30
&lt;/syntaxhighlight&gt;

と入力すると20行目から30行目を表示します。

また、

:&lt;syntaxhighlight lang=basic&gt;
AUTO
&lt;/syntaxhighlight&gt;

と入力すると、改行するたびに行番号を10ずつ増やして自動的に表示します。自動表示を停止させるのはBREAKキーを押します（機種によってはSTOPキーや、CTRL+STOPキーを同時押しなど、操作が多少異なります）。

* なぜ、こうなってるのか？
今でこそ、プログラムの実行結果の画面と、プログラム記述用のエディタ画面とは、別々の画面に分かれているのが普通です。

しかし、昔のパソコンでは、表示ウインドウが標準では1つしかありませんでした。そもそも「ウィンドウ」という概念すらなく、昔の古いプログラム言語では、実行結果の表示画面と、エディタ画面とが、同じひとつの画面だったりします。しかもコマンド入力機能がプログラム記述機能も兼ねていたり、あるいはパソコン本体にあるレバースイッチ（小型のレバースイッチがついていたりする）により、コマンド入力モード（「ターミナルモード」という）とプログラミングモードとを切り替えたりしていました。

現代でも、Windowsのコマンドプロンプトのような、OS付属のコマンド入力用アプリケーションでは、普通、ウィンドウは1つだけであり、そのたったひとつのウィンドウが、実行結果の表示画面と、コマンド入力画面とを兼ねています。


=== 新しいBASICでのプログラムの入力 ===
新しいBASICでは、プログラムを編集するためのエディタを持っており、これを入力に使います。エディタの概要や使い方自体は省略します。また、次のように「行番号を省略」できます。

:&lt;syntaxhighlight lang=basic&gt;
PRINT &quot;3+5=&quot;;
PRINT 3+5
END
&lt;/syntaxhighlight&gt;

プログラムの実行は、RUNではなく、エディタのメニューから「実行」を選択します。

古いBASICのように「命令を実行して、即終了」するには、中には「直接入力」(例: イミディエイト ウィンドウ )が簡単にできる新しいBASICもありますが、ほとんどの新しいBASICではエディタのメニューから対応した項目を選ぶ必要があります。

ここでは行番号付きの古いBASICの書式で説明します。
　

== 以下は基本的に古い形式で説明します ==
* ここで 古い形式を N-BASIC, MSX-BASIC とします。それ以降のBASICで働くように考慮します。
* 説明はストレートでわかりやすく、具体例を多く入れます。
* 出来るだけ専門用語を使いません。もし使うときは説明を入れます。

== 最初に ==
* BASICのプログラムは行単位で実行されます。
* 行の上から下に向かって実行されます（分岐などもあります）。
* STOP命令, END命令で実行が終了します。
* 空白にも意味がありますので注意しましょう。

※ 他のプログラム言語でも、似たような文法の言語は、多くあります。他のプログラム言語によくあるのは、主に、
:特別な指示がないかぎり、上から下に向かって順に実行される。
:空白に意味がある。
です。

== 注釈（コメント）  REM ==
注釈（ちゅうしゃく）をつけるには'''REM'''を使います。「レム」と読みます。注釈とは「何も実行しない」という命令で、プログラムの説明を書いたり、[[w:デバッグ|デバッグ]]（エラーの原因をさがす作業のこと）などで一時的に命令を実行させないようにするとき、などに使います。

:&lt;syntaxhighlight lang=basic&gt;
10 REM PRINT &quot;1&quot;
20 PRINT &quot;2&quot;
30 END
&lt;/syntaxhighlight&gt;

このプログラムを実行すると、10行目は何も実行せず、20行目が実行されて、画面に「2」とだけ表示します。
30行はEND命令です、この命令で実行を終了します。

===== コラム　=====

マイクロソフト系のBASICでは、アポストロフィーを代わりに使えます。

== 表示  PRINT ==
画面に表示させるには PRINT文を使います。「プリント」と読みます。

:&lt;syntaxhighlight lang=basic&gt;
10 PRINT &quot;これが表示されます。&quot;
20 PRINT 123
30 END
&lt;/syntaxhighlight&gt;

PRINTの後に続くものを画面に表示します。文字列、数値、変数など


===== コラム =====
PRINTに続く定数、変数を画面に表示します。どのような型であっても表示されます。数値、文字など。また、；セミコロンを変数末尾に置く事によって文末の改行が行われません。つまり二つのPRINT文をひとつとして連続に表示することが出来ます。一般的な注意として、PRINT文は高度な内部処理を行うために処理が遅くなります。

== 変数 ==

'''変数'''は、数値や文字などのデータを入れておく箱のようなものです。

変数の名前には、以下のような規則があります。
* アルファベットから始まる。
*: 1ABC などは不可
* アルファベットと数字で構成される。（記号と空白は不可）
*: A:B PI3.14 などは不可
* BASIC内で使用されている命令名と重複しない。
*: PRINT などは不可
* 変数名の大文字と小文字は区別されない。
*: ABCとaBcは同じ変数と解釈される。
また、古いBASICや簡易なBASICでは、機種によって変数名の長さに「2文字以下」「8文字以下」という制限があります。

== 入力  INPUT ==
キーボードから入力するには、INPUT文を使います。


:&lt;syntaxhighlight lang=basic&gt;
 5 REM これは 数値をキー入力して、変数Aに代入、そして変数Aを表示する。
10 INPUT A
20 PRINT A
30 END
&lt;/syntaxhighlight&gt;

10 INPUT A では、数値変数Aに キーボードから入力した数値を代入します。

このような書き方も出来ます。

:&lt;syntaxhighlight lang=basic&gt;
10 INPUT &quot;数値を入力して下さい &quot;,A
20 PRINT A
30 END
&lt;/syntaxhighlight&gt;

入力を促す文字列を表示してから、入力に入ります。

== 代入と計算 ==

'''変数'''は、数値や文字などのデータを入れておく箱のようなものです。

:&lt;syntaxhighlight lang=basic&gt;
10 A=12
20 B=3
30 PRINT A+B
40 PRINT A-B
50 PRINT A*B
60 PRINT A/B
70 END
&lt;/syntaxhighlight&gt;

このプログラムは、変数 A に 12、変数 B に 3 を代入し、足し算・引き算・掛け算・割り算の結果を表示する物です（順に、15 9 36 4 と表示されます）。

変数への代入は '''=''' を使用します。上のプログラムでは直接数字を代入しましたが、計算式（変数を使用するものも含む）を代入することができます。

BASICにおける代入とは、「記号=の右側にある計算式の結果を、記号=の左側の変数に代入しろ」という意味です。

そのため、
 12 = A
という命令はエラーになります。
かならず、代入先の変数は、記号=の左側にある必要があります。

また、右側にある計算式を、記号=の左にある変数に代入するので、
 A=A+1
のように、自分自身を用いた式を代入することもできます。もし、「A+1=A」という順序だと、エラーになります。


:&lt;syntaxhighlight lang=basic&gt;
10 A=12
20 A=A+1
30 PRINT A
40 END
&lt;/syntaxhighlight&gt;

を実行すると、計算結果（12＋1）の「13」が表示されるでしょう。


なお、変数への代入は「LET」命令で、
 A=12
は
 LET A=12
なのですが、JIS規格BASICを除いて、ほとんどの新旧のBASICを問わず、LETは省略可能です。

計算の記号は、足し算には'''+'''、引き算には'''-'''、掛け算には'''*'''、割り算には,'''/''' の記号が割り当てられています。余りは「'''MOD'''」（モジェロ）です。

括弧()を使う事が出来ます。計算の順序に迷ったら括弧を使うようにしましょう。

 100 A=(10+2)/4


将来的に、LET文のある他のプログラミング言語の学習のことを考えて、LET文をつかって上記のプログラムを書いてみましょう。

:&lt;syntaxhighlight lang=basic&gt;
10 LET A=12
20 LET B=3
30 PRINT A+B
40 PRINT A-B
50 PRINT A*B
60 PRINT A/B
70 END
&lt;/syntaxhighlight&gt;

== 入力命令 ==
利用者からキーボードで数値を入力してもらうには、INPUT 文を使います。
INPUT命令を使って数値または文字列(変数名$)を入力させる場合、

;例
 INPUT &quot;ここに文字を表示させることも可能&quot;;変数名
 PRINT &quot;入力した数値（文字列）は&quot;;変数名;&quot;です&quot;

とします。

（プログラム例）
:&lt;syntaxhighlight lang=basic&gt;
10 INPUT &quot;数値を入力してください&quot; ;A
20 PRINT &quot;入力された数値は&quot;
30 PRINT A
40 PRINT &quot;です。&quot;
50 END
&lt;/syntaxhighlight&gt;

または

:&lt;syntaxhighlight lang=basic&gt;
 5 PRINT &quot;数値を入力してください&quot;
10 INPUT A
20 PRINT &quot;入力された数値は&quot;
30 PRINT A
40 PRINT &quot;です。&quot;
50 END
&lt;/syntaxhighlight&gt;


== 変数の初期化 ==
たとえば、上のプログラムを実行したあとに、
 PRINT A
を実行すると、さきほど入力した変数が出るかもしれません。

この理由は、メモリ内に、以前に使用した変数が、そのまま残っているからです。

つまり、プログラムを終了しても、それだけでは変数の内容は消去されません。

命令 NEW を使うと、BASICで扱っている変数にすべてゼロ 0 を代入し、初期化（しょきか）します。

もし、上の節のプログラムの実行直後に、まったく別のプログラムを実行する必要があったとして、そこでも同じ変数名の変数が使われていたとしたら、その変数は初期化をしていないと、エラーの原因になってしまいます。

まったく別のプログラムでも、同じ変数名「A」や「B」を、まったく別の内容で使うこともありますので、必要に応じて NEW 命令を使いましょう。

:&lt;syntaxhighlight lang=basic&gt;
10 NEW
20 LET A=7
30 PRINT A+9
40 END
&lt;/syntaxhighlight&gt;

と書いて実行すれば、このプログラムの実行前にどんなプログラムで変数「A」を用いていようが、それを初期化できます。

なお、上記のプログラムの実行結果として、計算結果として「16」が表示されます。

このプログラムの場合なら、わざわざNEWで変数Aを初期化しなくても、その次の行で &lt;nowiki&gt;A=7&lt;/nowiki&gt;と記述しているので、じつは初期化の必要はありません。

ですが、作ろうとするプログラムが複雑になってくると、あつかう変数の個数が多くなり、変数ひとつずつ初期化をするのが大変になる場合もありますし、個数が多いと一つづつ初期化する方法だと、初期化しわすれる変数も出て来るかもしれません。

なので、ねんのため、 NEW 命令で、いっきに、すべての変数を初期化してしまいましょう。初期化される対象は、そのBASICで扱っている「変数」だけですので、安心しても平気です。


なお、下記のように、もし計算途中に、NEWを入れると、

（あまり、よくないプログラム）
:&lt;syntaxhighlight lang=basic&gt;
20 LET A=7
25 NEW
30 PRINT A+9
40 END
&lt;/syntaxhighlight&gt;

このプログラムなら、PRINT命令で「9」が表示されたりします。なぜならAが初期化されてしまい、Aに0が代入されているからです。

なお、現在のプログラム言語では、NEW命令は別の意味で使われています。


なお、計算作業のときに、初期の瞬間の状態に対応する数値のことを、科学技術用語で「初期値」（しょきち、initial value イニシャル バリュー）といいます。ファミコンソフトなどのゲーム業界などでも、ゲーム開始状態の主人公のライフ（生命力）値とかの数値をまとめて「初期パラメーター」などといいますね。それと同じことです。

理科などでは、たとえばボールを投げた瞬間のボールの速度のこと「初期速度」と言います。

もし、現代のプログラム言語のなかの命令文の語句で、「init」などの語句があったら、それはもしかしたら、初期値（※ 英語で initial value ）のことかもしれません。


== 条件分岐  IF THEN ELSE ==
「もし、明日 晴れだったなら、遠足。そうでなく、雨だったらなら、教室で自習。」のような場合わけを条件分岐（じょうけん ぶんき）といいます。

プログラム中である条件に当てはまるかで実行する内容を変えるときには '''IF'''～'''THEN'''～'''ELSE'''文 を使用します。

条件分岐では IF という語句を、ほぼ、かならず使うので、条件分岐命令のことを「IF文」とも言います。「IF」とは、「イフ」と読み、意味は「もし 〜〜 ならば、」という意味の、英語の接続詞です（日本では、中学校の英語の授業で 接続詞 IF を習うでしょう）。

ほかのプログラム言語でも、条件分岐命令のことを普通は「IF文」と言います。なお、THENは「ゼン」と読み、ELSEは「エルス」と読みます。

:&lt;syntaxhighlight lang=basic&gt;
10 A=0
20 B=3
30 IF A &gt; B THEN PRINT &quot;A is bigger than B&quot; ELSE PRINT &quot;B is bigger than A&quot;
&lt;/syntaxhighlight&gt;

ここで使っているA &gt; Bの '''&gt;''' は'''比較演算子'''（ひかく えんざんし）といい、数値の比較に使います。

{| class=&quot;wikitable&quot;
|-
! 演算子 !! 意味 !! 数学の記号
|-
| A '''='''  B || AとBは等しい || A＝B
|-
| A '''&gt;'''  B || AはBより大きい || A＞B
|-
| A '''&lt;'''  B || AはBより小さい || A＜B
|-
| A '''&gt;=''' B || AはB以上 || A≧B
|-
| A '''&lt;=''' B || AはB以下 || A≦B
|-
| A '''&lt;&gt;''' B || AとBは等しくない || A≠B
|}

他のプログラム言語でも、IF文 の考え方と 比較演算子 の考えかたは、ほぼかならず使います。なので、いまここのBASICの学習で、比較演算子の考え方を、しっかりと理解しましょう。

IF文は、IFとTHENの間に条件式を書き、THENから条件式が成立するときの命令を書きます。そして成立しなかったときのことはその後ろにELSEに続けて書きます。なお、THENは「ゼン」と読み、ELSEは「エルス」と読みます。

THEN の意味は、「そうであれば〜〜」という意味です。ELSEの意味は、「そうでなければ〜〜」という意味です。

例の30行目は、もし A &gt; Bが成立すればPRINT &quot;A is bigger than B&quot;を実行し、もし成立しなければPRINT &quot;B is bigger than A&quot;を実行するという意味であります。文字列の場合は、

 IF 変数名$=&quot;&quot; THEN 真の場合の行番号または命令 ELSE 偽の場合の行番号または命令

PRINT命令の場合、PRINTを省略(THEN &quot;内容&quot;のように)できます。

なお、ELSEは省略できます。

複数行にわたってしか書けないものを実行させたい場合、GOTO命令（後述）を使い行を飛ばす必要があります（この場合、GOTOと書くのを省略して、行番号だけでも書けます）。

== 分岐  GOTO ==
無条件でジャンプします。

条件分岐ではない、強制の分岐には'''GOTO'''命令を使います。「GOTO」は「ゴー トゥー」と読みます。GOTOの後に行番号を入れると、対応する行の命令を実行します。

:&lt;syntaxhighlight lang=basic&gt;
10 GOTO 30
20 PRINT &quot;1&quot;
30 PRINT &quot;2&quot;
40 END
&lt;/syntaxhighlight&gt;

このプログラムを実行すると20行目がスキップされ、30行目が実行されて、画面に「2」とだけ表示します。

:&lt;syntaxhighlight lang=basic&gt;
10 GOTO 40
20 PRINT &quot;1&quot;
30 GOTO 60 
40 PRINT &quot;2&quot;
50 GOTO 20
60 END
&lt;/syntaxhighlight&gt;

このプログラムを実行すると、画面に「2」「1」と表示します。が、このようにGOTOの飛び先が入り組んだプログラムは「スパゲティ･プログラム」と呼ばれて、「他の人が見てもプログラムの構造を一目では把握しづらい」ために、通常のプログラムでは 禁じ手（きんじて） とされています。

:&lt;syntaxhighlight lang=basic&gt;
10 PRINT &quot;1&quot;
20 PRINT &quot;2&quot;
30 GOTO 10 
40 END
&lt;/syntaxhighlight&gt;

このプログラムを実行すると、画面に「1」「2」を表示し続けます。このように「終了せずに、実行し続ける」プログラムを「無限ループ」と呼びます。表示を止めるには、古いBASICではAUTO命令を止めるときと同様に「BREAK」などのキーを押してください。新しいBASICではメニューから「停止」を選択します（Visual Basicなどでは無限ループを書くとそのまま問答無用で応答不能になってしまうものもありますので、アプリケーションを強制終了させるか、CTRL+ALT+DELするなどしてOSから強制終了させてください）。

新しいBASICでもGOTO命令は使用できますが、推奨はされません。

どうしてもGOTO文を使う必要のある場合には、REM文などによるコメント機能も活用しましょう。GOTO文の前の行で、REM文による説明で、GOTO文の行き先を説明したり、あるいは処理しようとしている内容などを記述すると、他の人がプログラム内容を把握しやすくなるでしょう。


== 繰り返し  FOR NEXT ==
プログラム中で同じ処理を繰り返す場合には、'''FOR'''～'''NEXT''' 文を使用します。

:&lt;syntaxhighlight lang=basic&gt;
10 J=0
20 FOR N=1 TO 5
30     J=J+N
40     PRINT &quot;N=&quot;;N;&quot;  J=&quot;;J
50 NEXT N
60 END
&lt;/syntaxhighlight&gt;


この例は、FORからNEXTの間を繰り返します。回数は、1から5までの5回。もしSTEPを指定してあれば、増量値の設定ができます。
これを実行すると以下の様に表示されます。

FORの直後の変数（上記の場合はN）と、NEXTの直後の変数は、同じ変数でなければなりません。

:&lt;syntaxhighlight lang=text&gt;
N= 1  J= 1
N= 2  J= 3
N= 3  J= 6
N= 4  J= 10
N= 5  J= 15
&lt;/syntaxhighlight&gt;

FOR 文の構文は以下の様になります。
 FOR 変数=初期値 TO 最終値 STEP 変更量
上の文のうち、「STEP 変更量」は省略できます。省略されたときには変数は1づつ変化します。

変数が初期値から最終値まで変化し、その各値ごとに NEXT までの文が実行されます。

== DATA文 ==
INPUT文で毎回データ入力するのは大変です。

プログラムの中に記録することが出来ます。
DATA文、READ文、RESTORE文　です。

:&lt;syntaxhighlight lang=basic&gt;
20 READ A
30 PRINT A
40 DATA 1,2,3
&lt;/syntaxhighlight&gt;

20行でDATA文から１個読み込んで変数Aに代入します。30行で表示します、この例では「１」が表示されます。もし次に読み込んだなら「２」が読み込まれます。


:&lt;syntaxhighlight lang=basic&gt;
10 RESTORE 50
20 READ A
30 PRINT A
40 DATA 1,2,3
50 DATA 4,5,6
&lt;/syntaxhighlight&gt;

10行のRESTOREでDATA文の読み込み先を指定します、ここでは50行から読み込みます。20行で読んで、30行で表示。この例では「４」が表示されます。普通は FOR NEXT文などを使って 連続して読み込みます。

DATA文の考え方は、ファイル操作のシーケンシャルファイルと似ています。


== サブルーチン　GOSUB ==
同じ内容のプログラムは、まとめてサブルーチンにする事ができます、GOSUBです。

:&lt;syntaxhighlight lang=basic&gt;
110 INPUT A
120 GOSUB 200
130 PRINT A
150 END
200 REM サブルーチン
210 A=A*2
220 RETURN
&lt;/syntaxhighlight&gt;

プログラムの動きを行番号で書きます。 110 120 200 210 220 130 150 。順番に注目。
RETURNを使うとGOSUBの次に戻ります

== 関数 () ==
関数はサブルーチンに似ています。組み込まれたサブルーチンのように思ってください。

:&lt;syntaxhighlight lang=basic&gt;
10 INPUT A
20 B=ABS(A)
30 PRINT B
50 END
&lt;/syntaxhighlight&gt;
ABS()は絶対値を返す関数です。

他にも色々な関数があります。

:ABS(x)　
:ATN(x)　
:SGN(x)　
:SIN(x)　
:COS(x)　
:EXP(x)　
:INT(x)　
:LOG(x)　
:SQR(x)　
:RND(1)

== 文字列操作 $ ==
ここまでの説明で、数値のみを扱いました。ここでは、文字の入力、表示、操作を説明します。

=== 文字定数と文字変数 ===
文字を表す時は&quot;&quot;で囲みます。
 &quot;これは文字です&quot;

文字を表す文字列変数では、変数名の末尾に$を付けます。

 A$=&quot;文字列&quot;

=== 文字列の結合 ===
文の足し算が出来ます。

 10 A$=&quot;今日は&quot;
 20 B$=&quot;晴れ。&quot;
 30 C$=A$+B$
 40 PRINT C$
 50 END

文字の入力と表示

 10 INPUT A$
 20 PRINT A$
 30 END

=== 文字列の関数と変換 ===
BASICでは文字列の便利な関数があります。

ASC(x$)　
RIGHT$(x$,y)　
LEFT$(x$,y)　
MID$(x$,y,z)　
LEN(x$)　
STR$(x)　
VAL(x$)　
CHR$(x)　
TAB(x)　

== 浮動小数点 # ==
ここまでは数値の整数で行いました。

割り算で割り切れないときに扱う小数点の処理、浮動小数点の定数、変数について説明します。誤差についても。

BASICでは小数点を付けると、小数点付きの実数として扱われます。

 100 PI=3.14

 100 A=3.14
 200 PRINT A
 400 END

;誤差
コンピューターの計算では誤差が発生します。
誤差の程度は機種によって異なります。

 10 A=10.0/7.0
 20 B=A*7.0
 30 PRINT A
 40 PRINT B
 50 END


== 配列  DIM ==
住所録のようなものを作るときに使います。同じような変数をたくさん作るときに、変数が多くて大変です。そこで配列変数（はいれつ へんすう）を使います。

使い方は、最初に配列変数を宣言します。例えば DIM a(3)と書いたなら、変数a(1) a(2) a(3)の3個の配列変数が使えるようになります(BASICの種類によってはa(0)も使えるものがあります)。
 
「DIM」とは次元 DIMENSION の略のことです。DIMの部分が、配列宣言の命令です。DIM a(3)の「a」の部分は変数名ですので、べつにbでもcでも、かまいません。

DIM a(3)のカッコとカッコ内の部分を「添え字」（そえじ）と言います。

配列変数の便利な所は、数値で書いた部分に数値変数を使って、例えば、a(i)のように使う事ができ、ループなどと組合わせれば多数の変数を一度に扱うことが出来ます。

 10 DIM A(10)
 20 FOR I=1 to 10
 30   A(I)=I*2
 40 NEXT I
 50 FOR J=1 TO 10
 60   PRINT A(I)
 70 NEXT J
 90 END


これは、一次元配列の例です。
 10 DIM NAMAE$(3)
 20 DIM NO(3)
 30 FOR I=1 TO 3
 40   INPUT &quot;NAMAE&quot;;NAMAE$(I)
 50   INPUT &quot;BANGO&quot;;NO(I)
 60 NEXT I
 70 FOR I=1 TO 3
 80   PRINT NAMAE$(I),NO(I)
 90 NEXT I
 100 END

これは、３人の名前と番号を入力して、表示するプログラムコードです。配列を使うことにより、簡潔に書くことが出来ます。簡単に人数を多くすることが出来ます。改良して住所録のように作り変えることも容易です。

配列には、このような一次元配列の他に二次元、３次元配列もあります。

== あとがき ==
ここでは、始めての人が雰囲気をつかめるように基本の中の初歩を最低限に書きました。そして、初級と応用は別の本につづきます。

== 補足 ==
=== 複数行のIF文 ===
現在では構造化BASICもあります。これは条件文が成立すればTHENからENDIFあるいはELSEまでの部分を実行して、成立しなければELSEからENDIFまでを実行するもので、例のプログラムは
 10 A=0
 20 B=3
 30 '''IF''' A &gt; B '''THEN'''
 40   PRINT &quot;A is bigger than B&quot;
 50 '''ELSE'''
 60   PRINT &quot;B is bigger than A&quot;
 70 '''ENDIF'''
 80 END
と書けて、非常に見やすくなります。ただし、必ずしも使えるものではありません。古いBASICでは1行で書く方法しか使えません。

=== マルチステートメント ===
（:）で区切って、一行に多くのコマンドを書く事ができます。ただし、これは古いBASICの文法なのであまり使わない方が良いでしょう。

{{-}}
== マルチメディア関係 ==
円や直線などの画像を表示したり、音声を鳴らしたりなどの機能の命令は、BASIC対応のパソコンを作っている会社ごとに違っていました。ハードウェア側の性能にも関係することであり、そのため、仕様統一しきれなかったのです。

一応、BASICの国際規格も存在していますが、実際には、この規格に従ってないBASICも多いです。おそらく、特に、画像表示や音声などのマルチメディア関係の機能では、そのような規格外の仕様が多いでしょう。

このwikibooks日本語版『BASIC』では、日本の読者を対象にしていることもあり、日本で普及した日本産パソコンのハードウェアを想定して、BASICの、画像表示や音声などのマルチメディア関係のプログラムを記述します。

=== グラフィック関連 ===
==== 直線 ====
:※ BASICの書籍が入手できないので、記憶とネット上の情報に頼って記述しております。

N88BASIC互換のBASICならば、画像をつくるときは、
 LINE (100,130)-(200,230),1
のように記述することで、画像で直線を引けます。

内容は、
 LINE(始点のx座標、始点のy座標)-（終点のx座標、終点のy座標）、色番号
です。
気をつけることとして、画面の左上が座標(0,0)です。右下に行くにつれて、座標の値が大きくなります。

色番号は、一般に、
:0 黒
:1 青
:2 赤
:3 紫
:4 緑
:5 水色
:6 黄色
:7 白
です。色番号のことを「パレット番号」ともいいます。

背景色が標準設定では黒でしょうから、色番号が0（黒）だと、線が見えないかもしれません。

 LINE (100,130)-(200,230),1
は、青色の直線を引きます。

 LINE (100,130)-(200,230),2
は、赤色の直線を引きます。


 LINE (100,130)-(200,230),2,B
とすると、長方形の枠線のみを描きます。その長方形の対角線の座標が、(100,130)から(200,230)というわけです。
BはBOXの意味です。

この命令 LINE (100,130)-(200,230),2,B では、対角線は、描かれません。また、塗りつぶしも、されません。


塗りつぶしをするには、「B」ではなく「BF」にします。
 LINE (100,130)-(200,230),2,BF

FはFILLの意味です。

==== 円 ====
書式は
 CIRCLE (中心のx座標,中心のy座標),半径,色
です。

たとえば、
 CIRCLE (250,180),50,2
で、（250,180）座標を中心とする半径50の赤い（色番号: 2）円を書きます。

円弧を描くには、
 CIRCLE (中心のx座標,中心のy座標),半径,色,開始角,終了角
の構文を利用します。

角度の測り方は、数学のxy座標での角度の測り方と同じで、右を0度として、半時計まわり（左まわり）です。角度の単位は、ラジアン です。約3.14で半円になります（BASICのソフトウェアの種類によっては、違うかもしれません。それぞれのソフトウェアごとに確認してください。）。

まだラジアンを習っていない中学生のかたは、この節は飛ばしましょう。

 5 CLS
 10 CIRCLE (250,180),50,2,0,3.14
と書けば、半円弧が描かれます。

楕円（だえん）または楕円弧を書くには、
 10 CIRCLE (250,180),50,2,0,3.14,2
のようにします。

CIRCLE命令は、
 CIRCLE (中心のx座標,中心のy座標),半径,色,開始角,終了角,比率
という書式になっています。

比率は、縦と横の比率であり、1だと正円になります。1より大きいと縦長の楕円になり、1より小さいと横長の楕円になります。

塗りつぶすには、


==== 点のプロット ====
命令「PSET」を使うと、指定した位置に、点をひとつ追加します。

書式は
 PSET(x座標,y座標),色番号
です。

PSETの活用方法は通常、次のように、FOR文などの繰り返し文とくみあわせて、計算式などの結果の作図をするのに使用するでしょう。

 10 FOR N=0 TO 50
 20 PSET(200+N,100+0.01*N*N),1
 30 NEXT N
 40 END


=== 音 ===

 BEEP
と入力すると、「プツッ」とか「ピー」とかの音を鳴らします。ビープ音といいます。


== 乱数 ==
「RND()」で、0から1までの小数を含む乱数を発生させます。

RND(1)のように、括弧の中に数字を入れて使用します。

 10 X = RND (1)
 20 PRINT X
のように使用します。


サイコロをつくるには（1から6の整数だけを出すプログラムをつくるには）、乱数命令に、整数化の命令などと組み合わせます。

ループさせていますが、INPUT 命令を使ってEnterキーを押すごとに次の乱数を表示させています。RND()は、実際には1の値が生成されることは、ほとんど無いと思われるのでこのプログラムになります。割り込みキー（BREAKキーやESCキー）で実行が終了します。

 10 X = INT(RND(1) * 6 + 1)
 20 PRINT X
 30 INPUT Y
 40 GOTO 10

== 1970〜80年代のパソコン事情が背景にある ==
BASICは、形式的には、BASICはプログラム言語であるとして分類されています。しかし、実際には、古いBASICを21世紀に再現したBASICでは、他のプログラム言語にはない、画像表示の機能が充実しています。これはどういう事かというと、再現BASICでは、画像表示の命令を実行する際には、OSの画像表示の機能を呼び出して、使っているのです。一般的に、プログラムを通しての画像表示についての仕様は、各OSごとにバラバラです。そのため、BASICのインタプリタ自体の作成者は、それぞれのOSごとに、BASICインタプリタを作りなおす必要があります。このため、再現BASICには、Windows版しかインタプリタの作られてない再現BASICもあります。

そもそも、実際の古いBASICの流行した1970年代ごろは、21世紀の今とはパソコン販売の状況が違っています。1970年代ごろの当時は、まだOS（オペレーティング システム）が高度化する前だったこともあり、さらに、OSとパソコン本体がくっついて販売されていたこともあり、1970年代ごろは、BASICが販売されているパソコンと一緒に、OSと一緒にパソコン本体に組み込まれている状態で、販売されていました。

このため、実際の1970〜80年代に市販されていたパソコンに組み込まれていたBASICでは、画面に円や直線などを表示したりする画像表示の命令や、ブザー音を鳴らすなど命令なども、簡単にプログラム記述できるようになっています。

本来、画像表示のための処理は、ディスプレイの種類ごとに、解像度がバラバラだったりするので、パソコン内部動作を分ける必要があるので、オペレーティングシステムの機能を使って、画像を表示したりすることになります。

しかし、当時のBASICでは、オペレーティングシステムの仕組みを、意識する必要はありませんでした。なぜなら、特定企業のパソコンに組み込まれた状態でBASICが配布されていたので、その特定企業のディスプレイやスピーカーといったハードウェアを、簡単に制御できるように、BASICが改良してあったのです。

このような事情のため、そもそも当時のほとんどの消費者は、そもそもオペレーティング システムいう概念すら知りませんでした。

このように、BASICの機能の背景には、1970〜80年当時のパソコン事情があります。

1970年当時は、各パソコン会社のBASICが最初から特定の自社パソコンに対応した状態で、パソコンに組み込まれていて販売されていたので、BASICから直接オペレーティングシステムの機能を利用できるわけです。このため、1970年ごろのBASICの機能は、現在の「プログラム言語」とは、やや違っています。

さて21世紀の現在、プログラムで画像を表示したり、あるいは音声を鳴らしたりなどのプログラムを記述したい場合には、オペレーティングシステムの機能を活用する必要があります。OSの機能を使うためのコマンド群である「API」（エー ピー アイ）といいます。つまり、再現BASICのインタプリタ作成者は、（おそらく）APIを駆使して、再現BASICの画像表示や音声機能などを、作っているのです。

オペレーティングシステムには、ウィンドウズやマックOSやリナックスなど、色々とありますが、それぞれのOSごとに仕組みが違うので、プログラムの記述作業も、それぞれのOSごとに、プログラムを分ける必要があります。

上述のようなパソコン事情が、1970年頃と現代では大きく違うので、もはやBASICだけでは、高度なアプリケーションを作ろうとしても、あまり簡単には作れなくなってしまいました。

なので、もし、21世紀の現代の人が、独学でBASICを学ぶ場合は、けっして古いBASICだけで満足せずに、なるべく、C言語を学んだり、さらに、その後の時代の他のプログラム言語も学びましょう。

== 参考リンク ==


{{stub}}
[[Category:BASIC|*]]
[[Category:プログラミング言語]]
{{NDC|007.64}}</text>
      <sha1>1ts8dhk52cnuhatfy98eglg6itid6hp</sha1>
    </revision>
  </page>
  <page>
    <title>会社法第847条</title>
    <ns>0</ns>
    <id>4403</id>
    <revision>
      <id>205717</id>
      <parentid>201281</parentid>
      <timestamp>2022-07-23T12:26:24Z</timestamp>
      <contributor>
        <username>はいかぐら</username>
        <id>45848</id>
      </contributor>
      <minor />
      <comment>/* 解説 */</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="4855" xml:space="preserve">[[法学]]＞[[民事法]]＞[[商法]]＞[[コンメンタール会社法]]＞[[第7編 雑則 (コンメンタール会社法)]]

==条文==
（[[w:株主代表訴訟|責任追及等の訴え]]）
;第847条
# 6箇月（これを下回る期間を定款で定めた場合にあっては、その期間）前から引き続き株式を有する株主（[[会社法第189条|第189条]]第2項の定款の定めによりその権利を行使することができない単元未満株主を除く。）は、株式会社に対し、書面その他の法務省令で定める方法により、発起人、設立時取締役、設立時監査役、役員等（[[会社法第423条|第423条]]第1項に規定する役員等をいう。）若しくは清算人（以下この節において「発起人等」という。）の責任を追及する訴え、[[会社法第102条の2|第102条の2]]第1項、[[会社法第212条|第212条]]第1項若しくは[[会社法第285条|第285条]]第1項の規定による支払を求める訴え、[[会社法第120条|第120条]]第3項の利益の返還を求める訴え又は[[会社法第213条の2|第213条の2]]第1項若しくは[[会社法第286条の2|第286条の2]]第1項の規定による支払若しくは給付を求める訴え（以下この節において「責任追及等の訴え」という。）の提起を請求することができる。ただし、責任追及等の訴えが当該株主若しくは第三者の不正な利益を図り又は当該株式会社に損害を加えることを目的とする場合は、この限りでない。
# 公開会社でない株式会社における前項の規定の適用については、同項中「6箇月（これを下回る期間を定款で定めた場合にあっては、その期間）前から引き続き株式を有する株主」とあるのは、「株主」とする。
# 株式会社が第1項の規定による請求の日から60日以内に責任追及等の訴えを提起しないときは、当該請求をした株主は、株式会社のために、責任追及等の訴えを提起することができる。
# 株式会社は、第1項の規定による請求の日から60日以内に責任追及等の訴えを提起しない場合において、当該請求をした株主又は同項の発起人等から請求を受けたときは、当該請求をした者に対し、遅滞なく、責任追及等の訴えを提起しない理由を書面その他の法務省令で定める方法により通知しなければならない。
# 第1項及び第3項の規定にかかわらず、同項の期間の経過により株式会社に回復することができない損害が生ずるおそれがある場合には、第1項の株主は、株式会社のために、直ちに責任追及等の訴えを提起することができる。ただし、同項ただし書に規定する場合は、この限りでない。

==解説==
いわゆる[[w:株主代表訴訟]]についての規定である。
*第1項は、提訴請求について規定している。（[[w:単独株主権]]）
*:第189条（単元未満株式についての権利の制限等）
*:第423条（役員等の株式会社に対する損害賠償責任）
*:第212条（不公正な払込金額で株式を引き受けた者等の責任）
*:第120条（株主の権利の行使に関する利益の供与）
*第2項は、[[w:公開会社でない会社|公開会社でない会社]]の場合の提訴請求の主体の適格の要件の変更について規定している。
*第3項は、責任追及等の訴えの提訴できる条件について規定している。
*第4項は、責任追及等の訴えの際の通知について規定している。
*第5項は、株式会社に回復することができない損害が生じるおそれがある場合の例外について規定している。
*第6項は、責任追及等の訴えの訴額の算定方法について規定している。
*第7項は、被告の申し立てによる担保提供命令について規定している。
*第8項は、担保提供命令の際の被告の疎明事項について規定している。

==関連条文==
*[[会社法第386条]]（監査役設置会社と取締役との間の訴えにおける会社の代表）

----
{{前後
|[[コンメンタール会社法|会社法]]
|[[第7編 雑則 (コンメンタール会社法)|第7編 雑則]]&lt;br&gt;
[[第7編 雑則 (コンメンタール会社法)#2|第2章 訴訟]]&lt;br&gt;
[[第7編 雑則 (コンメンタール会社法)#2-2|第2節 株式会社における責任追及等の訴え]]
|[[会社法第846条の9]]&lt;br&gt;（原告が敗訴した場合の損害賠償責任）
|[[会社法第847条の2]]&lt;br&gt;（旧株主による責任追及等の訴え）
}}

{{stub}}

[[Category:会社法|847]]</text>
      <sha1>dskbq50lhbmkdfq5wfospiws7v1ztlg</sha1>
    </revision>
  </page>
  <page>
    <title>民法第122条</title>
    <ns>0</ns>
    <id>4558</id>
    <revision>
      <id>205745</id>
      <parentid>172942</parentid>
      <timestamp>2022-07-23T21:52:15Z</timestamp>
      <contributor>
        <username>Rhkmk</username>
        <id>66092</id>
      </contributor>
      <minor />
      <comment>/* 条文 */</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="2428" xml:space="preserve">[[法学]]＞[[民事法]]＞[[民法]]＞[[コンメンタール民法]]＞[[第1編 総則 (コンメンタール民法)]]

==条文==
（取り消すことができる行為の追認）
;第122条
:取り消すことができる行為は、[[民法第120条|第120条]]に規定する者が'''追認したとき'''は、以後、取り消すことができない。
===改正経緯===
#2017年改正で、但書「ただし、追認によって第三者の権利を害することはできない。」を削除。
#2004年（平成16年）改正前の民法においては、追認の効果は「初ヨリ有効ナリシモノト看做ス」とされていたが、「取り消すことができる行為」は取り消されるまでは有効であるため、正確でないことから、現行のように改められた。

==解説==
[[w:追認|追認]]の効果について規定。取消しは[[民法第119条|第119条]]により、遡及効を有するが、追認することにより取消権（形成権）は確定的に消滅し、当該行為が当初から有効であったことが確定する。この場合、取り消されることを期待した行為を当事者外に及ぼす余地はないため、第三者の権利侵害の場合については、従前から存在意義につき議論があり、2017年改正で削除された。

「追認したとき」と取り扱われるための要件については、民法第123条、民法第124条を参照。
*民法第120条（取消権者）

==関連条文==
*[[民法第119条]]（取消しの効果）
*[[民法第123条]]（取消し及び追認の方法）
*[[民法第124条]]（追認の要件）
*[[民法第125条]]（法定追認）

==参考文献==
*[[w:我妻栄|我妻栄]]『新訂民法総則（民法講義1）』（岩波書店、1965年）398頁
*[[w:四宮和夫|四宮和夫]]『民法総則（第4版補正版）』（弘文堂、1996年）221頁

----
{{前後
|[[コンメンタール民法|民法]]
|[[第1編 総則 (コンメンタール民法)|第1編 総則]]&lt;br&gt;
[[第1編 総則 (コンメンタール民法)#5|第5章 法律行為]]&lt;br&gt;
[[第1編 総則 (コンメンタール民法)#5-4|第4節 無効及び取消し]]
|[[民法第121条の2]]&lt;br&gt;（原状回復の義務）
|[[民法第123条]]&lt;br&gt;（取消し及び追認の方法）
}}

{{stub}}
[[category:民法|122]]
[[category:民法 2017年改正|122]]</text>
      <sha1>o5lw8x2ahpwkgl1mkqqtdv5652xy087</sha1>
    </revision>
  </page>
  <page>
    <title>民法第536条</title>
    <ns>0</ns>
    <id>4764</id>
    <revision>
      <id>205718</id>
      <parentid>197354</parentid>
      <timestamp>2022-07-23T12:27:39Z</timestamp>
      <contributor>
        <username>はいかぐら</username>
        <id>45848</id>
      </contributor>
      <minor />
      <comment>/* 参照条文 */</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="7432" xml:space="preserve">[[法学]]＞[[民事法]]＞[[民法]]＞[[コンメンタール民法]]＞[[第3編 債権 (コンメンタール民法)]]
==条文==
（債務者の[[危険負担]]等）
;第536条
# '''当事者双方の責めに帰することができない事由'''によって債務を履行することができなくなったときは、債権者は、反対給付の履行を拒むことができる。
# '''債権者の責めに帰すべき事由'''によって債務を履行することができなくなったときは、債権者は、反対給付の履行を拒むことができない。この場合において、債務者は、'''自己の債務を免れたことによって利益を得たとき'''は、これを債権者に償還しなければならない。
===改正経緯===
2017年改正により以下の条文から改正。

# 前二条に規定する場合を除き、当事者双方の責めに帰することができない事由によって債務を[[履行]]することができなくなったときは、債務者は、反対給付を受ける権利を有しない。 
#*主体を債務者から債権者とする。
#*前二条 - ともに削除された。従って、「'''当事者双方の責めに帰することができない事由'''によって債務を履行することができなくなったとき」は、無条件に債務者が危険を負担する。
#:*[[民法第534条]]（債権者の危険負担） 
#:*[[民法第535条]]（停止条件付双務契約における危険負担） 
#*想定された適用局面
#*:家屋の賃貸借の場合、類焼で家屋が全焼し家屋を貸すという債務を履行することが出来なくなった時は、債務者である家主は、家賃という反対給付を受け取ることが出来ない。
# 債権者の責めに帰すべき事由によって債務を履行することができなくなったときは、債務者は、反対給付を受ける権利を失わない。この場合において、'''自己の債務を免れたことによって利益を得たとき'''は、これを債権者に償還しなければならない。 
#*主体を債務者から債権者とする。趣旨について改正前後で変更はない。
#*適用局面
#*:債権者である賃借人の失火で全焼したときは、家主は家賃を請求することが出来る。

==解説==
危険負担の債務者主義について定めた規定。
===第1項（当事者双方の責めに帰することができない事由による不履行の場合）関連===
当事者双方の帰責事由によらない履行不能の場合に債務者の反対給付を受ける権利も消滅する旨を定める民法第536条第1項については
もともと同条が「前二条に規定する場合」以外の場面を対象としていることから、この規定を適用して処理される実例が乏しく，判例等も少ないことが指摘されている。

その上、同条が適用されると想定される個別の契約類型において、危険負担的な処理（双方の責めに帰することができない事由で債務の一部ないし全部の履行ができなくなった場合の費用等の負担の処理）をすることが適当な場面については、契約各則においてその旨の規定を以下のとおり設けた。
*賃貸借 [[民法第611条]](賃借物の一部滅失等による賃料の減額等)、[[民法第616条の2]](賃借物の全部滅失等による賃貸借の終了)
*雇用 [[民法第624条の2]]（履行の割合に応じた報酬）
*請負 [[民法第634条]]（注文者が受ける利益の割合に応じた報酬）
*委任 [[民法第648条]]（受任者の報酬）

また，それ以外の同条第1項の適用が問題となり得る場面については、今回の改正により履行不能による契約の解除の要件として、債務者の帰責事由(旧・[[民法第543条|第543条]]ただし書)を不要としたため、債権者は債務の不履行を理由に契約の解除をすることにより自己の対価支払義務を免れることができるようになり、機能の重複が見られるようになった。

実際の適用場面を想定しにくい本条第1項を維持し、機能の重複する制度を併存させるよりも、法制度の簡明化を目的に、本項を削除し、解除に一元化する案も有力であったが、解除制度と危険負担制度とが併存する現行の体系の急激な変更を懸念する声も多く、削除は見送られた。従って、改正後も適用局面は限定されるものと予想される。

===第2項（債権者の責めに帰すべき事由による不履行の場合の解除権の制限）関連===
債務者の履行がない場合において、その不履行が契約の趣旨に照らして債権者の責めに帰すべき事由によるものであるときは、債権者は契約の解除をすることができない（[[民法第543条]]）。その帰結として反対給付を受ける権利は消滅しないという効果を導く。改正前後に趣旨の変更はないが、改正前の「反対給付を受ける権利を失わない」との文言については、これによって未発生の反対給付請求権が発生するか否かが明確でないとの指摘があったことを踏まえ、「債権者は、反対給付の履行を拒むことができない」という規定に改めた。

なお、第1項同様、賃貸借、雇用、請負、委任については、各則における規定が優先される。

==参照条文==
*[[民法第567条]]
*:売買契約において、売主が引渡しの債務の履行を提供したにもかかわらず、買主の[[受領遅滞]]により、当事者双方の責めに帰することができない事由によって目的物の滅失等が生じた場合、買主はその目的物に関して、売主に契約不適合の責任を追及することはできない（危険負担が移転する）。

==判例==
*[http://www.courts.go.jp/search/jhsp0030?hanreiid=63684&amp;hanreiKbn=02 解雇無効確認等請求]（最高裁判決 昭和37年07月20日）[[労働基準法第26条]],[[労働基準法第24条]]1項
*[http://www.courts.go.jp/search/jhsp0030?hanreiid=56327&amp;hanreiKbn=02  請負代金請求]（最高裁判決  昭和52年02月22日）[[民法第632条]] 
*[http://www.courts.go.jp/search/jhsp0030?hanreiid=70477&amp;hanreiKbn=02 雇用関係存在確認等](最高裁判決 昭和62年04月02日)[[労働基準法第12条]]1項,[[労働基準法第12条]]4項,[[労働基準法第24条]]1項,[[労働基準法第26条]]
*[http://www.courts.go.jp/search/jhsp0030?hanreiid=70485&amp;hanreiKbn=02 賃金（通称　ノースウエスト航空賃金請求）]（最高裁判決 昭和62年07月17日）[[労働基準法第26条]]

----
{{前後
|[[コンメンタール民法|民法]]
|[[第3編 債権 (コンメンタール民法)|第3編 債権]]&lt;br&gt;
[[第3編 債権 (コンメンタール民法)#2|第2章 契約]]&lt;br&gt;
[[第3編 債権 (コンメンタール民法)#2-1|第1節 総則]]
|[[民法第535条]]&lt;br&gt;（同時履行の抗弁）&lt;br&gt;[[民法第535条]]&lt;br&gt;削除
|[[民法第537条]]&lt;br&gt;（第三者のためにする契約）
}}

{{stub}}
[[category:民法|536]]
[[category:民法 2017年改正|536]]</text>
      <sha1>o7taf6xxo3sbjbgq1yhtiiqottrts2l</sha1>
    </revision>
  </page>
  <page>
    <title>民法第117条</title>
    <ns>0</ns>
    <id>4906</id>
    <revision>
      <id>205744</id>
      <parentid>200896</parentid>
      <timestamp>2022-07-23T21:41:49Z</timestamp>
      <contributor>
        <username>Rhkmk</username>
        <id>66092</id>
      </contributor>
      <minor />
      <comment>/* 条文 */</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="6519" xml:space="preserve">[[法学]]＞[[民事法]]＞[[民法]]＞[[コンメンタール民法]]＞[[第1編 総則 (コンメンタール民法)]]

== 条文 ==
（[[w:無権代理|無権代理人]]の責任）
;第117条
# 他人の代理人として契約をした者は、自己の代理権を証明したとき、又は本人の追認を得たときを除き、相手方の選択に従い、相手方に対して履行又は損害賠償の責任を負う。
# 前項の規定は、次に掲げる場合には、適用しない。
#: 一　他人の代理人として契約をした者が代理権を有しないことを相手方が知っていたとき。
#: 二　他人の代理人として契約をした者が代理権を有しないことを相手方が過失によって知らなかったとき。ただし、他人の代理人として契約をした者が自己に代理権がないことを知っていたときは、この限りでない。
#: 三　他人の代理人として契約をした者が行為能力の制限を受けていたとき。
=== 改正経緯 ===
*2017年改正前の条文は以下のとおり。表現を理解しやすいように改めたものである。また、改正により、相手方に過失があった場合でも、悪意の無権代理人に対しては履行又は損害賠償を請求できることが明記された。
# 他人の代理人として契約をした者は、自己の代理権を証明することができず、かつ、本人の追認を得ることができなかったときは、相手方の選択に従い、相手方に対して履行又は損害賠償の責任を負う。 
# 前項の規定は、他人の代理人として契約をした者が代理権を有しないことを相手方が知っていたとき、若しくは過失によって知らなかったとき、又は他人の代理人として契約をした者が[[w:行為能力|行為能力]]を有しなかったときは、適用しない。

== 解説 ==
無権代理人の責任の発生要件と発生する責任の内容について規定している。

損害賠償とは'''履行利益'''（りこうりえき）の損害賠償であり、相手方の要求する時までに契約の目的物の価額が値上がりすれば賠償額も上がる。

この規定は、自ら債務を負う[[w:効果意思|効果意思]]を持たない無権代理人に、法が敢えて履行責任（または履行利益の損害賠償責任）を負わせるものであるから、[[w:法定責任|法定責任]]であるといわれる。その趣旨は、代理権を有するかのような外観を信頼した相手方の保護にある。したがって、保護される相手方は、無権代理人が代理権を有しないことについて、[[w:善意|善意]]、無過失であることが要求され、かつ、行為能力を有しない無権代理人（[[民法第102条|102条]]により代理人は制限行為能力者であってもよい）には効果を帰属させない。

ここで、相手方は無権代理人が自分と契約を締結した事実、無権代理人が顕名をした事実を証明しただけで責任を追及できるとされているので、無権代理人の責任の要件は、無権代理人が立証責任を負うとされる。したがって代理権を有したこと、本人が追認したこと、相手方が取り消したこと、相手方の悪意有過失、自らが制限行為能力者であることを証明できなければ無権代理人は責任を免れない。

== 参照条文 ==
* [[民法第115条]]（無権代理の取消し）
* [[民法第116条]]（無権代理の追認）
* [[民法第118条]]（単独行為の無権代理）

== 判例 ==
* [http://www.courts.go.jp/app/hanrei_jp/detail2?id=52942 登記抹消請求] （最高裁判決 昭和35年11月29日）[[民法第545条]]
* [http://www.courts.go.jp/app/hanrei_jp/detail2?id=57723 建物引渡所有権移転登記手続等請求]（最高裁判決 昭和37年4月20日） [[民法第113条]]
* [http://www.courts.go.jp/app/hanrei_jp/detail2?id=56288 土地所有権移転登記抹消登記手続請求]（最高裁判決 昭和40年6月18日） 民法第113条，[[民法第896条]]
* [http://www.courts.go.jp/app/hanrei_jp/detail2?id=54946 自動車譲渡代金請求]（最高裁判決 昭和42年9月26日）[[商法第168条]]1項6号
* [http://www.courts.go.jp/app/hanrei_jp/detail2?id=52032 貸金請求] （最高裁判決 昭和48年7月3日） 民法第113条，[[民法第896条]]
*: 無権代理人を相続した本人は、無権代理人が民法117条により相手方に債務を負担していたときには、無権代理行為について追認を拒絶できる地位にあつたことを理由として、右債務を免れることができない。
* [http://www.courts.go.jp/app/hanrei_jp/detail2?id=55207 保証債務履行]（最高裁判決 昭和62年7月7日） [[民法第109条]]，[[民法第110条]]，民法第113条
*: 無権代理人は、民法117条1項所定の責任を免れる事由として、[[w:表見代理|表見代理]]の成立を主張することはできない。
* [http://www.courts.go.jp/app/hanrei_jp/detail2?id=56365 貸金] （最高裁判決 平成5年1月21日）[[民法第112条]]，民法第896条，[[民法第898条]]
*:無権代理人が本人を共同相続した場合には、共同相続人全員が共同して無権代理行為を追認しない限り、無権代理人の相続分に相当する部分においても、無権代理行為が当然に有効となるものではない。
* [http://www.courts.go.jp/app/hanrei_jp/detail2?id=73151  土地建物所有権移転登記抹消登記、土地所有権移転請求権仮登記抹消登記等]（最高裁判決 平成5年1月21日）[[民法第113条]]，民法第896条，民法第898条
* [http://www.courts.go.jp/app/hanrei_jp/detail2?id=52792 根抵当権設定登記抹消登記手続請求本訴、同反訴]（最高裁判決 平成10年7月17日）民法第113条、民法第896条

-----
{{前後
|[[民法]]
|[[第1編 総則 (コンメンタール民法)|第1編 総則]]&lt;br&gt;[[第1編 総則 (コンメンタール民法)#5|第5章 法律行為]]&lt;br&gt;[[第1編 総則 (コンメンタール民法)#5-3|第3節　代理]]
|[[民法第116条]]&lt;br&gt;(無権代理の追認)
|[[民法第118条]]&lt;br&gt;(単独行為の無権代理)
}}

{{stub}}
[[category:民法|117]]
[[category:民法 2017年改正|117]]</text>
      <sha1>ekgeqf0g2bo42v4of9j18b2v6qfbgt2</sha1>
    </revision>
  </page>
  <page>
    <title>高等学校倫理</title>
    <ns>0</ns>
    <id>5012</id>
    <revision>
      <id>205741</id>
      <parentid>204466</parentid>
      <timestamp>2022-07-23T14:12:56Z</timestamp>
      <contributor>
        <username>椎楽</username>
        <id>32225</id>
      </contributor>
      <minor />
      <comment>/* はじめに */</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="2927" xml:space="preserve">{{進捗状況}}
&lt;small&gt; [[小学校・中学校・高等学校の学習]]＞[[高等学校の学習]]＞[[高等学校倫理]] &lt;/small&gt;&lt;br&gt;
&lt;small&gt; [[哲学・思想]] &gt; [[高等学校倫理]] &lt;/small&gt;

高等学校公民の科目である「倫理」の教科書です。&lt;br&gt;
本教科書は高等学校学習指導要領に基づいて執筆されます。&lt;br&gt;
学習指導要領に定められた標準単位数は2単位です。

== 目次 ==
=== はじめに ===
[[高等学校倫理/倫理を学ぶ目的]]{{進捗|100%|2007-01-19}}

=== 青年期の課題と人間としての在り方生き方 ===
ア [[高等学校倫理/青年期の課題]]{{進捗|00%|2007-01-19}}&lt;br&gt;
イ [[高等学校倫理/自己の確立を目指して]]{{進捗|00%|2007-01-19}}&lt;br&gt;

===人間としての自覚===

ア　[[高等学校倫理/古代ギリシアの哲学|哲学の誕生――自然哲学者・ソフィスト]]{{進捗|75%|2019-03-23}}&lt;br&gt;
:-タレス
:-ピタゴラス
:-ヘラクレイトス
:-デモクリトス
イ　哲学の発展――ソクラテス以降のギリシャ哲学{{進捗|00%|2013-07-05}}&lt;br&gt;
:-ソクラテス
:-プラトン
:-アリストテレス
:-ヘレニズム時代の思想
ウ　諸子百家の思想{{進捗|00%|2013-07-05}}&lt;br&gt;
エ　宗教と人間{{進捗|25%|2018-03-23}}
:-[[高等学校倫理/三大宗教の始まり]]

===国際社会に生きる日本人としての自覚===
ア　日本人の精神と風土{{進捗|00%|2013-07-05}}&lt;br&gt;
イ　日本での仏教の受容と発展{{進捗|00%|2013-07-05}}&lt;br&gt;
ウ　儒教の受容と発展{{進捗|00%|2013-07-05}}&lt;br&gt;
エ　日本独自の思想の発展――国学と庶民の思想{{進捗|00%|2013-07-05}}&lt;br&gt;
オ　日本の近代化と西洋思想の受容{{進捗|00%|2013-07-05}}

===現代に生きる人間の倫理と思想===
ア　人間性の尊重{{進捗|00%|2013-07-05}}&lt;br&gt;
イ　宗教改革{{進捗|00%|2013-07-05}}&lt;br&gt;
ウ　モラリストの思想{{進捗|00%|2013-07-05}}&lt;br&gt;
エ　[[高等学校倫理/近代の合理的・科学的な思考と方法]]{{進捗|25%|2019-04-08}}&lt;br&gt;
オ　ドイツ観念論哲学{{進捗|00%|2013-07-05}}&lt;br&gt;
カ　民主主義社会の倫理と思想{{進捗|00%|2013-07-05}}&lt;br&gt;
キ　新しい知性と人間のあり方について{{進捗|00%|2013-07-05}}&lt;br&gt;
ク　自然観の再考と人間の未来{{進捗|00%|2013-07-05}}

=== 現代と倫理 ===
ア [[高等学校倫理/現代の特質と倫理的課題]]{{進捗|00%|2007-01-19}}&lt;br&gt;
イ [[高等学校倫理/現代に生きる人間の倫理]]{{進捗|00%|2007-01-19}}&lt;br&gt;
ウ [[高等学校倫理/現代の諸課題と倫理]]{{進捗|00%|2007-01-19}}&lt;br&gt;

=== 資料 ===
ア [[高等学校倫理/先人たちの言葉]]{{進捗|00%|2019-03-27}}

イ [[高等学校倫理/参考文献]]

[[Category:高等学校教育|りんり]]
[[Category:社会科教育|高りんり]]
[[Category:高等学校倫理|*]]</text>
      <sha1>6ngddek2y9d9ocbms6xaks0phqj8wna</sha1>
    </revision>
    <revision>
      <id>205742</id>
      <parentid>205741</parentid>
      <timestamp>2022-07-23T14:17:33Z</timestamp>
      <contributor>
        <username>椎楽</username>
        <id>32225</id>
      </contributor>
      <comment>/* 人間としての自覚 */</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="3272" xml:space="preserve">{{進捗状況}}
&lt;small&gt; [[小学校・中学校・高等学校の学習]]＞[[高等学校の学習]]＞[[高等学校倫理]] &lt;/small&gt;&lt;br&gt;
&lt;small&gt; [[哲学・思想]] &gt; [[高等学校倫理]] &lt;/small&gt;

高等学校公民の科目である「倫理」の教科書です。&lt;br&gt;
本教科書は高等学校学習指導要領に基づいて執筆されます。&lt;br&gt;
学習指導要領に定められた標準単位数は2単位です。

== 目次 ==
=== はじめに ===
[[高等学校倫理/倫理を学ぶ目的]]{{進捗|100%|2007-01-19}}

=== 青年期の課題と人間としての在り方生き方 ===
ア [[高等学校倫理/青年期の課題]]{{進捗|00%|2007-01-19}}&lt;br&gt;
イ [[高等学校倫理/自己の確立を目指して]]{{進捗|00%|2007-01-19}}&lt;br&gt;

===人間としての自覚===

ア　[[高等学校倫理/古代ギリシアの哲学|哲学の誕生――自然哲学者・ソフィスト]]{{進捗|75%|2019-03-23}}&lt;br&gt;
:-タレス
:-ピタゴラス
:-ヘラクレイトス
:-デモクリトス
イ　哲学の発展――ソクラテス以降のギリシャ哲学{{進捗|00%|2013-07-05}}&lt;br&gt;
:-[[高等学校倫理/ソクラテス|ソクラテス]]
:-[[高等学校倫理/プラトン|プラトン]]
:-[[高等学校倫理/アリストテレス|アリストテレス]]
:-[[高等学校倫理/ヘレニズムの思想|ヘレニズムの思想]]
ウ　諸子百家の思想{{進捗|00%|2013-07-05}}&lt;br&gt;
:-[[高等学校倫理/儒家の思想|儒家の思想]]
:-[[高等学校倫理/道家の思想|道家の思想]]
:-[[高等学校倫理/諸子百家の思想|諸子百家の思想]]
エ　宗教と人間{{進捗|25%|2018-03-23}}
:-[[高等学校倫理/三大宗教の始まり]]

===国際社会に生きる日本人としての自覚===
ア　日本人の精神と風土{{進捗|00%|2013-07-05}}&lt;br&gt;
イ　日本での仏教の受容と発展{{進捗|00%|2013-07-05}}&lt;br&gt;
ウ　儒教の受容と発展{{進捗|00%|2013-07-05}}&lt;br&gt;
エ　日本独自の思想の発展――国学と庶民の思想{{進捗|00%|2013-07-05}}&lt;br&gt;
オ　日本の近代化と西洋思想の受容{{進捗|00%|2013-07-05}}

===現代に生きる人間の倫理と思想===
ア　人間性の尊重{{進捗|00%|2013-07-05}}&lt;br&gt;
イ　宗教改革{{進捗|00%|2013-07-05}}&lt;br&gt;
ウ　モラリストの思想{{進捗|00%|2013-07-05}}&lt;br&gt;
エ　[[高等学校倫理/近代の合理的・科学的な思考と方法]]{{進捗|25%|2019-04-08}}&lt;br&gt;
オ　ドイツ観念論哲学{{進捗|00%|2013-07-05}}&lt;br&gt;
カ　民主主義社会の倫理と思想{{進捗|00%|2013-07-05}}&lt;br&gt;
キ　新しい知性と人間のあり方について{{進捗|00%|2013-07-05}}&lt;br&gt;
ク　自然観の再考と人間の未来{{進捗|00%|2013-07-05}}

=== 現代と倫理 ===
ア [[高等学校倫理/現代の特質と倫理的課題]]{{進捗|00%|2007-01-19}}&lt;br&gt;
イ [[高等学校倫理/現代に生きる人間の倫理]]{{進捗|00%|2007-01-19}}&lt;br&gt;
ウ [[高等学校倫理/現代の諸課題と倫理]]{{進捗|00%|2007-01-19}}&lt;br&gt;

=== 資料 ===
ア [[高等学校倫理/先人たちの言葉]]{{進捗|00%|2019-03-27}}

イ [[高等学校倫理/参考文献]]

[[Category:高等学校教育|りんり]]
[[Category:社会科教育|高りんり]]
[[Category:高等学校倫理|*]]</text>
      <sha1>n570qgvciutabv8l81icteq5vnzvxeu</sha1>
    </revision>
  </page>
  <page>
    <title>高等学校倫理/倫理を学ぶ目的</title>
    <ns>0</ns>
    <id>5014</id>
    <revision>
      <id>205739</id>
      <parentid>134621</parentid>
      <timestamp>2022-07-23T14:12:03Z</timestamp>
      <contributor>
        <username>椎楽</username>
        <id>32225</id>
      </contributor>
      <minor />
      <comment>椎楽 がページ「[[倫理を学ぶ目的]]」を「[[高等学校倫理/倫理を学ぶ目的]]」に移動しました: 高校「倫理」のサブページとするため</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="2739" xml:space="preserve">&lt;small&gt; [[高等学校倫理]]＞はじめに＞[[倫理を学ぶ目的]] &lt;/small&gt;

現在、日本の高等学校では公民科目の[[高等学校現代社会]]または[[高等学校政治経済]]・[[高等学校倫理]]が必修科目として学習指導要領により定められています。

現代社会と選択余地があるものの、必修科目であることは高等学校で'''倫理'''を学ぶことが強く薦められていることに他なりません。

なぜ、私たちは倫理を学ぶことを促されているのでしょうか。この学習指導要領には倫理の指導者、高校教諭にこのような目標を設定しています。

:人間尊重の精神と生命に対する畏敬の念に基づいて,青年期における自己形成と人間としての在り方生き方について理解と思索を深めさせるとともに,人格の形成に努める実践的意欲を高め,他者と共に生きる主体としての自己の確立を促し,良識ある公民として必要な能力と態度を育てる。
生きるとは、どういうことなのだろうか。また、どう生きればよいのか。「私」や「他人」とは何であるのか。そして、どのような「私」になればいいのか。どのように「他人」と接すればよいのか。&lt;br&gt;
このような疑問は青年期に差しかかった私たちが直面するであろう解決しがたい問題となります。その解決の糸口としてこの'''倫理'''が示されているのです。


このような疑問は、現代に生きる私たちだけに限ったことではなく、遠い昔の人たちも同じように経験したことであると思われます。その中でもこの疑問を解決することに一生の多くを裂いたであろう先哲、過去の偉人たちが残した言葉は現代にも生きています。その言葉を頼りに私たちそれぞれの疑問を解決する糸口を探し出そう。これが学習指導要領の定める倫理なのです。

指導者に示された目標であると同時にこれは私たち一人一人にも投げかけられた目標でもあるのです。先哲の言葉、思想、作品に触れることで彼らの一生をかけた悩み、苦しみ、情熱などが垣間見えることでしょう。彼らの思いを道しるべにして、倫理の学習を始めてみませんか。

[[Category:高等学校教育|倫りんりをまなふもくてき]]
[[Category:社会科教育|倫りんりをまなふもくてき]]
[[Category:高等学校倫理|*]]
[[Category:思想|高りんりをまなふもくてき]]
[[Category:哲学|高りんりをまなふもくてき]]</text>
      <sha1>hsxbmva8nul8sptyyd2s001029s56p6</sha1>
    </revision>
  </page>
  <page>
    <title>民法第111条</title>
    <ns>0</ns>
    <id>5354</id>
    <revision>
      <id>205720</id>
      <parentid>172926</parentid>
      <timestamp>2022-07-23T12:47:01Z</timestamp>
      <contributor>
        <username>Rhkmk</username>
        <id>66092</id>
      </contributor>
      <minor />
      <comment>/* 条文 */</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="2263" xml:space="preserve">[[法学]]＞[[民事法]]＞[[民法]]＞[[コンメンタール民法]]＞[[第1編 総則 (コンメンタール民法)]]

==条文==
（[[w:代理権|代理権]]の消滅事由） 
;第111条
# 代理権は、次に掲げる事由によって消滅する。 
#:一　本人の死亡 
#:二　代理人の死亡又は代理人が[[w:|破産手続開始決定]]若しくは後見開始の審判を受けたこと。 
# [[w:委任|委任]]による代理権は、前項各号に掲げる事由のほか、委任の終了によって消滅する。

==解説==
{| class=&quot;wikitable&quot; style=&quot;background-color:#fdd&quot;
|+ 代理権の消滅事由
! !! 本人（委任者）について !! 代理人（受任者）について
|-
! 死亡
| 消滅 || 消滅
|-
! 破産手続き開始決定
| style=&quot;background-color:#dfd&quot; | 法定代理権は消滅せず&lt;br&gt;委任による代理権は消滅
| 消滅
|-
! 後見開始の審判
| style=&quot;background-color:#ddf&quot; | 消滅せず
| 消滅
|}

==参考条文==
*[[民法第112条]]（代理権消滅後の表見代理）
*[[民法第653条]]（委任の終了事由）
*[[不動産登記法第17条]]（代理権の不消滅）
*[[w:任意後見契約に関する法律|任意後見契約に関する法律]]第11条
*:（任意後見人の代理権の消滅の対抗要件） 
*:第11条 　任意後見人の代理権の消滅は、登記をしなければ、善意の第三者に対抗することができない。
*[[商法第506条]]（商行為の委任による代理権の消滅事由の特例）

==判例==
*[http://www.courts.go.jp/search/jhsp0030?hanreiid=57126&amp;hanreiKbn=02 試掘権移転登録手続等請求]（最高裁判決 昭和28年04月23日）[[戸籍法第89条]]，[[民事訴訟法第57条]]1項，[[民事訴訟法第85条]]
----
{{前後
|[[コンメンタール民法|民法]]
|[[第1編 総則 (コンメンタール民法)|第1編 総則]]&lt;br&gt;
[[第1編 総則 (コンメンタール民法)#5|第5章 法律行為]]&lt;br&gt;
[[第1編 総則 (コンメンタール民法)#5-3|第3節 代理]]
|[[民法第110条]]&lt;br&gt;（権限外の行為の表見代理）
|[[民法第112条]]&lt;br&gt;（代理権消滅後の表見代理等）
}}

{{stub}}
[[category:民法|111]]
[[category:民法 2017年改正|111]]</text>
      <sha1>lcd0czbiw6jqe4c5jpxi6m4ay53ybjf</sha1>
    </revision>
  </page>
  <page>
    <title>会社法第849条</title>
    <ns>0</ns>
    <id>7751</id>
    <revision>
      <id>205759</id>
      <parentid>201312</parentid>
      <timestamp>2022-07-24T06:19:52Z</timestamp>
      <contributor>
        <username>はいかぐら</username>
        <id>45848</id>
      </contributor>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="6455" xml:space="preserve">[[法学]]＞[[民事法]]＞[[商法]]＞[[会社法]]＞[[コンメンタール会社法]]＞[[第7編 雑則 (コンメンタール会社法)]]

==条文==
（訴訟参加）
;第849条
# 株主等又は株式会社等は、共同訴訟人として、又は当事者の一方を補助するため、責任追及等の訴え（適格旧株主にあっては[[会社法第847条の2|第847条の2]]第1項各号に掲げる行為の効力が生じた時までにその原因となった事実が生じた責任又は義務に係るものに限り、最終完全親会社等の株主にあっては特定責任追及の訴えに限る。）に係る訴訟に参加することができる。ただし、不当に訴訟手続を遅延させることとなるとき、又は裁判所に対し過大な事務負担を及ぼすこととなるときは、この限りでない。
# 次の各号に掲げる者は、株式会社等の株主でない場合であっても、当事者の一方を補助するため、当該各号に定める者が提起した責任追及等の訴えに係る訴訟に参加することができる。ただし、前項ただし書に規定するときは、この限りでない。
#: 一　株式交換等完全親会社（[[会社法第847条の2|第847条の2]]第1項各号に定める場合又は同条第3項第一号（同条第4項及び第5項において準用する場合を含む。以下この号において同じ。）若しくは第二号（同条第4項及び第5項において準用する場合を含む。以下この号において同じ。）に掲げる場合における株式交換等完全子会社の完全親会社（同条第1項各号に掲げる行為又は同条第3項第一号の株式交換若しくは株式移転若しくは同項第二号の合併の効力が生じた時においてその完全親会社があるものを除く。）であって、当該完全親会社の株式交換若しくは株式移転又は当該完全親会社が合併により消滅する会社となる合併によりその完全親会社となった株式会社がないものをいう。以下この条において同じ。）　適格旧株主
#: 二　最終完全親会社等　当該最終完全親会社等の株主
# 株式会社等、株式交換等完全親会社又は最終完全親会社等が、当該株式会社等、当該株式交換等完全親会社の株式交換等完全子会社又は当該最終完全親会社等の完全子会社等である株式会社の取締役（監査等委員及び監査委員を除く。）、執行役及び清算人並びにこれらの者であった者を補助するため、責任追及等の訴えに係る訴訟に参加するには、次の各号に掲げる株式会社の区分に応じ、当該各号に定める者の同意を得なければならない。
#: 一　監査役設置会社　監査役（監査役が2人以上ある場合にあっては、各監査役）
#: 二　監査等委員会設置会社　各監査等委員
#: 三　指名委員会等設置会社　各監査委員
# 株主等は、責任追及等の訴えを提起したときは、遅滞なく、当該株式会社等に対し、訴訟告知をしなければならない。
# 株式会社等は、責任追及等の訴えを提起したとき、又は前項の訴訟告知を受けたときは、遅滞なく、その旨を公告し、又は株主に通知しなければならない。
# 株式会社等に株式交換等完全親会社がある場合であって、前項の責任追及等の訴え又は訴訟告知が[[会社法第847条の2|第847条の2]]第1項各号に掲げる行為の効力が生じた時までにその原因となった事実が生じた責任又は義務に係るものであるときは、当該株式会社等は、前項の規定による公告又は通知のほか、当該株式交換等完全親会社に対し、遅滞なく、当該責任追及等の訴えを提起し、又は当該訴訟告知を受けた旨を通知しなければならない。
# 株式会社等に最終完全親会社等がある場合であって、第5項の責任追及等の訴え又は訴訟告知が特定責任に係るものであるときは、当該株式会社等は、同項の規定による公告又は通知のほか、当該最終完全親会社等に対し、遅滞なく、当該責任追及等の訴えを提起し、又は当該訴訟告知を受けた旨を通知しなければならない。
# 第6項の株式交換等完全親会社が株式交換等完全子会社の発行済株式の全部を有する場合における同項の規定及び前項の最終完全親会社等が株式会社の発行済株式の全部を有する場合における同項の規定の適用については、これらの規定中「のほか」とあるのは、「に代えて」とする。
# 公開会社でない株式会社等における第5項から第7項までの規定の適用については、第5項中「公告し、又は株主に通知し」とあるのは「株主に通知し」と、第6項及び第7項中「公告又は通知」とあるのは「通知」とする。
# 次の各号に掲げる場合には、当該各号に規定する株式会社は、遅滞なく、その旨を公告し、又は当該各号に定める者に通知しなければならない。
#: 一　株式交換等完全親会社が第6項の規定による通知を受けた場合　適格旧株主
#: 二　最終完全親会社等が第7項の規定による通知を受けた場合　当該最終完全親会社等の株主
# 前項各号に規定する株式会社が公開会社でない場合における同項の規定の適用については、同項中「公告し、又は当該各号に定める者に通知し」とあるのは、「当該各号に定める者に通知し」とする。

==解説==
責任追及等の訴えに訴訟参加に関する規定である。

==関連条文==

----
{{前後
|[[コンメンタール会社法|会社法]]
|[[第7編 雑則 (コンメンタール会社法)|第7編 雑則]]&lt;br&gt;
[[第7編 雑則 (コンメンタール会社法)#2|第2章 訴訟]]&lt;br&gt;
[[第7編 雑則 (コンメンタール会社法)#2-2|第2節 株式会社における責任追及等の訴え]]
|[[会社法第848条]]&lt;br&gt;（訴えの管轄）
|[[会社法第849条の2]]&lt;br&gt;（和解）
}}

{{stub}}
[[category:会社法|849]]</text>
      <sha1>s2vrfmj9dnb92qkotwz8u50fqvjrtt4</sha1>
    </revision>
  </page>
  <page>
    <title>学習方法/中学高校の学習全般</title>
    <ns>0</ns>
    <id>10174</id>
    <revision>
      <id>205776</id>
      <parentid>173453</parentid>
      <timestamp>2022-07-24T07:54:48Z</timestamp>
      <contributor>
        <username>Nermer314</username>
        <id>62933</id>
      </contributor>
      <minor />
      <comment>/* インターネットの活用 */</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="10204" xml:space="preserve">{{告知|議論}}
:議論中でも上書き編集する事は構いませんが、さらに上書きされる可能性もあります。
----
進路に応じて、適した勉強法は変わるだろうが、このページでは大学進学を将来的に志望する者で、主に、中学生・高校生に向けた学習法を述べる。
中学校・高校などの教科の学習など、それらに共通するであろう学習方法について述べる。

大学生向けの勉強法は、別ページを参照して下さい。

{{独自研究の可能性|PAGENAME={{PAGENAME}}|内容=中学高校の学習方法について}}
また、各教科・各科目の個別の勉強法については、市販の参考書を何冊か見れば、ふつうは、その参考書の前書きのページあたりに、その参考書をつかった勉強法などが書かれているだろうから、そのようなものを参考にしたほうが安全だろう。

== 基本的な学習法 ==
学習の中心は、学校で配布された検定教科書や資料集など、そして、それを利用した学校の授業である。受験参考書はわかりやすく端的に解説されていることが多いので、授業、教科書、資料集だけではよく理解できないと感じたときには参考書も読むとよい。大学受験を考えると、教科書と学校配布教材だけの学習範囲は入試対策としては不十分な部分もあるため&lt;ref name=&quot;t&quot;&gt;『高校の勉強のトリセツ』、GAKKEN&lt;/ref&gt;&lt;ref name=&quot;s&quot;&gt;船登惟希 『改訂版 高校一冊目の参考書』、KADOKAWA、2019年3月18日&lt;/ref&gt;、参考書を用いた学習にはそれを補う意味もある。

どのような学習のスタイルが合っているかには個人差も大きい。特定の指導方針に従うことを難なくそつなくこなせる生徒がいる一方で、逆に理解が難しくなり学習活動に困難を感じることが多くなる場合もあるかもしれない。基本的には学習に関しては教員をはじめとするまわりの大人たちのアドバイスを受けるのがよいが、それを活用するためにはその意味を自分なりに理解し咀嚼したうえで実践することも必要になるだろう。自分なりの理解に落とし込めないアドバイスも一旦は実践してみるのがよいが、実践してみてしっくりこなければやめてしまってもよい。

受験対策として、入試過去問を用いた演習などは当然に必要になるが、基礎をおろそかにしていきなり演習に取り組んでも得るものは少ない。学問に関してはまず対象の課題議論の基礎をよく理解して知ることが最も重要であること、そしてそれは思いのほか困難であるためまず優先して取り組むべきであることを意識しておくとよい。一方で、各種試験問題を分析することから様々な知見が得られることもあり、試験対策の学習もあながち無為なものとは言い切れない面があるだろう。

== 授業の受け方 ==
* 出席をする
特に義務教育ではなくなる高等学校において、授業に出席しなければ履修が認められず、単位が認められないため進級できない。もちろん出席するだけでよいわけではなく、出席したうえでその時間をどう過ごすかが問題ではあるが、まずは授業に出席しなければならない。

* ノートをとる
授業を受ける際には、ノートをとることも基本的な学習の一つである。ノートの取り方に関しても、これという一つの正解があるわけではなく、結局は毎日の授業の中でそれぞれの生徒が試行錯誤しながらいいノートの取り方を見出していくことになるだろう。ノートを上手にとり、情報量の多い見やすいノートを作ることができれば、あとから見直すときにも有用であるが、それだけが重要なわけではない。むしろ、授業を聞くときに話を聞きながら考えることは重要なことで、その思考の過程、その思考の結果も大きな勉強である。

== 塾など ==
塾は、教育的な環境と課題を用意し、その課題を塾生に課す場所である。塾側は商売として様々なそれらしいことを語るが、結局生徒側がそれぞれの考えを持ったうえで上手に利用する必要がある&lt;ref name=&quot;t&quot; /&gt;&lt;ref name=&quot;s&quot; /&gt;&lt;!--&lt;ref&gt;『高校の勉強のトリセツ』、GAKKEN&lt;/ref&gt;&lt;ref&gt;船登惟希 『改訂版 高校一冊目の参考書』、KADOKAWA、2019年3月18日&lt;/ref&gt;--&gt;。

== 参考書と問題集 ==
参考書を買う際は、まずは解説の多い入門書的な &quot;参考書&quot; を選んで買うのが良いだろう。入門用の &quot;参考書&quot; を選ぶ際には、まずは学校の予習復習用から受験対策まで広く対応した、初学者用の本を買うのが良いだろう。

大学受験での浪人生ならともかく、現役の高校生・中学生の場合は、未習科目や未習単元について、いきなり受験対策用の難度の高い参考書を買うのは、あまりお勧めしない。受験対策用の本は、すでに教科書や入門用の参考書や問題集を買った人が、さらに理解を深め、試験に備えるために読み解く本である。

経済的な理由や学習深度、あまり散漫な学習方法を取らないほうがいいという理由から、参考書は一冊持っていれば十分だとも考えられる。しかし、多読や速読が得意な生徒であれば、2冊、複数所持したり、読み比べて様々な検討、学習、分析をするのも、有効な学習法だと言える。

問題演習もやはり重要だろう。教科書にも、参考書でも、そして学校の授業でも問題演習をする機会はあるが、ある程度の量をこなすことは、試験対策にも、受験対策にも、そして学習理解にも実は有意義な事である。それぞれの学習深度に合わせた判断になるが、多くの場合問題集も学校で提供されるし、はじめは初歩の簡単な問題集から始めるのがよいが、市販の問題集も様々に販売されている。

== 質問の方法 ==
学習をしていて、教科書や(学校でもらった)副読本を調べても分からない点があるときは、教員に質問をしてみるのも良い。しかし質問というのは相手がいて成り立つものだし、ある種の社会的な技術なので、なんでもやみくもに質問してもいい結果は得られないかもしれない。質問の前に自分の中で問題点をはっきりさせておいて、聞き方も相手に伝わるように工夫するのがよいだろう。

たとえば「この問題が分からなくて、こういうことかな？、って考えたのですけど、あってるかどうか分かりません。教えてください。」とか「この説明のここの部分までは、こうだろう、と思うのですけど、この先の説明が分かりません」のように、疑問点を明確にした質問の方が、質問する側にとっても得られるものが大きい。

== テストの使い方 ==
=== 学校の定期テストの使いかた ===
中学校や高校の定期テストでは、普段からあまり勉強していない生徒が{{ruby|一夜漬|いちやづ}}けで何とかしようとする、ということはしばしば聞かれるが、あまり得策ではない。一夜漬けに限らず、そもそも睡眠時間を削る勉強法をとるべきではない&lt;ref&gt;船登惟希 『改訂版 高校一冊目の参考書』、KADOKAWA、2019年3月18日、69ページ&lt;/ref&gt;。勉強は量が少なくても日常的に習慣的に続けるのがよく、テスト前日は早く寝て、翌朝早く起きて勉強するようにしたほうがよい。

テストを受けた後，点数が高かったり低かったり、成績がどうなるかも気になるだろうが、それ以上にテスト後には苦手分野や重要だと思われる分野を確認して復習するのが重要である&lt;ref&gt;梁川由香『高校の勉強のトリセツ』、GAKKEN、2020年2月10日 （版の記載なし）第8刷 発行、114ページ にて、テスト後の復習を推奨している&lt;/ref&gt;。

=== 模試の使い方 ===
予備校などが、入試などを真似た模擬試験（もぎしけん、略して「模試」（もし））を有料で行っている。模擬試験では日本全国の受験者の中での順位統計なども発表されるので、進路を考える上では有用なデータが得られる。またそれだけでなく、模擬試験についても定期テストと同様に、自分の苦手分野や理解が十分でない単元を見つけて、模試の問題と解説を参考によく学習しなおしてみるとよい。

== インターネットの活用 ==
インターネットは身近なメディアだが、使い方は案外難しい。その大きな特徴として、情報の量は膨大だが、あてにならない情報、いい加減な情報の数も膨大だということが言える。その中で、正しい良質な情報に出会うためにはどうしたらよいか？それを一概に言うことはできないが、たとえば日本の官公庁のサイトは信頼度が高いし、読んでいると勉強になる面もある。

例えば国立国会図書館↓
:https://www.ndl.go.jp/

あるいは厚生労働省↓
:https://www.mhlw.go.jp/index.html

URL の最後尾 .go.jp は日本政府のドメイン名なので、URL を見ることでこのサイトが日本政府の政府機関だということが確認できる。

また、[[インターネットを使う]]も参考にしてみてください。


== 参考文献 ==

[[Category:学習方法|がくしゅうぜんぱん]]</text>
      <sha1>hth3a8yqtfzz9trdlod5beuh46oup4m</sha1>
    </revision>
  </page>
  <page>
    <title>高等学校日本史B</title>
    <ns>0</ns>
    <id>10189</id>
    <revision>
      <id>205737</id>
      <parentid>203057</parentid>
      <timestamp>2022-07-23T14:03:05Z</timestamp>
      <contributor>
        <username>椎楽</username>
        <id>32225</id>
      </contributor>
      <minor />
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="4449" xml:space="preserve">* [[日本史]] ＞ [[高等学校日本史]] ＞ [[高等学校日本史B]]
* [[高等学校の学習]] &gt; [[高等学校地理歴史|地理歴史]] &gt; [[高等学校日本史B|日本史B]]
----
日本の高等学校課程における「日本史B」の教科書。


== 原始・古代の日本 ==
=== 古代国家の形成 ===
* [[高等学校日本史B/日本文化のあけぼの]]（人類の発生、旧石器時代、縄文時代）
* [[高等学校日本史B/弥生時代]]（弥生時代）
* [[高等学校日本史B/古墳とヤマト王権]]

=== 律令国家の形成 ===
* [[高等学校日本史B/飛鳥の朝廷]]
* [[高等学校日本史B/律令国家への道]]（大化の改新 〜 大宝律令、租庸調など）
* [[高等学校日本史B/奈良時代]]
* [[高等学校日本史B/天平文化]]

=== 貴族政治と国風文化 ===
* [[高等学校日本史B/平安初期]]
* [[高等学校日本史B/藤原氏の台頭]]
* [[高等学校日本史B/平安時代の地方政治]]
* [[高等学校日本史B/国風文化]]

== 中世の日本 ==
=== 院政期 ===
* [[高等学校日本史B/院政とその展開]]
* [[高等学校日本史B/保元・平治の乱]]
* [[高等学校日本史B/院政期の文化]]

=== 武家政権の成立 ===
* [[高等学校日本史B/鎌倉幕府の成立]]
* [[高等学校日本史B/北条氏の台頭]]
* [[高等学校日本史B/武家社会]]
* [[高等学校日本史B/鎌倉時代の経済]]
* [[高等学校日本史B/元寇と鎌倉幕府の動揺]]
* [[高等学校日本史B/後醍醐天皇と建武の新政]]

=== 室町〜戦国時代 ===
* [[高等学校日本史B/室町幕府の成立と南北朝時代]] {{進捗|00%|2018-06-21}}
* [[高等学校日本史B/室町幕府の展開]]
* [[高等学校日本史B/室町幕府の衰退と下剋上の時代]]
* [[高等学校日本史B/戦国大名の台頭]]
* [[高等学校日本史B/室町文化と戦国時代の文化]]

== 近世の日本 ==
=== 戦国時代末～織豊政権 ===
* [[高等学校日本史B/ヨーロッパ人との交流]]
* [[高等学校日本史B/織田信長・豊臣秀吉]]
* [[高等学校日本史B/桃山文化]]

=== 幕藩体制の成立 ===
* [[高等学校日本史B/徳川幕府の成立]] {{進捗|00%|2018-06-06}}
* [[高等学校日本史B/寛永文化]]

=== 幕藩体制の展開 ===
* [[高等学校日本史B/幕藩体制の展開]]
* [[高等学校日本史B/江戸時代の経済の発展]]
* [[高等学校日本史B/元禄文化と学問の発展]]

=== 幕藩体制の動揺 ===
* [[高等学校日本史B/幕藩体制の動揺]]
* [[高等学校日本史B/幕藩体制の停滞と諸藩の改革]]
* [[高等学校日本史B/江戸中・後期の文化]] {{進捗|00%|2018-06-06}}

== 近代の日本 ==
=== 近代への転換 ===
* [[高等学校日本史B/開国]]
* [[高等学校日本史B/明治維新]]
* [[高等学校日本史B/明治の近代化の改革]]
* [[高等学校日本史B/明治初期の文化]]
* [[高等学校日本史B/明治初期の外交]]

=== 日本の軍事的覇権 ===
* [[高等学校日本史B/立憲体制の確立]]

* [[高等学校日本史B/日清・日露戦争]]

* [[高等学校日本史B/第一次世界大戦と日本]]

=== ブロック経済の成立と崩壊 ===
* [[高等学校日本史B/経済恐慌と中国侵略]]
* [[高等学校歴史総合/世界恐慌とブロック経済]]
* [[高等学校歴史総合/満州事変]]
* [[高等学校日本史B/第二次世界大戦と日本]]

== 現代の日本 ==
=== 占領期と独立 ===
* [[高等学校日本史B/占領と改革]]
* [[高等学校日本史B/冷戦の開始と講和]]

=== 平和と繁栄をめざして ===
* [[高等学校日本史B/安保闘争の時代]]
:* 参考: [[高等学校政治経済/政治/右翼と左翼、保守と革新]] (※ 用語解説。分かっていれば、読み飛ばしても良い。) {{進捗|50%|2016-04-05}}
* [[高等学校日本史B/高度経済成長の日本]]

=== 理想の挫折 ===
* [[高等学校日本史B/高度経済成長の終焉]]
* [[高等学校日本史B/冷戦後の日本]]

== テーマ史 ==
* [[高等学校日本史B/テーマ史別]]

== 資料集 ==
* [[高等学校日本史B/史料集|史料集]]

== 学習方法 ==
* [[学習方法/高校日本史]]

{{DEFAULTSORT:にほんしB}}
[[カテゴリ:高等学校教育]]
[[カテゴリ:社会科教育]]
[[カテゴリ:高等学校日本史|*]]</text>
      <sha1>bmphmxne16bv0xeqwk9xrmjq10kh23i</sha1>
    </revision>
  </page>
  <page>
    <title>高等学校日本史B/日本文化のあけぼの</title>
    <ns>0</ns>
    <id>16287</id>
    <revision>
      <id>205726</id>
      <parentid>201941</parentid>
      <timestamp>2022-07-23T13:53:23Z</timestamp>
      <contributor>
        <username>椎楽</username>
        <id>32225</id>
      </contributor>
      <comment>カテゴリ追加+古すぎる人類進化説明カット</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="8908" xml:space="preserve">== 人類の誕生 ==
人類は、およそ500万年あたり前に、アフリカで誕生したと、化石人骨などから考えられている。そのころの人類は'''猿人'''である。

今から1万年あたり前をさかいに、さかいの前を'''更新世'''（こうしんせい）といい、さかいの後を'''完新世'''（かんしんせい）という。

日本列島は更新世（こうしんせい）の当時、寒冷な'''氷期'''（ひょうき）と比較的温かい'''間氷期'''（かんひょうき、かんぴょうき）が交互に続いており、更新世はいわゆる'''氷河時代'''のことであり、また更新世の当時は日本がユーラシア大陸と陸続きであったため大型動物が多く日本列島にやってきていた。
更新世のこのとき、日本列島の北からは、'''マンモス'''や'''ヘラジカ'''が日本に来て、　南からは、'''オオツノジカ'''（大角鹿）や'''ナウマンゾウ'''（1948年、'''野尻湖'''（のじりこ、長野）で発見される）が日本に来ていることが確認されている。

このような更新世が、約250万年前から約1万年前まで続いた。

なお、約5〜1万年前のあいだに、人類は'''新人'''（しんじん、ホモ＝サピエンス）に進化している。約10万年前には旧人が発生していたと考えられている。

== 旧石器時代 ==
人類が石器を使い始めた時期は、今からおよそ250万年前のころ（更新世である）と考えられている。
石器に、打ち欠いてつくっただけの'''打製石器'''（だせいせっき）のみを使用していた旧石器時代（きゅうせっきじだい）が、石器時代の中でも最も古い。

かつて日本には旧石器時代が存在しないと考えられていたが、しかし1946年、群馬県にある'''岩宿遺跡'''（いわじゅくいせき）で、更新世に堆積した'''関東ローム層'''から打製石器を'''相沢忠洋'''（あいざわ ただひろ）が発見する。そして1949年に、学術調査が行われた。これらの調査により、日本にも旧石器時代があったことが証明され、日本史上の定説を覆すこととなった。

これを契機に、日本の各地で更新世の地層から石器が発見された。

ここでは名前と用途を紹介するが資料集などで実物の写真を確認していただきたい。

# '''打製石斧'''（せきふ）　切る、土を掘る。旧石器時代の古くからある。
# '''ナイフ形石器'''　切る、削る。旧石器時代の古くからある。
# '''尖頭器'''（せんとうき）　　　　槍の先端に付ける。旧石器時代の後半に現れた。
# '''細石器'''（さいせっき）　　木や骨の先端に嵌めこむ。旧石器時代の終わり頃に現れた。旧石器時代の石器では、もっとも新しい時代の石器。

狩猟に使える石器がこのように存在することから、当時の日本人は、狩猟を行って得た獣の肉を、食料にしていたと考えられている。

[[File:Fossil of Minatogawa Man.jpg|thumb|120px|left|港川人（港川1号）の化石（レプリカ）。国立科学博物館の展示。]]

人骨は3種類覚えとけば問題ない。　沖縄県の'''港川人'''（みなとがわじん）・'''山下町洞人'''（やましたちょうどうじん）　静岡県の'''浜北人'''（はまきたじん）である。これらの人骨はいずれも新人段階であり、3万年前までの人骨である。

港川人は人骨がよく残っており、アジア南部の人種であると考えられている。

{{clear}}

== 縄文時代 ==
=== 縄文時代の成立 ===
今からおよそ1万数千年前ごろの更新世末期から、地球の気候が温暖化して海面が上昇し、これにより日本列島が形成された。（約1万年前）

植物は、東日本では落葉広葉樹林が広がり、西日本では照葉樹林が広がった。この森林の変化にともない、ドングリ、クルミ、クリなどの木の実や、ヤマイモなどの根茎類（こんけいるい）が豊富になった。

=== 縄文時代の生活 ===
人類は　'''磨製石器'''（ませいせっき）、'''土器'''、'''弓矢'''　を手にし生活基板を創り上げていった。この時代の土器の模様には、縄を回転させて土器につけた模様が多く、そのため、この時代の土器のことを'''縄文土器'''（じょうもんどき）と言う。また、この時代を'''縄文時代'''という。

動物は、マンモスなどの大型動物はすでに絶滅しており、シカやイノシシやウサギなどの比較的小型で俊敏な動物が多かった。このような俊敏な動物を狩るのに、弓矢が適していた。牧畜は行われていない。また、本格的な農耕は行われていない。

また、土器は貯蔵（ちょぞう）の他にも、食物の煮炊き（にたき）にも使われていたようであり、木の実のアク抜きや、獣肉の煮沸などにも使われたようである。

[[ファイル:Arrowhead.jpg|thumb|160px|日本の石鏃（黒曜石製）]]
[[ファイル:Sekisui.jpg|thumb|石錘（せきすい）]]
:※ 磨製石器の名前と用途を紹介するが写真での確認を忘れないこと。
# '''石鏃'''（せきぞく）　　矢の先端部として使用。
# '''石匙'''（いしさじ）　　皮を剥ぐ際に使用。
# '''すり石・石皿'''（いしざら）　　木の実などの、かたい食物をつぶす。
# '''石錘'''（せきすい）　　網のおもりとして使用。
また、'''骨角器'''（こっかくき）といい動物の骨や角を銛や釣り針に使用していた。

縄文土器の特徴として　　'''縄目模様　　黒褐色'''（低温で焼いているため）　'''厚手でもろい'''　　が挙げられる。

木の実などによる定住して得られる食料が普及したためか、人々は'''竪穴住居'''（たてあな じゅうきょ）に住み、円を成して共同生活する環状集落を作った。また'''貝塚'''（かいづか）が発見されており、ハマグリやアサリなどの貝が捨てられている。このことから、漁労が発達していたことが、うかがえる。
:・ '''大森貝塚'''（おおもり かいづか、東京）　　　1877年に'''モース'''により発見された。
:・ '''加曾利貝塚'''（かそり かいづか、千葉）　　　日本最大の貝塚。
:・ 夏島貝塚（なつしま かいづか、神奈川）　　日本最古の貝塚の一つ。
:・ 津雲貝塚（つくも かいづか、岡山）　　人骨170体が発見された。

また交易も盛んであったことが分かっている。
:・ '''黒曜石'''　：黒曜石は、原産地が限られる。その黒曜石が、原産地から離れた各地から出土していることから、交易が行われていたことが分かる。場所は　'''和田峠'''（わだとうげ,長野）、白滝・十勝町（北海道）、箱根（神奈川）、神津島（こうづしま,東京）、姫島（ひめしま,大分）、阿蘇山（熊本）。
:・ '''サヌカイト'''（讃岐石）　：産出場所は　　'''二上山'''（ふたがみやま、にじょうざん、奈良）
:・ '''ひすい'''（硬玉、「こうぎょく」）　：産出場所は新潟県の'''姫川'''（ひめかわ）。
[[File:Periodo jomon, dogu, 2000-1000 a.c. 3.JPG|thumb|right|200px|土偶 青森県 亀ヶ岡遺跡の出土（通称：遮光器土偶）]]

* アニミズム
自然現象に霊威を認める呪術（じゅじゅつ）的な思想（いわゆる'''アニミズム'''）があったと考えられている。女性をかたどった'''土偶'''（どぐう）や、男性の生殖器（いわゆる男根）をかたどった'''石棒'''（せきぼう）がある。'''抜歯'''（ばっし）が、成人式や婚姻などのときに通過儀礼として歯を抜く風習だった。死者を埋葬するときに死体の手足をかがめる'''屈葬'''（くっそう）があった。また'''環状列石'''（かんじょうれっせき、秋田県の大湯、「おおゆ」）もアニミズムの一つだと考えられている。

* 遺跡
縄文時代で有名な遺跡は、青森県にある'''三内丸山遺跡'''（さんないまるやまいせき）である。

* その他
身分の差は、あまり無かったようである。寿命は短く、30歳くらいまで、だったようである。
[[category:高等学校日本史|にほんふんかのあけほの]]</text>
      <sha1>71gl12cv7yp2drszgw6icye4l4yuobg</sha1>
    </revision>
    <revision>
      <id>205727</id>
      <parentid>205726</parentid>
      <timestamp>2022-07-23T13:54:28Z</timestamp>
      <contributor>
        <username>椎楽</username>
        <id>32225</id>
      </contributor>
      <minor />
      <comment>テンプレ追加</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="8916" xml:space="preserve">{{Nav}}
== 人類の誕生 ==
人類は、およそ500万年あたり前に、アフリカで誕生したと、化石人骨などから考えられている。そのころの人類は'''猿人'''である。

今から1万年あたり前をさかいに、さかいの前を'''更新世'''（こうしんせい）といい、さかいの後を'''完新世'''（かんしんせい）という。

日本列島は更新世（こうしんせい）の当時、寒冷な'''氷期'''（ひょうき）と比較的温かい'''間氷期'''（かんひょうき、かんぴょうき）が交互に続いており、更新世はいわゆる'''氷河時代'''のことであり、また更新世の当時は日本がユーラシア大陸と陸続きであったため大型動物が多く日本列島にやってきていた。
更新世のこのとき、日本列島の北からは、'''マンモス'''や'''ヘラジカ'''が日本に来て、　南からは、'''オオツノジカ'''（大角鹿）や'''ナウマンゾウ'''（1948年、'''野尻湖'''（のじりこ、長野）で発見される）が日本に来ていることが確認されている。

このような更新世が、約250万年前から約1万年前まで続いた。

なお、約5〜1万年前のあいだに、人類は'''新人'''（しんじん、ホモ＝サピエンス）に進化している。約10万年前には旧人が発生していたと考えられている。

== 旧石器時代 ==
人類が石器を使い始めた時期は、今からおよそ250万年前のころ（更新世である）と考えられている。
石器に、打ち欠いてつくっただけの'''打製石器'''（だせいせっき）のみを使用していた旧石器時代（きゅうせっきじだい）が、石器時代の中でも最も古い。

かつて日本には旧石器時代が存在しないと考えられていたが、しかし1946年、群馬県にある'''岩宿遺跡'''（いわじゅくいせき）で、更新世に堆積した'''関東ローム層'''から打製石器を'''相沢忠洋'''（あいざわ ただひろ）が発見する。そして1949年に、学術調査が行われた。これらの調査により、日本にも旧石器時代があったことが証明され、日本史上の定説を覆すこととなった。

これを契機に、日本の各地で更新世の地層から石器が発見された。

ここでは名前と用途を紹介するが資料集などで実物の写真を確認していただきたい。

# '''打製石斧'''（せきふ）　切る、土を掘る。旧石器時代の古くからある。
# '''ナイフ形石器'''　切る、削る。旧石器時代の古くからある。
# '''尖頭器'''（せんとうき）　　　　槍の先端に付ける。旧石器時代の後半に現れた。
# '''細石器'''（さいせっき）　　木や骨の先端に嵌めこむ。旧石器時代の終わり頃に現れた。旧石器時代の石器では、もっとも新しい時代の石器。

狩猟に使える石器がこのように存在することから、当時の日本人は、狩猟を行って得た獣の肉を、食料にしていたと考えられている。

[[File:Fossil of Minatogawa Man.jpg|thumb|120px|left|港川人（港川1号）の化石（レプリカ）。国立科学博物館の展示。]]

人骨は3種類覚えとけば問題ない。　沖縄県の'''港川人'''（みなとがわじん）・'''山下町洞人'''（やましたちょうどうじん）　静岡県の'''浜北人'''（はまきたじん）である。これらの人骨はいずれも新人段階であり、3万年前までの人骨である。

港川人は人骨がよく残っており、アジア南部の人種であると考えられている。

{{clear}}

== 縄文時代 ==
=== 縄文時代の成立 ===
今からおよそ1万数千年前ごろの更新世末期から、地球の気候が温暖化して海面が上昇し、これにより日本列島が形成された。（約1万年前）

植物は、東日本では落葉広葉樹林が広がり、西日本では照葉樹林が広がった。この森林の変化にともない、ドングリ、クルミ、クリなどの木の実や、ヤマイモなどの根茎類（こんけいるい）が豊富になった。

=== 縄文時代の生活 ===
人類は　'''磨製石器'''（ませいせっき）、'''土器'''、'''弓矢'''　を手にし生活基板を創り上げていった。この時代の土器の模様には、縄を回転させて土器につけた模様が多く、そのため、この時代の土器のことを'''縄文土器'''（じょうもんどき）と言う。また、この時代を'''縄文時代'''という。

動物は、マンモスなどの大型動物はすでに絶滅しており、シカやイノシシやウサギなどの比較的小型で俊敏な動物が多かった。このような俊敏な動物を狩るのに、弓矢が適していた。牧畜は行われていない。また、本格的な農耕は行われていない。

また、土器は貯蔵（ちょぞう）の他にも、食物の煮炊き（にたき）にも使われていたようであり、木の実のアク抜きや、獣肉の煮沸などにも使われたようである。

[[ファイル:Arrowhead.jpg|thumb|160px|日本の石鏃（黒曜石製）]]
[[ファイル:Sekisui.jpg|thumb|石錘（せきすい）]]
:※ 磨製石器の名前と用途を紹介するが写真での確認を忘れないこと。
# '''石鏃'''（せきぞく）　　矢の先端部として使用。
# '''石匙'''（いしさじ）　　皮を剥ぐ際に使用。
# '''すり石・石皿'''（いしざら）　　木の実などの、かたい食物をつぶす。
# '''石錘'''（せきすい）　　網のおもりとして使用。
また、'''骨角器'''（こっかくき）といい動物の骨や角を銛や釣り針に使用していた。

縄文土器の特徴として　　'''縄目模様　　黒褐色'''（低温で焼いているため）　'''厚手でもろい'''　　が挙げられる。

木の実などによる定住して得られる食料が普及したためか、人々は'''竪穴住居'''（たてあな じゅうきょ）に住み、円を成して共同生活する環状集落を作った。また'''貝塚'''（かいづか）が発見されており、ハマグリやアサリなどの貝が捨てられている。このことから、漁労が発達していたことが、うかがえる。
:・ '''大森貝塚'''（おおもり かいづか、東京）　　　1877年に'''モース'''により発見された。
:・ '''加曾利貝塚'''（かそり かいづか、千葉）　　　日本最大の貝塚。
:・ 夏島貝塚（なつしま かいづか、神奈川）　　日本最古の貝塚の一つ。
:・ 津雲貝塚（つくも かいづか、岡山）　　人骨170体が発見された。

また交易も盛んであったことが分かっている。
:・ '''黒曜石'''　：黒曜石は、原産地が限られる。その黒曜石が、原産地から離れた各地から出土していることから、交易が行われていたことが分かる。場所は　'''和田峠'''（わだとうげ,長野）、白滝・十勝町（北海道）、箱根（神奈川）、神津島（こうづしま,東京）、姫島（ひめしま,大分）、阿蘇山（熊本）。
:・ '''サヌカイト'''（讃岐石）　：産出場所は　　'''二上山'''（ふたがみやま、にじょうざん、奈良）
:・ '''ひすい'''（硬玉、「こうぎょく」）　：産出場所は新潟県の'''姫川'''（ひめかわ）。
[[File:Periodo jomon, dogu, 2000-1000 a.c. 3.JPG|thumb|right|200px|土偶 青森県 亀ヶ岡遺跡の出土（通称：遮光器土偶）]]

* アニミズム
自然現象に霊威を認める呪術（じゅじゅつ）的な思想（いわゆる'''アニミズム'''）があったと考えられている。女性をかたどった'''土偶'''（どぐう）や、男性の生殖器（いわゆる男根）をかたどった'''石棒'''（せきぼう）がある。'''抜歯'''（ばっし）が、成人式や婚姻などのときに通過儀礼として歯を抜く風習だった。死者を埋葬するときに死体の手足をかがめる'''屈葬'''（くっそう）があった。また'''環状列石'''（かんじょうれっせき、秋田県の大湯、「おおゆ」）もアニミズムの一つだと考えられている。

* 遺跡
縄文時代で有名な遺跡は、青森県にある'''三内丸山遺跡'''（さんないまるやまいせき）である。

* その他
身分の差は、あまり無かったようである。寿命は短く、30歳くらいまで、だったようである。
[[category:高等学校日本史|にほんふんかのあけほの]]</text>
      <sha1>7xai9hnfpo16t42e5q4tc77yo59br5x</sha1>
    </revision>
  </page>
  <page>
    <title>高等学校日本史B/弥生時代</title>
    <ns>0</ns>
    <id>16289</id>
    <revision>
      <id>205728</id>
      <parentid>186634</parentid>
      <timestamp>2022-07-23T13:55:23Z</timestamp>
      <contributor>
        <username>椎楽</username>
        <id>32225</id>
      </contributor>
      <minor />
      <comment>カテゴリ追加</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="18658" xml:space="preserve">{{Nav}}
==弥生時代==

弥生時代の特徴としては　　
: 金属器　　
: '''弥生土器'''
: 農耕、水稲耕作（すいとうこうさく）
である。
このような弥生文化が、紀元前4世紀ごろから起こった。

[[File:Periodo yayoi, dotaku (bronzo a forma di campana), II-I sec a.C..JPG|thumb|絵のある銅鐸（どうたく）。香川県出土（東京国立博物館蔵、国宝）&lt;br /&gt;
左下に、うす と きね を用いた作業の絵がある。右下は高床倉庫の絵。右上は弓矢で動物を射る絵。]]
金属器とは、青銅器（せいどうき）と鉄（てつ）のことで、日本の場合は同時に伝来されたとしている。青銅とは、銅と錫（すず）との合金。また機織の技術も伝えられる。
'''銅鐸'''（どうたく）、銅剣（どうけん）、銅矛（どうほこ）などが発見されている。
発見された銅鐸に刻まれた絵に、臼（うす）や杵（きね）を用いた農作業らしき絵がある。このことからも、弥生時代に稲作が行われていることが分かる。この銅鐸の絵には、他にも、高床倉庫の絵、動物を弓矢で射っている絵がある。

稲の穂を切り取るための'''石包丁'''（いしぼうちょう）など、石器も用いられている。

これらの文明が海外から伝達したが、伝達元として複数説あり、朝鮮半島から伝わった説と、中国南部から直接伝わった説がある。有力な説は、朝鮮半島から伝わった説のほうである。石包丁など石器の形が、朝鮮半島と九州北部とで類似することが、朝鮮半島由来説の根拠である。

一方、沖縄地方では漁労を中心とした'''貝塚文化'''が、北海道地方では'''縄文文化'''を継続した続縄文文化が作られていた。続縄文文化は次第に擦文文化・オホーツク文化となる。

水稲耕作が盛んになり数々の遺跡がある
# 板付遺跡（福岡）　　　弥生初期の水田跡
# 菜畑遺跡（佐賀）　　　最古の水田跡
# 砂沢遺跡（青森）　　　東日本最古の水田跡
# 垂柳遺跡（青森）　　　本州最北端の水田跡


農耕は初期と後期に別れ方法が全く異なるので注意しておきたい。初期の時代の農耕は、湿田（しつでん）に直接種をまく直播という方法をとっていた。弥生時代の後期には'''乾田'''（かんでん）が開発された。
また、収穫時には石包丁を使い穂の部分だけとる穂首刈りを行った。遺跡は、登呂遺跡（静岡）や唐古鍵遺跡（奈良）が有名。後期に場合は灌漑を利用していた。百間川遺跡（岡山）が有名。

弥生時代にはブタの飼育が行われていたらしいことが、近年になって生まれた。かつては、イヌしか飼育されていないと考えられていた。

当時使われていた木製農具。
# 木鋤・木鍬　　　耕作に使用（漢字に注意）
# 大足　　　　　　肥料を混ぜる
# 田舟　　　　　　収穫用の移動手段
# 竪杵、木臼　　　脱穀
# 田下駄　　　　　ぬかるみ防止

石斧（せきふ）も、樹木の伐採用に用いられた（磨製石斧）。

農産物の貯蔵は'''高床倉庫'''に保管された。

弥生土器の特徴としては　
:① 薄手で硬い　　
:② 赤褐色（高温で焼く）　　
:③ 無紋　
である。

また種類がいくつかあるので覚える。漢字が難しいが書けるように。
# &lt;big&gt;&lt;big&gt;壺&lt;/big&gt;&lt;/big&gt;（つぼ）　　貯蔵用
# &lt;big&gt;&lt;big&gt;甕&lt;/big&gt;&lt;/big&gt;（かめ）　　煮炊き用
# &lt;big&gt;&lt;big&gt;高杯&lt;/big&gt;&lt;/big&gt;（たかつき）　盛り付け用
# &lt;big&gt;&lt;big&gt;甑&lt;/big&gt;&lt;/big&gt;（こしき）　　　蒸し器
これらは東京の本郷（ほんごう）弥生町の向ヶ丘（むこうがおか）貝塚で発見された。
弥生土器は、かつては「弥生式土器」と呼ばれていたが、現在の日本の学校教育や歴史学などでは、弥生土器と呼ぶのが通例になっている。

青銅器は　
:銅鐸（近畿地方）　
:平形銅剣（瀬戸内）　
:銅矛・銅戈（九州）
を覚える。これらは祭器として利用されてきた。
遺跡は大量の銅剣や矛が出てきた荒神谷遺跡（島根）や一箇所での最大量の銅鐸が出土した加茂岩倉遺跡（島根）が有名である。


また灌漑利用などで争いが絶えず、高地性集落と呼ばれる山、丘の頂上に暮らしたり（紫雲出山遺跡（香川）など）や
集落の周りに濠を作った環濠集落（かんごうしゅうらく）と呼ばれるものを創り上げた。　
:① '''吉野ケ里遺跡'''（佐賀）　
:② 唐古鍵遺跡（奈良）　
:③ 大塚遺跡（横浜）　
:④ 池上曽根遺跡（大阪）
が有名。


また地域ごとに格差が生まれた。これは墓を見れば一目瞭然であった。
* 土壙墓　　　　　　　　穴の中に遺体を埋葬
* 箱式石棺墓　　　　　　石棺をつくり複数の遺体を埋葬　　
* 甕棺墓　　　　　　　　２つの土器の中にいれ埋葬
* 支石墓　　　　　　　　甕棺の上に支石を立てて埋葬
* 方形周溝墓　　　　　　近畿に分布。溝を形成して埋葬　宇津木遺跡（東京）が有名
* 墳丘墓　　　　　　　　瀬戸内に分布。土盛した大規模な墓　四隅突出形墳丘墓や楯築墳丘墓（岡山）が有名

縄文時代のころは死者の多くに屈葬を行っていたが、弥生時代になり'''伸展葬'''（しんてんそう）を行うことが多くなった。

== 中国史書からみた日本 ==
=== 『漢書』地理志 ===
* 
&lt;div style=&quot;border:1px solid #000000;&quot;&gt;
　『漢書』地理志
:夫れ（それ）楽浪（らくろう）海中（かいちゅう）に 倭人（わじん）有り。 分れて（わかれて）百余国（ひゃくよこく）と 為る（なる）。 歳時（さいじ）を 以て（もって）来り（きたり）献見す（けんけんす）と云ふ（いう）。

::（原漢文）
&lt;/div&gt;


これは『'''漢書'''』'''地理志'''（かんじょ、ちりし）（著者:班固）の抜粋を、漢文から日本語に書き下した文である。（原書は漢文）

つまり、
: 日本は「'''倭'''」（わ）と呼ばれていた。
: 倭国（わこく）は'''100'''国くらいの小国に分裂していた。　
: 朝鮮半島の'''楽浪郡'''（らくろうぐん）に、倭国のリーダーが使者を（定期的に？）派遣した。　
ということである。

=== 『後漢書』東夷伝 ===
[[File:King of Na gold seal.jpg|thumb|金印（きんいん）。「漢委奴国王」と刻まれている。「漢の委の奴の国王」（かんのわのなのこくおう）と読まれる。綬（じゅ、※ 組みひも）は出土していない。1辺は2.3cm、重さは109g。材質は金。福岡県の志賀島（しかのしま）で1784年（江戸時代）に出土。　（国宝。福岡市博物館蔵。）]]
[[File:King of Na gold seal imprint 1935.jpg|thumb|金印の印文。「漢委奴国王」と刻まれている。]]

* 

&lt;div style=&quot;border:1px solid #000000;&quot;&gt;
　『'''後漢書'''』'''東夷伝'''（ごかんじょ、とういでん）
:建武中元（けんむ ちゅうげん）二年、倭（わ）の奴国（なこく）、貢を奉じて朝賀（ちょ8が）す（＝奉貢朝賀す）。使人（しじん）自ら（みずから）大夫（たいふ）と称す。倭国（わこく）の極南界（きょくなんかい）なり。光武、賜ふ（たまうに）に 印綬（いんじゅ）を以ってす。安帝（あんてい）の永初（えいしょ）元年、倭国王帥升（すいしょう）等（ら）、生口（せいこう）百六十人を献じ、請見（せいけん）を願ふ。桓霊（かんれい）の間、倭国大いに乱れ、更（こもごも）相攻伐し（あいこうばつし）歴年（れきねん）主なし。

::（原漢文）
&lt;/div&gt;

これは『'''後漢書'''』'''東夷伝'''（ごかんじょ、とういでん）の抜粋である（著者:范曄、原書は漢文）。

:・ 建武中元二年 - 紀元（後）57年。
:・ 印綬 （いんじゅ）- 印は「漢倭奴国王」の金印のこと。綬は組みひも。
:・ 永初（えいしょ）元年 - 107年。
:・ 桓霊（かんれい）の間 - 後漢の桓帝・霊帝のころ。すなわち147〜189年の間。

内容は・・・
# 奴国王（なこくおう）が光武帝（こうぶてい）に使者を派遣。
# 使者は「大夫」と自称。
# 光武帝が印綬（いんじゅ）を与える（福岡県志賀島（しかのしま）で'''金印'''（きんいん）が発見されている。これには「漢委奴国王」と刻まれている。　
# 倭国王帥升（すいしょう）が生口（せいこう）を160人献上した。生口は奴隷。　
# 後漢の桓帝・霊帝のころ（すなわち147〜189年の間）、倭国は大いに乱れて（小国が多数、分立していた？）、統一する王がいなかった。
という話である。


::（※ 範囲外: ）なお、東夷伝の「夷」（い）の意味は、外国人とか未開人・野蛮人とか、そういう意味。

== 邪馬台国 ==
中国大陸では後漢が220年に滅び、220年ごろには'''魏'''（ぎ）・'''蜀'''（しょく）・'''呉'''（ご）の３カ国が並び立つ'''三国時代'''（さんごく じだい）になっていた。

中国の歴史書『'''三国志'''』（さんごくし）のうちの、魏についての歴史書の『&lt;span style=&quot;font-size: large;&quot;&gt;魏志&lt;/span&gt;』（ぎし）にある倭人についての記述（&lt;span style=&quot;font-size: large;&quot;&gt;倭人伝&lt;/span&gt;（わじんでん））によると、３世紀の始めごろの日本では、小国どうしの争いが多かったが、'''30'''か国ほどの小国が小国どうしの共同の女王として、&lt;span style=&quot;font-size: large;&quot;&gt;邪馬台国&lt;/span&gt;（やまたいこく）の&lt;span style=&quot;font-size: large;&quot;&gt;卑弥呼&lt;/span&gt;（ひみこ）という女王を立てて連合し、日本の戦乱がおさまったという。卑弥呼は、30か国ほどの国をしたがえたという。

邪馬台国の卑弥呼は、239年に魏に使者をおくり、魏の皇帝から、「&lt;span style=&quot;font-size: large;&quot;&gt;親魏倭王&lt;/span&gt;」（しんぎわおう）の称号をもらい、また金印と、&lt;span style=&quot;font-size: large;&quot;&gt;銅鏡&lt;/span&gt;100枚をもらったことが、倭人伝に記されている。

卑弥呼は晩年、'''狗奴国'''（くなこく）と戦ったとあるが、その直後のころの247年に卑弥呼は亡くなった。人々は、卑弥呼のための大きな墓をつくった。そののち男の王が立ったが、国内が乱れたため、卑弥呼の同族である13歳の'''壱与'''（いよ）が女王になって戦乱が収まった。壱与は、魏にかわった晋に対して使者を266年に送った。魏志倭人伝によると、晋の都の洛陽に、倭の女王・壱与からの使者が来た、とうふうなことが書かれてある。

この壱与からの使者の記述のあと、しばらく中国の文献には倭についての記述は登場しなくなり、から266年から150年間ほどの倭についての詳細は不明である。

邪馬台国の位置が、どこにあったのかは、現在でも不明である。学説では、&lt;span style=&quot;font-size: large;&quot;&gt;近畿&lt;/span&gt;地方の大和（やまと）にもとめる説と&lt;span style=&quot;font-size: large;&quot;&gt;九州&lt;/span&gt;説が、有力な説である。

近畿地方にもとめる説の場合、のちのヤマト王権の母体が邪馬台国だったというような可能性が高く、九州から近畿までの範囲をふくむ連合政権があったことになる。いっぽう、九州説を取った場合、邪馬台国は比較的小規模な地方政権の連合だということになる。

九州説を取るか、近畿説を取るかで、邪馬台国とヤマト王権についての考え方が、大きく異なる。

この時代の日本には、階級が奴隷から王まで、あったことが、倭人伝の記述から分かっている。

== 魏志倭人伝 ==
魏志倭人伝には、つぎのようなことが書かれている。（一部省略）


{| style=&quot;width:100%&quot;
|valign=top style=&quot;width:60%;text-indent:1em;font-size:1.1em&quot;|
&lt;div style=&quot;border:1px solid #000000;&quot;&gt;
　'''『魏志』倭人伝'''（抜粋）
:{{Ruby|倭人|わじん}}は{{Ruby|帯方|たいほう}}の{{Ruby|東南|とうなん}}{{Ruby|大海|たいかい}}の中にあり、{{Ruby|山島|さんとう}}に{{Ruby|依|よ}}りて{{Ruby|国邑|こくゆう}}を{{Ruby|為|な}}す。{{Ruby|旧|もと}}百余国。漢の時、{{Ruby|朝見|ちょうけん}}する者あり。今、{{Ruby|使訳|しやく}}通ずる所三十国。{{Ruby|群|ぐん}}より{{Ruby|倭|わ}}に{{Ruby|至|いた|る}}には、海岸に{{Ruby|循|したが}}いて{{Ruby|水行|すいこう}}し、・・・（中略）・・・{{Ruby|邪馬台国|やまたいこく}}に至る。女王の都する所なり。男子は大小と無く、{{Ruby|皆|みな}}{{Ruby|黥面|げいめん}}{{Ruby|文身|ぶんしん}}す。・・・{{Ruby|租賦|そふ}}を収むに{{Ruby|邸閣|ていかく}}{{Ruby|有|あ}}り。国々に{{Ruby|市|いち}}{{Ruby|有|あ}}り。有無を交易し、大倭をして之を監せしむ。女王国より以北には、特に一大卒を置き、諸国を検察せしむ。諸国之を{{Ruby|畏憚|いたん}}す。・・・下戸、大人と道路に{{Ruby|相逢|あいあ}}へば、{{Ruby|逡巡|しゅんじゅん}}して草に入り、辞を伝へ事を説くには、{{Ruby|或|あるい}}は{{Ruby|蹲|うずくま}}り或は{{Ruby|跪|ひざまず}}き、両手は地に{{Ruby|拠|よ}}り之が{{Ruby|恭敬|きょうけい}}を為す。・・・
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;

:{{Ruby|其|そ}}の国、{{Ruby|本|もと}}{{Ruby|亦|また}}男子を以て王と為す。{{Ruby|住|とど}}まること七、八中年。'''倭国乱れ、{{Ruby|相|あい}}{{Ruby|攻伐|こうばつ}}して年を{{Ruby|歴|へ}}たり。{{Ruby|乃|すなわ}}ち共に一女子を立てて王と為す。名を{{Ruby|卑弥呼|ひみこ}}と{{Ruby|曰|い}}ふ。{{Ruby|鬼道|きどう}}を事とし、能く衆を{{Ruby|惑|まど}}はす。'''{{Ruby|年已|すで}}に長大なるも、{{Ruby|夫婿|ふせい}}無し。男弟有り、{{Ruby|佐|たす}}けて国を治む。・・・'''{{Ruby|景初|けいしょ}}二年六月、倭の女王、大夫{{Ruby|難升米|なしめ}}{{Ruby|等|ら}}を{{Ruby|遣|つかわ}}し群に{{Ruby|詣|いた}}り'''、天子に詣りて{{Ruby|朝献|ちょうけん}}せんことを求む。・・・その年十二月、{{Ruby|詔書|しょうしょ}}して倭の女王に報じて曰く、「・・・今{{Ruby|汝|なんじ}}を以て'''{{Ruby|親魏倭王|しんぎわおう}}と為し、金印紫綬を{{Ruby|仮|ゆる}}し'''、{{Ruby|装封|そうふう}}して{{Ruby|帯方|たいほう}}の{{Ruby|太守|たいしゅ}}に付し仮授せしむ。・・・」と。・・・''卑弥呼以て死す。大いに{{Ruby|冢|つか}}を作る。''径百余歩、{{Ruby|徇葬|じゅんそう}}する者、{{Ruby|奴婢|ぬひ}}百余人。更に男王を立てしも、国中服せず、{{Ruby|更々|こもごも}}{{Ruby|相誅殺|ちゅうさつ}}し、当時千余人を殺す。{{Ruby|復|ま}}た卑弥呼の{{Ruby|宗女|そうじょ}}{{Ruby|壱与|いよ}}の年十三なるを立てて王と為す。国中{{Ruby|遂|つい}}に定まる。

::（原漢文。『魏書』東夷伝 倭人条）
&lt;/div&gt;

|valign=top style=&quot;width:5%;text-indent:1em&quot;|
|valign=top style=&quot;width:35%;text-indent:1em&quot;|


倭人の国は、多くの国に分かれている。使者が調べたところ、今のところ、30あまりの国である。

【風習について】

男たちは、いれずみをしている。服は、幅の広い布をまとっており、ほとんど縫われていない。女は髪を後ろで結い、服は布の中央に穴をあけ、頭を通して着ている。

稲と紵麻（からむし）を植えている。桑（くわ）と蚕（かいこ）を育てており、糸を紡いで糸を作っている。土地は温暖であり、冬も夏も野菜を食べ、はだしで暮らしている。

下戸（げこ、民衆）が大人（たいじん、権力者）と出会うと、下戸は草むらに後ずさりして、道をゆずる。また下戸が大人に言葉を伝えたりするときは、ひざまずき、両手を地面につける。

【卑弥呼について】

倭国は、もともと男の王が治めていたが、戦乱が長く続いたので、諸国が共同して一人の女子を王にした。その女王の名を卑弥呼という。卑弥呼は、鬼道（「きどう」）で政治を行っている。卑弥呼は成人しているが、夫はおらず、弟が政治を助けている。王位についてからの卑弥呼を見た者は少なく、1000人の召使いをやとっており、宮殿の奥にこもる。卑弥呼の宮殿には、物見やぐら や柵が儲けられており、厳重に守られており、番人が武器を持って守衛している。

卑弥呼が死んだとき、直径100歩あまりの大きな墓がつくられ、奴隷100人がともに葬られた。

（※ 『魏志』倭人伝より抜粋して要約。）

|}

:朝見（ちょうけん） - 朝貢し謁見する。
:使訳（しやく） - 使節。
:鬼道（きどう） - 呪術。
:夫婿（ふせい） - 夫。
:景初（けいしょ）二年 - 景初3年（239）の誤り。
:冢（つか） - 墳丘。
:徇葬（じゅんそう） - 殉死（じゅんし）。
:宗女（そうじょ） - 一族の女。
:壱与（いよ） - 台与（とよ）の誤りとも言われている。

魏志倭人伝は、正式名は『三国志』の『魏書』（ぎしょ）の東夷伝の倭人条。『三国志』は三世紀に普（しん）の陳寿（ちんじゅ）によって編纂（へんさん）された。
[[category:高等学校日本史|やよいしたい]]</text>
      <sha1>st0lg406pt88wmug18sbml3t6llo7wk</sha1>
    </revision>
  </page>
  <page>
    <title>利用者・トーク:Honooo</title>
    <ns>3</ns>
    <id>18705</id>
    <revision>
      <id>205760</id>
      <parentid>198257</parentid>
      <timestamp>2022-07-24T06:23:13Z</timestamp>
      <contributor>
        <ip>163.43.134.100</ip>
      </contributor>
      <comment>/* ちょっとそれは... */ 新しい節</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="19968" xml:space="preserve">== ウィキブックスにようこそ！ ==
こんにちは、Honoooさん、はじめまして！ ウィキブックスの参加者の一人、[[利用者:Vigorous action|Vigorous action]] （[[利用者・トーク:Vigorous action|&lt;small&gt;Ｔａｌｋ&lt;/small&gt;]]&lt;small&gt;/&lt;/small&gt;[[特別:Contributions/Vigorous action|&lt;small&gt;History&lt;/small&gt;]]）と申します。ウィキブックスへようこそ！

* お隣の[[利用者:Honooo|利用者ページ]]は、ご自身の自己紹介の他、作業用のスペースなどとして利用することができます。
* 執筆の際には[[Wikibooks:中立的な観点|中立的な観点]]および[[Wikibooks:著作権|著作権]]にご留意ください。
* 何か疑問点がありましたら[[Wikibooks:談話室]]で質問することができます。また、教科書の内容に関するご質問がありましたら[[Wikibooks:ヘルプデスク|ヘルプデスク]]へお越しください。
あなたが実り多き活動をされることを楽しみにしております。

Welcome to Japanese Wikibooks. Thank you for your contributions! If you don't prefer to use Japanese, and when looking for further information, feel free to visit [[Wikibooks:談話室]]. Enjoy!

なお、このメッセージは主に利用者‐会話ページに何も記入されていない方に投稿しております。Honoooさんが、すでに活動を開始されてから期間が経っていらっしゃるのでしたら、ご存知のことばかりをご案内したかもしれません。不明をお詫び申し上げます。--[[利用者:Vigorous action|Vigorous action]] （[[利用者・トーク:Vigorous action|&lt;small&gt;Ｔａｌｋ&lt;/small&gt;]]&lt;small&gt;/&lt;/small&gt;[[特別:Contributions/Vigorous action|&lt;small&gt;History&lt;/small&gt;]]） 2014年1月4日 (土) 22:46 (UTC)
:こんばんは Vigorousさん。コメントをいただいてからもう五年もたってしまいましたが、いまさらながら返信いたします(^^)。大体私は昔のパソコン通信時代から、コメントやメールに対する返信、その時期やタイミング、内容、するかしないかで、不手際が多いようで、よく顰蹙を浴びていました…。結局未だにうまく出来ていないことが多いんですよね(^^;;;)。最近はウィキバーシティで少しだけ、書いています。結局ここが自由にかけて、一番いいかなーって感じですね。内容的にはおそらく、独自研究に近いものだと思いますが、特に消されることもないようなので、かろうじて許容されているようです。それではそろそろ寝ます。おやすみなさい(^^)/ --[[利用者:Honooo|Honooo]] ([[利用者・トーク:Honooo|トーク]]) 2019年3月8日 (金) 14:25 (UTC)
==「モノ」と「物」と「もの」の微妙な違い==
こんばんは。令和少年です。要約欄で、「モノ」という表記が嫌いとおっしゃっていましたが、厳密な使い分け方があります。&lt;br&gt;
物→物体。目に見えて形のある物体。&lt;br&gt;
もの→抽象的な事柄として使用する形式名詞。抽象的な物体を指す。例えば、「冷たいものが飲みたい」など。&lt;br&gt;
モノ→もとの漢字の意味から外れ、比喩的に使用する場合に用いる。比喩化した物体。例えば、「モノを売って儲ける」など。&lt;br&gt;
参考までに。--&lt;span class=&quot;plainlinks&quot;&gt;[[User:令和少年|&lt;span style=&quot;color:#1e50a2&quot;&gt;''令''&lt;/span&gt;&lt;span style=&quot;color:#aacf53&quot;&gt;'''''和'''''&lt;/span&gt;&lt;span style=&quot;color:#b7282e&quot;&gt;''少''&lt;/span&gt;&lt;span style=&quot;color:#eb6101&quot;&gt;'''''年'''''&lt;/span&gt;&lt;/span&gt;]] &lt;small&gt;([[User talk:令和少年|トーク]]&lt;/span&gt; • &lt;span title=&quot;ウィキブックス日本語版での投稿記録を表示します&quot;&gt;[[Special:Contributions/令和少年|投稿履歴]]&lt;/span&gt; • &lt;span title=&quot;他プロジェクトにある同名アカウントの統一ログイン状態を表示します&quot;&gt;[[特別:アカウント統一管理/令和少年|グローバル利用者情報]]&lt;/span&gt; • &lt;span title=&quot;他プロジェクトにある同名アカウントの直近の投稿記録と被ブロック状態を表示&quot;&gt;[//tools.wmflabs.org/guc/index.php?user={{urlencode:令和少年}}&amp;blocks=true&amp;lang=ja 全履歴]&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/small&gt;&lt;/span&gt;) 2020年5月3日 (日) 14:13 (UTC)
:あっ，そうですか。今日はもう眠いのでこのまま寝て，明日以降よく読んでみますが，でも気になるのはこの使い分けの出典，ソースは何でしょうか…。誰の見解，主張ですかね…。--[[利用者:Honooo|Honooo]] ([[利用者・トーク:Honooo|トーク]]) 2020年5月3日 (日) 14:25 (UTC)
:この使い分けは「ヒト」と「人」のような類で、[http://senderofview.com/mono-thedifference-properuse/]とか[http://plus2.jp/%E3%83%A2%E3%83%8E%E3%80%81%E7%89%A9%E3%80%81%E3%82%82%E3%81%AE%E3%80%81%E3%83%A2%E3%83%8E%E3%81%A3%E3%81%A6%E3%81%AA%E3%82%93%E3%81%A0%EF%BC%9F/]あたりでしょうか。実生活でも何気なく使い分けませんか？「人間にとって大切な物」と書かれると違和感を覚えますよね。それに、カタカナにすることによってより抽象的比喩的に表現できます。例えば歴史漫画や、小学校の教科書では、弥生時代の発展を、「ムラからクニへ」と称しています。それは、当時のムラやクニが現在の意味合いとは違い多少比喩的になるからではと考えられます。--&lt;span class=&quot;plainlinks&quot;&gt;[[User:令和少年|&lt;span style=&quot;color:#1e50a2&quot;&gt;''令''&lt;/span&gt;&lt;span style=&quot;color:#aacf53&quot;&gt;'''''和'''''&lt;/span&gt;&lt;span style=&quot;color:#b7282e&quot;&gt;''少''&lt;/span&gt;&lt;span style=&quot;color:#eb6101&quot;&gt;'''''年'''''&lt;/span&gt;&lt;/span&gt;]] &lt;small&gt;([[User talk:令和少年|トーク]]&lt;/span&gt; • &lt;span title=&quot;ウィキブックス日本語版での投稿記録を表示します&quot;&gt;[[Special:Contributions/令和少年|投稿履歴]]&lt;/span&gt; • &lt;span title=&quot;他プロジェクトにある同名アカウントの統一ログイン状態を表示します&quot;&gt;[[特別:アカウント統一管理/令和少年|グローバル利用者情報]]&lt;/span&gt; • &lt;span title=&quot;他プロジェクトにある同名アカウントの直近の投稿記録と被ブロック状態を表示&quot;&gt;[//tools.wmflabs.org/guc/index.php?user={{urlencode:令和少年}}&amp;blocks=true&amp;lang=ja 全履歴]&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/small&gt;&lt;/span&gt;) 2020年5月3日 (日) 15:31 (UTC)
::物ものモノは字づらが違う以上は書き分けますよね…。ただ，明文的な定義や使い分けよりは，その文章を書く時の文脈や書き手の心理の影響が大きそうですね。「人間にとって大切な物」って実はそんな違和感感じないんですよ…。ただ今はちょっと今日中その次の日の朝までに仕上げなければいけないことがあって，それが気になって頭が明晰ではないのでそう思うのかもしれません。いずれにせよその用事が終わってもう少し余裕ができたら，この使い分けについて考えてみます。--[[利用者:Honooo|Honooo]] ([[利用者・トーク:Honooo|トーク]]) 2020年5月3日 (日) 16:23 (UTC)
::あ，そうか。紹介して頂いたサイトはあまりにも一般的なサイトな上ちょっと長いので，令和さんの文章だけ読みましたが，成程，妥当な分類ですねー。形式名詞ってあるんですね，勉強になりました(^^)。ただ私自身はもうちょっと，感覚的，感情的な分類をしていますねー…。こういう感じなんですが…↓&lt;br&gt;
::物→一般的，普遍的な意味で物を示す言葉。つまり…物の事ですね^^。&lt;br&gt;
::もの→同じ概念を示していても柔らかい印象を受けます。自分自身は，読み手に柔らかい印象を与えるために使います。&lt;br&gt;
::モノ→ネガティブなイメージがある。自分ではほとんど，出来れば全く，使わない。おそらく書き手の何らかの念がこもっている，何か特定の事象，概念を強調したいときに使うんだと思うけど…。--[[利用者:Honooo|Honooo]] ([[利用者・トーク:Honooo|トーク]]) 2020年5月4日 (月) 00:53 (UTC)
:::(横から失礼)横から失礼いたします。今回の場合、当該部分の執筆者の独特の「話し言葉」として、使用されているように見えます。その編集者は「ワタシ」など、ブログのような口調を使用します。それらの一環として考えても問題はないと考えます。なお、私はこれらに違和感を覚えます。--{{利用者:ダーフレ/日本語}}2020年5月4日 (月) 04:55 (UTC)
::::そうですね。ただ，この場で直接の主題ではないのに特定人物に対する噂話をすることは控えたいと思いますが，そういえば昔私が若いころある職場で割と好意を寄せてる年配の方がいて，その方は書き言葉や文章で，片仮名を多用していましたね…。年取った人ってそんな感じかなーなんて思っていましたが…。--[[利用者:Honooo|Honooo]] ([[利用者・トーク:Honooo|トーク]]) 2020年5月4日 (月) 05:36 (UTC)
:::::某氏の書き方は、別として、Honoooさんが、要約欄に「カタカナの『モノ』が嫌い」と書いていらっしゃいましたのでちょっと連絡させていただきました。--&lt;span class=&quot;plainlinks&quot;&gt;[[User:令和少年|&lt;span style=&quot;color:#1e50a2&quot;&gt;''令''&lt;/span&gt;&lt;span style=&quot;color:#aacf53&quot;&gt;'''''和'''''&lt;/span&gt;&lt;span style=&quot;color:#b7282e&quot;&gt;''少''&lt;/span&gt;&lt;span style=&quot;color:#eb6101&quot;&gt;'''''年'''''&lt;/span&gt;&lt;/span&gt;]] &lt;small&gt;([[User talk:令和少年|トーク]]&lt;/span&gt; • &lt;span title=&quot;ウィキブックス日本語版での投稿記録を表示します&quot;&gt;[[Special:Contributions/令和少年|投稿履歴]]&lt;/span&gt; • &lt;span title=&quot;他プロジェクトにある同名アカウントの統一ログイン状態を表示します&quot;&gt;[[特別:アカウント統一管理/令和少年|グローバル利用者情報]]&lt;/span&gt; • &lt;span title=&quot;他プロジェクトにある同名アカウントの直近の投稿記録と被ブロック状態を表示&quot;&gt;[//tools.wmflabs.org/guc/index.php?user={{urlencode:令和少年}}&amp;blocks=true&amp;lang=ja 全履歴]&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/small&gt;&lt;/span&gt;) 2020年5月4日 (月) 11:33 (UTC)

== 流石に挑発が過ぎます ==

問題点があれば、それを改善した表現にで本文に、全体としての問題であれば「ノート」等に指摘し、コミュニティメンバーを募るなりし改善するのが、WikiMediaProjectの作法だと思います。--[[利用者:Tomzo|Tomzo]] ([[利用者・トーク:Tomzo|トーク]]) 2020年12月18日 (金) 11:32 (UTC)
:そうですか…挑発というよりはユーモアを駆使した調和を目指したつもりだったんですが…。どっちにしろ私はここですじにく氏と双方向の会話はしたことありませんし，今の状態ではノートでの議論が進展するようにも思えないし，そもそもこのページに関する不満をどう表現して文章化したらいいのかも，あまり考え思いつかないですしね…。とにかくまあ今回はこのページを何とかしたいと思うので、もう眠いから今日は寝て，おいおい戦略を練っていきます。--[[利用者:Honooo|Honooo]] ([[利用者・トーク:Honooo|トーク]]) 2020年12月18日 (金) 11:45 (UTC)

芸風だということですので、私は寛大に取っておきますが、[https://ja.wikibooks.org/w/index.php?title=%E5%88%A9%E7%94%A8%E8%80%85%E3%83%BB%E3%83%88%E3%83%BC%E3%82%AF:Tomzo&amp;curid=6202&amp;diff=183903&amp;oldid=183901 この絵文字は挑発ととられても仕方ありません。]まあ、要約欄における暴言で短時間投稿ブロックされた私に言われたくはないでしょうが。 --[[利用者:Kyube|kyube]] ([[利用者・トーク:Kyube|トーク]]) 2021年9月13日 (月) 03:17 (UTC)
:いやー日本人同士でごく極たまに、ここぞというときに使えば、過激なギャグとして成立すると思ってたんですが、最近は控えるムードが強いんですね。確かに私は1990年代感覚でいることは事実だ…--[[利用者:Honooo|Honooo]] ([[利用者・トーク:Honooo|トーク]]) 2021年9月13日 (月) 10:45 (UTC)

== 某氏について ==

もうご存知かもしれませんがすじにくシチューさんにWikipediaの方では[https://ja.wikipedia.org/wiki/Wikipedia:投稿ブロック依頼/すじにくシチュー 投稿ブロック依頼]が出されたようです。一応報告しておきます。--[[利用者:コルモラン|コルモラン]] ([[利用者・トーク:コルモラン|トーク]]) 2021年5月6日 (木) 11:55 (UTC)
:いやー知っていますよ。気にはしてたんですが、実は私の立場はここでの利用者ページの削除の時と同じように、票は投じないという事なんです。確かに私は彼の主張や文章には多くの場合反対だし、ストレスも感じてるんですが、一方で実は彼の（あるいは彼女かもしれませんね…）心の中にあるものに、明らかに自分の中にもある同じものを感じてるんですよ…。ですからまあ気にはしてるけど票は投じないという事ですね…。まあルールはあまり知らないので投票権があるかどうかも知らないのですが…。推移は今後見守りますが、とりあえず今日はもう寝ます。--[[利用者:Honooo|Honooo]] ([[利用者・トーク:Honooo|トーク]]) 2021年5月6日 (木) 12:18 (UTC)

== お久しぶりです ==

* [[利用者:Honooo|Honooo]]さん、お久しぶりです。[[User:コルモラン]]として活動していた者です。京大を私は目指しているので京大対策のページを見ていたところ、トラブルになっているようなのでお邪魔しました。さてアフリマン云々の例え話ですが分かりにくいと思います。すじにくさんはともかく[[利用者:Evgrem2|Evgrem2さん]]にはもうちょっと優しくしても良いのでは。--[[利用者:コドモラン|コドモラン]] ([[利用者・トーク:コドモラン|トーク]]) 2021年11月15日 (月) 12:42 (UTC)
*:あっ，そうですか…コルモランさんって，老○という言葉が嫌いと書いていましたから，年取った方だと思っていたのですが，そうじゃあないんですね…。
*:別にEvgrem2さんに厳しくしているわけではありませんよ。批判されたから，反論して私の立場を説明しているだけですし…。アフリマンの話もそれほど大した話じゃあなくて，アフリマン→唯物論者，物理主義者，ルシファー→自由意思と反逆，という割と簡単なイメージ，シュタイナーの議論に基づいて，と言っても私はシュタイナーの元の文に当たっていませんがね^^;;。
*:それにTomzoさんのトークページを見てもらえれば分かるとおもうのですが， Elesqoさん=Evgremさん という可能性もありますよ。その場合はもちろん和解は継続中ですし…
*:あとですねー例えばEvgremさんは京大対策についてしか書いてないでしょ？ところがすじにくさんはここで総合的に文章を書いている。だとしたらその内容はともかくにすると，参加姿勢としてはすじにくさんのほうが共感しますよね…。--[[利用者:Honooo|Honooo]] ([[利用者・トーク:Honooo|トーク]]) 2021年11月15日 (月) 14:19 (UTC)

== 編集について ==

[[user:Mauzie683794‎]]さんの一連の発言除去については、取り扱いが適当ではないため、いったん差し戻しました。しかしながら、Honoooさんの書き込み内容及び表現については、Mauzie683794‎さんのご指摘も一理あるとことはありますので、
ウィキペディアにおける「[[w:Wikipedia:礼儀を忘れない|礼儀を忘れない]]」「[[w:Wikipedia:エチケット|エチケット]]」を心がけていただき、穏当な記述にて対応いただくよう再度お願いいたします。--[[利用者:Tomzo|Tomzo]] ([[利用者・トーク:Tomzo|トーク]]) 2022年3月1日 (火) 10:40 (UTC)
:言葉遣いは重要です。相手との対話に際しては「です・ます」調での応対をお願いします。--[[利用者:Tomzo|Tomzo]] ([[利用者・トーク:Tomzo|トーク]]) 2022年3月1日 (火) 12:45 (UTC)
::ですます調に関しては，今後も，使う意味があると思ったときに使います。Tomzo さん，見てて分かったと思うけど，結局あの人は対話する気さえないんだよ? ただ私はその手の議論はしない主義なのでね。大体泥棒と承認欲求，この二つの言葉使った時点で私的には完全アウトなんですよ。もちろんこの言葉は Tomzo さんも，場合によっては使うよね。でも私的には自発的にはまず使わない言葉だな。とにかくあの人は手に負えないしめんどくさいので，しばらく放置しておくしかない，そうします。--[[利用者:Honooo|Honooo]] ([[利用者・トーク:Honooo|トーク]]) 2022年3月1日 (火) 16:52 (UTC)
::礼儀，エチケット，ですます調，この３つはあっても根源的に他者を侮っている人間っているよ。--[[利用者:Honooo|Honooo]] ([[利用者・トーク:Honooo|トーク]]) 2022年3月1日 (火) 17:01 (UTC)
::もう少し補足するけど，最近の中途半端に知的な人間って，礼儀とですます調を守りつつ，ありえない汚いこと言う奴が多いと思うな。そんな狂った会話したくないんで…--[[利用者:Honooo|Honooo]] ([[利用者・トーク:Honooo|トーク]]) 2022年3月1日 (火) 17:21 (UTC)

== 連絡 ==

まず、貴殿に対する投稿ブロック依頼ですが，[[Wikibooks:投稿ブロック依頼/Honooo]]を作成しました。今後の議論はそちらでお願いします。

次に，貴殿が提出した投稿ブロック依頼ですが、こちらも[[Wikibooks:投稿ブロック依頼/すじにくシチュー]]に移動しました（sdが貼ってありますがあれはsrdがないため代用しているだけで，コメントは行うことができます）。また、[[Wikibooks:コメント依頼/すじにくシチュー]]の方は節を追加しましたので，それに沿って事情などを書いていただけると幸いです。--[[利用者:スタリオン箕浦|スタリオン箕浦]] &lt;small&gt;([[利用者・トーク:スタリオン箕浦|会話]]/[[特別:投稿記録/スタリオン箕浦|投稿記録]]/[[特別:Log/スタリオン箕浦|ログ]]/[[特別:メール送信/スタリオン箕浦|メール]])&lt;/small&gt; 2022年5月8日 (日) 09:08 (UTC)

:はい，わかりました^^。
:ただ私は一種腹立ち紛れにあれを書いたし、すじ肉先輩も同じようなものだと思うから、この議題が執行されるとは余り思ってないんですよ。と、いうか我々以外の第三者が意見を書かない以上、この議題は一切進展しないでしょうね。--[[利用者:Honooo|Honooo]] ([[利用者・トーク:Honooo|トーク]]) 2022年5月8日 (日) 09:18 (UTC)

== ちょっとそれは... ==

利用者ページにE.Sujがやばい事をしていると書いている所についてなんだけど、晒しは良くないと思います。--[[特別:投稿記録/163.43.134.100|163.43.134.100]] 2022年7月24日 (日) 06:23 (UTC)</text>
      <sha1>q4zwru3iadu8t2odffo1xsl4e1w7mwd</sha1>
    </revision>
    <revision>
      <id>205762</id>
      <parentid>205760</parentid>
      <timestamp>2022-07-24T06:33:29Z</timestamp>
      <contributor>
        <username>Honooo</username>
        <id>14373</id>
      </contributor>
      <comment>/* ちょっとそれは... */ 返信</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="20177" xml:space="preserve">== ウィキブックスにようこそ！ ==
こんにちは、Honoooさん、はじめまして！ ウィキブックスの参加者の一人、[[利用者:Vigorous action|Vigorous action]] （[[利用者・トーク:Vigorous action|&lt;small&gt;Ｔａｌｋ&lt;/small&gt;]]&lt;small&gt;/&lt;/small&gt;[[特別:Contributions/Vigorous action|&lt;small&gt;History&lt;/small&gt;]]）と申します。ウィキブックスへようこそ！

* お隣の[[利用者:Honooo|利用者ページ]]は、ご自身の自己紹介の他、作業用のスペースなどとして利用することができます。
* 執筆の際には[[Wikibooks:中立的な観点|中立的な観点]]および[[Wikibooks:著作権|著作権]]にご留意ください。
* 何か疑問点がありましたら[[Wikibooks:談話室]]で質問することができます。また、教科書の内容に関するご質問がありましたら[[Wikibooks:ヘルプデスク|ヘルプデスク]]へお越しください。
あなたが実り多き活動をされることを楽しみにしております。

Welcome to Japanese Wikibooks. Thank you for your contributions! If you don't prefer to use Japanese, and when looking for further information, feel free to visit [[Wikibooks:談話室]]. Enjoy!

なお、このメッセージは主に利用者‐会話ページに何も記入されていない方に投稿しております。Honoooさんが、すでに活動を開始されてから期間が経っていらっしゃるのでしたら、ご存知のことばかりをご案内したかもしれません。不明をお詫び申し上げます。--[[利用者:Vigorous action|Vigorous action]] （[[利用者・トーク:Vigorous action|&lt;small&gt;Ｔａｌｋ&lt;/small&gt;]]&lt;small&gt;/&lt;/small&gt;[[特別:Contributions/Vigorous action|&lt;small&gt;History&lt;/small&gt;]]） 2014年1月4日 (土) 22:46 (UTC)
:こんばんは Vigorousさん。コメントをいただいてからもう五年もたってしまいましたが、いまさらながら返信いたします(^^)。大体私は昔のパソコン通信時代から、コメントやメールに対する返信、その時期やタイミング、内容、するかしないかで、不手際が多いようで、よく顰蹙を浴びていました…。結局未だにうまく出来ていないことが多いんですよね(^^;;;)。最近はウィキバーシティで少しだけ、書いています。結局ここが自由にかけて、一番いいかなーって感じですね。内容的にはおそらく、独自研究に近いものだと思いますが、特に消されることもないようなので、かろうじて許容されているようです。それではそろそろ寝ます。おやすみなさい(^^)/ --[[利用者:Honooo|Honooo]] ([[利用者・トーク:Honooo|トーク]]) 2019年3月8日 (金) 14:25 (UTC)
==「モノ」と「物」と「もの」の微妙な違い==
こんばんは。令和少年です。要約欄で、「モノ」という表記が嫌いとおっしゃっていましたが、厳密な使い分け方があります。&lt;br&gt;
物→物体。目に見えて形のある物体。&lt;br&gt;
もの→抽象的な事柄として使用する形式名詞。抽象的な物体を指す。例えば、「冷たいものが飲みたい」など。&lt;br&gt;
モノ→もとの漢字の意味から外れ、比喩的に使用する場合に用いる。比喩化した物体。例えば、「モノを売って儲ける」など。&lt;br&gt;
参考までに。--&lt;span class=&quot;plainlinks&quot;&gt;[[User:令和少年|&lt;span style=&quot;color:#1e50a2&quot;&gt;''令''&lt;/span&gt;&lt;span style=&quot;color:#aacf53&quot;&gt;'''''和'''''&lt;/span&gt;&lt;span style=&quot;color:#b7282e&quot;&gt;''少''&lt;/span&gt;&lt;span style=&quot;color:#eb6101&quot;&gt;'''''年'''''&lt;/span&gt;&lt;/span&gt;]] &lt;small&gt;([[User talk:令和少年|トーク]]&lt;/span&gt; • &lt;span title=&quot;ウィキブックス日本語版での投稿記録を表示します&quot;&gt;[[Special:Contributions/令和少年|投稿履歴]]&lt;/span&gt; • &lt;span title=&quot;他プロジェクトにある同名アカウントの統一ログイン状態を表示します&quot;&gt;[[特別:アカウント統一管理/令和少年|グローバル利用者情報]]&lt;/span&gt; • &lt;span title=&quot;他プロジェクトにある同名アカウントの直近の投稿記録と被ブロック状態を表示&quot;&gt;[//tools.wmflabs.org/guc/index.php?user={{urlencode:令和少年}}&amp;blocks=true&amp;lang=ja 全履歴]&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/small&gt;&lt;/span&gt;) 2020年5月3日 (日) 14:13 (UTC)
:あっ，そうですか。今日はもう眠いのでこのまま寝て，明日以降よく読んでみますが，でも気になるのはこの使い分けの出典，ソースは何でしょうか…。誰の見解，主張ですかね…。--[[利用者:Honooo|Honooo]] ([[利用者・トーク:Honooo|トーク]]) 2020年5月3日 (日) 14:25 (UTC)
:この使い分けは「ヒト」と「人」のような類で、[http://senderofview.com/mono-thedifference-properuse/]とか[http://plus2.jp/%E3%83%A2%E3%83%8E%E3%80%81%E7%89%A9%E3%80%81%E3%82%82%E3%81%AE%E3%80%81%E3%83%A2%E3%83%8E%E3%81%A3%E3%81%A6%E3%81%AA%E3%82%93%E3%81%A0%EF%BC%9F/]あたりでしょうか。実生活でも何気なく使い分けませんか？「人間にとって大切な物」と書かれると違和感を覚えますよね。それに、カタカナにすることによってより抽象的比喩的に表現できます。例えば歴史漫画や、小学校の教科書では、弥生時代の発展を、「ムラからクニへ」と称しています。それは、当時のムラやクニが現在の意味合いとは違い多少比喩的になるからではと考えられます。--&lt;span class=&quot;plainlinks&quot;&gt;[[User:令和少年|&lt;span style=&quot;color:#1e50a2&quot;&gt;''令''&lt;/span&gt;&lt;span style=&quot;color:#aacf53&quot;&gt;'''''和'''''&lt;/span&gt;&lt;span style=&quot;color:#b7282e&quot;&gt;''少''&lt;/span&gt;&lt;span style=&quot;color:#eb6101&quot;&gt;'''''年'''''&lt;/span&gt;&lt;/span&gt;]] &lt;small&gt;([[User talk:令和少年|トーク]]&lt;/span&gt; • &lt;span title=&quot;ウィキブックス日本語版での投稿記録を表示します&quot;&gt;[[Special:Contributions/令和少年|投稿履歴]]&lt;/span&gt; • &lt;span title=&quot;他プロジェクトにある同名アカウントの統一ログイン状態を表示します&quot;&gt;[[特別:アカウント統一管理/令和少年|グローバル利用者情報]]&lt;/span&gt; • &lt;span title=&quot;他プロジェクトにある同名アカウントの直近の投稿記録と被ブロック状態を表示&quot;&gt;[//tools.wmflabs.org/guc/index.php?user={{urlencode:令和少年}}&amp;blocks=true&amp;lang=ja 全履歴]&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/small&gt;&lt;/span&gt;) 2020年5月3日 (日) 15:31 (UTC)
::物ものモノは字づらが違う以上は書き分けますよね…。ただ，明文的な定義や使い分けよりは，その文章を書く時の文脈や書き手の心理の影響が大きそうですね。「人間にとって大切な物」って実はそんな違和感感じないんですよ…。ただ今はちょっと今日中その次の日の朝までに仕上げなければいけないことがあって，それが気になって頭が明晰ではないのでそう思うのかもしれません。いずれにせよその用事が終わってもう少し余裕ができたら，この使い分けについて考えてみます。--[[利用者:Honooo|Honooo]] ([[利用者・トーク:Honooo|トーク]]) 2020年5月3日 (日) 16:23 (UTC)
::あ，そうか。紹介して頂いたサイトはあまりにも一般的なサイトな上ちょっと長いので，令和さんの文章だけ読みましたが，成程，妥当な分類ですねー。形式名詞ってあるんですね，勉強になりました(^^)。ただ私自身はもうちょっと，感覚的，感情的な分類をしていますねー…。こういう感じなんですが…↓&lt;br&gt;
::物→一般的，普遍的な意味で物を示す言葉。つまり…物の事ですね^^。&lt;br&gt;
::もの→同じ概念を示していても柔らかい印象を受けます。自分自身は，読み手に柔らかい印象を与えるために使います。&lt;br&gt;
::モノ→ネガティブなイメージがある。自分ではほとんど，出来れば全く，使わない。おそらく書き手の何らかの念がこもっている，何か特定の事象，概念を強調したいときに使うんだと思うけど…。--[[利用者:Honooo|Honooo]] ([[利用者・トーク:Honooo|トーク]]) 2020年5月4日 (月) 00:53 (UTC)
:::(横から失礼)横から失礼いたします。今回の場合、当該部分の執筆者の独特の「話し言葉」として、使用されているように見えます。その編集者は「ワタシ」など、ブログのような口調を使用します。それらの一環として考えても問題はないと考えます。なお、私はこれらに違和感を覚えます。--{{利用者:ダーフレ/日本語}}2020年5月4日 (月) 04:55 (UTC)
::::そうですね。ただ，この場で直接の主題ではないのに特定人物に対する噂話をすることは控えたいと思いますが，そういえば昔私が若いころある職場で割と好意を寄せてる年配の方がいて，その方は書き言葉や文章で，片仮名を多用していましたね…。年取った人ってそんな感じかなーなんて思っていましたが…。--[[利用者:Honooo|Honooo]] ([[利用者・トーク:Honooo|トーク]]) 2020年5月4日 (月) 05:36 (UTC)
:::::某氏の書き方は、別として、Honoooさんが、要約欄に「カタカナの『モノ』が嫌い」と書いていらっしゃいましたのでちょっと連絡させていただきました。--&lt;span class=&quot;plainlinks&quot;&gt;[[User:令和少年|&lt;span style=&quot;color:#1e50a2&quot;&gt;''令''&lt;/span&gt;&lt;span style=&quot;color:#aacf53&quot;&gt;'''''和'''''&lt;/span&gt;&lt;span style=&quot;color:#b7282e&quot;&gt;''少''&lt;/span&gt;&lt;span style=&quot;color:#eb6101&quot;&gt;'''''年'''''&lt;/span&gt;&lt;/span&gt;]] &lt;small&gt;([[User talk:令和少年|トーク]]&lt;/span&gt; • &lt;span title=&quot;ウィキブックス日本語版での投稿記録を表示します&quot;&gt;[[Special:Contributions/令和少年|投稿履歴]]&lt;/span&gt; • &lt;span title=&quot;他プロジェクトにある同名アカウントの統一ログイン状態を表示します&quot;&gt;[[特別:アカウント統一管理/令和少年|グローバル利用者情報]]&lt;/span&gt; • &lt;span title=&quot;他プロジェクトにある同名アカウントの直近の投稿記録と被ブロック状態を表示&quot;&gt;[//tools.wmflabs.org/guc/index.php?user={{urlencode:令和少年}}&amp;blocks=true&amp;lang=ja 全履歴]&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/small&gt;&lt;/span&gt;) 2020年5月4日 (月) 11:33 (UTC)

== 流石に挑発が過ぎます ==

問題点があれば、それを改善した表現にで本文に、全体としての問題であれば「ノート」等に指摘し、コミュニティメンバーを募るなりし改善するのが、WikiMediaProjectの作法だと思います。--[[利用者:Tomzo|Tomzo]] ([[利用者・トーク:Tomzo|トーク]]) 2020年12月18日 (金) 11:32 (UTC)
:そうですか…挑発というよりはユーモアを駆使した調和を目指したつもりだったんですが…。どっちにしろ私はここですじにく氏と双方向の会話はしたことありませんし，今の状態ではノートでの議論が進展するようにも思えないし，そもそもこのページに関する不満をどう表現して文章化したらいいのかも，あまり考え思いつかないですしね…。とにかくまあ今回はこのページを何とかしたいと思うので、もう眠いから今日は寝て，おいおい戦略を練っていきます。--[[利用者:Honooo|Honooo]] ([[利用者・トーク:Honooo|トーク]]) 2020年12月18日 (金) 11:45 (UTC)

芸風だということですので、私は寛大に取っておきますが、[https://ja.wikibooks.org/w/index.php?title=%E5%88%A9%E7%94%A8%E8%80%85%E3%83%BB%E3%83%88%E3%83%BC%E3%82%AF:Tomzo&amp;curid=6202&amp;diff=183903&amp;oldid=183901 この絵文字は挑発ととられても仕方ありません。]まあ、要約欄における暴言で短時間投稿ブロックされた私に言われたくはないでしょうが。 --[[利用者:Kyube|kyube]] ([[利用者・トーク:Kyube|トーク]]) 2021年9月13日 (月) 03:17 (UTC)
:いやー日本人同士でごく極たまに、ここぞというときに使えば、過激なギャグとして成立すると思ってたんですが、最近は控えるムードが強いんですね。確かに私は1990年代感覚でいることは事実だ…--[[利用者:Honooo|Honooo]] ([[利用者・トーク:Honooo|トーク]]) 2021年9月13日 (月) 10:45 (UTC)

== 某氏について ==

もうご存知かもしれませんがすじにくシチューさんにWikipediaの方では[https://ja.wikipedia.org/wiki/Wikipedia:投稿ブロック依頼/すじにくシチュー 投稿ブロック依頼]が出されたようです。一応報告しておきます。--[[利用者:コルモラン|コルモラン]] ([[利用者・トーク:コルモラン|トーク]]) 2021年5月6日 (木) 11:55 (UTC)
:いやー知っていますよ。気にはしてたんですが、実は私の立場はここでの利用者ページの削除の時と同じように、票は投じないという事なんです。確かに私は彼の主張や文章には多くの場合反対だし、ストレスも感じてるんですが、一方で実は彼の（あるいは彼女かもしれませんね…）心の中にあるものに、明らかに自分の中にもある同じものを感じてるんですよ…。ですからまあ気にはしてるけど票は投じないという事ですね…。まあルールはあまり知らないので投票権があるかどうかも知らないのですが…。推移は今後見守りますが、とりあえず今日はもう寝ます。--[[利用者:Honooo|Honooo]] ([[利用者・トーク:Honooo|トーク]]) 2021年5月6日 (木) 12:18 (UTC)

== お久しぶりです ==

* [[利用者:Honooo|Honooo]]さん、お久しぶりです。[[User:コルモラン]]として活動していた者です。京大を私は目指しているので京大対策のページを見ていたところ、トラブルになっているようなのでお邪魔しました。さてアフリマン云々の例え話ですが分かりにくいと思います。すじにくさんはともかく[[利用者:Evgrem2|Evgrem2さん]]にはもうちょっと優しくしても良いのでは。--[[利用者:コドモラン|コドモラン]] ([[利用者・トーク:コドモラン|トーク]]) 2021年11月15日 (月) 12:42 (UTC)
*:あっ，そうですか…コルモランさんって，老○という言葉が嫌いと書いていましたから，年取った方だと思っていたのですが，そうじゃあないんですね…。
*:別にEvgrem2さんに厳しくしているわけではありませんよ。批判されたから，反論して私の立場を説明しているだけですし…。アフリマンの話もそれほど大した話じゃあなくて，アフリマン→唯物論者，物理主義者，ルシファー→自由意思と反逆，という割と簡単なイメージ，シュタイナーの議論に基づいて，と言っても私はシュタイナーの元の文に当たっていませんがね^^;;。
*:それにTomzoさんのトークページを見てもらえれば分かるとおもうのですが， Elesqoさん=Evgremさん という可能性もありますよ。その場合はもちろん和解は継続中ですし…
*:あとですねー例えばEvgremさんは京大対策についてしか書いてないでしょ？ところがすじにくさんはここで総合的に文章を書いている。だとしたらその内容はともかくにすると，参加姿勢としてはすじにくさんのほうが共感しますよね…。--[[利用者:Honooo|Honooo]] ([[利用者・トーク:Honooo|トーク]]) 2021年11月15日 (月) 14:19 (UTC)

== 編集について ==

[[user:Mauzie683794‎]]さんの一連の発言除去については、取り扱いが適当ではないため、いったん差し戻しました。しかしながら、Honoooさんの書き込み内容及び表現については、Mauzie683794‎さんのご指摘も一理あるとことはありますので、
ウィキペディアにおける「[[w:Wikipedia:礼儀を忘れない|礼儀を忘れない]]」「[[w:Wikipedia:エチケット|エチケット]]」を心がけていただき、穏当な記述にて対応いただくよう再度お願いいたします。--[[利用者:Tomzo|Tomzo]] ([[利用者・トーク:Tomzo|トーク]]) 2022年3月1日 (火) 10:40 (UTC)
:言葉遣いは重要です。相手との対話に際しては「です・ます」調での応対をお願いします。--[[利用者:Tomzo|Tomzo]] ([[利用者・トーク:Tomzo|トーク]]) 2022年3月1日 (火) 12:45 (UTC)
::ですます調に関しては，今後も，使う意味があると思ったときに使います。Tomzo さん，見てて分かったと思うけど，結局あの人は対話する気さえないんだよ? ただ私はその手の議論はしない主義なのでね。大体泥棒と承認欲求，この二つの言葉使った時点で私的には完全アウトなんですよ。もちろんこの言葉は Tomzo さんも，場合によっては使うよね。でも私的には自発的にはまず使わない言葉だな。とにかくあの人は手に負えないしめんどくさいので，しばらく放置しておくしかない，そうします。--[[利用者:Honooo|Honooo]] ([[利用者・トーク:Honooo|トーク]]) 2022年3月1日 (火) 16:52 (UTC)
::礼儀，エチケット，ですます調，この３つはあっても根源的に他者を侮っている人間っているよ。--[[利用者:Honooo|Honooo]] ([[利用者・トーク:Honooo|トーク]]) 2022年3月1日 (火) 17:01 (UTC)
::もう少し補足するけど，最近の中途半端に知的な人間って，礼儀とですます調を守りつつ，ありえない汚いこと言う奴が多いと思うな。そんな狂った会話したくないんで…--[[利用者:Honooo|Honooo]] ([[利用者・トーク:Honooo|トーク]]) 2022年3月1日 (火) 17:21 (UTC)

== 連絡 ==

まず、貴殿に対する投稿ブロック依頼ですが，[[Wikibooks:投稿ブロック依頼/Honooo]]を作成しました。今後の議論はそちらでお願いします。

次に，貴殿が提出した投稿ブロック依頼ですが、こちらも[[Wikibooks:投稿ブロック依頼/すじにくシチュー]]に移動しました（sdが貼ってありますがあれはsrdがないため代用しているだけで，コメントは行うことができます）。また、[[Wikibooks:コメント依頼/すじにくシチュー]]の方は節を追加しましたので，それに沿って事情などを書いていただけると幸いです。--[[利用者:スタリオン箕浦|スタリオン箕浦]] &lt;small&gt;([[利用者・トーク:スタリオン箕浦|会話]]/[[特別:投稿記録/スタリオン箕浦|投稿記録]]/[[特別:Log/スタリオン箕浦|ログ]]/[[特別:メール送信/スタリオン箕浦|メール]])&lt;/small&gt; 2022年5月8日 (日) 09:08 (UTC)

:はい，わかりました^^。
:ただ私は一種腹立ち紛れにあれを書いたし、すじ肉先輩も同じようなものだと思うから、この議題が執行されるとは余り思ってないんですよ。と、いうか我々以外の第三者が意見を書かない以上、この議題は一切進展しないでしょうね。--[[利用者:Honooo|Honooo]] ([[利用者・トーク:Honooo|トーク]]) 2022年5月8日 (日) 09:18 (UTC)

== ちょっとそれは... ==

利用者ページにE.Sujがやばい事をしていると書いている所についてなんだけど、晒しは良くないと思います。--[[特別:投稿記録/163.43.134.100|163.43.134.100]] 2022年7月24日 (日) 06:23 (UTC)

:晒しっていうのもあんたら若い連中が良く使う言葉だね。どういう意味?--[[利用者:Honooo|Honooo]] ([[利用者・トーク:Honooo|トーク]]) 2022年7月24日 (日) 06:33 (UTC)</text>
      <sha1>1rb3p6q3m2kuxv3tc081oya9kwahq2j</sha1>
    </revision>
  </page>
  <page>
    <title>中学校社会 公民/在日外国人の権利に関する国内問題と議論</title>
    <ns>0</ns>
    <id>18999</id>
    <revision>
      <id>205722</id>
      <parentid>145530</parentid>
      <timestamp>2022-07-23T13:16:39Z</timestamp>
      <contributor>
        <username>Nermer314</username>
        <id>62933</id>
      </contributor>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="10636" xml:space="preserve">:&lt;big&gt;※執筆者への注意
::ウィキブックス、ウィキペディアを始めとするプロジェクトはは政治運動の場所では無いので、たとえば外国人参政権の議論などで、どちらか片方の立場にたって主張をするようなことは、やめてください。そのような場で政治運動を行うことは、やめてください。&lt;/big&gt;
----

:※学生への注意  検定教科書の内容と、法律との間に、かなりの差があります。

== 在日外国人について ==
日本には、外国人も多く暮らしています。そのうちの多くは、中国人（約64万人）と韓国人・朝鮮人（合わせて約50万人）です。（なお、この記事では「朝鮮人」とは北朝鮮の国籍に属する人とします。）
近年では、フィリピン（約20万人）やブラジル（約18万人）やベトナム（約8万人）などからの出稼ぎ労働者などが増えています。

在日外国人にも人権はあるので、人権は保障されていますが（「人権」とは人間に与えられる権利なので、外国人も人なので人権は保障される。）、日本人とまったく同じ権利が与えられているわけではありません。
外国人に与えられない権利の例として、参政権（さんせいけん）があります。


== 在日韓国人・朝鮮人について ==
* そもそも在日朝鮮人・在日韓国人とは？
このうち韓国人と朝鮮人については、かつて日本が韓国（ 「大韓帝国」という国が、昔あった。 ）を併合していた歴史があり（1910年に大韓帝国を併合）、第二次大戦の終戦時ごろには約200万人の在日韓国人・朝鮮人がいました。

仕事で日本に来たり、あるいは戦時中の労働者としての動員で朝鮮半島から日本に連れて来られた人などです。

検定教科書では「強制連行」などと表記する場合があり、たしかに強制的につれてこられたわけですが、特定の民族を不利にあつかったわけではなく、戦時中の日本国民にも強制労働や徴兵の義務などを課したのと同じように、当事は日本国の一部だった朝鮮半島や台湾にも労働を強制したわけです。

* 現状
現在の日本国民の中には在日朝鮮人・韓国人を信用してない人もいて、そのため在日朝鮮人・韓国人を嫌う人もいます。そのため、在日朝鮮人・韓国人への差別があります。検定教科書の多くは、これを不合理な差別と考えているようであり、不合理なのでこの差別をなくすべき、というような事を主張しています。在日朝鮮人への結婚や就職での差別をなくすべき、と考えている検定教科書が多いです。

なお、在日朝鮮人・韓国人には、普段は本名のかわりに、日本風の通称を名乗っている人がいます。（ただし、役所などへ公式な書類を出す時などは、本名を名乗る必要がある。）例外的に、それは日本の慣習でも認められています。

(※ 在日朝鮮人の通称の存在については、中学教科書の範囲内です。)

検定教科書は、おおむね「在日朝鮮人は民族の誇りを守って、日本国籍を取得せずに日本に暮らし続けてる」というような事を言って、かれら在日朝鮮人・韓国人の立場をかばっています。


* 歴史の詳細（教科書の範囲外）
かれら第二次大戦の終戦当時の在日韓国人・朝鮮人の多くは、第二次大戦の終戦後は母国の韓国・北朝鮮に帰ったり、あるいは日本の国籍を取得して日本国民になったりしました。

ですが、様々な事情で母国には戻らず、日本国籍を取得しないで、そのまま日本に住みつづけた者も多くいました。
そのような関係で現在にも日本に多くの韓国人・朝鮮人がいます。

よくある勘違いとして、戦争中に強制連行により朝鮮半島から連れてこられた人の子孫が、在日朝鮮・韓国人の大半だと勘違いしている人が多いです。しかし、統計では、戦時中に国の命令で強制的に朝鮮半島から日本に連れてこられた人は、たったの数百〜数千人です。（※ 参考文献: 外務省情報文化局 『外務省発表集（外務省発表集および公表資料集）』第十号, 昭和三十五年（1960年）二月, p. 51-54. 「（三） アジア、豪州関係 1.在日朝鮮人の渡来および引揚げに関する経緯、とくに、戦時中の徴用労務者について 記事資料 昭和三十四年七月十一日」 ）

考えてみれば、朝鮮半島の人をわざわざ日本に連れてくるよりも、現地の朝鮮半島で働かせたほうが安上がりです。
 

また、その他の在日韓国人・朝鮮人として、日韓併合の時代から日本にいた韓国人・朝鮮人とは別に、第二次大戦後の朝鮮戦争（1950年に勃発）から逃れるために、1950年代ごろに日本に密入国してきた人が加わっています。
当時の推定では約20万人〜40万人の密入国の韓国人・朝鮮人が密入国した、と言われています。

べつに、これら朝鮮戦争時の密入国者の全てが、そのまま今でも在日外国人のままではなく、日本には国籍を日本国籍にかえる帰化（きか）という手続きもあるので、帰化して日本国籍になった人もいる。

また、帰化の手続きがあるので、帰化して日本国籍を取得する外国人も多く、そのため、在日韓国人・朝鮮人の数は減ってきています。

== 外国人参政権についての議論 ==
在日外国人にも人権はあるので、人権は保障されていますが、日本人とまったく同じ権利が与えられているわけではありません。外国人に与えられない権利の例として、参政権があります。

「無制限に外国人に参政権を与えると、もしも日本を侵略したり負かそうとする外国があると、参政権が悪用される恐れがある」という考えと、「国政への参政権は、国家の主権に関わる」という考えのもと、参政権は日本国籍を持つ日本国民にのみ与えられ、外国人には与えられていません。


また、参政権いがいの権利の制限として、公務員にも国籍条項（こくせき じょうこう）があり、外国人の日本国の公務員への就職は制限されています。

ちなみに世界の多くの国では、外国人には選挙権を与えていません。地方参政権などを外国人に与えているのは、世界でおよそ40カ国です。

日本での、これら外国人の権利への制限について、「差別では？」という意見を主張する人もいますが、今のところ、外国人参政権に反対する日本国民の意見が多く、外国人に国政への参政権は与えられていません。

「地方政治の参政権のみに限り、外国人にも与えるべきでは？」という主張をする意見もあり議論になっていますが、国政への外国人参政権への日本国民からの反対意見の大きさと同様に、地方参政権の外国人参政権にも反対する日本国民の意見が多く、外国人に地方政治の参政権は与えられていません。


「国民の義務である納税の義務を負っているのに、参政権は無いのはおかしいのでは？」という意見もありますが、「納税は参政権の根拠にならない。納税と参政権を結びつけると、低所得者は参政権が無くなることになり、おかしい。」という反対意見もあります。


日本では、日本国外に住んでいる日本人にも本国の選挙に投票できる参政権があります。

ですが、韓国では韓国以外に住んでいる在外の韓国人については2012年まで選挙権がありませんでした。
また、北朝鮮にいたっては政治が独裁政治であり、そもそも民主主義ではありません。


=== EUでの外国人参政権 ===
ちなみに世界の多くの国では、外国人には選挙権を与えていません。地方参政権などを外国人に与えているのは、世界でおよそ40カ国です。

ヨーロッパでは、EUの加盟国の多くが、加盟国の外国人に対してのみ、地方参政権にかぎり参政権を与えています。国政への原則として参政権は与えていません。

フランス、ドイツ、イタリアでは、EU加盟国以外の外国人には参政権はありません。

== 検定教科書での記述の傾向 ==
=== 教科書の記述と、現行の法律とのちがい ===
日本国での学校の検定教科書では、多くの教科書会社では、在日韓国人・朝鮮人への蔑視にもとづく差別があるとしている。その差別の具体例として、就職や結婚での差別がある、と記述している。


いっぽう、日本国籍を持つ障害者などは、企業がなるべく雇用に努める法的な義務があり、一定以上の規模の企業は、規模に応じて雇用する障害者を雇用する義務があり、従わないと罰金を払う必要がある。


なお、日本の学校教科書では、いわゆる「えた」・「ひにん」などの被差別部落の問題を取り上げたあとに、在日外国人の「差別」問題を記述に取り上げたものが多い。

被差別部落の問題については、日本国の国会などで、これらの差別の解消にもとづく答申として「同和対策審議会」の「答申」が1965年に出されたり、差別の解消をめざすための法律の「同和対策 特別措置法」などが存在している。日韓基本条約などの条約はあるし、在日韓国人・朝鮮人の在留資格について定めた法律「日本国との平和条約に基づき日本の国籍を離脱した者等の出入国管理に関する特例法」などもある。

[[Category:中学校公民|さいにちかいこくしんのけんりにかんするこくないもんたいときろん]]</text>
      <sha1>rl75gsvfrfee64s5eipb6dafpszhmvi</sha1>
    </revision>
  </page>
  <page>
    <title>学習方法/高校社会科全般</title>
    <ns>0</ns>
    <id>19369</id>
    <revision>
      <id>205783</id>
      <parentid>138038</parentid>
      <timestamp>2022-07-24T10:44:44Z</timestamp>
      <contributor>
        <username>Nermer314</username>
        <id>62933</id>
      </contributor>
      <minor />
      <comment>/* 国立志望の場合、二次試験で地歴公民が不要な場合も多い */</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="60630" xml:space="preserve">== 高校生用の教材を使おう。中学用の教材は、ほぼ不要。 ==
高校生が使うべきは、高校生用の教材（参考書・検定教科書・問題集など）である。

中学用の教材は、高校生が使う必要性は低い。なぜなら、高校の社会科は情報量が段違いに多いからである。

中学生用の難関高校入試むけの参考書よりも、高校の検定教科書の「日本史B」や「世界史B」などのほうが、はるかに高度かつ膨大な内容である。

:※ なお、「世界史A」「世界史B」などのように、「A」または「B」の違いがある科目では、A科目はたとえば歴史科目なら近現代史など一部の事項を扱っていたりして、いっぽうB科目の歴史科目は、古代から現代までの通史（つうし）を扱っている。そして、Aのほうが易しい。地理でも同様に、A科目のほうが易しい。しかし、入試で要求されるのは、B科目である。

:もし自分で地歴公民の教科書を買う場合、その科目に「A」と「B」の違いがあれば、Bのほうを買うのが良い。Bの教科書に、Aの内容も含まれている。なので、Bを買えば、もはやAを買うのは不要である。

さて、高校の教科書の内容が「高度」といっても、しょせんは高校生が読んでも分かる内容である。高校生用の検定教科書や、あるいは高校生用の標準的な参考書なら、ふつうの高校生が読んでも大方の意味はつかめるはずである。暗記できるかどうかは別として・・・。


これがもし、社会科でなくて数学とかだったら、中学数学の苦手な場合は、どんなに高校数学の計算をしたくても計算自体が苦手で出来ないならば、しかたなく中学用の教材で軽く復習する必要などもあるのかもしれない。

しかし、私たちが、いま学ぶのは社会科である。とりあえず、私達は日本語が標準的に読み書きできているし、日本や世界の歴史や世界の地理や経済についても、大体は中学で習っているはずである。（ただし、あなたが不良とか不登校とかでサボってなければ、であるが。）

ならば、ふつうの高校生なら、べつに中学用の教材にもどらなくても、高校用の教科書・参考書で勉強が始められるはずだ。


== いきなりワークブックを使うのは非効率 ==
高校レベルの学習では、ワークブックや問題集にいきなり取り組むのは、非効率です。

いきなりワークブックに取り掛かろうにも、地歴公民では、高校新入生では、ワークブックの問題ですら、まったく問題が解けないでしょう。

なので、まず先に、検定教科書や、やさしめの参考書（実質的にはセンター試験対策本）を、ある程度の量の単元を読み終えてから、その単元の問題練習に取り掛かりましょう。


== 『もういちど読む』シリーズは高校生の学習には不便 ==
* 山川出版の「もういちど読む山川日本史」などは、現在の大学入試の出題傾向とは違う可能性が生じる。

:'''もしセンター試験対策や一般入試対策などのために検定教科書の内容を確認したいなら、検定教科書そのものを注文して購入したほうが安全。''' （検定教科書の注文法については、本ページの後の節で説明する。）

山川出版じしんも、一般的な高校生が受験勉強として『もういちど学ぶ』シリーズを使うことは、あまり推奨していない。

　山川出版の「もういちど読む山川日本史」など「もういちど読む」シリーズは、現在の高校生の学習用には、あまり使えなさそうだ。読者層の想定が、すでに一度その科目を高校時代に習った経験のある大人にむけて書かれているので、未習の高校生には役立たない。高校生は、人生で初めてその科目を習う初学者であり、その科目をまだ習ってないので、高校生には予備知識の説明が不足しており、不便である。

また、どこからどこまでが高校で習う知識で、どこからが大人向けの追記事項なのかが不明確であるので、入試傾向の把握には使えない。一般の大人には、現代の高校社会科の教育についての情報は不要なので、高校教育内容についての説明は省略されているのだろう。

また、「もういちど読む」シリーズでは、科目によっては大人向けの時事解説などを追加している場合があり、現代の大学入試の傾向とは大いに違う科目もある。

さらにまた、昔の検定教科書をベースとしている場合がありうるので、やはり現代の大学入試の出題傾向とは違う可能性が生じてしまう。

なので、せっかく「もういちど読む」シリーズを買っても、結局、あらたに検定教科書を買いなおして大学入試への対応をする必要が生じてしまう。

すでに中学の社会科のカリキュラムからして、90年代と2010年代とでは、けっこう、ちがっている。中高とも現在のカリキュラムのほうが、昔よりも、内容が高度である。たとえば昔の「ゆとり教育」時代の高校1年〜2年の社会科のレベルは、ほぼ現在の中3レベルであろう（中学と高校では科目が違うので単純には比べられないが、昔は高校教科書で扱ってた入門的レベルの話題が、現在では多く中学社会科に降りている）。

ともかく、あくまで「もういちど読む」シリーズは、高校卒業してから10数年以上は経った大人で専門外の人が、高校時代の知識を活用して、その科目の基礎知識をアップデートするために書かれている。そのアップデートの到達目標も、一般向けの教養書レベルの知識獲得が目的であり、入試対策は目標ではない。

なお、『もういちど学ぶ』シリーズは、理科も社会科も数学も、専門外の社会人に向けて書かれた本である。

そもそも高校生向け・大学受験生向けに書かれてない教材を、高校生や受験生が受験勉強で使うのは、ヤメたほうがイイ。


== 検定教科書の購入法について ==
=== 買うべき教科書の選びかた ===
高校社会科の場合、教科書の取り扱い店で、教科書を注文できる場合がある。高校に入学して教科書を買う際、学校配布でなく、教科書の取扱店から購入する場合がある。その本屋で、検定教科書の注文が出来る場合がある。

なお、検定教科書は有料である。当然、一般の書籍を買うときに価格を払うのと同様に、教科書の購入にも価格を払う必要がある。


高校では、学年によっては、生徒が、まだ学校からは教科書をもらえない場合があり、そのような場合に検定教科書で自習したい場合は、注文する必要があるかもしれない。

とくに社会科では、科目によっては参考書の内容が膨大すぎる場合があるので、基礎を把握するために検定教科書も読みあわせると便利だろう。

ただし、教科書の注文は時間が掛かるし、高校生には難しいかもしれないので、無理に注文しろとは言わない。

とりあえず、このような注文という方法もあるということを紹介しておく。


学校で「日本史」や「世界史」を習っても、学校や学年によっては「日本史A」だったり「世界史A」だったりする場合がある。そのような場合に、「日本史B」とか「世界史B」とかの教科書が欲しい場合は、自分で購入するしかない。

「世界史A」などのA科目と、「世界史B」などのB科目とを、まちがえて注文しないように。

とりあえず、ふつうの高校生が受験勉強などで使う必要があるのは、B科目のほうである。つまり、「日本史B」「世界史B」のほうを受験勉強で使うのが普通である。

歴史科目のA科目は、近現代を中心にあつかっているし、本の厚さも薄い。B科目は、古代から近現代までを網羅している。とうぜん厚さは、B科目のほうが厚い。

なるべくB科目のほうを注文しておこう。大は小を兼ねる。

また、同じB科目でも同じ出版社から出ている教科書でも2通り以上のバージョンがあり、教科書が厚くて詳細な説明のバージョンと、教科書がやや薄めであり短期間で概要を把握するためのバージョンがある。どちらを買うべきかは目的にもよるが、とりあえず厚めで説明の細かいバージョンを買えばよい。

たとえば山川出版の世界史Bの場合、『詳説 世界史B』と『新世界史』と『高校世界史』とがあるが、もっとも説明の細かいバージョンが『詳説 世界史B』のはずである。世界史Bを初めて買う場合は、とりあえず、『詳説 世界史B』を買っておくと安全だ。大型書店などで山川の教科書が売られている場合に、その店で売っている教科書のバージョンも、たいてい『詳説 世界史B』など詳説シリーズのバージョンである。

なお、山川の世界史'''A'''の教科書で「'''要'''説 世界史」というのがあるので、混同しないように。「要」と「詳」の違いである。

このように、同じ1つの出版社からでも、少なくとも6種類ほどの検定教科書が出ている場合もある。どの教科書が一番詳しい教科書かが分かない場合、その教科書取り扱い店の、店の人などに質問すると、良いだろう。

=== 注文の方法、購入方法など ===
注文の方法などが、よく分からなければ、どこの地区でも、小学生～高校生が検定教科書を紛失したときなどに教科書を注文できる 教科書取り扱い書店 があるはずなので、その書店の人に注文方法などを質問しよう。

もちろん、検定教科書の価格は有料である。当然、一般の書籍を買うときに価格を払うのと同様に、教科書の購入にも価格を払う必要がある。

注文による取り寄せのため、注文してから入荷されるまでに時間が掛かる。出版社側の在庫切れなどの場合もあり、注文を取り消すことになる必要が生じる場合もある。

この節では、これらの教科書取り扱い店などで自分で検定教科書を購入する方法について述べる。（そのような購入も法的に可能である。）

* 教科書の購入は、各学校の教科書取次店や、教科書取扱店で注文できるのが、普通である。ふつうは、どの地区にも、近くの中学・高校の教科書を取り扱ってる書店がある。

* ただし、一般の書店では検定教科書は取り扱っていないので注意。

学校の教科書を紛失した場合など、教科書の取扱店の本屋で注文をして、教科書を購入する場合がある。その本屋で、検定教科書の注文が出来る場合がある。

高校に入学して教科書を買う際、学校配布でなく、教科書の取扱店から購入する場合がある。その本屋で、検定教科書の注文が出来る場合がある。


また、東京圏であれば神保町三省堂書店や、または第一教科書（JR総武線の大久保駅南口にある）などで購入や注文が、おこなえるはずである。（2014年に記述。）

=== 外部リンク ===
* [http://www.aomoritosyo.co.jp/kh07_kyokasho/kounyu/tokuyaku.html/ 全国教科書取扱特約店一覧（青森県図書教育用品）]全国の教科書販売店の一覧
* [http://www.daiichikyokasho.co.jp/ 第一教科書]教科書直売店
* [http://www.text-kyoukyuu.or.jp/ 社団法人　全国教科書供給協会]教科書の価格、教科書発行者一覧を載せる

== 偉人伝・伝記は入試に出ない ==
小学校から高校までで習う歴史は通史（つうし）という。これは歴史を古代から現代まで出来事順に記述したものである。歴史上の人物の人生は通史では重視されない。そのため、偉人伝で扱われるような人物の人生については、まず大学入試に出ない。せいぜい、ナポレオンや坂本龍馬など、検定教科書にも出る人物について、検定教科書や参考書などにも書かれている内容が、一般入試で出る可能性も少しはあるくらいだ。

「日本史」の場合は、やや詳しめの人物知識が入試に出る場合もありえる(特に創設者や関係者が検定教科書にも載っているような私大)が、検定教科書や参考書を読んだほうが、入試対策として有効である。

「世界史」では、登場人物が多く、あまり人物の詳細は出ないだろう。

「倫理」の場合、哲学史や哲学用語や主要な学説などの基礎が入試に出るが、哲学者の人生の詳細については入試に出ない。哲学者について出題される場合でも、「次の選択肢の中から、◯◯の学説を唱えた人物を選べ」的な出題をされる場合がほとんどである。なので、学説以外の人生については、せいぜいシュバイツァーとかマザーテレサのような検定教科書や参考書にも学説以外の社会活動の書いてある哲学者だけを、教科書レベルで把握しておけば、充分であろう。

「政治経済」でも、政治や経済の理論を年代や学派ごとに整理したものも学問分野として確立しているため、政治理論や経済理論を打ち立てた人物の名前が出ることもある。そして、「ホッブズの『リヴァイアサン』」のように、理論家とその著作が密接に結びついている場合もあるため、人物名も出るには出る。一方で、例えば、伊藤博文については、日本史の検定教科書に書いてある内容ですら「政治経済」の入試で直接問われることは稀である。これは、「政治経済」における大日本帝国憲法の単元では、伊藤博文の人生でなくて「大日本帝国憲法の特徴」を理解することが重視されているからだ。

現状では「現代社会」は「倫理」と「政治経済」をミックスして易しくしたものであるため、「倫理」「政治経済」の傾向とほぼ変わらない。


== 暗記方法 ==
=== 地歴公民は、暗記科目である。 ===
地理・日本史・世界史・政治経済・倫理の、どれも暗記科目である。

数学などと違い、入試での地歴公民は、用語などは覚えていないと、入試問題の解きようが無い。基本的に、入試における5教科の科目は、数学と物理以外は、ほぼ暗記科目である。しかし、センター試験などでは、用語を直接問う問題は、近年、減少傾向である。

=== 効率的な暗記のために、教科書を読むことが必要である。 ===
「地歴公民は暗記科目]といっても、やみくもに用語集などを丸暗記するのは非効率である。まずは教科書を何度か通読して読んでおく必要がある。標準レベル以上の教科書なら、少なくとも各科目の教科書を2回以上は読んで欲しい。（どの教科書が標準レベルか分からなければ、とりあえず（やや高レベルだが）山川出版の教科書を購入しておけば良い。教科書の選び方については、他の節で説明したので、ここでは説明を省略する。）

科目にもよるが、基本的には、教科書が重要である。「脱ゆとり教育」のこともあり、教科書の読み込みだけでも、そこそこ高い学力を養成できる。なお、参考書の中には、1990年代くらいの古い時代に初版の作られた参考書もあり、近年の入試傾向よりも詳しすぎる書籍もある。

=== 暗記は、年号でなく語句を中心に ===
しかし、暗記科目といっても、おぼえるべき内容は、語句などが中心である。けっして年号ではない。たとえ世界史や日本史などの歴史系科目であっても、じつは年号よりも語句のほうが入試での比重が高い。なぜなら、高校の社会科目であつかう年号は膨大すぎて、けっして覚えきれない。なので、年号を覚えきろうと思ってはいけない。

じっさいにセンター試験の過去問題集などを見ても、語句の意味を理解してるかどうかを要求する問題などが多い。センター試験では年号問題は少ない（ほぼ皆無）。

このため、年号暗記は、労力が大きいわりに、あまり大学入試で報われない。なので、暗記勉強は語句の暗記を中心にして行うこと。センター入試などの年代順を問う問題では、年号を暗記するよりも、おそらく、問題のパターンごと覚えてしまったほうが良いかもしれない。

そもそも日本史と世界史以外では、年代を問う問題は、基本的に出ない。なお、センター日本史では、年代順を問われやすい。その年代はだいたい20年単位ほどの近さの出来事が選択肢に並んでいるので、つまり年号の暗記は、せいぜい、その精度で良い。

（例外として、難関の私大の日本史だともっと細かい年号の順序が問われる場合もあるが、他の科目も勉強する時間も必要なので、本ページでは、これ以上は深入りしない。）

ただし日本史などの近現代史などで、1年単位で順序を問う問題もある。この場合は、解くのを諦めるか、もしくは、頑張って暗記しよう。「政治経済」科目でも、戦後史などで、1年単位で順序を問う問題もある。

中学入試・高校入試だと、年号暗記も、志望校によっては、やや重点的に勉強する場合もあったかもしれない。しかし、大学入試では、出題傾向が変わる。単純な年号暗記では解けない問題が、大学入試では増えてくる。

=== 語呂合わせの記憶法は高校社会科では非効率 ===
高校の社会科で扱う語句は膨大であり、たとえ語呂あわせの記憶をしようにも、その語呂を記憶すること自体に膨大な労力が掛かってしまうので、非効率である。

なので、まずは書き取りなどの反復練習や、あるいは理解によって覚えるという記憶法を優先して、勉強を行うべきである。

近年のマークシート試験の普及により、地歴公民では筆記試験を行う大学は減少してるが、しかし高校時代の地歴公民の普段の学習でマークシート試験を行うわけにもイカナイので、とりあえず書き取り練習などをすると良いだろう。


語呂合わせが非効率な理由は、もし小学・中学の社会科だったら語句が少なめに限られているので、語呂あわせが有効な場合もあったかもしれない。だが高校の社会科では事情が違う。高校の社会科では、ひとまず語呂合わせは封印すべきである。

なぜなら、語呂合わせは、せっかく学んでも、語呂自体を忘れたら無意味である。語呂合わせによる暗記法は、最終手段にすべきである。

わざわざ自分で語呂を生み出す必要性も少ない。歴史科目でも、わざわざ年号などを語呂合わせする必要も少ない。そもそも年号を直接的に問う問題自体が、大学入試での出題頻度が少ない。

== 参考書と問題集が必要である。 ==
=== 参考書はとりあえずセンター対策本を ===
地歴公民の理解を深める手っ取り早い方法は、教科書の他に、もう1冊、平易な参考書か、別の教科書出版社の教科書を読む方法である。一方、いきなり用語集や、「難関私大・国立大2次試験対策」用の受験参考書を読むのは、非効率な結果に終わるでしょう。

しかし、その「簡単な参考書」とやらを入手するのに、（地歴公民では）ちょっと手間が掛かる。結論からいうと、地歴公民で簡単な参考書を入手するには、'''「センター試験対策」などと銘打った参考書を買うことになります。'''

「センター試験対策」参考書は、書籍の外見は、分厚いかもしれませんが、単に字が大きめだったり、図が多いから厚いだけで、内容はわりと平易なので、安心してください。

「センター試験対策」本以外には、あまり、高校1年あたりでも理解して読めそうな入門レベルの参考書は、なかなか売っていない。数学の「数学1A」参考書などとは異なり、地歴公民では1～2年生などに合わせることが困難なのでしょう。文英堂シグマベストの地歴公民や、数研出版チャート式の歴史科目の参考書は、教科書よりも、かなりくわし目であり、おそらく一般的なレベルの大学入試では、そこまで暗記は要求されません。

:（「文英堂シグマベスト」シリーズは理系では平均的レベルとして評判がありますが、しかし地歴公民の「文英堂シグマベスト」シリーズのレベルは やや受験参考書レベルよりで難度が高いので、高校新入生や理系志望者はレベルを混同しないように気をつけましょう。）

:（なお一般に数研出版チャート式の『日本史』や『世界史』参考書などは、もっと難度が高く、難関大学受験向けレベルですので、高校新入生には不適切です。（なお、チャート式『政治経済』は絶版です。）

:このようなハイレベルの受験参考書でも、難関大の文系学部志望や、調べもの学習で辞書的に使う場合や、あるいは大学進学後の高校レベルの復習、卒業後の勉強・・・などには役立ちますので、書店では受験参考書も販売されています。しかし高校在学中には、受験参考書にペースを振り回されないように気をつける必要があります。

また、そもそも国立大学入試では、一部の学部を除いて、文系学部でも二次試験では地歴公民の試験を行わない。このためか私大入試でも、平均的なレベルの多くの私立大学の地歴公民の出題傾向も、センター試験の過去の出題傾向などにあわせている。難関私大を除けば、センターレベルを大幅に超えるような問題は、出題されづらいだろう。

これら非センター対策本の参考書をそのまま覚えようとすると、他教科や理系科目の学習時間を無視した膨大な量になっている場合も多いので、センター対策以外の受験参考書を学習ペースの目印にするのは危険な場合があります。


さて、検定教科書には練習問題などが無いので、ワークブックなどを使用する必要があります。しかしワークブックを使用する前に、まず、教科書や、平均レベル（実質的にはセンター対策本）の参考書で知識を増やす必要があります。なぜなら'''地歴公民では知識不足の状態だと、ワークブックの問題すら、解けません'''。なので、簡単な参考書でよいので、まず、これから学ぶ単元を読み終えてください。

そして、ワークブックなどを活用して、知識を確認して定着させてください。

ただし、入試には、ワークブック的な内容は、そのままは出題されません。そもそも入試では、語句の書きとり問題は、近年の大学入試では、採点の手間などのためか、なかなか出題されません（4択問題的な、選択肢を選ぶ問題のほうが、センターは当然、私大入試でも好まれます）。


=== 受験科目では、教科書は、出版社の異なる2冊以上を買うのが望ましい ===
:受験科目では、2冊以上を買うべき理由は、著者によって視点が異なるからである。また、入試での頻出事項も、複数冊を比べて、両方の参考書で共通する点を調べる事で、確認できる。メディアリテラシーなどの観点もある。（「新聞を読むときに、新聞社の異なる2誌以上を読み比べろ。」などという新聞の読み方と同様。）
:また、2冊の教科書で解説文を2倍読む事になるので、理解も単純計算で2倍になるので、用語などが記憶にも残りやすくなり暗記しやすくなる。


=== 教科書や参考書を読む際に、語句を書き取り練習しよう。 ===
教科書や参考書を読む際に、語句を書き取り練習しよう。

ただし、この時点では、おぼえきる事が目的では無い。内容を理解することが目的だ。単に読むだけよりも、少しの回数でも語句を書いたほうが、覚えやすいし理解しやすいし漢字などの勉強にもなるし、一石三鳥である。なので、あまり語句の書き取りに時間を掛けすぎてはならない。なので、1つの語句あたり、1回や2回ていどの書き取りで構わない。（また、センター入試では、漢字の書き取りは出題されない。）

書き取り練習の方法は、ルーズリーフなどの用紙および筆記用具を準備して、書き取り練習しよう。教科書本体や参考書本体には、書き込まない。ルーズリーフなどに、1つの語句あたり、1回や2回ていどの書き取りで構わない。いきなり覚えきろうと何十回も書くと、語句の量が多いので挫折する。参考書では、重要な語句は赤字や青字などの色字になってたり、あるいは太字になってたりするので、そのような書体の区別で語句が変別できる。

なので、いきなり分厚い参考書には手を出さないほうが良い。たとえば、山川出版の詳説研究シリーズの日本史や世界史は、とりあえず後回しにしよう。べつに山川出版を批判してるわけではなく、詳説研究シリーズの日本史や世界史は名著だと思う。しかし、高校1年～2年などの初心者や、あるいは理系志望には、詳説研究シリーズは向かない。

まずは、センター対策本とか文英堂とかチャート式とかの参考書を買っておこう。


英単語の書き取り練習と同じで、社会科の語句も、書かないと覚えられないのである。

やさしめの参考書の1冊目を読み終わったら、問題集をはじめよう。使い方は次のとおり。

=== 問題集も必要。 ===
:参考書だけでは、問題練習が不足している。参考書によっては、そもそも問題が参考書には掲載されていない場合もありうる。なので、問題集を別途、購入する必要がある。なお、問題練習の際、問題集には書き込みをしないのがノウハウである。問題集は、何度も繰り返して練習する必要がある。もし、問題集に書き込みしてしまうと、復習のときに使用できない。

問題集を買う際、1〜2年のころからセンター試験対策問題集またはセンター試験過去問を、あるていど使ってしまうのも、良いだろう。

後述するが、国公立大学を受験するさい、かならずセンター試験で5教科受験が必要になる。そして、もし理系を目指す場合、理学部などのいくつかの学科が存在が、国立大学に片寄っており、私立大学にその大学が少ない、という問題がある。

とはいえ、高校の定期試験では、用語の書き取りを要求する問題なども出る。「○○の□□のことを何と言うか。答えよ。」的な書き取り問題である。

なので、穴埋め問題などを中心に、高校1〜2年は練習しておくのも良いだろう。


さて、センター対策も1〜2年から勉強すると、結果的にセンター過去問ごと覚える事になる場合もあるが、それでも構わない。なぜなら、他大の入試などで、センター試験の過去問を真似た出題がされる場合もあるからだ。センターは建前上は、高校でならう基礎的な事の理解を要求しているという建前なので、他の大学でも出題しやすいのである。

また、採点の都合により、各大学ごとの試験でも、選択問題式またはマークシート式の出題をする大学も多いのである。

なのでセンター試験の文系科目は、過去問ごと、あるていどは覚えてしまえばいいのである。

センターにせよ、大学の一般受験にせよ、マークシート問題や選択問題などとして出題可能な問題のパターンは、あるていど限られており、なのでセンター過去問などを練習していると、有利な場合が多い。

「偏差値の高い学生」というのは、単に、入試の頻出事項を優先的に勉強してるだけのことである。入試の優等生は、多くの大学の入試を解けるので、さぞかし何でも知ってるように見えるが、じつは似たような入試問題がいくつもの大学で使い回しされているだけ、という場合もある。（べつに社会科に限らない。）

さて、センター過去問集を高校1〜2年で買った場合、高校3年にまたセンター過去問集を買い直す必要がある。

=== 記述問題について ===
各大学ごとの試験では、難関大の文系学部などで「文字数30文字位内で述べよ」のような記述問題が出される場合もあるので、記述対策もしておく必要もあるが、しかし、多くの大学では地歴公民の記述問題はなく、地歴公民での記述対策の優先順位は低い。

なぜなら、入試では採点の負担により、記述問題を要求する大学は少ない。また、一見すると記述問題は論理的思考力を要求してるかのように見えるが、じっさいには、細かい知識についての記述を要求すれば、その問題は実質的には単なる暗記問題である場合もありうる。このような記述問題の不完全さもあり、近年の入試では、記述問題は少ない。

このため、記述問題の対策は、ほとんどする必要がないのが、大学入試の地歴公民での現状である。

ともかく学習者としては、選択問題と、穴埋め問題と、記述問題の対策の優先順位は、

:センター的な選択問題　＞　穴埋め問題　＞＞　記述問題
であろう。（＞＞　という不等号は、「かなり大小の差がある」という意味。）


高校受験をしたばかりの高校1年生には（あるいは昭和生まれの大人などには）信じられないかもしれないが、近年の大学入試では採点の都合などにより、社会科の入試では、選択問題はけっこう多いのである。


さて、穴埋め対策も、私大対策や学校の定期試験対策では必要である。穴埋め対策では、問題集の答えを、実際に手で書けるか確かめてみる必要がある。ルーズリーフ用紙などでよいから用紙を用意して、そこに答えを書いてみる。

基本問題は、問題の答えが10秒ほど考えて分からなかったら、すぐに答えを見る。答えを知らないと解きようが無い問題が多い。

参考書で、まだ理解してない内容が問題集で出てくる場合もある。そういう場合、とりあえず、答えを見ておいて、覚えられるところだけで良いので、書き取りして覚えておこう。

簡単な問題集で良いので、さっさと問題集をひととおり終えよう。まだ、問題集の内容を覚えきれなくても良い。

こうすれば、ひととおり問題集を終わらしてあるので、テストや入試での、おおまかな出題傾向とかを既に掴んでいるはずだ。

参考書に戻って、解けなかった分野を重点的に、ふたたび読みなおそう。（すべてを読み直す必要は無い。べつに覚えきるまで読み直す必要も無い。）あるいは、新たな参考書を読んでもよい。そこらへんの手法は各自に任せる。　そして、新たに問題集を用意する。今度の問題集は、難度のやや高い問題集（たとえばセンター入試対応レベルなど）を用意し、ふたたび、問題集を解きにいこう。

やはり、まだ理解してないところが問題集に出るだろうが、ひとまず10秒くらい考えてから解けなかったら、答えにある解説を読んでおいて、覚えられるところは書き取り練習などをして覚えにいこう。


== 用語集を覚えるのは、参考書を読んだあと ==
用語集は後回し。用語集暗記よりも、まず問題集などに取り掛かるのが先。もちろん、用語集も時間があれば、参考書につづけて読むべきである。ただし、優先順位を間違えてはいけない。参考書を読んでない人は、用語集よりも先に、参考書を読むべきである。いきなり、用語集などで丸暗記しようとすると、暗記する項目が多すぎるうえ、知識の体系化もされていないので覚えづらく、まず挫折（ざせつ）するだろう。

参考書よりも先に用語集を読む行為が非効率な理由は、用語集は基礎知識を学ぶようには出来ていないことによる。いっぽう、参考書は、基礎知識を学ばせることを目的に編集されている。だから、参考書で基礎知識を学ぶ必要がある。用語集は、一通り参考書を読み終え、問題練習も簡単な問題集などの基礎問題を練習しおえた人が、用語の知識や出題頻度などを確認したりして、さらなる得点力の向上をめざすために用いる書籍である。用語集は、初学者向けではなく、中級者以上に向けている。

だから、「社会科のテストは暗記科目」というのを真に受けて、丸暗記するのは非効率である。

まずは教科書と参考書で基礎知識を学ぶのが先であり、つぎに初歩的な問題集やセンター過去問数年分などで理解を定着させるのが先であり、用語集での知識追加は後回しなのである。&quot;暗記&quot;は、学習の目標であり、手段では無い。まずは参考書を一通り読んで、重要単語などはノートなどに書き写して何回か反復練習しよう。問題集で基本問題くらいは10秒ほどでいいから考えながら問題練習をしよう。その上で、暗記勉強をするほうが良いだろう。

ただし、暗記しないと解きようが無い問題も多いのが事実である。

== 国立志望の場合、二次試験で地歴公民が不要な場合も多い ==
国立大学の志望の場合、二次試験で地歴公民では受験できない大学も、多くある。

多くの国立の文系学部の二次試験の入試では、「国語、数学、英語」の３科目が、入試科目になっている。

たとえ'''文系の学部の入試でも、地歴公民が二次試験の入試科目に入ってない場合も多い'''。

受験勉強の際には、センター試験対策までをすれば、ほとんどの大学の場合、十分である。

なお、理系学部の国立二次試験の典型的なパターンは、「数学、理科、英語」の３科目であるのが一般的なので、地歴公民は理系学部の二次試験では不要の場合がほとんどである。

== 理系志望や国立志望なら、地歴公民ではセンター対策を優先する ==
地歴・公民の大学入試対策では、センター試験対策を優先したほうが良い。教科書を1回読んで、参考書を1回読んだら、さっさとセンター試験の過去問練習も始めるべきだろう。

なぜなら、国立大学を受験する際、文系学科・理系学科志望にかかわらず、かならず5教科センター受験が必要になるからだ。

そして理科系の大学を目指す場合、国立大学に片寄っているため（特に理学部に顕著。理系の大学が少ないのは日本政府の失策であろう）、家庭の経済状況などによっては、理系を目指す場合は国立受験をせざるを得なくなる場合がある。

さて、地歴公民以外の国語・英語・数学・理科の勉強方法は、二次試験対策でもセンター対策をかねるが、しかし地歴公民は違う。

地歴公民では、センター独自の対策が必要な問題が多い。センター試験では、他教科と比べると、地歴公民の問題だけは、やたらと細かい知識を問う。そして、日本史、政治経済、地理、倫理のセンター試験では、その科目の出題範囲が世界史と比べて狭いぶん、受験生に点差をつけるため、'''引っかけ問題'''的な出題で、細かい知識を要求する出題が珍しくない。

そのため、文英堂シグマベストとかチャート式などの一般的な参考書の解説を何冊も読み込んでも、センターの地歴公民は十分に解けない。なぜなら、参考書は、理解させることを目的に書かれているが、センター地歴公民で要求されるものには、引っかけ問題に、引っ掛からないようにするノウハウもあるからだ。その一方で、「わかっていれば選択肢を見るだけで解けてしまう」ことが多い(そのせいで、「センター試験で歴史や地理、政治経済の正確な学力がはかれるのか?」という意見も多いのだが、そのことについてはここでは置く)。

引っ掛からないようにするには、あらかじめ、引っかけ問題のパターンを、過去問で練習しておけば良い。そのため、センター地歴公民を解けるようになるには、センター過去問に慣れる必要がある。解説付きのセンター過去問集を買って、何度も問題練習しなければならない。

基本対策は、「いつ」「どこで」「だれが」「何をした」ということをしっかりと整理しておくことである。たいていの引っかけはここのどこかで似たものを紛れ込ませている。過去問を自力で解いてから、不正解だったところや正解しても自信のないところは資料集や用語集と照らし合わせて、「どこでひっかかったのか」を確認しながら対策を進めるといいだろう。

こうした「作業」はどうしても時間がかかる。早くからセンター対策に取り組むべき理由はここにある。

センター対策の開始として重要なのは、とりあえずセンター試験の地歴公民の過去問を入手しないと、話にならない。

なお、'''予備校講師などの解説する「センター対策　世界史」などと銘打った参考書だけでは不十分'''であり（買っても良いが）、とにかく、'''まず先に、（実際にセンター出題された）センター過去問の問題集を入手し'''、そして過去問練習をし始める必要がある。

そして、分からない事が多い時代があれば、そこで初めて（もし必要があれば）「センター対策　世界史」「センター対策　地理」などと銘打った参考書を読むべきだろう。


とはいえ、1年の1学期からセンター対策ばかりをするのは、地歴公民では非効率であろう。そもそも、まだ自分が理系に向いてるのか文系に向いてるのかも不明であろう。もし文系志望に変わった場合、私大一般入試や国立二次試験では、地歴公民のいくつかの科目を筆記試験を受験しなければならない場合がある。なので、さすがに高校1年の1学期くらいのうちは、まだセンター対策に深入りしないほうがいいだろう。

なお、センター試験では、現状では（2017年）、書き取り問題が無い。　つまり、極端なことを言えば、もし理系志望で、地歴公民はセンターでしか受験では使用しない場合、地歴公民に書かれた語句については、まったく漢字で書けなくとも構わないのである。また、2017年の現状では、理系の学部の受験では、国立の二次試験では、地歴公民は出ないのが一般的である。 特に日本史では、漢字のかなり難しい用語も多く（「検非違使」（けびいし）とか「山県有朋」（やまがたありとも）とか）、それらの書き取り練習を省けるのは、受験生にとっては、とても重要である。世界史でも、中国史では、むずかしい漢字の用語が多い。センター受験だけでしか世界史を使わないなら、中国史の用語や中国人の人名などの漢字練習をしないで済む。

とはいえ、高校1年生〜2年生くらいのうちは、高校の校内の中間期末テストなども兼ねて、たとえ理系志望でも、授業で習った範囲の用語などは、なるべく漢字で書けるようにしておこう。高校の校内の中間期末テストでは、もし平仮名で答案を書いたり漢字を間違えたりすれば減点されるのが一般的であろう。

また、将来的には、入試制度が変わる可能性もありうるし、あるいは、将来的にいくつかの理系国立大学でも二次試験で地歴公民を出題する可能性もありうる。（もし仮に、理系大学が国立二次試験で地歴公民を出題したとしても、合法である。） もしアナタが浪人した場合など、もしかしたら、その間に各大学の入試制度が変更する場合もありうるので、なるべく、漢字の書き取り練習も、高校1〜2年のうちの余裕のある範囲内でよいので、漢字書き取りも練習したほうがいいだろう。

また、もし仮に、理系高校生が、中学校社会科で習う用語すら漢字で書けなかったり、あるいは地歴公民の基本用語すら漢字で書けなさすぎて、漢字能力のひどすぎる理系学生が続出するようだと、さすがに将来的に世論が変わって受験制度の見直しをされる可能性もありうる。もっとも、仮に世論が変わって、理系学生にも地歴公民の用語を漢字に書かせるように世論が主張しはじめたとしても、さらにセンター試験関係の法律などが変わるまでには、10年ちかい年月が掛かるだろうから、現時点の高校生は気にする必要は無いのだが。しかし、だからといって、わざわざ漢字能力を下げる必要もあるまい。


== センターだけでしか地歴公民を使わない場合 ==
センターだけでしか地歴公民を使わない場合、もしかしたら用語集すら、もう不要かもしれない。用語集を読む時間も、足りないだろう。実際にセンター過去問を解いてみるほうが大切である。

なお、山川出版社の用語集での各用語の重要度は、検定教科書での掲載回数であり、つまり、'''けっして入試の出題回数ではない。'''

まして、けっしてセンター試験だけに、用語集は合わせてくれない。

なので、'''実際にセンター過去問を購入して、アナタが自分の目で、いろいろと近年のセンター入試の実情を確認する必要がある。
'''

早い話、高校3年になったら、すでに習った地理や日本史・世界史などでは、教科書を何度も読みかえしたりするよりも、1度通読したら、とりあえずセンター過去問を練習したほうがいいかもしれない。（たいていの高校で、2年のおわりまでに地理・日本史・世界史を習う。高校3年で政治経済を習う。）

入試範囲の内容をひととおり教育してくれる検定教科書は、それはそれで入門書としては便利なので、1度は通読しておこう。

もちろん、こういった勉強法では、けっして、私大文系や国立文系二次などの地歴公民の論述問題は解けないだろう。しかし、そんな論述対策の勉強なんて、文系学部を志望する受験生に任せよう。もし理系志望の受験生なら、歴史の論述を勉強する必要は無いだろう。

「自分は地歴公民の勉強をサボってるのでは・・・」と罪悪感を感じる理系高校生もいるかもしれないので、次のように読者にアドバイスしておく。

たとい、一般的な高校受験生が、難関の私立高校受験で地歴公民の論述問題を解けなくっても、公立高校入試などの普通の穴埋め問題などが解けて高得点を出せれば、その中学生はきちんと勉強しているように、たとい理系志望の大学受験生が地歴公民の論述をできなくたって、もしもセンター過去問をそこそこ解ければ、理系志望のその受験生は、きちんと勉強できているのである。

== 理系志望のセンター地歴公民の科目決め ==
理系志望の場合、センター地歴公民の受験科目は、「地理」・「政治経済・倫理」・「世界史」のどれかにしておくのが安全であろう。

一見すると、「政治経済」は計算的な要素もあるので理系志望にとってラクそうに見えるが、同じように考える競争相手も多く、思ったほどラクではない。また、「倫理」をいしょに勉強する必要があり、これはほぼ暗記科目である。

世界史は、一見すると暗記が多そうだが、センターでは、範囲の広いぶん、やや易しめの問題がでる場合もある。

一般的な高校では、政治経済を習うのが高校3年からなので、高校2年までは、とりあえず世界史も勉強しておこう。もしかしたら、世界史で受験したほうが有利かもしれない場合がある。


また、「日本史」は、範囲が世界史よりも狭いぶん、センター入試では細かい知識を要求してくる。なので、よほど日本史に自信のないかぎり、理系志望なら、日本史はあまりセンター受験しないほうがいいかもしれない。

しかも「日本史」の場合、中学卒業までに習う「歴史」科目の内容がほとんど「日本史」的な内容であるためか、高校の1〜2年あたりで受験科目を日本史に決定する者も、私大文系志望の高校生などには多く、そのため、高校の早い段階から日本史ばかりを勉強して、日本史による1科目入試や、日本史と英語などの2科目入試などの少数科目入試での入試突破を狙ってるという者も多いのである。

== ニュース・時事の関連 ==
=== 結論 ===
結論から言うと、時事問題はあまり入試にでない。もし読者がどうしても入試対策として時事知識が必要なら、書店の参考書コーナーで大学受験用の時事参考書が販売されているだろうから、それを買うと良いだろうし、さらに中学受験用の時事参考書が販売されていれば、それも買うのが良いかもしれない。

理由は、以下の節のとおり。

=== テレビのニュース番組や新聞に、時間を掛けすぎないように ===
「もっとニュースとか新聞とかを見て政治とか経済を勉強しろ」と言う大人もいるかもしれないが、テレビのニュースも新聞も、けっして高校生の学習用には作られていない。そのため、ニュースなどを漫然と見てもあまり勉強にはならない。

もちろん、ニュースの視聴や新聞を読むことなどが悪いことではない。現在の諸問題の根本には地歴・公民で習っていることが少なくないからだ。が、あまり時間を掛けすぎないようにするべきである。これらマスメディアを読み解く分析力は、高校社会科の学習の目的の一つに過ぎず、けっして社会科の学習手段では無い。高校社会科の学習手段は、あくまで参考書を読み、問題練習などをするのが原則である。

とはいえ、入試に時事問題が出る場合もあるので、まったくマスメディアの報道を無視するわけにもいかない。しかし時事問題の対策なら、科目「現代社会」の参考書に書かれてる程度の時事の勉強で妥当だろう。あまりにも最近の出来事にはまだ学者たちの分析が終わっておらず、一つの「正解」を決めることが難しいことが理由だ。そして、入試日に近すぎる時事問題は、入試問題の作成が終わってるので出ない。

=== 小論文じたいが、あまり入試に出ない ===
国語の小論文などで、昨今の時事についての意見を書かせる問題もありえるが、そもそも小論文を出題する大学は、意外と少ない。志望先の学校や学科によっては、まったく小論文を出さないこともある。だから、小論文が出されるかどうか、小論文で時事問題が聞かれることがあるかを過去問に沿ってチェックしておこう。

必要であったとしても、『現代用語の基礎知識』『イミダス』のような、時事を解説した本を読んでいる時間は高校生には無い。これらの本を読むと、参考書や問題集での勉強時間が足りなくなるだろう。これらは大学生や社会人がレポートを書いたり発表をしたりするときに参考にする本だ。

時事対策が必要なら、受験対策用に書かれた時事問題集を書店で探して買って読むと良い。特にオススメなのは中学受験用の時事問題解説書だ。これらは時事問題で必要なことを社会科の問題に沿うような形で丁寧に解説している。小学生用だと思うかもしれないが、あまり気にする必要がない。むしろ、大人向けの時事解説書よりも、教育的な記述が期待できる。また、近年の中学入試は大学入試を意識したものが多く、小学生用に「翻訳」されているだけで、その中身は大学受験に近い場合も珍しくない。そのため、中学受験の時事問題集をそのまま、大学入試対策に利用できるのである。

=== 犯罪事件は時事問題や現代史には出ない ===
犯罪事件はまず入試には出ない。理由としては以下のことがあげられる。

# 事件関係者が存命していることが多く、彼らのプライバシーを保護するため。
# [[w:推定無罪|推定無罪]]の原則などから、裁判が終わるまでは「正解」が決められない。さらに、判決が出ても[[w:再審|再審]]によって、「正解」が「不正解」になる可能性がある。
# 社会科で習う事項とからめにくい。

ただし、連合赤軍（れんごう せきぐん）の浅間山荘（あさま さんそう）事件のように、比較的古く、教科書にも載っている項目(安保闘争)と関連づけられる事件ならば、出る可能性はある。とはいえ、仮に入試に出たとしても、あまり詳しくは事件の詳細を覚える必要はない。犯罪事件と歴史・政治経済用語との関係を押さえるべきだろう。

また、オウム真理教による地下鉄サリン事件は、中学高校の歴史教科書などで、戦後日本史の一部として記載されている。

また、戦後の日本政治の疑獄（ぎごく）事件だが、ロッキード事件やリクルート事件、佐川急便事件などが、高校社会科の範囲内である。

=== 特定企業の経済ニュースも入試に出ない ===
たとえば新日鉄と住友金属が合併して2012年に新日鉄住金になった、2005年に旧ライブドアがニッポン放送に敵対的買収をしかけたなどの経済問題も、入試にはまず出ない。仮に出たとしても、企業名を答えさせるのではなく、「合併」とか「買収」「公開買い付け」「TOB」などの用語を答えさせるだろう。地理や政治経済の入試で、大企業の立地をいくつか知っていると、工業統計などについての問題が解きやすくなるかもしれないが、近年の動向までを知る必要はない。

なぜなら、入試で企業名を質問するのは、特定の企業の宣伝になりかねないからだ。そして、半導体や家電やIT業界のように、業界の変化も速いものは分析が追い付かず、一つの「正解」を決めるのが困難だというのもある。

ただし、元・国鉄のJRや、元・電信電話公社のNTT、元・専売公社のJTは、中曽根政権の行財政改革の結果として、検定教科書で紹介されている。

=== 政治ニュースも出づらい ===
特定企業の経済ニュースが入試に出づらいのと同様に、特定の政治家のニュースや近年制定された法律、現在の内閣の政策も出づらい。たとえば2015年に科目「政治経済」などの検定教科書を見たところ、「アベノミクス」という用語についてすら書いていない（したがってリフレ政策についても書いていない）。2012年の衆院選で自民党が与党に戻ったことまでしか紹介していない。

これも、しばらく年月が経過して評価が定着してからでなければ、「正解」を決められないためである。政治ニュースも正解/不正解を簡単に決められる客観的な事実、もしくは政治用語と関連付けられるようなものでない限り出題されにくい。

=== 国語科目「現代文」の評論文も勉強すると良いだろう ===
国語科目の現代文の教科書で、近年の話題をあつかった評論文も、いくつか掲載されている。

評論の作者のいう主張を、けっして鵜呑み（うのみ）にするわけにはいかないが、しかし、教科書会社が教科書掲載前にある程度は下調べをしており、高校生に読ませても問題のない内容を抜粋して紹介しているので、全体的に質が高い評論なので、社会科の時事の参考にもなる。

しかも好都合なことに、もし運わるく、社会科の入試では国語「現代文」に書かれていた知識・理論が出題されなくても、国語科目の入試のほうで関連する文章が出題される可能性が高いので、高校生には、とても好都合である。

現代文Bの教科書や教科書ガイドなどを購入しておくと、時事問題を学ぶときの参考になるだろう。


== 教科書ガイドは基本的に使わない ==
いちおう、地歴公民の科目にも、教科書ガイドが存在します。

しかし、普通の受験勉強では、まず教科書ガイドを使うことは無いでしょう。

書店などにある高校生向けの勉強法の書籍をみても、そもそも高校の地歴公民の学習法では、教科書ガイドの存在すら意識されずに、存在が忘れられているほどです。

小中学校では、教科書ガイドの位置付けは、ちょっとしたレベル高めの教材のような感じでしたが、しかし高校では事情が違います。高校では、教科書ガイドは文字どおり、教科書を読んでよく分からなかった人のためのガイドでしかないので、なので高校の教科書ガイドはレベル高めの教材'''ではない'''のです。


高校の教科書ガイドの使い道は、せいぜい国語と英語で、著作権などの問題で、教科書であつかってる文芸作品などの著作物が市販の参考書では著作権法のために紹介困難なので教科書ガイドで補うような使い方をのぞくと、まず高校の学習では教科書ガイドは使わないです。文系科目ですら、地歴公民では、教科書ガイドは基本的に不要です。


せいぜい、私大の指定校推薦をもらうために高校の定期テストで確実に高得点をとる場合に、もし自校の教師が教科書ガイドを作問の参考にしている場合にだけ、ガイド類が必要になるかもしれないくらいでしょうか。しかし、果たして、指定校推薦をもらえるような偏差値の高そうな高校で、教科書ガイドばかりを定期試験の作問の参考にするかというと、可能性はやや低そうです。

むしろ、定期テスト対策の教材を書店で買うなら、ワークブック類などのほうが、定期テスト対策としては確実でしょう。

もしセンター試験の出題傾向を知りたいなら、教科書ガイドではなく、センター過去問そのものを購入したほうが早いです。

同様に、もし他校で使ってる検定教科書の内容を把握したいなら（高校の範囲の把握のため）、その検定教科書そのものを教科書の取扱い店で注文して購入するほうが早いです。


なので、もし地歴公民の勉強法の評論において評論家などで、地歴公民で教科書ガイドをつかう勉強法を提唱する受験評論家などがいたら、その人は、単に間違った勉強法を主張しているか、あるいは、まだ世間の知らない革新的な勉強法を発見したかのどちらかですので、どちらにせよ鵜呑み（うのみ）にしないように気をつける必要があります。</text>
      <sha1>dodmjzn0u4yybj5ghkkw2k1t3uyl9ok</sha1>
    </revision>
  </page>
  <page>
    <title>中学校社会 歴史/日露戦争</title>
    <ns>0</ns>
    <id>19396</id>
    <revision>
      <id>205721</id>
      <parentid>197081</parentid>
      <timestamp>2022-07-23T13:05:30Z</timestamp>
      <contributor>
        <username>Nermer314</username>
        <id>62933</id>
      </contributor>
      <comment>/* 日露戦争 */</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="18318" xml:space="preserve">== ロシアの南下政策と日英同盟 ==
1899年（明治32年）の義和団の事件のあとも、ロシアは兵力をひかず、ロシア軍は満州にいつづけた。そして、朝鮮半島や清に勢力をひろげようとする南下政策（なんか せいさく）をロシアは目指した。

ロシアは、冬でも凍らない港が、軍事上の理由で必要だった。このような冬でも凍らない港のことを、不凍港（ふとうこう）と言う。なので、ロシアは、領土を南方に拡大したかった。

いっぽう、中国大陸に利権を持つイギリスにとっては、ロシアの南下政策が不都合だった。さらに当時のロシアは、ロシア国内で東西に長いシベリア鉄道（シベリアてつどう）を建設していた。もしシベリア鉄道が完成すると、軍隊の兵士や軍事物資も、すばやく送れるようになるので、イギリスにとっては、ロシアはとても危険な国だった。

そこでイギリスは、ロシアの南下政策に対抗するため、日本とイギリスとのあいだでの同盟を1902年に結んだ。この日本とイギリスの同盟を、&lt;big&gt;'''日英同盟'''&lt;/big&gt;（にちえい どうめい、英語: Anglo-Japanese Alliance　アングロ-ジャパニーズ・アライアンス）と言う。


*日英同盟にいたるまでの経緯

遼東半島（リャオトンはんとう、りょうとうはんとう）にあった旅順（りょじゅん、リュイシュン）では、ロシアが軍艦の基地を増設していた。

'''義和団事件'''の鎮圧の名目で、ロシアは満洲を占領した。義和団の乱の収束後も、ロシアは満州から撤兵しなかった（※ 「義和団事件」については、[[中学校社会 歴史/日清戦争から日露戦争までのあいだ]] ）。

日本・イギリス・アメリカの３カ国がロシアに抗議（こうぎ）して、ロシアは兵を引くことを約束した。だが、じっさいにはロシアは兵をひかずに居続けた。それどころか、ロシアは占領軍の増強をした。

ロシアの強硬な方針に、イギリスは危機感を感じた。そしてイギリスは、日本と同盟をした。これが日英同盟である。

ロシアの勢力の拡大を恐れ、日本の政府は戦争を警戒していった。いっぽうのロシアの政府も、大国であるロシアとすれば小国にすぎない日本を恐れる必要はなく、なので日本との戦争もかまわないという強硬な姿勢をロシアは強めていった。

== 日露戦争 ==
日本はロシアとの戦争をふせぐため、外交で解決しようとした。日本の案では、ロシアが満州を支配することを認めるかわりに、日本が朝鮮を支配することを認めさせるという案をロシアに提出した。（※ 教育出版および清水書院の検定教科書に、このことの記述あり。）

しかし、ロシアがこの案を拒否し、交渉はまとまらず決裂し、1904年に、ついに日本はロシアとの戦争の開戦にふみきった。

ロシアの満州領有に反対するイギリスとアメリカは、日本の戦費の調達に協力し、日本を経済的に支援した。（※ 中学の範囲。東京書籍の教科書に記述あり。）

このころ、日本銀行副総裁（ふくそうさい）の'''高橋是清'''（たかはし これきよ）が、外債（「がいさい」、外国からの借金のこと）の調達のため、イギリスやアメリカを訪問して、イギリスやアメリカの銀行家や資本家からの信用を得て、日本公債を発行し、戦費調達に成功した。

このように、日本は日露戦争のために多額の借金をした。


日露戦争の戦場になった場所は、朝鮮半島の周辺の海域と、満州の陸上および海域であった。

陸地での戦場では、旅順（りょじゅん、リュイシュン）や奉天（ほうてん、フォンティエン）での戦いで、日本は苦戦のすえ、ロシアに勝った。旅順の攻略では乃木希典（のぎ まれすけ）が日本軍をひきいた。奉天の戦いでは大山巌（おおやま いわお）が日本軍をひきいた。

[[ファイル:Tsushima battle map-ja.svg|thumb|300px|right|ロシア艦隊は対馬近海で連合艦隊と遭遇し、日本海南西部で撃破された。]]
日本海海戦では、海軍中将（ちゅうじょう）の'''東郷平八郎'''（とうごう へいはちろう）ひきいる連合艦隊が、ロシアの'''バルチック艦隊'''を全滅させた。

勝敗の結果だけを見ると日本の大勝のように見えるが、日本は大きく戦力を消耗しており、また、軍事費を使いきっていた。日本は、戦争の続行がむずかしかった。


いっぽうのロシアでも政府に反対する革命の動きがおきはじめ、ロシア政府は戦争をつづけることが、むずかしくなった。


そこで日本は状況が日本に有利なうちに講和をしようと考え、アメリカにロシアとの講和の仲立ちをしてもらって、講和条約である &lt;big&gt;'''ポーツマス条約'''&lt;/big&gt; (英語: Portsmouth Treaty) が結ばれ、日露戦争は終結した。

=== 講和 ===
[[ファイル:Jutaro Komura.jpg|thumb|200px|小村寿太郎（こむら じゅたろう）]]
アメリカ大統領の&lt;big&gt;セオドア＝ローズベルト&lt;/big&gt;(Roosevelt)が講和の仲立ちになり、日本の代表は外相（がいしょう、意味：外交の大臣のこと）の&lt;big&gt;'''小村寿太郎'''&lt;/big&gt;（こむら じゅたろう）であった。ロシアの代表は&lt;big&gt;ヴィッテ&lt;/big&gt;(Витте)である。

:条約の結果、日本は朝鮮での優越権を認められた。 

:日本は、南満州の長春（ちょうしゅん、チャンチュン）以南の鉄道の利権を得た。 
:日本は、ロシアから樺太の北緯50度以南（ほぼ南半分）の領土を、日本へゆずらせた。 
:日本は、ロシアから、'''旅順'''および'''大連'''（だいれん）をふくむ遼東（リャオトン）半島の南端部の'''租借権'''（そしゃくけん）を、日本へ譲らせた。 
:日本は漁業権を獲得した。沿海州およびカムチャッカ半島の沿岸での漁業権を日本が獲得。

日本は講和を急いだため、賠償金（ばいしょうきん）をとらなかった。このことが国民の反発を呼び、東京の日比谷（ひびや）では焼き討ち事件が起きた。新聞社や警察の交番などが焼き討ちされた。（日比谷焼き討ち事件）　国民からすれば、戦争で多くの負担をしたにもかかわらず、賠償金をとれないことを不満に感じたのであった。

:（※ 高校の範囲:）このとき日本が獲得した大連が、のちの日本の満州経営での拠点になる。後述の満鉄株式会社の本社も大連にあった。（第一学習社『日本史A』の見解）

=== 戦後 ===
満州には、満州経営のため、政府により半官半民の企業の'''南満州鉄道株式会社'''（みなみまんしゅう てつどう かぶしきがいしゃ）
（ 略称： '''満鉄'''（まんてつ） ）が設立された。　
また、満鉄の鉄道の警備などのため、満州に日本軍が置かれた。

なお、この満州鉄道を警備している日本軍は、のちの1919年に「関東軍」（かんとうぐん）と言い改められる。中国の山海関（さんかいかん）より東の位置を「関東」といい、その地域を守備していたので、関東軍（かんとうぐん）と言い改められる。

この戦争の交渉の結果、日本は満州に権益を得ることになった。のちの第二次世界対戦のときに日本軍が満州に滞在している理由は、おおまかな理由は、元をただせば、この日露戦争で得た権益を防衛するために派兵されたからである。

さて、1907年には &lt;big&gt;日露協約&lt;/big&gt;（にちろ きょうやく） で、日本とロシアとの、満州での勢力範囲が決められた。

この満州への日本による権益獲得では、アメリカが日露戦争では資金面などで日本に協力したにも関わらず、ほぼ日本が満州の権益を独占することになり、アメリカは満州に権益を獲得できなかった。アメリカなどは、満州の事業の門戸解放を日本に要求したが、日本は要求をこばんだ。こうしてアメリカの日本への不満が高まり、のちにアメリカと日本とが対立していく原因の一つともなったとも考えられる。

=== 戦前の世論 ===
==== 非戦論 ====
日露戦争の前、開戦を、多くの国民が支持した。だが、開戦に反対する意見もあった。
非戦論（ひせんろん）をとなえた人をあげれば、キリスト教徒の'''内村鑑三'''（うちむら かんぞう）や、社会主義者の幸徳秋水（こうとく しゅうすい）が有名である。


[[ファイル:Akiko Yosano younger.jpg|thumb|200px|与謝野晶子（よさの あきこ）]]
また、歌人の&lt;big&gt;'''与謝野晶子'''&lt;/big&gt;（よさの あきこ）は、戦場にいる弟を思いやる詩を書き、「君（きみ） 死（し）にたまふ（たもう）こと なかれ」という詩を書いた。

&lt;div style=&quot;border:1px solid #000000;&quot;&gt;
　'''君死にたまふことなかれ'''（抜粋）

:    あゝ をとうとよ 君を泣く 
:    君 死にたもふこと なかれ 
:    末（すえ）に 生まれし 君なれば 
:    親の なさけは まさりしも 
:    親は 刃(やいば)を にぎらせて 
:    人を 殺せと をしえしや 
:    人を 殺して 死ねよとて 
:    二十四までを そだてしや 

::雑誌『明星』（みょうじょう）、明治37年(1904年)9月号『恋衣』（晶子第四歌集）所収。
&lt;/div&gt;


与謝野晶子の詩は、当時の日本国民の多くから、反戦の気持ちを遠回しにうたった詩として、うけとめられた。

なお、現代では、与謝野晶子を反戦詩人としてあつかう説をとなえる学者や評論家がいるが、のちの第一次世界大戦や第二次世界大戦のころには、日本および戦争を支持する詩も書いていることもあり、はたして与謝野晶子が日露戦争に反戦であったかどうかについては、はっきりとした証拠がない。


* 内村鑑三の戦争廃止論
&lt;div style=&quot;border:1px solid #000000;&quot;&gt;
::内村鑑三の戦争廃止論

:余（よ）は日露非開戦論者であるばかりでない、戦争絶対的廃止論者である。・・・（中略）・・・戦争の利益は強盗の利益である。・・・・・・近くはその実例を日清戦争において見ることができる。二億の富と一万の生命を消費して日本国がこの戦争より得し（えし）ものは何であるか。・・・その目的たりし朝鮮の独立は・・・弱められ、支那（「しな」＝中国のこと）分割の端緒（たんしょ）は開かれ、日本国民の分担は非常に増加され、・・・東洋全体を危殆（きたい）の地位にまで持ちきったではないか。

::（『万朝報』（よろずちょうほう）1903年6月30日、抜粋。）
&lt;/div&gt;

現代語訳

私は日露戦争の非開戦論者であるばかりでなく、戦争の絶対廃止論者である。・・・（中略）・・・戦争の利益は強盗の利益である。・・・・・・近くはその実例を日清戦争において見ることができる。二億の富と一万の生命を消費して日本国がこの戦争より得たものは何であるか。・・・その目的だった朝鮮の独立は弱められ、中国の分割が始まり、日本国民の負担はとても増加し、・・・東洋全体が危険におちいったではないか。

（以上、現代語訳）


内村鑑三のこの反戦論は、当時の世論である主戦論に対抗したものである。

==== 七博士の主戦論 ====
当時の主戦論の例としては、東京帝国大学の七人の大学教授の主戦論が有名である。

この七博士の主戦論の口語訳を紹介しよう。（※ 原文は口調が難しいので、省略。）

*口語訳（要約）
&lt;div style=&quot;border:1px solid #000000;&quot;&gt;
::七博士の主戦論

:ロシアは朝鮮に問題を起こそうとしている。そうする理由は、満州はすでにロシアの勢力範囲にあると（ロシアが）見なしているからだ。

:したがって極東のこの問題を保全するのは、満州を保全することにかかっており、これ（＝戦争のこと）を決断しなければならない。

::（『東京朝日新聞』1963年6月24日、抜粋および要約）
&lt;/div&gt;

== 条約改正 ==
*日清戦争の前後
[[ファイル:Mutsu Munemitsu.jpg|thumb|150px|陸奥宗光（むつ むねみつ）]]
日清戦争の直前の1894年に、イギリスとのあいだで、外務大臣の陸奥宗光（むつ むねみつ）の交渉により、治外法権をなくすことに成功。この治外法権の廃止（はいし）は、日本がイギリスと結んだ、 日英通商航海条約（にちえい つうしょう こうかい じょうやく） による。

（1870年代から条約改正のための交渉はしていたが、そのころは、欧米は理由をつけて、受け入れなかった。）

日清戦争で日本が勝利すると、ロシア・フランスなども治外法権をなくすことに同意したが、日本の関税（かんぜい）自主権（じしゅけん）は、みとめなかった。


*日露戦争の後
[[ファイル:Jutaro Komura.jpg|thumb|150px|小村寿太郎（こむら じゅたろう）]]
日露戦争で日本が勝利したことにより日本の国際的な地位が高まると、各国は、関税自主権の改正にも応じるようになり、外務大臣の小村寿太郎（こむら じゅたろう）の各国との交渉により、1911年に日本の関税自主権は回復した。

{{clear}}

== 日本の勝利がアジアへ希望をもたらす ==
この日露戦争での日本の勝利は、黄色人者（日本）が白人の国（ロシア）に勝利した戦争であるので、アジアやアフリカの欧米の植民地にされた地域の人々を勇気づけた。だが、その後の日本は、欧米と同じように植民地支配的な政策を朝鮮などで行っていったことにより、アジア・アフリカの欧米への不満と同様に日本も失望されていくことになる。とはいえ、日露戦争の終戦直後の時点では、アジア・アフリカの植民地支配をされていた民衆は、日本の勝利に喜ぶ者が多かった。


::のちのインドの独立運動家ネルーは、獄中で書いた著書『父が子に語る世界史』の中で、ネルーの少年時代のころの日露戦争における大日本帝国の勝利が、アジア諸国に独立への希望を与えたことを書いており、ネルー少年自身も感激した。

::しかし、その後、大日本帝国が欧米列強と同じく、近隣諸国を植民地支配下に置いたことを著書で記述している。日本による侵略の悲惨を最初に味わわされたのは朝鮮であったというふうに記述している。

とはいえ、先ほども述べたように、日露戦争の終戦直後の時点では、日本の勝利に希望をいだくアジアの民衆が多かったのである。

なので、日露戦争のあと、アジアでは独立を目指す政治運動がさかんになる。もっとも、アジア植民地のヨーロッパ諸国からの独立の時期そのものは、ほとんどは第二次世界大戦後の時代になる。


== ※ 範囲外: イギリスは「光栄ある孤立」だったのか？ ==
日英同盟までの、ギリスは中立路線・非同盟政策をつらぬいていて、『光栄ある孤立』（：Splendid Isolation）と自賛していた。そして日英同盟の成立により、イギリスの『孤立』は終了した。

しばしば現代日本の歴史評論などで、このことが日英同盟の重要性を説明するのに使われる。あたかも、日本が、イギリスの伝統的な中立政策を終了させるほどの大国かのように、評論される場合がある。

しかし、じつはイギリスが『光栄ある孤立』と初めて言ったのは1896年で、日英同盟が1902成立なので、たったの6年間であり、実は意図的な『孤立』期間はあまり長くないのが真相である。

真相は、イギリスと対立していたドイツによって、イギリスが外交的に孤立する状況に追い詰められてた背景がある。

アフリカ大陸の植民地利権をめぐり、ドイツとイギリスは対立していた。

このころイギリスは、オランダ系のアフリカ植民地国家と戦争をしていた（ボーア戦争など）。そして、ドイツはオランダを支援していたのであった。また、ドイツ自体も、周辺国とさまざまな同盟を結んでいた（いわゆる『ビスマルク政策』。詳しくは高校で習う）。 そのため、イギリスは外交的な孤立に追い込まれた。

そのボーア戦争のさい、イギリス領カナダがイギリスを支持表明する目的で『光栄ある孤立』（：Splendid Isolation）と評したのが、この言葉の由来である。


どうやらイギリスは、あまり意識して非同盟政策をしていたようではないようだ。


[[Category:中学校歴史|にちろせんそう]]</text>
      <sha1>s54jojrt0nmkdhujzsqjrxxogcgms1e</sha1>
    </revision>
  </page>
  <page>
    <title>学習方法/高校受験/英語</title>
    <ns>0</ns>
    <id>19527</id>
    <revision>
      <id>205746</id>
      <parentid>205715</parentid>
      <timestamp>2022-07-23T22:31:41Z</timestamp>
      <contributor>
        <username>Honooo</username>
        <id>14373</id>
      </contributor>
      <comment>/*私立高受験*/ 第一段のみ再編集。1/3。</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="21176" xml:space="preserve">{{Notice|'''{{PAGENAME}}'''では、中学校英語高校受験対策の学習方法について解説します。独自研究や中立性を欠いた文章が含まれる場合があります。ご了承ください。}}
==高校受験に向けた英単語学習==
英作文をはじめ、基本的に英語のスペルは正しく書くべきだろう。もちろん試験ではスペル間違いはそれなりに減点、あるいは不可になる。

英単語のスペルを覚えるいい方法、効果的な方法があればよいが、それぞれの学習者の工夫も必要だと思うが、一般的にもさまざまな主張やアドバイスがある。

『進研ゼミ 高校入試情報サイト』では、中学校の英単語学習として、意味や用法を覚え、スペルも書いて練習しようと勧めている&lt;ref name=&quot;:0&quot;&gt;[https://czemi.benesse.ne.jp/open/nyushi/study/1367896_13980.html]2022年4月25日に確認&lt;/ref&gt;。

英単語書き取り練習は漢字練習と同じようなものでしょう。まず中学校必須単語から、一単語あたり5～10回書いて覚えたい。

英語学習では英単語をそれなりの数覚えているのが有効、というのは、多くの人の主張するところで、中学生は中学生として覚えているのが妥当で必要な単語を、意味、スペル、そして出来れば品詞もしっかり覚えていくといいですよね。

しかし単語を覚えただけで、英語の学習バッチリとはならないだろうし、他にも発音や熟語、様々な用法を考慮した文作成や解釈、英語学習の要素は色々ありますよね。

しかし前編集者の推奨はあくまで単語書きとり練習中心、その過程でCD音声や例文読解を取り込めば、総合的な学習になるだろう、という主張&lt;ref name=&quot;:0&quot; /&gt;。

しかし一方で、書き取り練習は、英単語を覚えるための効果的な学習法ではない、という主張と、それを支持する論文もある&lt;ref&gt;[https://www.jstage.jst.go.jp/article/cogpsy/2005/0/2005_0_104/_article/-char/ja/ 見崎研志, &amp; 仲真紀子. (2005). 記憶促進における反復書記の有効性に関する検討. ''日本認知心理学会発表論文集'', ''2005''(0), 104-104.]&lt;/ref&gt;&lt;ref&gt;[https://www.jstage.jst.go.jp/article/cogpsy/2006/0/2006_0_171/_article/-char/ja/ 見崎研志, &amp; 仲真紀子. (2006). 反復書記学習が記憶に及ぼす影響. ''日本認知心理学会発表論文集'', ''2006''(0), 171-171.]&lt;/ref&gt;。

その場合は、こういうやり方がいいだろう。まず、英単語を見てその意味を思い浮かべる。思い浮かべた意味と真の意味が違っていたら、真の意味を覚えて次の単語に移る。これを覚えるまで何回か繰り返す。こういう学習法が最適だという主張もあります。

また、最近は英単語を覚えるためのスマホアプリなどが登場している。これらを活用することも有効な手段であろう。

実は世の中学習法については諸説紛々で、いろいろな方法を語る人物がいるから、学習者の自主的な判断、選択、発想が必要になるだろう。いろいろ試して自分自身で学習法を見出すことも重要だし、他者の意見を取り入れるにしても、種々の方法を併用して、学習法、勉強とは何かという事を発展的に考えていくことが大切だと思います。

単語学習の方法の視点として、学習するなら覚えるなら、重要度の高い単語から覚えていきたい、そういう考えがありますよね。

もちろん長文や、読解問題では、結局それほど重要だとみなされない単語が使われることも多いので、この視点がどれほど的を射ているかも一考の余地がある。

しかし高校入試の試験問題では、あまり馴染みのない単語には注釈がついている場合が多いので、学習重要語、記憶優先順位というのはやっぱりあると思います。

ただ大筋では、中学校重要単語、高校重要単語と、段階を示す事が出来るでしょうが、実際の試験問題でその分類が徹底的に守られるわけではないでしょう。例えば disappoint「がっかりする」や opinion「意見」などは一般的に、高校 2~3年で学習する単語だと見なされてれているようですが、事実上高校入試で使われている。とはいえほとんどの場合は中学生では難しすぎる単語として、注釈、解説はあるでしょう。

ところで前編集者はやたら中学範囲と高校範囲の分別にこだわるけど、そんなの最初っからあいまいなものでね。結局学校での学習内容なんて、学校により、クラスにより、それぞれ違うもので、あるクラスで学習したことが別のクラスでは学習しない、ある中学課程の本に書かれていることがあるクラスでは学習しない、あるいはその逆、そんなことはしょっちゅうだし、あって当たり前だよ。

そういう差異やあいまいさ、むらを踏まえた上で、統一の試験問題、選考方針で入学者を選ぼうというのが高校入試なんだよね。その差異や違いについていちいち理屈を言って、不平を言って議論するなんて、愚論の極みだろう。

しかもそうやって選考した結果が、絶対の人間判断基準でもない。入試に受かるのも人生なら、落ちるのも人生だよ。

さて、英単語学習の話に戻りますが、例えば中学校向けあるいは高校受験対策向けの英単語集で勉強する道もありますよね。

前編集者の推奨では、この手の単語集の学習では前半部分は飛ばして、と、いうのは、多くの初歩的すぎる単語は別の機会で学習している可能性が高いから、中間の単語から学習するのがいいようですね。そして最後まで学習したら最初に戻る…。あるいは前半部分はもうやらないで、より次の段階の、例えば高校で学習するような単語の勉強に向かうのもいいようです。

==受験勉強の学習範囲==
前項でも書いたように、中学範囲、高校範囲と区別して、その違いにこだわることはあまり意味がないし、その区別も事実上あいまいだ。特に学習すべき単語については、明確に中学単語、高校単語と区別することは、ごく基本的な単語以外、はっきりしない、おおざっぱな物になるだろう。

公立高校の入学試験は、一般的に標準的、基本的な出題が多いので、英単語に関してもそんな難しい単語を使わず、学校教科書の範囲の単語が使用されると思われる。

近年は中学校英語で扱う単語数が増加しているようだ。しかし、基本的には学校で習う単語をよく理解して覚えておくのを現編集者は推奨するが、むしろ少し背伸びして手を伸ばして、高校1年向けの参考書（3000語程度）を学習するのも良いのではないか、という意見もある。

単語集は、高校受験用の単語集はもちろん中学校範囲の単語を扱っていますが、やはり依然として、高校初等の単語集にも手を出すことを勧める意見もある。

ただ県立・都立などの公立高校やごく普通の私立高校では、そんな難度の高い英単語は出てこないでしょう。国立大付属高校の試験でも、それほど英単語難度は高くないようだ。だから多少難易度の高い単語を使用するのは、私立の難易高入試でしょうね。

現編集者は、中学校時の学習は、中学校の範囲をじっくり良く理解すればそれで十分だと考えるが、いやそうではない、ある程度高校範囲を先行したほうが良いという主張も根強くある。ただその場合でも、例えば英単語において、高校3年くらいをターゲットにした難関大学受験用英単語を覚える必要はなく、せいぜい高校初歩、最基本英単語の理解で十分だろう。

前編集者は頑なに、英語の学校教科書と中学用単語集だけではやや受験対策として不足だと主張するが、本当だろうか? 現編集者は、中学生は高校受験も含めて、中学校の学習をしっかりすれば対策として十分だと考える。

と、言うか、それが十分なのに不合格にするような高校、行かなくてもいいのでは?

==難関私立高校==
……とは言え、難関私立高校入試では、英語試験問題としてかなりの難しい出題があるだろう。ある程度成績のいい子はそういう高校に行ってみたい、受験したいと思うだろうし、それは自然な希望だろう。

使用される単語、熟語も、かなり難しい言葉が使われる場合もある。

ただ現編集者は基本的に、優秀な人間の集まりとか、エリートの集まりとか、その辺の存在には全く興味がないので、この問題についてはほぼ何も知らないし語ることもない。だから、前編集をそのまま継承しつつ、幾つかの指摘をしておく。

まず、やはり使われる英単語の難度として、高いものになるだろうから、高校初等の単語集の学習は有用。

しかし、仮にその学習をするにした所で、高校初等重要語3000語を覚えればもう十分だと考えられる。

高校英単語4500語は覚える必要はないだろう。やはりある程度難易度の高い単語には解説がつく。

単語の他に、私立難易高では英作文の出題が目立つ。そのためには少しハードルを下げて、高校1800語をしっかり学習するとよいだろうという指摘がある。

しかしせっかく英作文をするなら、英米人が読んでも妥当な、自然な文章が書けると当然望ましいが、やはり初学者や中学生、ネイティブでもない日本人がいきなりそんな奇麗な文を書けるわけではないので、ある程度許容できると見なされれば、試験ではそこそこ点数になる。

基本的に高校入試とは、中学の学習に関する試験なので、まず中学校の課程をきちんと身に着けて理解することが重要だが、私立の難易高の場合は、少しそれより背伸びした学習も必要かもしれない。

== 文法 ==
===まず…===
中学校で学習する英文法は、我々の英語理解の基本になるものだが、しかし絶対的なものではないだろう。高校では高校で、英文法のアップデートがなされるし、そして高校を卒業した後でも、何度も何度も英文法と言語文法のアップデートはなされていくだろう。

しかし我々は小学校でさらっと英語を知った後、中学校で最初に割と深く英文法を学習することになる。これは受験対策でもそうでなくても、よく理解しておきたい。受験勉強として取り組むなら、受験標準問題集による演習でもよいし、参考書類での理解を主軸にした学習でも良いだろう。

このページは高校受験対策がテーマだから、問題集での演習を勧める人が多いし、もちろんそれはそれで有用だが、現編集者はむしろ、各種参考書類での理解と読解を主体にした学習も勧める。

と、いうのは、結局勉強というのは、他者の発する質問や問題に答えることではなく、物事を知り理解することだからだ。そして物事を良く理解して知っているのなら、大抵の問題や質問にはそこそこ解答できる。

===古い参考書===
古い本にももちろん内容はあるが、高校受験勉強をするなら、毎年最新の情報と教材をもとに学習するのが一番望ましいだろう。

===私立高受験===
文法事項に関して、中学校で学習する内容というのはある程度定められているが、そこから逸脱した、難易度の高い構文や文章が出題されると、解答も困るかもしれない。一般的には私立高入試でも、そんな文法的に扱いが難しい英文は使われないだろう。英語の構成や構文、文法事項の参考資料として、受験用の発展的な参考書を学習しておくのもいいだろう。

;高校の参考書は必要か不要か
高校の参考書は、やさしい参考書であるなら実は2020年代の現代では中学生でも読めますが（1990年代は高校で教えていた仮定法や無生物主語なども、2020年代では中学で仮定法および無生物主語を習うようになったので、現代ではあまり中学英文法と高校英文法との分野の違いは無い）、高校受験の時点で、わざわざ高校生むけの文法参考書を買う必要は無いでしょう。

それでも買いたければどうぞ自己責任で。

;英検2級レベルの文法問題について
英検準2級が、（仮定法ではなく一般の）過去完了や未来完了など、やや複合的な文法を扱います。もしかしたら、英検準2級程度の文法があると、読解しやすい問題を出す私立高校もあるかもしれません。ただし書店の英検コーナーで探しても、英検の参考書ではあまり文法の解説が充実していないので、代わりに高校生向けの参考書のうち、やさしいレベルのものを通読することになるでしょうか。（高校では文法参考書は、学年別には分かれていません。）

どうしても高校受験の段階で文法を先取りするなら、英検準2級程度で十分でしょう。

なお、準2級ではない英検2級の文法事項は、おおよそ高校3年間の範囲です。

私立高校とはいえ、高校入試で仮に仮定法過去完了が出たとしても、推測ですが、せいぜい長文読解などでチラっと出てくるくらいとかで、特に細かい文法知識を要求する設問ではなく、おそらくはおおよその意味を把握するような問題でしょうか。

だとしたら、せいぜい文法参考書を通読するくらいで十分です。

== 発音 ==
発音に関しては、各種参考書や問題集などに乗ってる発音記号や音源などを参考にすればよいだろう。

英単語の発音がわからないとリスニングができないし、スピーキングや実用的な英語会話をしようというときに障害になる。

前編集者は発音の詳細にこだわるよりは単語熟語を覚えるほうが優先だろうと書いているが、高校入試だけに目的を特化する限りは、現編集者も特に異議を述べるつもりはない。

== リスニング ==
都立共通問題英語ではリスニング問題が出題されます。おそらく他県でもリスニング問題は出題されるはずです。

リスニング問題の対策について、リスニング問題には、やはり、日常的に英語教材を聞くというのが一番効果的です。参考書付属のリスニング対策音声を聞くなどして対策しましょう。

YouTubeなどで検索すれば、実際に話されている生の英語をいくらでも聞くことができますが、しかし中学生では語彙や文法の面で、いきなりネイティブの英語を聞き取るのは難しいと思います。もちろん、英語力にとても自身のある人はチャレンジしても構いませんが、しかし高校レベルの単語すら習得できていない中学生の多くにはYouTubeなどは非実用的です。

まず、高校レベルのリスニング教材を習得してからでないと、YouTubeなどに深入りしても、時間の無駄になります。

中学レベルでは、せいぜい、YouTubeの英語動画で英会話の雰囲気を掴んだり、実際の英会話のスピードを知るための参考としてYouTubeなどを視聴してみるぐらいが関の山でしょうか。


なお、前編集で、発音の教育が日本では軽視されてきたという主張があったのですが、間違いです。

CDどころかカセットテープすらも無かった明治や大正の時代、その代わりに国定教科書などで長々と発音の説明しています。「近代図書デジタルアーカイブ」という公共サイトに戦前の教科書があるので、それが証拠です（中高生の人は読みにいく必要ありません）。

ともかく、最近の動向として、リスニングも重視されるようになってきています。

なので、バランスよく勉強しましょう。もちろん、リスニングばかりを勉強して、書き取りも英作文もできないのでは本末転倒で、それはそれで困りますし、海外での実用性も乏しいでしょう。海外でも英作文や読み書きは必要なはずです。

なので、高校受験英語の勉強では、要するに普通に英単語の勉強などと併行して、リスニング教材なども勉強すればいいだけです。

== スピーキング ==
都立高入試では、2023年度からスピーキングテストが導入されます。おそらく、他県でもスピーキングテストが導入されるようになるのではないでしょうか。

== シャドーイング ==
シャドーイングとは、英語を「聞こえたままに」発音する練習方法です。英語の音についての理解が深まるので、リスニングやスピーキング対策に適しています。英文は何でもいいので、手頃なリスニング問題の音声からシャドーイングしてみましょう。また、慣れてきたら英語の曲をシャドーイングしてみるというのもいいでしょう。受験勉強の息抜きにもなりますし、楽しみながら学ぶというのも大切です。

== 英検 ==
英検を取っておくと高校受験において有利になる可能性があります。

東京都の場合、英検3級以上を取っておくと、私立併願や推薦で内申点を加算されるところが多いです。加算される点数は1点の場合が多いですが、加算方法や加算基準は高校により異なるので、公式HPや学校見学などで事前に確認しておきましょう。

英検3級以上は英語で面接官とのインタビューがあるので、英検を取得する場合、その対策が必要になります。

都立高一般入試の場合は英検取得が受験に有利になることはありません。

しかし、推薦の場合は都立私立どちらとも、英検はアピールポイントになるでしょう。

結果的に、英検を入試で使わなかったとしても、英検取得は英語学習のモチベーションになりますし、今の自分にどのくらいの英語力があるか分かったり、今後の英語の学習の指針になったりするので、余裕があれば受験したほうがいいでしょう。

なお、かつて俗に「英検3級が中学卒業レベル、標準的な高校受験レベル」みたいに言われていましたが、あくまで大まかな目安にすぎず（それもかなり大まか）、実際には出題傾向の違いもあり、英検と高校受験では単純には換算できません。なお近年、中学英語の教育範囲が変わり、今まで高校レベルで教えていた文法の一部（たとえば仮定法など）が中学に前倒しになったので、もしかしたら英検3級では高校受験対策としては不適かもしれません。（英検準2級程度のほうが文法的には近いのかもしれません。）

ともかく、一般入試を受けるなら、英検よりもまずは高校受験そのものの対策をするのが優先事項です。英検の対策ばかりして肝心の高校受験英語の勉強をしなければ、一般入試での高校受験英語の成績は当然ながら悪化します。なので、志望校への推薦合格などが確実で無い限りは、あくまで英検対策は補助にするのが安全でしょう。

[[Category:中学校教育|がくしゅうほうほうこうこうじゅけんえいご]]
[[Category:学習方法|がくしゅうほうほうこうこうじゅけんえいご]]</text>
      <sha1>7c34f2tgu55vzggwrt9u3isp8yg561t</sha1>
    </revision>
    <revision>
      <id>205757</id>
      <parentid>205746</parentid>
      <timestamp>2022-07-24T06:07:03Z</timestamp>
      <contributor>
        <username>Honooo</username>
        <id>14373</id>
      </contributor>
      <comment>/* 私立高受験 */ ２段落目まで修正。2/3。</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="21151" xml:space="preserve">{{Notice|'''{{PAGENAME}}'''では、中学校英語高校受験対策の学習方法について解説します。独自研究や中立性を欠いた文章が含まれる場合があります。ご了承ください。}}
==高校受験に向けた英単語学習==
英作文をはじめ、基本的に英語のスペルは正しく書くべきだろう。もちろん試験ではスペル間違いはそれなりに減点、あるいは不可になる。

英単語のスペルを覚えるいい方法、効果的な方法があればよいが、それぞれの学習者の工夫も必要だと思うが、一般的にもさまざまな主張やアドバイスがある。

『進研ゼミ 高校入試情報サイト』では、中学校の英単語学習として、意味や用法を覚え、スペルも書いて練習しようと勧めている&lt;ref name=&quot;:0&quot;&gt;[https://czemi.benesse.ne.jp/open/nyushi/study/1367896_13980.html]2022年4月25日に確認&lt;/ref&gt;。

英単語書き取り練習は漢字練習と同じようなものでしょう。まず中学校必須単語から、一単語あたり5～10回書いて覚えたい。

英語学習では英単語をそれなりの数覚えているのが有効、というのは、多くの人の主張するところで、中学生は中学生として覚えているのが妥当で必要な単語を、意味、スペル、そして出来れば品詞もしっかり覚えていくといいですよね。

しかし単語を覚えただけで、英語の学習バッチリとはならないだろうし、他にも発音や熟語、様々な用法を考慮した文作成や解釈、英語学習の要素は色々ありますよね。

しかし前編集者の推奨はあくまで単語書きとり練習中心、その過程でCD音声や例文読解を取り込めば、総合的な学習になるだろう、という主張&lt;ref name=&quot;:0&quot; /&gt;。

しかし一方で、書き取り練習は、英単語を覚えるための効果的な学習法ではない、という主張と、それを支持する論文もある&lt;ref&gt;[https://www.jstage.jst.go.jp/article/cogpsy/2005/0/2005_0_104/_article/-char/ja/ 見崎研志, &amp; 仲真紀子. (2005). 記憶促進における反復書記の有効性に関する検討. ''日本認知心理学会発表論文集'', ''2005''(0), 104-104.]&lt;/ref&gt;&lt;ref&gt;[https://www.jstage.jst.go.jp/article/cogpsy/2006/0/2006_0_171/_article/-char/ja/ 見崎研志, &amp; 仲真紀子. (2006). 反復書記学習が記憶に及ぼす影響. ''日本認知心理学会発表論文集'', ''2006''(0), 171-171.]&lt;/ref&gt;。

その場合は、こういうやり方がいいだろう。まず、英単語を見てその意味を思い浮かべる。思い浮かべた意味と真の意味が違っていたら、真の意味を覚えて次の単語に移る。これを覚えるまで何回か繰り返す。こういう学習法が最適だという主張もあります。

また、最近は英単語を覚えるためのスマホアプリなどが登場している。これらを活用することも有効な手段であろう。

実は世の中学習法については諸説紛々で、いろいろな方法を語る人物がいるから、学習者の自主的な判断、選択、発想が必要になるだろう。いろいろ試して自分自身で学習法を見出すことも重要だし、他者の意見を取り入れるにしても、種々の方法を併用して、学習法、勉強とは何かという事を発展的に考えていくことが大切だと思います。

単語学習の方法の視点として、学習するなら覚えるなら、重要度の高い単語から覚えていきたい、そういう考えがありますよね。

もちろん長文や、読解問題では、結局それほど重要だとみなされない単語が使われることも多いので、この視点がどれほど的を射ているかも一考の余地がある。

しかし高校入試の試験問題では、あまり馴染みのない単語には注釈がついている場合が多いので、学習重要語、記憶優先順位というのはやっぱりあると思います。

ただ大筋では、中学校重要単語、高校重要単語と、段階を示す事が出来るでしょうが、実際の試験問題でその分類が徹底的に守られるわけではないでしょう。例えば disappoint「がっかりする」や opinion「意見」などは一般的に、高校 2~3年で学習する単語だと見なされてれているようですが、事実上高校入試で使われている。とはいえほとんどの場合は中学生では難しすぎる単語として、注釈、解説はあるでしょう。

ところで前編集者はやたら中学範囲と高校範囲の分別にこだわるけど、そんなの最初っからあいまいなものでね。結局学校での学習内容なんて、学校により、クラスにより、それぞれ違うもので、あるクラスで学習したことが別のクラスでは学習しない、ある中学課程の本に書かれていることがあるクラスでは学習しない、あるいはその逆、そんなことはしょっちゅうだし、あって当たり前だよ。

そういう差異やあいまいさ、むらを踏まえた上で、統一の試験問題、選考方針で入学者を選ぼうというのが高校入試なんだよね。その差異や違いについていちいち理屈を言って、不平を言って議論するなんて、愚論の極みだろう。

しかもそうやって選考した結果が、絶対の人間判断基準でもない。入試に受かるのも人生なら、落ちるのも人生だよ。

さて、英単語学習の話に戻りますが、例えば中学校向けあるいは高校受験対策向けの英単語集で勉強する道もありますよね。

前編集者の推奨では、この手の単語集の学習では前半部分は飛ばして、と、いうのは、多くの初歩的すぎる単語は別の機会で学習している可能性が高いから、中間の単語から学習するのがいいようですね。そして最後まで学習したら最初に戻る…。あるいは前半部分はもうやらないで、より次の段階の、例えば高校で学習するような単語の勉強に向かうのもいいようです。

==受験勉強の学習範囲==
前項でも書いたように、中学範囲、高校範囲と区別して、その違いにこだわることはあまり意味がないし、その区別も事実上あいまいだ。特に学習すべき単語については、明確に中学単語、高校単語と区別することは、ごく基本的な単語以外、はっきりしない、おおざっぱな物になるだろう。

公立高校の入学試験は、一般的に標準的、基本的な出題が多いので、英単語に関してもそんな難しい単語を使わず、学校教科書の範囲の単語が使用されると思われる。

近年は中学校英語で扱う単語数が増加しているようだ。しかし、基本的には学校で習う単語をよく理解して覚えておくのを現編集者は推奨するが、むしろ少し背伸びして手を伸ばして、高校1年向けの参考書（3000語程度）を学習するのも良いのではないか、という意見もある。

単語集は、高校受験用の単語集はもちろん中学校範囲の単語を扱っていますが、やはり依然として、高校初等の単語集にも手を出すことを勧める意見もある。

ただ県立・都立などの公立高校やごく普通の私立高校では、そんな難度の高い英単語は出てこないでしょう。国立大付属高校の試験でも、それほど英単語難度は高くないようだ。だから多少難易度の高い単語を使用するのは、私立の難易高入試でしょうね。

現編集者は、中学校時の学習は、中学校の範囲をじっくり良く理解すればそれで十分だと考えるが、いやそうではない、ある程度高校範囲を先行したほうが良いという主張も根強くある。ただその場合でも、例えば英単語において、高校3年くらいをターゲットにした難関大学受験用英単語を覚える必要はなく、せいぜい高校初歩、最基本英単語の理解で十分だろう。

前編集者は頑なに、英語の学校教科書と中学用単語集だけではやや受験対策として不足だと主張するが、本当だろうか? 現編集者は、中学生は高校受験も含めて、中学校の学習をしっかりすれば対策として十分だと考える。

と、言うか、それが十分なのに不合格にするような高校、行かなくてもいいのでは?

==難関私立高校==
……とは言え、難関私立高校入試では、英語試験問題としてかなりの難しい出題があるだろう。ある程度成績のいい子はそういう高校に行ってみたい、受験したいと思うだろうし、それは自然な希望だろう。

使用される単語、熟語も、かなり難しい言葉が使われる場合もある。

ただ現編集者は基本的に、優秀な人間の集まりとか、エリートの集まりとか、その辺の存在には全く興味がないので、この問題についてはほぼ何も知らないし語ることもない。だから、前編集をそのまま継承しつつ、幾つかの指摘をしておく。

まず、やはり使われる英単語の難度として、高いものになるだろうから、高校初等の単語集の学習は有用。

しかし、仮にその学習をするにした所で、高校初等重要語3000語を覚えればもう十分だと考えられる。

高校英単語4500語は覚える必要はないだろう。やはりある程度難易度の高い単語には解説がつく。

単語の他に、私立難易高では英作文の出題が目立つ。そのためには少しハードルを下げて、高校1800語をしっかり学習するとよいだろうという指摘がある。

しかしせっかく英作文をするなら、英米人が読んでも妥当な、自然な文章が書けると当然望ましいが、やはり初学者や中学生、ネイティブでもない日本人がいきなりそんな奇麗な文を書けるわけではないので、ある程度許容できると見なされれば、試験ではそこそこ点数になる。

基本的に高校入試とは、中学の学習に関する試験なので、まず中学校の課程をきちんと身に着けて理解することが重要だが、私立の難易高の場合は、少しそれより背伸びした学習も必要かもしれない。

== 文法 ==
===まず…===
中学校で学習する英文法は、我々の英語理解の基本になるものだが、しかし絶対的なものではないだろう。高校では高校で、英文法のアップデートがなされるし、そして高校を卒業した後でも、何度も何度も英文法と言語文法のアップデートはなされていくだろう。

しかし我々は小学校でさらっと英語を知った後、中学校で最初に割と深く英文法を学習することになる。これは受験対策でもそうでなくても、よく理解しておきたい。受験勉強として取り組むなら、受験標準問題集による演習でもよいし、参考書類での理解を主軸にした学習でも良いだろう。

このページは高校受験対策がテーマだから、問題集での演習を勧める人が多いし、もちろんそれはそれで有用だが、現編集者はむしろ、各種参考書類での理解と読解を主体にした学習も勧める。

と、いうのは、結局勉強というのは、他者の発する質問や問題に答えることではなく、物事を知り理解することだからだ。そして物事を良く理解して知っているのなら、大抵の問題や質問にはそこそこ解答できる。

===古い参考書===
古い本にももちろん内容はあるが、高校受験勉強をするなら、毎年最新の情報と教材をもとに学習するのが一番望ましいだろう。

===私立高受験===
文法事項に関して、中学校で学習する内容というのはある程度定められているが、そこから逸脱した、難易度の高い構文や文章が出題されると、解答も困るかもしれない。一般的には私立高入試でも、そんな文法的に扱いが難しい英文は使われないだろう。英語の構成や構文、文法事項の参考資料として、受験用の発展的な参考書を学習しておくのもいいだろう。

;中学生だけど高校参考書を先行して読んじゃうという勉強。
何度も書くがあまり背伸びしたり無理したり、また自分があまり凄くて賢い人間だと思い込むのは多々問題がある。特に中学校英語文法に関しては、高校学習に手を出すのはあまりメリットがないという指摘もある。最近では中学校で学習する文法事項が、1990年代より高度に、充実しているという。前編集者は仮定法や無生物主語の解説を例として挙げている。

;英検2級レベルの文法問題について
英検準2級が、（仮定法ではなく一般の）過去完了や未来完了など、やや複合的な文法を扱います。もしかしたら、英検準2級程度の文法があると、読解しやすい問題を出す私立高校もあるかもしれません。ただし書店の英検コーナーで探しても、英検の参考書ではあまり文法の解説が充実していないので、代わりに高校生向けの参考書のうち、やさしいレベルのものを通読することになるでしょうか。（高校では文法参考書は、学年別には分かれていません。）

どうしても高校受験の段階で文法を先取りするなら、英検準2級程度で十分でしょう。

なお、準2級ではない英検2級の文法事項は、おおよそ高校3年間の範囲です。

私立高校とはいえ、高校入試で仮に仮定法過去完了が出たとしても、推測ですが、せいぜい長文読解などでチラっと出てくるくらいとかで、特に細かい文法知識を要求する設問ではなく、おそらくはおおよその意味を把握するような問題でしょうか。

だとしたら、せいぜい文法参考書を通読するくらいで十分です。

== 発音 ==
発音に関しては、各種参考書や問題集などに乗ってる発音記号や音源などを参考にすればよいだろう。

英単語の発音がわからないとリスニングができないし、スピーキングや実用的な英語会話をしようというときに障害になる。

前編集者は発音の詳細にこだわるよりは単語熟語を覚えるほうが優先だろうと書いているが、高校入試だけに目的を特化する限りは、現編集者も特に異議を述べるつもりはない。

== リスニング ==
都立共通問題英語ではリスニング問題が出題されます。おそらく他県でもリスニング問題は出題されるはずです。

リスニング問題の対策について、リスニング問題には、やはり、日常的に英語教材を聞くというのが一番効果的です。参考書付属のリスニング対策音声を聞くなどして対策しましょう。

YouTubeなどで検索すれば、実際に話されている生の英語をいくらでも聞くことができますが、しかし中学生では語彙や文法の面で、いきなりネイティブの英語を聞き取るのは難しいと思います。もちろん、英語力にとても自身のある人はチャレンジしても構いませんが、しかし高校レベルの単語すら習得できていない中学生の多くにはYouTubeなどは非実用的です。

まず、高校レベルのリスニング教材を習得してからでないと、YouTubeなどに深入りしても、時間の無駄になります。

中学レベルでは、せいぜい、YouTubeの英語動画で英会話の雰囲気を掴んだり、実際の英会話のスピードを知るための参考としてYouTubeなどを視聴してみるぐらいが関の山でしょうか。


なお、前編集で、発音の教育が日本では軽視されてきたという主張があったのですが、間違いです。

CDどころかカセットテープすらも無かった明治や大正の時代、その代わりに国定教科書などで長々と発音の説明しています。「近代図書デジタルアーカイブ」という公共サイトに戦前の教科書があるので、それが証拠です（中高生の人は読みにいく必要ありません）。

ともかく、最近の動向として、リスニングも重視されるようになってきています。

なので、バランスよく勉強しましょう。もちろん、リスニングばかりを勉強して、書き取りも英作文もできないのでは本末転倒で、それはそれで困りますし、海外での実用性も乏しいでしょう。海外でも英作文や読み書きは必要なはずです。

なので、高校受験英語の勉強では、要するに普通に英単語の勉強などと併行して、リスニング教材なども勉強すればいいだけです。

== スピーキング ==
都立高入試では、2023年度からスピーキングテストが導入されます。おそらく、他県でもスピーキングテストが導入されるようになるのではないでしょうか。

== シャドーイング ==
シャドーイングとは、英語を「聞こえたままに」発音する練習方法です。英語の音についての理解が深まるので、リスニングやスピーキング対策に適しています。英文は何でもいいので、手頃なリスニング問題の音声からシャドーイングしてみましょう。また、慣れてきたら英語の曲をシャドーイングしてみるというのもいいでしょう。受験勉強の息抜きにもなりますし、楽しみながら学ぶというのも大切です。

== 英検 ==
英検を取っておくと高校受験において有利になる可能性があります。

東京都の場合、英検3級以上を取っておくと、私立併願や推薦で内申点を加算されるところが多いです。加算される点数は1点の場合が多いですが、加算方法や加算基準は高校により異なるので、公式HPや学校見学などで事前に確認しておきましょう。

英検3級以上は英語で面接官とのインタビューがあるので、英検を取得する場合、その対策が必要になります。

都立高一般入試の場合は英検取得が受験に有利になることはありません。

しかし、推薦の場合は都立私立どちらとも、英検はアピールポイントになるでしょう。

結果的に、英検を入試で使わなかったとしても、英検取得は英語学習のモチベーションになりますし、今の自分にどのくらいの英語力があるか分かったり、今後の英語の学習の指針になったりするので、余裕があれば受験したほうがいいでしょう。

なお、かつて俗に「英検3級が中学卒業レベル、標準的な高校受験レベル」みたいに言われていましたが、あくまで大まかな目安にすぎず（それもかなり大まか）、実際には出題傾向の違いもあり、英検と高校受験では単純には換算できません。なお近年、中学英語の教育範囲が変わり、今まで高校レベルで教えていた文法の一部（たとえば仮定法など）が中学に前倒しになったので、もしかしたら英検3級では高校受験対策としては不適かもしれません。（英検準2級程度のほうが文法的には近いのかもしれません。）

ともかく、一般入試を受けるなら、英検よりもまずは高校受験そのものの対策をするのが優先事項です。英検の対策ばかりして肝心の高校受験英語の勉強をしなければ、一般入試での高校受験英語の成績は当然ながら悪化します。なので、志望校への推薦合格などが確実で無い限りは、あくまで英検対策は補助にするのが安全でしょう。

[[Category:中学校教育|がくしゅうほうほうこうこうじゅけんえいご]]
[[Category:学習方法|がくしゅうほうほうこうこうじゅけんえいご]]</text>
      <sha1>enl9gxaynyi8axyyjf991xz8wnz3zzo</sha1>
    </revision>
    <revision>
      <id>205779</id>
      <parentid>205757</parentid>
      <timestamp>2022-07-24T08:31:48Z</timestamp>
      <contributor>
        <username>Honooo</username>
        <id>14373</id>
      </contributor>
      <comment>/* 私立高受験 */ 3/3。</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="21168" xml:space="preserve">{{Notice|'''{{PAGENAME}}'''では、中学校英語高校受験対策の学習方法について解説します。独自研究や中立性を欠いた文章が含まれる場合があります。ご了承ください。}}
==高校受験に向けた英単語学習==
英作文をはじめ、基本的に英語のスペルは正しく書くべきだろう。もちろん試験ではスペル間違いはそれなりに減点、あるいは不可になる。

英単語のスペルを覚えるいい方法、効果的な方法があればよいが、それぞれの学習者の工夫も必要だと思うが、一般的にもさまざまな主張やアドバイスがある。

『進研ゼミ 高校入試情報サイト』では、中学校の英単語学習として、意味や用法を覚え、スペルも書いて練習しようと勧めている&lt;ref name=&quot;:0&quot;&gt;[https://czemi.benesse.ne.jp/open/nyushi/study/1367896_13980.html]2022年4月25日に確認&lt;/ref&gt;。

英単語書き取り練習は漢字練習と同じようなものでしょう。まず中学校必須単語から、一単語あたり5～10回書いて覚えたい。

英語学習では英単語をそれなりの数覚えているのが有効、というのは、多くの人の主張するところで、中学生は中学生として覚えているのが妥当で必要な単語を、意味、スペル、そして出来れば品詞もしっかり覚えていくといいですよね。

しかし単語を覚えただけで、英語の学習バッチリとはならないだろうし、他にも発音や熟語、様々な用法を考慮した文作成や解釈、英語学習の要素は色々ありますよね。

しかし前編集者の推奨はあくまで単語書きとり練習中心、その過程でCD音声や例文読解を取り込めば、総合的な学習になるだろう、という主張&lt;ref name=&quot;:0&quot; /&gt;。

しかし一方で、書き取り練習は、英単語を覚えるための効果的な学習法ではない、という主張と、それを支持する論文もある&lt;ref&gt;[https://www.jstage.jst.go.jp/article/cogpsy/2005/0/2005_0_104/_article/-char/ja/ 見崎研志, &amp; 仲真紀子. (2005). 記憶促進における反復書記の有効性に関する検討. ''日本認知心理学会発表論文集'', ''2005''(0), 104-104.]&lt;/ref&gt;&lt;ref&gt;[https://www.jstage.jst.go.jp/article/cogpsy/2006/0/2006_0_171/_article/-char/ja/ 見崎研志, &amp; 仲真紀子. (2006). 反復書記学習が記憶に及ぼす影響. ''日本認知心理学会発表論文集'', ''2006''(0), 171-171.]&lt;/ref&gt;。

その場合は、こういうやり方がいいだろう。まず、英単語を見てその意味を思い浮かべる。思い浮かべた意味と真の意味が違っていたら、真の意味を覚えて次の単語に移る。これを覚えるまで何回か繰り返す。こういう学習法が最適だという主張もあります。

また、最近は英単語を覚えるためのスマホアプリなどが登場している。これらを活用することも有効な手段であろう。

実は世の中学習法については諸説紛々で、いろいろな方法を語る人物がいるから、学習者の自主的な判断、選択、発想が必要になるだろう。いろいろ試して自分自身で学習法を見出すことも重要だし、他者の意見を取り入れるにしても、種々の方法を併用して、学習法、勉強とは何かという事を発展的に考えていくことが大切だと思います。

単語学習の方法の視点として、学習するなら覚えるなら、重要度の高い単語から覚えていきたい、そういう考えがありますよね。

もちろん長文や、読解問題では、結局それほど重要だとみなされない単語が使われることも多いので、この視点がどれほど的を射ているかも一考の余地がある。

しかし高校入試の試験問題では、あまり馴染みのない単語には注釈がついている場合が多いので、学習重要語、記憶優先順位というのはやっぱりあると思います。

ただ大筋では、中学校重要単語、高校重要単語と、段階を示す事が出来るでしょうが、実際の試験問題でその分類が徹底的に守られるわけではないでしょう。例えば disappoint「がっかりする」や opinion「意見」などは一般的に、高校 2~3年で学習する単語だと見なされてれているようですが、事実上高校入試で使われている。とはいえほとんどの場合は中学生では難しすぎる単語として、注釈、解説はあるでしょう。

ところで前編集者はやたら中学範囲と高校範囲の分別にこだわるけど、そんなの最初っからあいまいなものでね。結局学校での学習内容なんて、学校により、クラスにより、それぞれ違うもので、あるクラスで学習したことが別のクラスでは学習しない、ある中学課程の本に書かれていることがあるクラスでは学習しない、あるいはその逆、そんなことはしょっちゅうだし、あって当たり前だよ。

そういう差異やあいまいさ、むらを踏まえた上で、統一の試験問題、選考方針で入学者を選ぼうというのが高校入試なんだよね。その差異や違いについていちいち理屈を言って、不平を言って議論するなんて、愚論の極みだろう。

しかもそうやって選考した結果が、絶対の人間判断基準でもない。入試に受かるのも人生なら、落ちるのも人生だよ。

さて、英単語学習の話に戻りますが、例えば中学校向けあるいは高校受験対策向けの英単語集で勉強する道もありますよね。

前編集者の推奨では、この手の単語集の学習では前半部分は飛ばして、と、いうのは、多くの初歩的すぎる単語は別の機会で学習している可能性が高いから、中間の単語から学習するのがいいようですね。そして最後まで学習したら最初に戻る…。あるいは前半部分はもうやらないで、より次の段階の、例えば高校で学習するような単語の勉強に向かうのもいいようです。

==受験勉強の学習範囲==
前項でも書いたように、中学範囲、高校範囲と区別して、その違いにこだわることはあまり意味がないし、その区別も事実上あいまいだ。特に学習すべき単語については、明確に中学単語、高校単語と区別することは、ごく基本的な単語以外、はっきりしない、おおざっぱな物になるだろう。

公立高校の入学試験は、一般的に標準的、基本的な出題が多いので、英単語に関してもそんな難しい単語を使わず、学校教科書の範囲の単語が使用されると思われる。

近年は中学校英語で扱う単語数が増加しているようだ。しかし、基本的には学校で習う単語をよく理解して覚えておくのを現編集者は推奨するが、むしろ少し背伸びして手を伸ばして、高校1年向けの参考書（3000語程度）を学習するのも良いのではないか、という意見もある。

単語集は、高校受験用の単語集はもちろん中学校範囲の単語を扱っていますが、やはり依然として、高校初等の単語集にも手を出すことを勧める意見もある。

ただ県立・都立などの公立高校やごく普通の私立高校では、そんな難度の高い英単語は出てこないでしょう。国立大付属高校の試験でも、それほど英単語難度は高くないようだ。だから多少難易度の高い単語を使用するのは、私立の難易高入試でしょうね。

現編集者は、中学校時の学習は、中学校の範囲をじっくり良く理解すればそれで十分だと考えるが、いやそうではない、ある程度高校範囲を先行したほうが良いという主張も根強くある。ただその場合でも、例えば英単語において、高校3年くらいをターゲットにした難関大学受験用英単語を覚える必要はなく、せいぜい高校初歩、最基本英単語の理解で十分だろう。

前編集者は頑なに、英語の学校教科書と中学用単語集だけではやや受験対策として不足だと主張するが、本当だろうか? 現編集者は、中学生は高校受験も含めて、中学校の学習をしっかりすれば対策として十分だと考える。

と、言うか、それが十分なのに不合格にするような高校、行かなくてもいいのでは?

==難関私立高校==
……とは言え、難関私立高校入試では、英語試験問題としてかなりの難しい出題があるだろう。ある程度成績のいい子はそういう高校に行ってみたい、受験したいと思うだろうし、それは自然な希望だろう。

使用される単語、熟語も、かなり難しい言葉が使われる場合もある。

ただ現編集者は基本的に、優秀な人間の集まりとか、エリートの集まりとか、その辺の存在には全く興味がないので、この問題についてはほぼ何も知らないし語ることもない。だから、前編集をそのまま継承しつつ、幾つかの指摘をしておく。

まず、やはり使われる英単語の難度として、高いものになるだろうから、高校初等の単語集の学習は有用。

しかし、仮にその学習をするにした所で、高校初等重要語3000語を覚えればもう十分だと考えられる。

高校英単語4500語は覚える必要はないだろう。やはりある程度難易度の高い単語には解説がつく。

単語の他に、私立難易高では英作文の出題が目立つ。そのためには少しハードルを下げて、高校1800語をしっかり学習するとよいだろうという指摘がある。

しかしせっかく英作文をするなら、英米人が読んでも妥当な、自然な文章が書けると当然望ましいが、やはり初学者や中学生、ネイティブでもない日本人がいきなりそんな奇麗な文を書けるわけではないので、ある程度許容できると見なされれば、試験ではそこそこ点数になる。

基本的に高校入試とは、中学の学習に関する試験なので、まず中学校の課程をきちんと身に着けて理解することが重要だが、私立の難易高の場合は、少しそれより背伸びした学習も必要かもしれない。

== 文法 ==
===まず…===
中学校で学習する英文法は、我々の英語理解の基本になるものだが、しかし絶対的なものではないだろう。高校では高校で、英文法のアップデートがなされるし、そして高校を卒業した後でも、何度も何度も英文法と言語文法のアップデートはなされていくだろう。

しかし我々は小学校でさらっと英語を知った後、中学校で最初に割と深く英文法を学習することになる。これは受験対策でもそうでなくても、よく理解しておきたい。受験勉強として取り組むなら、受験標準問題集による演習でもよいし、参考書類での理解を主軸にした学習でも良いだろう。

このページは高校受験対策がテーマだから、問題集での演習を勧める人が多いし、もちろんそれはそれで有用だが、現編集者はむしろ、各種参考書類での理解と読解を主体にした学習も勧める。

と、いうのは、結局勉強というのは、他者の発する質問や問題に答えることではなく、物事を知り理解することだからだ。そして物事を良く理解して知っているのなら、大抵の問題や質問にはそこそこ解答できる。

===古い参考書===
古い本にももちろん内容はあるが、高校受験勉強をするなら、毎年最新の情報と教材をもとに学習するのが一番望ましいだろう。

===私立高受験===
文法事項に関して、中学校で学習する内容というのはある程度定められているが、そこから逸脱した、難易度の高い構文や文章が出題されると、解答も困るかもしれない。一般的には私立高入試でも、そんな文法的に扱いが難しい英文は使われないだろう。英語の構成や構文、文法事項の参考資料として、受験用の発展的な参考書を学習しておくのもいいだろう。

;中学生だけど高校参考書を先行して読んじゃうという勉強。
何度も書くがあまり背伸びしたり無理したり、また自分があまり凄くて賢い人間だと思い込むのは多々問題がある。特に中学校英語文法に関しては、高校学習に手を出すのはあまりメリットがないという指摘もある。最近では中学校で学習する文法事項が、1990年代より高度に、充実しているという。前編集者は仮定法や無生物主語の解説を例として挙げている。

;英検準2級
英検準2級程度の知識があると何かと良いという指摘がある。（仮定法ではなく一般の）過去完了や未来完了などちょっと凝った時制やアスペクトを扱う。ちなみに参考までに、現編集者が最近読んだ文法の本には、英語には２種類の時制しか無いという。それは現在時制と過去時制。より厳密には過去時制と非過去時制。Will は発話時の現在において未来をイメージしているから現在時制だという。そして時制とは違うアスペクト（相）という概念を指摘する。英語には完了と進行の２種類のアスペクトが見られると書いてあったよ。

しかし英検準２級の一般の参考書は文法解説はあまり充実していない。文法を知りたければやはり受験用参考書という事になるか。英検２級はさらに難しく、高校３年間の範囲なので、中学生は考慮に入れる必要はないだろう。

例えば仮定法過去完了も、一応中学校で学習するが、ちょっと面倒な文章ではある。ただ割と簡単に割り切ると、仮定法過去は想像と仮定の現在を示しているし、仮定法過去完了は想像と仮定の過去を示している。

== 発音 ==
発音に関しては、各種参考書や問題集などに乗ってる発音記号や音源などを参考にすればよいだろう。

英単語の発音がわからないとリスニングができないし、スピーキングや実用的な英語会話をしようというときに障害になる。

前編集者は発音の詳細にこだわるよりは単語熟語を覚えるほうが優先だろうと書いているが、高校入試だけに目的を特化する限りは、現編集者も特に異議を述べるつもりはない。

== リスニング ==
都立共通問題英語ではリスニング問題が出題されます。おそらく他県でもリスニング問題は出題されるはずです。

リスニング問題の対策について、リスニング問題には、やはり、日常的に英語教材を聞くというのが一番効果的です。参考書付属のリスニング対策音声を聞くなどして対策しましょう。

YouTubeなどで検索すれば、実際に話されている生の英語をいくらでも聞くことができますが、しかし中学生では語彙や文法の面で、いきなりネイティブの英語を聞き取るのは難しいと思います。もちろん、英語力にとても自身のある人はチャレンジしても構いませんが、しかし高校レベルの単語すら習得できていない中学生の多くにはYouTubeなどは非実用的です。

まず、高校レベルのリスニング教材を習得してからでないと、YouTubeなどに深入りしても、時間の無駄になります。

中学レベルでは、せいぜい、YouTubeの英語動画で英会話の雰囲気を掴んだり、実際の英会話のスピードを知るための参考としてYouTubeなどを視聴してみるぐらいが関の山でしょうか。


なお、前編集で、発音の教育が日本では軽視されてきたという主張があったのですが、間違いです。

CDどころかカセットテープすらも無かった明治や大正の時代、その代わりに国定教科書などで長々と発音の説明しています。「近代図書デジタルアーカイブ」という公共サイトに戦前の教科書があるので、それが証拠です（中高生の人は読みにいく必要ありません）。

ともかく、最近の動向として、リスニングも重視されるようになってきています。

なので、バランスよく勉強しましょう。もちろん、リスニングばかりを勉強して、書き取りも英作文もできないのでは本末転倒で、それはそれで困りますし、海外での実用性も乏しいでしょう。海外でも英作文や読み書きは必要なはずです。

なので、高校受験英語の勉強では、要するに普通に英単語の勉強などと併行して、リスニング教材なども勉強すればいいだけです。

== スピーキング ==
都立高入試では、2023年度からスピーキングテストが導入されます。おそらく、他県でもスピーキングテストが導入されるようになるのではないでしょうか。

== シャドーイング ==
シャドーイングとは、英語を「聞こえたままに」発音する練習方法です。英語の音についての理解が深まるので、リスニングやスピーキング対策に適しています。英文は何でもいいので、手頃なリスニング問題の音声からシャドーイングしてみましょう。また、慣れてきたら英語の曲をシャドーイングしてみるというのもいいでしょう。受験勉強の息抜きにもなりますし、楽しみながら学ぶというのも大切です。

== 英検 ==
英検を取っておくと高校受験において有利になる可能性があります。

東京都の場合、英検3級以上を取っておくと、私立併願や推薦で内申点を加算されるところが多いです。加算される点数は1点の場合が多いですが、加算方法や加算基準は高校により異なるので、公式HPや学校見学などで事前に確認しておきましょう。

英検3級以上は英語で面接官とのインタビューがあるので、英検を取得する場合、その対策が必要になります。

都立高一般入試の場合は英検取得が受験に有利になることはありません。

しかし、推薦の場合は都立私立どちらとも、英検はアピールポイントになるでしょう。

結果的に、英検を入試で使わなかったとしても、英検取得は英語学習のモチベーションになりますし、今の自分にどのくらいの英語力があるか分かったり、今後の英語の学習の指針になったりするので、余裕があれば受験したほうがいいでしょう。

なお、かつて俗に「英検3級が中学卒業レベル、標準的な高校受験レベル」みたいに言われていましたが、あくまで大まかな目安にすぎず（それもかなり大まか）、実際には出題傾向の違いもあり、英検と高校受験では単純には換算できません。なお近年、中学英語の教育範囲が変わり、今まで高校レベルで教えていた文法の一部（たとえば仮定法など）が中学に前倒しになったので、もしかしたら英検3級では高校受験対策としては不適かもしれません。（英検準2級程度のほうが文法的には近いのかもしれません。）

ともかく、一般入試を受けるなら、英検よりもまずは高校受験そのものの対策をするのが優先事項です。英検の対策ばかりして肝心の高校受験英語の勉強をしなければ、一般入試での高校受験英語の成績は当然ながら悪化します。なので、志望校への推薦合格などが確実で無い限りは、あくまで英検対策は補助にするのが安全でしょう。

[[Category:中学校教育|がくしゅうほうほうこうこうじゅけんえいご]]
[[Category:学習方法|がくしゅうほうほうこうこうじゅけんえいご]]</text>
      <sha1>lvlzdfoqi60tnhetvjc3uuhn9y7ajpk</sha1>
    </revision>
  </page>
  <page>
    <title>学習方法/高校5教科全般</title>
    <ns>0</ns>
    <id>19572</id>
    <revision>
      <id>205785</id>
      <parentid>167018</parentid>
      <timestamp>2022-07-24T11:12:39Z</timestamp>
      <contributor>
        <username>Nermer314</username>
        <id>62933</id>
      </contributor>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="29224" xml:space="preserve">{{独自研究の可能性}}
== 大まかな道筋 ==
=== 教科書・参考書を読む===
:※ この段階は、高校1年生から3年生まで、全学年を対象にしています。 

いきなり受験用の問題集を解こうにも、高校1年～2年では、まったく解けません。高校の授業レベルをきちんと理解することが基本ですが、それと並行して、教科書や参考書を自分で読むことが重要です。

まずは、教科書（ただし国語科目を除く）や参考書を読みすすめてください。文系科目は、参考書などで重要語句とか単語・熟語などを覚えてください。理系科目も、とりあえず参考書を読み進めて、参考書の問題練習を解いてください。

参考書はよく吟味し、少ない冊数に絞りこんでやりこむのが適切です。もちろん、参考書によって、伝統的な教育内容を中心的にあつかった参考書もあれば、近年の入試動向を反映した参考書、さらには近年の検定教科書のあつかう話題を組み込んだ参考書もあり、多種多様です。たとえば、文英堂シグマベストと数研出版チャート式と学研の高校参考書では、明らかに編集方針が違っています。ですので、複数冊所持することは一向にかまいませんが、やたら沢山買っても読みきれません。読み切れない読みかけの参考書の山を作るのが最も無駄の大きい学習法ですので、そうなるぐらいならばこれという参考書を決めて1冊やりこむ方が適切です。

=== 定期テストのレベルの問題集に取り組む ===
:※ この段階は、高校1年生と2年生を対象にしています。

ある程度教科書・参考書を読んだら、次は高校の定期テスト対策レベルの簡単な問題集に取り掛かり、読み終えたぶんの問題を練習します。
（このような定期テストレベルの問題集は、「ワークブック」などと呼ばれる。書店では、参考書コーナーに置いてあるのが普通。）

教科書・参考書を読むだけだと、書き取り練習や計算練習などができません。そこで、高校1年〜2年2学期くらいの段階では、高校生用の市販のワークブック（高校から配布される場合もある）を活用してください。書店の高校参考書コーナーの付近にあります。もし高校から教科書会社などの出版しているワークブックを配布されていたら、その配布されたワークブックを利用しても構いません。

教科書や参考書を読みつつ、必要に応じて、ワークブックの問題を解いてください。

参考書にも練習問題がある場合もありますが、問題量が不足してたり、問題レベルが初心者に合ってなかったりして、いきなり参考書の問題集に取りかかるのは非効率です。まずは「ワークブック」から練習するのが効率的です。

ただし、ワークブックは出題が基礎的な内容に限られているため、高校2年生の2学期くらいからは将来的に入試問題慣れをするため、受験を意識した問題集に切り替えましょう。

参考書を読み進めることと並行して、問題集での問題練習に取り掛かってください。

このさい、問題集には書き込みしないように。教科書にも、書き込みしない。今後の復習のためです。そして、なるべく早めに教科書や参考書の未読部分を通読し、教科書や参考書を読み終え、なるべく早めに簡単な問題集を終えてください。

国立志望などのように受験教科数が多い場合や、部活や委員会などに時間を取られる場合、高校2年終わりまでにワークブックが終わらないかもしれません。その場合、偏差値50以上の高校で普段から真面目に勉強してるなら、わざわざ3年生でワークブックを勉強する必要がありません。高校3年になったら、より実践的な問題集に時間を割くべきです。

さて、基本的なレベルの問題集だけだと入試を突破するのは難しいが、基本的なレベルの問題集も確実に解けないようでは入試を突破できるはずがない。まずは基本的なレベルの問題集もきちんと問題練習するべきです。

=== 定期テストの後に、復習を忘れずに ===
定期テストの前には言われなくても試験勉強をするでしょう。それはそれで、試験前の勉強も必要なのですが、しかし、定期テストをこなすだけで満足してはいけません。定期テスト後に、最低限、未修得の分野を復習する事が必要です。全国模試の場合も同様です。

=== 入試平均レベルの問題集に取り組む ===
:※ この段階は、高校2年生と3年生を対象にしています。
次に、入試対策用の問題集に取り組みます。まずは平均的な難度の大学向けの問題集でよいので、問題集を入手して、問題練習してください。この「標準的」とされる「入試」対策用の問題集ですら、現役の高校生には、解くのがかなり難しいです。なので、まだ「難関校むけ」の問題集には取り掛からないほうが良いでしょう。解けない問題集の解答冊子を読む作業ほど無駄な勉強はありません。たとえ難関校を志望する場合ですら、標準難度の入試問題を解く能力も要求されます。なので、志望校が難関校か中堅校かのどちらにせよ、平均的な難度の入試対策問題集を解きまくれる能力が、受験生のころまでに必要になります。難関校向けの問題集よりも、まず先に標準レベルの入試対策問題集を使用してください。

* 高校1年の読者の場合
高校1年生でも、授業で習うだろう数学IAや生物基礎などの入試問題は解けるかもしれませんが、入試問題集に深入りするのは2年以降で構いません。どうしても高1で入試問題集をしたい場合、センター試験対策の問題集にしておきましょう。

なお、たとえどんなに数学IAの入試難問が解けたところで、数学IIIの平均的な入試問題が解けなければ、理系のまともな大学には不合格です。どんなに生物基礎の難問が解けたところで、高2高3で習う生物（旧・生物II）科目の平均的な入試問題が解けなければ、理工学部の生物学科には不合格です。

=== 過去問に取り組む時期について ===
:※ この段階は、高校2年生と3年生を対象にしています。
大学入試対策の最後の仕上げとして、志望校の過去問に取り組みます。注意すべきなのは、過去問とは出題傾向や難度のレベルを調べるためのものであり、使用者の学力向上を第一目的としてはいないということです。眺めるのは早いに越したことはないですが、やりこむのは入試直前期だけで十分です。ただし、入試直前期には必ずやりこむべきです。特にセンター試験の過去問などは、試験馴れの目的も含めて、少なくとも過去数年分のセンター過去問ぐらいは練習したほうが良いでしょう。

高校3年になったばかりの時期では、過去問の得点が悪いのが通常&lt;ref&gt;『高校の勉強のトリセツ』、GAKKEN、136ページ&lt;/ref&gt;だと市販の学習ノウハウ本にも言われてますので、あまり過去問対策を急ぎすぎないようにしましょう。

== 教科ごとの学習のバランス ==
=== 英数国が基本 ===
特に受験直前ではない低学年の学習において、基本的な教科として重要なのは英語・数学・国語の3教科です。これは、これら3教科の学力をつけるには付け焼刃ではなく時間をかけたじっくりとした学習が必要なこと、これら3教科の学力をつけることが他教科の学習効率にもつながってくること、これら3教科は大学入試において大きな配点で課されることが多いこと、などによります。中でも大学入試においては、国語は文系、数学は理系において特に重視されがちですが、英語は文理ともに最重要な教科であり、1年生のときから英語の学習を重点的に行うことが推奨されます&lt;ref&gt;『高校の勉強のトリセツ』、GAKKEN、132ページ&lt;/ref&gt;&lt;ref&gt;船登惟希 『改訂版 高校一冊目の参考書』、KADOKAWA、2019年3月18日、136ページ&lt;/ref&gt;。大学入学後の学習にも英語力は文理とも必要なことを考えれば、当然と言えるかもしれません。数学に関しては、英語についで文理ともに重要であり時間のかかる教科ですので、英語についで早くから重点的に学習することが必要になります&lt;ref&gt;船登惟希『改訂版 高校の勉強のトリセツ』、GAKKEM、2020年3月31日 改訂版 第1刷、132ページ&lt;/ref&gt;。

=== 文理選択との兼ね合い ===
普通科の高校の多くでは、高校2年生から文系と理系に分かれたカリキュラムで学習するために&lt;ref&gt;『高校の勉強のトリセツ』、GAKKEN、126ページ&lt;/ref&gt;、その選択は実際には1年生の間に迫られることになります。大昔は3年生で初めて文理を選択することが主流の時代もありましたが、昨今の学習内容の増加により、それでは各教科の学習が十分できなくなっているためです。高校1年生で進路を真剣に考えなければならないというのはそれだけでとても高いハードルですが、厳しい言い方をすればもう高校生なのですから、自分のことは自分の頭で真剣に考え、適切な選択をしなければなりません。

2年生以降の学習では、文理選択によりカリキュラムが決まってくることで、学習する教科のバランスは自ずと希望する進路に最適化された形で調整されます。逆に言えば、そこから進路志望を変更すること（いわゆる文転など）は極めて厳しい道になりますので、文理選択の前に十分に進路について考えておく必要があります。

== ノートの使い方 ==
記憶の定着を図るために、授業の内容などをノートにとるという学習は有用かもしれません。

=== ノートづくりを目的にしてはならない ===
ノートを作る際に注意すべきなのは、ノートはあくまで手段であって、ノートづくりが目的ではないということです。複数の色のボールペンやマーカーを駆使して鮮やかなノートを作り上げる人がときどきいますが、その作業自体はあまり学習には役立たず、無駄な時間になることがほとんどです。

ノートは、書き取り練習だと割り切って、使ったほうが良いでしょう。手を動かして練習したいなら、ノートづくりをするよりも、語句の書き取り練習とか、あるいは問題練習などに時間を割いたほうが良いでしょう。「必要に応じて、ノートを作れる」という能力は、学習の結果・成果であって、けっして学習の手法ではありません。

=== カラフルなノートを作る必要は無い ===
たとえノートで色ペン・色マーカーを使うにして、せいぜい赤ボールペンまたは青ボールペンか、あるいは色マーカーの一本でもあれば、高校生のノートでは十分でしょう。べつに予備として青ペンとか5色マーカーとかを持っていても構いませんが、あまり色の使い分けを気にする必要はありません。教師が色チョークを使うたびにその色のペンでノートをとる人が多くみられますが、実は教師自身も使い分けを意識せずなんとなく別の色を使っている場合もあります。ですので、わざわざマーカーの色を語句によって使い分けることを、いちいち気にするぐらいなら、いっそのこと、ぜんぶ同じ色のペンで使ってしまったほうが良いでしょう。複数の色ペンを使い分ける労力があるなら、授業中ならば教師の説明を聞いて理解することに集中してください。家庭学習なら、複数の色ペンを使いわける労力があるんだったら、その時間を使って参考書を読み込むとか、問題練習とかをしたほうが良いでしょう。

=== 書き取り練習 ===
英語や社会科や古文漢文などの文系科目において、ある程度の書き取り練習は必要ですが、すべてを丸暗記しようとして1度に10回や20回もの書き取りをするような学習はやめましょう。高校では中学のように易しい内容ばかりを問うてはくれませんので、丸暗記ではとても乗り切れないのです。

高校生の文系科目の勉強法は、まずは、ひととおり教科書・参考書の各章・各節を読みおえたら、重要語句を覚えたり、その周辺の知識を覚えるなどしましょう。このとき、細部の丸暗記は後回しで、全体の流れを理解するように努めましょう。

しかし、社会科の場合、何十回と書き取るヒマがあるなら、市販の用語集などを読み込んだほうがマシでしょう。 

なお、共通テストはマークシート方式のため、社会科の用語の漢字を問う問題などの書き取りは出題されないので、注意のこと。

また、書き取りの他にも、教科書・参考書を声に出して読んだりと自分で勉強方法を工夫しましょう。

=== ノートと雑紙 ===
高校の5教科の家庭学習では、ノートの復習・整理よりも、書き取り練習用の用紙や、あるいは計算練習用の用紙などの「雑紙」が、必要になります。なので紙の枚数のことを気にせずに好きなだけ書き取り練習などに使えるような「紙」はたくさん用意しておくべきです。不要になったプリントの裏紙など、なるべく遠慮なく使い捨てられる紙を、たくさんストックしておくとよいでしょう。そのような紙を用いて、書き取り練習をしたり、計算練習をしたり、問題練習をしたりと、どんどん手を動かして記憶や理解を定着させる練習作業のほうが、はるかに学習として役に立ちます。

もしノートに知識をまとめるなら、雑紙で練習したあとの自分の知識をまとめたものをノートにきれいに記すとよいでしょう。むろん「きれいに」というのは日本語の「てにをは」をしっかり補って答案を作成するということで、けっして色鮮やかにすることではありません。

=== ノートの提出・チェックなど ===
そうして、もし、そこそこ整理されたノートがあれば、機会があれば、学校教員または塾講師などに確認してもらえるように、彼ら教員・講師などに頼んでください。ここで、採点者に通用する答案を作成する練習をすることができます。単にノートで知識を整理するだけでは、あまり論述の練習にはなりません。だれかにノートの質を確認してもらう必要があります。質の確認の取れてないノートは、その時点では、まだ単なる鉛筆で書き込みされた紙の集まりに過ぎません。

ただし、教員にも仕事があるでしょうし、あなた以外の生徒も相手にしないといけませんので、無理にはノート確認をお願いしてはいけません。塾講師などを利用する必要があるかもしれません。もし、教員や塾講師が忙しくて、あなたのノート確認まで時間を取れないなら、自分でワークブックや問題集などで問題練習して、知識の質を確認します。簡単なワークブックとか、簡単な問題集などでも良いので、それらの教材を利用して問題練習することで、知識の質を検証してください。

さて、学校によっては、ノート提出を学生に要求する場合もあります。もし、そういう機会があれば、せっかくの機会を利用して、ノートを提出して教員に確認してもらいましょう。また、レポート課題などを出す学校もあります。ノートに整理した内容がレポートに利用できそうであれば、せっかくノートにまとめたのですから、その内容をレポートにも利用しましょう。

ただし何度も注意していますが、ノート作りはあくまで補助であって、けっしてノートづくりが目的ではありません。無理にノート作りに時間を割く必要はありません。また、無理にノートを教員・塾講師などに提出・確認依頼する必要もありません。「もし、そこそこ整理されたノートがあれば、」というふうに「もし」という条件つきです。ノートの整理のために、書き取り練習などの時間を減らしてしまうのは、本末転倒です。

ノート作りは、自然に授業中の内容とかをノートにメモしていく程度で良いのです。自然にそこそこのノートが出来上がれば、せっかくノートがあるのでしょうから、利用するのも一手というだけです。

=== ノートを書かない ===
思い切ってノートを全く書かないというのも一つの手です。せっかく苦労してノートを書いても、専門家の書いた教科書・参考書には遠く及びません。それならば、最初から既に完成された教科書・参考書を使って勉強したほうが良いでしょう。

== 教科書ガイドについて ==
教科書ガイドの使い方について、次の2通りの意見が提出され、議論になっています。読者は、自己責任で判断してください。

=== 説1 ===
書店には、「教科書ガイド」があふれています。特に古典や英語なら、これがあれば予習のためにわざわざ自分で訳を考える必要はない、という代物です。教科書ガイドは、次のような目的には大いに役に立ちます。

* 目前の授業でとりあえず教員に怒られないで済ませるため
* 目前の定期テストでとりあえず赤点をとらないため

一方、次のような目的には全く役に立ちません。

* 大学受験に対応できる学力をつけるため

そもそもなぜ授業の予習で訳をさせるのでしょう。それは、訳を覚えるためではありません。なにしろ、教科書に載っているのとまったく同じ文章は、（稀に不注意な大学がうっかり「やらかす」ことを除けば）受験には絶対に出ないのです。授業の予習で訳をするのは、訳をするという経験を積むことによって、次に見る文章は自分で訳せるようにそのノウハウを身につけるためです。出来上がった訳などはどうでもよく、訳を作るという経験が重要なのです。その経験をすっ飛ばしてしまう教科書ガイドは、百害あって一利なしです。赤点をとらなければそれでいい、というのであれば構いませんが、学力をつけたいと思うのであれば、次の古紙回収の日にまとめて捨ててしまいましょう。

=== 説2 ===
古典や英語なら、教科書ガイドがあれば、自分で訳を調べる手間が、かなり省けます。古典の場合、訳を考える必要が英語よりも少ないため、古典の教科書ガイドに現代語訳がすでに書かれており、古典の教科書ガイドは大いに役に立ちます。（とはいえ、古文単語集なども勉強しておきましょう。）

また、古典の市販の和訳集は、たとえ高校生向けのものでも、巻号（「第○○巻」などのこと）ごとに特定の作品にばかり深入りしているものが多く（たとえば第1巻は1冊まるごと「枕草子」とか）、入試動向とはズレているので、リスク分散のためにも、古典の教科書ガイドを何冊か購入して読んでおくのが安全でしょう。

また、国語では現代文の場合でも、著作権の理由などか、国語の市販の参考書では解説の書かれていない作品についても、教科書ガイドで解説が書かれており、参考になる場合があります。

ただし、古典を除けば、英語や現代文では、教科書とまったく同じ文章は、普通は入試には出ないので、入試対策としては、あまり教科書ガイドは役立ちません。

なので、その教科の入試動向が分からないうちは、なるべく普段の学習では、教科書ガイドでなく、まずは参考書で勉強しましょう。例外的に、教科書ガイドも深く読んだほうが入試対策もふくめて勉強しやすい科目や事柄（古典の訳、定期テスト対策など）だけ、教科書ガイドで勉強するのが効率的でしょう。

なお、英語の教科書ガイドには、そもそも、教科書の英文そのままの翻訳は教科書ガイドには書いておらず、かわりに教科書で使用されている熟語や構文などの解説が書いてあるだけです。結局、教科書ガイドを読んでも、自分で和文翻訳を考える必要が残ります。英語の教科書ガイドは、単に辞書や単語集を調べる手間を減らすためのものです。

教科書ガイドだけで勉強していると、本来は理解できていない構文でも、教科書の構文まるごと訳を覚えてしまったりして、それでも定期試験では高得点がとれてしまう場合もあり、ついつい「理解したつもり」になってしまいがちです。なので、英語の教科書ガイドにある（構文や熟語などの）翻訳は、あくまでも定期テスト前などの確認の用途にしておきましょう。

もし、自分のこれから勉強しようとする教科が、教科書ガイドを使用せずとも充分に勉強できる教科であれば（例えば数学や理科では、教科書ガイドを使う機会がない場合がほとんど）、むしろ、わざわざ教科書ガイドを購入しないほうが、「理解したつもり」に陥る（おちいる）ことを防げるので、安全かもしれません。

同様に、国語や英語などの定期試験対策をする場合でも、なるべく、教科書ガイドに頼る時間を減らすように努力しましょう。そのため、教科書ガイドだけを購入するのではなく、5教科の参考書も購入しましょう。

また、国語の古典でも、平均レベルを越えた大学の場合、検定教科書でも扱ってない作品を出題する事があるので、教科書ガイド以外に古文単語集などの勉強も必要です。

なお、どの教科でも、授業ではその教科書すべてを扱いきれず、いくつかの単元が未習になる場合もあります。そのような場合に、独学したい場合に、教科書ガイドは活用できます。センター試験の出題範囲は、その科目の検定教科書の範囲を参考にしていますので、時間に余裕があれば、検定教科書の未集でやり残した範囲も勉強しておくと、入試対策としても安全です。

教科書ガイドがなくても、参考書などを頼りにして、ある程度は独学する事はできますが、しかし教科によっては（国語など）、教科書の問題の答え合わせが、参考書だけではできない場合があります。そのような場合の、教科書の答え合わせに、教科書ガイドが役立ちます。
特に国語の場合、参考書でも扱っていない作品があり、すべての作品の解説を購入するのは無理なので（金銭的にも難しいし、そもそも現代文では高校生向けの解説書が販売されてない作品がほとんど）、独学の際にも役立ちます。

教員の中には、不適切な量の予習を要求する教師もいて、そのような教師への対策としても教科書ガイドが有効な場合があります。生徒にはまず全教科の学習があるということを無視して、いたずらに自分の担当科目ばかり、大量の予習を要求したりする指導などがありますが、しかし教科書ガイドがあれば予習がしやすくなり、そのような不適切指導による負担が軽減されます。

学校教員のなかには、教科書ガイドの内容をよく知らずに、憶測だけで「教科書ガイドを使うべきではない。教科書ガイドは役に立たない。」という主旨の指導をする人も、ときどき居ます。ですが、教科書ガイドの出版社も、それほど馬鹿ではないので、マジメな高校生が読んでも役立つように内容を工夫しています。

もし、教科書ガイドによって、教員の授業の価値が成り立たなくなるとしたら、役に立たないのは教科書ガイドではなく、教科書本体に何らかの欠陥があるのでしょう。裏をかえせば、数学や理科などのように、教科書ガイドがなくても、教科書と参考書だけで充分に勉強できる教科では、当然ながら、教科書ガイドは、あまり役立ちません。

なので、その教科・科目の特徴や入試傾向によって、教科書ガイドを購入するかどうか、使い分けましょう。


== バランスよく学習する ==
教科ごとの学習量のバランスにも注意しましょう。特定の科目に偏るのではなく、全教科をしっかり学習することが、進路実現のためにも役に立つのです。このように言うのは簡単ですが、各教科の担当教員ごとに予習復習や課題の要求量が違いますので、ついつい課題の多い教科の学習に偏りがちです。ですので、バランスよく学習するためには、そのような意識を常に持っていることが不可欠なのです。

※ 次の2通りの意見が提出され、議論になっています。
:意見A: 2年生前半までは英数国の3教科の力をしっかりまんべんなく伸ばしましょう。

:意見B: 2年生前半までは英数国の3教科の力を中心に、高校で習う全ての教科を伸ばしましょう。

これらの教科はどのような進路を選ぶにしろ学習を避けられませんし、力をつけるのに時間のかかる教科です。2年生後半からは理社にも力を入れ、5教科のバランスを整えていくことになります。このときまだ英数国の基礎力が不十分だと、理社まで手が回らず、どっちつかずでどうしようもなくなります。1年生から2年生前半までで英数国に穴をつくらないことが必要不可欠です。


== 塾・予備校の注意点 ==
塾や予備校の中には、不適切な指導をするところもあるので、注意が必要です。生徒にはまず学校での学習があり、他科目の学習があるということを無視して、いたずらに自分の担当科目の、自分の塾オリジナルの、不必要な難問を含んでいたりする教材を勉強させたり、大量の宿題を要求したりする指導などが代表的でしょう。

志望校や受験校の選択についても、過度に現役合格にこだわるあまりの不適切な指導をされることもしばしばあります。こういった指導をする塾や予備校は、市場原理で淘汰されてはいるものの、根絶されてはいません。その塾・予備校に相談しても改善が見られない場合、保護者に相談して、他の塾・予備校に変えるなどの対策が必要です。

== 脚注・参考文献 ==</text>
      <sha1>ayomalk5ljfu63mluxzldy0mp65fatl</sha1>
    </revision>
  </page>
  <page>
    <title>高等学校日本史B/古墳とヤマト王権</title>
    <ns>0</ns>
    <id>21683</id>
    <revision>
      <id>205729</id>
      <parentid>205641</parentid>
      <timestamp>2022-07-23T13:56:01Z</timestamp>
      <contributor>
        <username>椎楽</username>
        <id>32225</id>
      </contributor>
      <comment>カテゴリとテンプレ追加</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="17805" xml:space="preserve">{{Nav}}
== 古墳の出現 ==
[[画像:NintokuTomb Aerial photograph 2007.jpg|thumb|left|大仙（だいせん）古墳。百舌鳥（もず）古墳群の中心的な古墳で、被葬者は仁徳（にんとく）天皇と考えられているが、諸説ある。（大阪府堺市）]]
[[File:Bronze Mirror in Ancient Japan.jpg|thumb|三角縁神獣鏡（さんかくぶちしんじゅうきょう）]]
[[File:KofunSoldier.jpg|thumb|140px|埴輪。武装男子立像（群馬県太田市出土）東京国立博物館蔵、国宝]]

3世紀後半には'''古墳'''が造られるようになっていた。特に巨大な古墳が奈良県の大和（やまと）に多く、この奈良を中心にして少なくとも近畿地方一帯を支配する強大な政権があったと考えられ、これを'''ヤマト王権'''や'''ヤマト政権'''などと呼ぶ。

古墳の分布から考えると、4世紀中頃までにヤマト王権による支配領域が、九州北部から東北地方南部にまで広がっていったと考えられている。

古墳の形には、さまざまな形があるが、特に巨大な古墳には前方後円墳が多い。また、数が多いのは円墳や方墳である。古墳の多くは、表面に石が葺かれ、'''埴輪'''（はにわ）なども置かれた。内部には石室（せきしつ）があり、石室には石棺や木棺などの棺がおさめられた。このほか、さまざまな副葬品がおさめられた。副葬品には、古墳時代のはじめごろは銅鏡や銅剣などがおさめられた。有名な銅鏡としては、'''三角縁神獣鏡'''（さんかくぶちしんじゅうきょう）などがある。

最大規模の古墳は、大阪府にある'''前方後円墳'''（ぜんぽうこうえんふん）の'''大仙古墳'''（だいせんこふん）であり、大王陵と考えられている。

== ヤマト王権 ==
=== 近畿豪族の連合 ===
特に大きな古墳が、大和（やまと、奈良県）や河内（かわち、大阪府）を中心に多く作られているので、近畿地方を中心に、有力な豪族たちがいたと思われている。この近畿地方の有力な豪族たちは連合政権を形成しており、この政権を指して、現代では'''ヤマト王権'''（ヤマトおうけん）、'''ヤマト政権'''などという。


4世紀〜5世紀には、前方後円墳が、大和地方だけでなく、各地に広がっていく。5世紀の後半には、ヤマト王権は九州から関東までを支配していた。また、各地に前方後円墳があることから、

この大和にいた、有力な豪族たちの連合体であるヤマト王権が、のちに日本を支配していき、のちの飛鳥時代の朝廷（ちょうてい）になっていく。


[[File:Inariyama sword.JPG|thumb|350px|right|まんなかにある、たてに長い茶色いのが、発掘された鉄剣。金錯銘鉄剣（国宝、埼玉県立さきたま史跡の博物館）]]
埼玉県の稲荷山古墳から見つかった鉄剣には、&lt;big&gt;'''ワカタケル'''大王&lt;/big&gt;（ワカタケルだいおう、ワカタケルおおきみ）の名が刻まれた文が、刻まれてあります。文を読むと、この地方の王は、ワカタケル大王に使えていたらしいです。

熊本県の 江田船山（えた ふなやま）古墳 にも、おなじ名前の刻まれた鉄刀（てっとう）があり、ワカタケル大王の支配する領域が、関東地方から九州までの広い範囲（はんい）に、およんでいたことが、分かります。

正確に言うと、当時はまだ漢字しか文字がなかったので、稲荷山の鉄剣には115字の漢字が刻まれており、その漢字の中に「獲加多支鹵大王」（ワカタケル大王）という名が、刻まれています。　

また江田船山の鉄刀には、刻まれた文が破損しており、「獲□□□鹵大王」（ワ？？？ル大王　？）というふうに名前の一部が読めなくなっています。（□が破損部とする。）

後の日本の神話の書の『古事記』（こじき）や、後の歴史書の『日本書紀』（にほんしょき）などから「ワカタケル」という人物の存在が知られているので、鉄剣などがワカタケルの存在をうらづける証拠になったのです。日本書紀に「幼武天皇」（わかたけ てんのう）という記述があるのです。
ワカタケル大王とは、&lt;big&gt;雄略天皇&lt;/big&gt;（ゆうりゃくてんのう）だということが分かっています。

この大和にいた、有力な豪族、および、この大和の地域の有力な豪族たちの連合体が、のちに日本を支配していき、のちの飛鳥時代の朝廷（ちょうてい）になっていく。

大和にいた、有力な豪族、および、この大和の地域の有力な豪族たちの連合体のことを、現代の歴史学では「ヤマト政権」とか「ヤマト王権」とかという。べつに当時の人が「ヤマト政権」と呼んでいたわけではない。

ヤマト政権が、のちの時代に朝廷になるといっても、古墳時代の始めや中頃では、まだヤマト政権は各地の豪族のうちの一部にしか、すぎない。のちの時代の天皇も、先祖をたどれば、（おそらく大和地方にいただろう）有力な豪族のうちの一つでしかない。

古墳時代の始めのうちは、まだ日本の統一がほとんど進んでおらず、ヤマト王権は、まだ、今の日本語で言う「朝廷」と呼べるような段階には至ってない。ヤマト王権が、古墳時代での各地の政権の統一をへて、のちの飛鳥時代の朝廷へと、なっていく。

=== 大王の出現 ===
[[画像:NintokuTomb Aerial photograph 2007.jpg|thumb|left|仁徳（にんとく）天皇陵（てんのうりょう）と思われている大仙たいせん古墳&lt;br /&gt;大阪府堺市。前方後円墳（ぜんぽう こうえんふん） 。]]
5世紀の後半ごろから、ヤマト王権は、ほぼ各地を平定した。
日本では、ヤマト王権の中の、もっとも有力な支配者を、'''大王'''（おおきみ）と呼んでいた。稲荷山古墳（いなりやま こふん、埼玉県）から出土した鉄剣の銘文で、みずから「大王」と読んでいる。中国では「倭王」（わおう）と呼んでいた階級であろう。大王の一族は、のちの天皇の一族である。たとえば、5世紀の中ごろに近畿地方に作られた大仙（だいせん）古墳は、大王の墓だと思われている。

そして、各地の豪族たちはヤマト王権に仕えた。

このころには、ほぼ政権の権力が安定しており、ヤマト王権の政治組織を整えられるようになった。そして、さまざまな政治の制度が作られた。

== 古墳の変化 ==
やがて古墳には、鉄製の武具や馬具、農具や土器などの生活用品も、石室におさめられるようになった。つまり、古墳が、死後の生活の場と考えられた。副葬された土器には、土師器（はじき）や須恵器（すえき）などが納められた。'''須恵器'''（すえき）は、5世紀に朝鮮半島から伝わった土器であり、灰色で堅い。'''土師器'''（はじき）は、須恵器伝来前からある在来の土器であり。弥生土器の系統をひき、赤い。

須恵器の製法は、丘（おか）などの斜めになってる地面の斜面をくりぬいて穴窯（あながま）を作り、その穴窯の中で土器を焼き固めるという、のぼり窯（のぼりがま）を用いた方法です。野焼きよりも高温に焼けるので、かたい土器が焼きあがるというわけです。
縄文土器は、野焼きの土器でした。弥生土器も、のぼり窯は用いていません。

石室は従来は竪穴式であったが、6世紀になると'''横穴式石室'''（よこあなしき せきしつ）が一般化してきた。これは朝鮮半島の風習と近く、日本が朝鮮半島から影響を受けたと思われる。


== 氏姓制度 ==
豪族は、血縁をもとに、氏（うじ）という集団を作っていた。氏を単位に、ヤマト王権の職務を担っていた。そして、豪族たちの名前に関する制度で、氏（うじ）と姓（かばね）とによる、後に言う'''氏姓制度'''（しせい せいど）が、作られた。
姓は、大王から、その氏の職務に応じて授けられた。

&lt;span style=&quot;color:red&quot;&gt;&lt;big&gt;氏&lt;/big&gt;&lt;/span&gt;（うじ）とは、主に、血のつながった者どうしの集団である。&lt;span style=&quot;color:red&quot;&gt;&lt;big&gt;姓&lt;/big&gt;&lt;/span&gt;（かばね）とは、政治の地位による称号（しょうごう）で、たとえば「臣」（おみ）や「連」（むらじ）という姓が、あります。

氏の代表者を氏上（うじのかみ）という。氏の構成員を氏人（うじびと）という。氏とは、その氏上や氏人などから成り立つ、組織であった。

有力な豪族の氏には、たとえば蘇我氏（そが し）・物部氏（もののべ し）・大伴氏（おおとも し）などが、あります

政治の仕事を行なう豪族には、さらに姓（かばね）が与えられた。中央の政治の姓には、臣（おみ）、連（むらじ）の姓が与えられ、中でも有力な豪族には'''大臣'''（おおおみ）、'''大連'''（おおむらじ）の姓が与えられた。

例えば、蘇我氏には「臣」（おみ）という姓（かばね）が与えられた。大伴や物部には「連」（むらじ）という姓（かばね）が与えられました。

そして、手工業や軍事などの管理にたずさわる豪族は、それよりも低い地位に置かれ、'''伴造'''（とものみやつこ）などの姓が与えられた。そして、その管理者のしたで働く、伴（とも）や部（べ）などの集団を、伴造などが管理した。

部には、様々な専門職であったらしい品部（しなべ）や、豪族の私有する民の部曲（かきべ）がある。

このような改革により、6世紀の半ばごろまでには、ヤマト王権による中央集権的な日本各地の支配が進み、のちの時代で言う「朝廷」のようなものが出来ていったと考えられる。


== 日本と外国との関係 ==

=== 中国 ===
[[File:Map of Northern Wei and Liu Song Dynasty ja.png|thumb|600px]]
終わりごろ、中国では「宋」（そう）という国が、中国の南部を治めていた。この時代、中国は北朝（ほくちょう）である、北魏（ほくぎ）と、南朝（なんちょう）である宋（そう）という、2つの国に分かれていて、南北の王朝が争っていた。

その宋の歴史書の『'''宋書'''』'''倭国伝'''（そうじょ わこくでん）では、５世紀に中国の王朝である宋に、日本からの外交で、日本の5人の大王が、それぞれ外交の使者を送ってきたことが、『宋書』に書かれています。
５人の王の名は、宋書によると、それぞれ讃（さん）、珍（ちん）、済（せい）、興（こう）、武（ぶ）という名です。
この５人の倭国の王を &lt;big&gt;倭の五王&lt;/big&gt;（わのごおう） といいます。日本は、高句麗との戦争で優位に立ちたいので、宋の支援（しえん）が、ほしかったのです。

この5人の王が、どの天皇か、それとも天皇ではない別の勢力なのか、いろんな説がある。

有力な説では、武（ぶ）は、日本書紀に「幼武天皇」（わかたけ てんのう）という記述のあるワカタケル大王のことだろうと思われています。つまり雄略天皇が武（ぶ）だろうと思われています。


*倭王（わおう）武（ぶ）の上奏文（じょうそうぶん）
この時代の倭王の「武」（ぶ）が、中国に送った手紙には、つぎのようなことが書かれています。


{| style=&quot;width:100%&quot;
|valign=top style=&quot;width:60%;text-indent:1em&quot;|

&lt;div style=&quot;border:1px solid #000000;&quot;&gt;
　'''倭王武の上奏文'''（抜粋）　（『宋書』倭国伝）
:興死して弟武立つ。自ら（みずから）使持節都督（しじせつととく）倭・百済・新羅・任那・加羅・秦韓（しんかん）・慕韓（ぼかん）・七国諸軍事安東（あんとう）大将軍倭国王と称す。
:順（じゅん）帝の昇明（しょうめい）二年、使を遣して表を上りて（たてまつりて）曰く、「報国（ほうこく）は偏遠（へんえん）にして、藩を外（そと）に作す（なす）。昔より祖禰（そでい）躬ら（みずから）甲冑を擐き（つらぬき）、山川を跋渉（ばっしょう）して、寧処に（いとま）あらず。東は毛人（もうじん）を征すること五十五国、西は衆夷（しゅうい）を服すること六十六国、渡りて海北を平ぐること九十五国」と。

::（『宋書』倭国伝、原文は漢文）
&lt;/div&gt;

|valign=top style=&quot;width:5%;text-indent:1em&quot;|
|valign=top style=&quot;width:35%;text-indent:1em&quot;|

&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;

「皇帝から臣下としての地位を受けた我が国は、中国から遠く離れた所を領域としています。
昔から私の祖先は、みずから よろい・かぶとを身につけ、山や川を踏み越え、休む日もなく、東は毛人（もうじん）の国（毛人＝おそらく東北地方の蝦夷（えみし））55か国を平定し、西は衆夷（しゅうい）の国（衆夷＝おそらく九州の熊襲（くまそ））66か国を平定しました。さらに海をわたって、海北（かいほく）の（海北 ＝おそらく朝鮮半島）９５か国を平定しました。

::（和訳して抜粋）

|}

このような内容が書かれています。この倭王が中国に送った手紙を、一般に、倭王武の上奏文（わおう ぶ の じょうそうぶん）と言います。「上奏」（じょうそう）とは、格下の者が、目上の地位の者に、申し上げることです。

なお、最終的に中国の南北朝を統一する国は、「隋」（ずい）という国によって6世紀おわりごろに統一されます。南北朝の次の王朝は、隋（ずい）王朝になります。

=== 朝鮮半島 ===
[[File:History of Korea 375 ja.png|330px|thumb|left|375年頃の朝鮮半島]]
[[File:Rubbing of the Gwanggaeto Stele.jpg|thumb|碑文の複製 1882年頃作成、東京国立博物館]]
4世紀には、朝鮮半島は国が分裂していた。南西部の百済（くだら、ペクチェ）と、東部の新羅（しらぎ、シルラ）と、北部の高句麗（こうくり、コグリョ）と、その他のいくつかの小国があった南部の伽耶（かや、カヤ）地方に分裂していて、おたがいに争っていた。伽耶（かや、カヤ）のことを任那（みまな）、あるいは加羅（から）ともいう。

伽耶は半島の南部にあり、百済は、南西部にあった。日本は、鉄の資源などをもとめて、南部や南西部の、伽耶や百済と交流があった。

日本は、伽耶（かや、カヤ）と百済（くだら、ペクチェ）に協力した。
日本は百済（くだら、ペクチェ）と連合して、敵である新羅（しらぎ、シルラ）および高句麗（こうくり、コグリョ）と戦う。

朝鮮半島での、広開土王（こうかいどおう）の碑文（ひぶん）によると、倭が高句麗（こうくり）との戦争を4世紀後半にしたことが書かれています。この戦いでは高句麗が勝って、倭の軍をやぶったそうです。広開土王は好太王（こうたいおう）とも言います。

なお最終的に、朝鮮半島を統一した国は新羅（しらぎ、シルラ）であり、7世紀に新羅が朝鮮半島を統一する。
{{clear}}

== 磐井の乱（いわいのらん） ==
6世紀はじめ、九州の北部で、大和朝廷に逆らう、大規模な反乱が527年に起きる。豪族の筑紫国造（つくしのくにのみやつこ）磐井（いわい）が、新羅とむすんで反乱を指揮した。朝鮮半島での、百済をすくうための出兵の負担への反発が、きっかけ。
この反乱のことを '''磐井の乱'''（いわい の らん） という。

ヤマト王権は、この反乱（磐井の乱）をおさえるのに、1年あまリ〜2年ほど、かかる。


== ヤマト王権の政治制度 ==
6世紀、ヤマト王権に服従した地方豪族は'''国造'''（くにのみやつこ）として任命された。

また、各地に、ヤマト王権の直轄地が設置され、その直轄地は'''屯倉'''（みやけ）という。

また、直轄民として従属する部の民を'''名代'''（なしろ）、'''子代'''（こしろ）とし、地方豪族に従属する民を'''部曲'''（かきべ）と呼んだ。

いっぽう、有力な豪族の私有地を'''田荘'''（たどころ）といい、有力な豪族が私有地を持っていた。
[[category:高等学校日本史|ほうけんへいしのらん]]</text>
      <sha1>ecger51a3ztadquishqzroh4zuxqdct</sha1>
    </revision>
    <revision>
      <id>205730</id>
      <parentid>205729</parentid>
      <timestamp>2022-07-23T13:56:38Z</timestamp>
      <contributor>
        <username>椎楽</username>
        <id>32225</id>
      </contributor>
      <minor />
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="17808" xml:space="preserve">{{Nav}}
== 古墳の出現 ==
[[画像:NintokuTomb Aerial photograph 2007.jpg|thumb|left|大仙（だいせん）古墳。百舌鳥（もず）古墳群の中心的な古墳で、被葬者は仁徳（にんとく）天皇と考えられているが、諸説ある。（大阪府堺市）]]
[[File:Bronze Mirror in Ancient Japan.jpg|thumb|三角縁神獣鏡（さんかくぶちしんじゅうきょう）]]
[[File:KofunSoldier.jpg|thumb|140px|埴輪。武装男子立像（群馬県太田市出土）東京国立博物館蔵、国宝]]

3世紀後半には'''古墳'''が造られるようになっていた。特に巨大な古墳が奈良県の大和（やまと）に多く、この奈良を中心にして少なくとも近畿地方一帯を支配する強大な政権があったと考えられ、これを'''ヤマト王権'''や'''ヤマト政権'''などと呼ぶ。

古墳の分布から考えると、4世紀中頃までにヤマト王権による支配領域が、九州北部から東北地方南部にまで広がっていったと考えられている。

古墳の形には、さまざまな形があるが、特に巨大な古墳には前方後円墳が多い。また、数が多いのは円墳や方墳である。古墳の多くは、表面に石が葺かれ、'''埴輪'''（はにわ）なども置かれた。内部には石室（せきしつ）があり、石室には石棺や木棺などの棺がおさめられた。このほか、さまざまな副葬品がおさめられた。副葬品には、古墳時代のはじめごろは銅鏡や銅剣などがおさめられた。有名な銅鏡としては、'''三角縁神獣鏡'''（さんかくぶちしんじゅうきょう）などがある。

最大規模の古墳は、大阪府にある'''前方後円墳'''（ぜんぽうこうえんふん）の'''大仙古墳'''（だいせんこふん）であり、大王陵と考えられている。

== ヤマト王権 ==
=== 近畿豪族の連合 ===
特に大きな古墳が、大和（やまと、奈良県）や河内（かわち、大阪府）を中心に多く作られているので、近畿地方を中心に、有力な豪族たちがいたと思われている。この近畿地方の有力な豪族たちは連合政権を形成しており、この政権を指して、現代では'''ヤマト王権'''（ヤマトおうけん）、'''ヤマト政権'''などという。


4世紀〜5世紀には、前方後円墳が、大和地方だけでなく、各地に広がっていく。5世紀の後半には、ヤマト王権は九州から関東までを支配していた。また、各地に前方後円墳があることから、

この大和にいた、有力な豪族たちの連合体であるヤマト王権が、のちに日本を支配していき、のちの飛鳥時代の朝廷（ちょうてい）になっていく。


[[File:Inariyama sword.JPG|thumb|350px|right|まんなかにある、たてに長い茶色いのが、発掘された鉄剣。金錯銘鉄剣（国宝、埼玉県立さきたま史跡の博物館）]]
埼玉県の稲荷山古墳から見つかった鉄剣には、&lt;big&gt;'''ワカタケル'''大王&lt;/big&gt;（ワカタケルだいおう、ワカタケルおおきみ）の名が刻まれた文が、刻まれてあります。文を読むと、この地方の王は、ワカタケル大王に使えていたらしいです。

熊本県の 江田船山（えた ふなやま）古墳 にも、おなじ名前の刻まれた鉄刀（てっとう）があり、ワカタケル大王の支配する領域が、関東地方から九州までの広い範囲（はんい）に、およんでいたことが、分かります。

正確に言うと、当時はまだ漢字しか文字がなかったので、稲荷山の鉄剣には115字の漢字が刻まれており、その漢字の中に「獲加多支鹵大王」（ワカタケル大王）という名が、刻まれています。　

また江田船山の鉄刀には、刻まれた文が破損しており、「獲□□□鹵大王」（ワ？？？ル大王　？）というふうに名前の一部が読めなくなっています。（□が破損部とする。）

後の日本の神話の書の『古事記』（こじき）や、後の歴史書の『日本書紀』（にほんしょき）などから「ワカタケル」という人物の存在が知られているので、鉄剣などがワカタケルの存在をうらづける証拠になったのです。日本書紀に「幼武天皇」（わかたけ てんのう）という記述があるのです。
ワカタケル大王とは、&lt;big&gt;雄略天皇&lt;/big&gt;（ゆうりゃくてんのう）だということが分かっています。

この大和にいた、有力な豪族、および、この大和の地域の有力な豪族たちの連合体が、のちに日本を支配していき、のちの飛鳥時代の朝廷（ちょうてい）になっていく。

大和にいた、有力な豪族、および、この大和の地域の有力な豪族たちの連合体のことを、現代の歴史学では「ヤマト政権」とか「ヤマト王権」とかという。べつに当時の人が「ヤマト政権」と呼んでいたわけではない。

ヤマト政権が、のちの時代に朝廷になるといっても、古墳時代の始めや中頃では、まだヤマト政権は各地の豪族のうちの一部にしか、すぎない。のちの時代の天皇も、先祖をたどれば、（おそらく大和地方にいただろう）有力な豪族のうちの一つでしかない。

古墳時代の始めのうちは、まだ日本の統一がほとんど進んでおらず、ヤマト王権は、まだ、今の日本語で言う「朝廷」と呼べるような段階には至ってない。ヤマト王権が、古墳時代での各地の政権の統一をへて、のちの飛鳥時代の朝廷へと、なっていく。

=== 大王の出現 ===
[[画像:NintokuTomb Aerial photograph 2007.jpg|thumb|left|仁徳（にんとく）天皇陵（てんのうりょう）と思われている大仙たいせん古墳&lt;br /&gt;大阪府堺市。前方後円墳（ぜんぽう こうえんふん） 。]]
5世紀の後半ごろから、ヤマト王権は、ほぼ各地を平定した。
日本では、ヤマト王権の中の、もっとも有力な支配者を、'''大王'''（おおきみ）と呼んでいた。稲荷山古墳（いなりやま こふん、埼玉県）から出土した鉄剣の銘文で、みずから「大王」と読んでいる。中国では「倭王」（わおう）と呼んでいた階級であろう。大王の一族は、のちの天皇の一族である。たとえば、5世紀の中ごろに近畿地方に作られた大仙（だいせん）古墳は、大王の墓だと思われている。

そして、各地の豪族たちはヤマト王権に仕えた。

このころには、ほぼ政権の権力が安定しており、ヤマト王権の政治組織を整えられるようになった。そして、さまざまな政治の制度が作られた。

== 古墳の変化 ==
やがて古墳には、鉄製の武具や馬具、農具や土器などの生活用品も、石室におさめられるようになった。つまり、古墳が、死後の生活の場と考えられた。副葬された土器には、土師器（はじき）や須恵器（すえき）などが納められた。'''須恵器'''（すえき）は、5世紀に朝鮮半島から伝わった土器であり、灰色で堅い。'''土師器'''（はじき）は、須恵器伝来前からある在来の土器であり。弥生土器の系統をひき、赤い。

須恵器の製法は、丘（おか）などの斜めになってる地面の斜面をくりぬいて穴窯（あながま）を作り、その穴窯の中で土器を焼き固めるという、のぼり窯（のぼりがま）を用いた方法です。野焼きよりも高温に焼けるので、かたい土器が焼きあがるというわけです。
縄文土器は、野焼きの土器でした。弥生土器も、のぼり窯は用いていません。

石室は従来は竪穴式であったが、6世紀になると'''横穴式石室'''（よこあなしき せきしつ）が一般化してきた。これは朝鮮半島の風習と近く、日本が朝鮮半島から影響を受けたと思われる。


== 氏姓制度 ==
豪族は、血縁をもとに、氏（うじ）という集団を作っていた。氏を単位に、ヤマト王権の職務を担っていた。そして、豪族たちの名前に関する制度で、氏（うじ）と姓（かばね）とによる、後に言う'''氏姓制度'''（しせい せいど）が、作られた。
姓は、大王から、その氏の職務に応じて授けられた。

&lt;span style=&quot;color:red&quot;&gt;&lt;big&gt;氏&lt;/big&gt;&lt;/span&gt;（うじ）とは、主に、血のつながった者どうしの集団である。&lt;span style=&quot;color:red&quot;&gt;&lt;big&gt;姓&lt;/big&gt;&lt;/span&gt;（かばね）とは、政治の地位による称号（しょうごう）で、たとえば「臣」（おみ）や「連」（むらじ）という姓が、あります。

氏の代表者を氏上（うじのかみ）という。氏の構成員を氏人（うじびと）という。氏とは、その氏上や氏人などから成り立つ、組織であった。

有力な豪族の氏には、たとえば蘇我氏（そが し）・物部氏（もののべ し）・大伴氏（おおとも し）などが、あります

政治の仕事を行なう豪族には、さらに姓（かばね）が与えられた。中央の政治の姓には、臣（おみ）、連（むらじ）の姓が与えられ、中でも有力な豪族には'''大臣'''（おおおみ）、'''大連'''（おおむらじ）の姓が与えられた。

例えば、蘇我氏には「臣」（おみ）という姓（かばね）が与えられた。大伴や物部には「連」（むらじ）という姓（かばね）が与えられました。

そして、手工業や軍事などの管理にたずさわる豪族は、それよりも低い地位に置かれ、'''伴造'''（とものみやつこ）などの姓が与えられた。そして、その管理者のしたで働く、伴（とも）や部（べ）などの集団を、伴造などが管理した。

部には、様々な専門職であったらしい品部（しなべ）や、豪族の私有する民の部曲（かきべ）がある。

このような改革により、6世紀の半ばごろまでには、ヤマト王権による中央集権的な日本各地の支配が進み、のちの時代で言う「朝廷」のようなものが出来ていったと考えられる。


== 日本と外国との関係 ==

=== 中国 ===
[[File:Map of Northern Wei and Liu Song Dynasty ja.png|thumb|600px]]
終わりごろ、中国では「宋」（そう）という国が、中国の南部を治めていた。この時代、中国は北朝（ほくちょう）である、北魏（ほくぎ）と、南朝（なんちょう）である宋（そう）という、2つの国に分かれていて、南北の王朝が争っていた。

その宋の歴史書の『'''宋書'''』'''倭国伝'''（そうじょ わこくでん）では、５世紀に中国の王朝である宋に、日本からの外交で、日本の5人の大王が、それぞれ外交の使者を送ってきたことが、『宋書』に書かれています。
５人の王の名は、宋書によると、それぞれ讃（さん）、珍（ちん）、済（せい）、興（こう）、武（ぶ）という名です。
この５人の倭国の王を &lt;big&gt;倭の五王&lt;/big&gt;（わのごおう） といいます。日本は、高句麗との戦争で優位に立ちたいので、宋の支援（しえん）が、ほしかったのです。

この5人の王が、どの天皇か、それとも天皇ではない別の勢力なのか、いろんな説がある。

有力な説では、武（ぶ）は、日本書紀に「幼武天皇」（わかたけ てんのう）という記述のあるワカタケル大王のことだろうと思われています。つまり雄略天皇が武（ぶ）だろうと思われています。


*倭王（わおう）武（ぶ）の上奏文（じょうそうぶん）
この時代の倭王の「武」（ぶ）が、中国に送った手紙には、つぎのようなことが書かれています。


{| style=&quot;width:100%&quot;
|valign=top style=&quot;width:60%;text-indent:1em&quot;|

&lt;div style=&quot;border:1px solid #000000;&quot;&gt;
　'''倭王武の上奏文'''（抜粋）　（『宋書』倭国伝）
:興死して弟武立つ。自ら（みずから）使持節都督（しじせつととく）倭・百済・新羅・任那・加羅・秦韓（しんかん）・慕韓（ぼかん）・七国諸軍事安東（あんとう）大将軍倭国王と称す。
:順（じゅん）帝の昇明（しょうめい）二年、使を遣して表を上りて（たてまつりて）曰く、「報国（ほうこく）は偏遠（へんえん）にして、藩を外（そと）に作す（なす）。昔より祖禰（そでい）躬ら（みずから）甲冑を擐き（つらぬき）、山川を跋渉（ばっしょう）して、寧処に（いとま）あらず。東は毛人（もうじん）を征すること五十五国、西は衆夷（しゅうい）を服すること六十六国、渡りて海北を平ぐること九十五国」と。

::（『宋書』倭国伝、原文は漢文）
&lt;/div&gt;

|valign=top style=&quot;width:5%;text-indent:1em&quot;|
|valign=top style=&quot;width:35%;text-indent:1em&quot;|

&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;

「皇帝から臣下としての地位を受けた我が国は、中国から遠く離れた所を領域としています。
昔から私の祖先は、みずから よろい・かぶとを身につけ、山や川を踏み越え、休む日もなく、東は毛人（もうじん）の国（毛人＝おそらく東北地方の蝦夷（えみし））55か国を平定し、西は衆夷（しゅうい）の国（衆夷＝おそらく九州の熊襲（くまそ））66か国を平定しました。さらに海をわたって、海北（かいほく）の（海北 ＝おそらく朝鮮半島）９５か国を平定しました。

::（和訳して抜粋）

|}

このような内容が書かれています。この倭王が中国に送った手紙を、一般に、倭王武の上奏文（わおう ぶ の じょうそうぶん）と言います。「上奏」（じょうそう）とは、格下の者が、目上の地位の者に、申し上げることです。

なお、最終的に中国の南北朝を統一する国は、「隋」（ずい）という国によって6世紀おわりごろに統一されます。南北朝の次の王朝は、隋（ずい）王朝になります。

=== 朝鮮半島 ===
[[File:History of Korea 375 ja.png|330px|thumb|left|375年頃の朝鮮半島]]
[[File:Rubbing of the Gwanggaeto Stele.jpg|thumb|碑文の複製 1882年頃作成、東京国立博物館]]
4世紀には、朝鮮半島は国が分裂していた。南西部の百済（くだら、ペクチェ）と、東部の新羅（しらぎ、シルラ）と、北部の高句麗（こうくり、コグリョ）と、その他のいくつかの小国があった南部の伽耶（かや、カヤ）地方に分裂していて、おたがいに争っていた。伽耶（かや、カヤ）のことを任那（みまな）、あるいは加羅（から）ともいう。

伽耶は半島の南部にあり、百済は、南西部にあった。日本は、鉄の資源などをもとめて、南部や南西部の、伽耶や百済と交流があった。

日本は、伽耶（かや、カヤ）と百済（くだら、ペクチェ）に協力した。
日本は百済（くだら、ペクチェ）と連合して、敵である新羅（しらぎ、シルラ）および高句麗（こうくり、コグリョ）と戦う。

朝鮮半島での、広開土王（こうかいどおう）の碑文（ひぶん）によると、倭が高句麗（こうくり）との戦争を4世紀後半にしたことが書かれています。この戦いでは高句麗が勝って、倭の軍をやぶったそうです。広開土王は好太王（こうたいおう）とも言います。

なお最終的に、朝鮮半島を統一した国は新羅（しらぎ、シルラ）であり、7世紀に新羅が朝鮮半島を統一する。
{{clear}}

== 磐井の乱（いわいのらん） ==
6世紀はじめ、九州の北部で、大和朝廷に逆らう、大規模な反乱が527年に起きる。豪族の筑紫国造（つくしのくにのみやつこ）磐井（いわい）が、新羅とむすんで反乱を指揮した。朝鮮半島での、百済をすくうための出兵の負担への反発が、きっかけ。
この反乱のことを '''磐井の乱'''（いわい の らん） という。

ヤマト王権は、この反乱（磐井の乱）をおさえるのに、1年あまリ〜2年ほど、かかる。


== ヤマト王権の政治制度 ==
6世紀、ヤマト王権に服従した地方豪族は'''国造'''（くにのみやつこ）として任命された。

また、各地に、ヤマト王権の直轄地が設置され、その直轄地は'''屯倉'''（みやけ）という。

また、直轄民として従属する部の民を'''名代'''（なしろ）、'''子代'''（こしろ）とし、地方豪族に従属する民を'''部曲'''（かきべ）と呼んだ。

いっぽう、有力な豪族の私有地を'''田荘'''（たどころ）といい、有力な豪族が私有地を持っていた。
[[category:高等学校日本史|こふんとやまとおうけん]]</text>
      <sha1>d4pomsxo5a6yx9zophzq3z8axfznn5h</sha1>
    </revision>
  </page>
  <page>
    <title>高等学校商業 経済活動と法/代理</title>
    <ns>0</ns>
    <id>22637</id>
    <revision>
      <id>205719</id>
      <parentid>108012</parentid>
      <timestamp>2022-07-23T12:33:09Z</timestamp>
      <contributor>
        <username>はいかぐら</username>
        <id>45848</id>
      </contributor>
      <minor />
      <comment>/* 問題点のある代理行為 */</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="5412" xml:space="preserve">{{stub}}
== 代理の原則 ==
=== 代理の意義と意味 ===
契約は当事者どうしが本人どうしで行うのが原則である。しかし、本人の許可などがあれば、別人に契約をしてもらっても合法である。
このように、本人以外の人に契約をしてもらう方法が'''代理'''（だいり）である。

たとえば、人Aが人Bを相手に土地の売買をする場合、Aが人Cを代理人として、CにBとの契約をしてもらってもいい。

[[File:代理.svg|thumb|500px|代理（任意代理）の法律関係]]

この場合、Aが本人であり、Bが代理人である。代理人Bは、Cとの交渉に入るさい、Aの代理人である事を示さなければならない。（'''顕名主義'''（けんめいしゅぎ） ）

== 任意代理と法定代理 ==
代理には、任意代理と法定代理がある。

本人（図ではA）が代理人を選ぶ場合の「代理」のことを'''任意代理'''という。

いっぽう、未成年である子について、親が代理人になる場合は、本人（つまり子）は、自由には代理人を選べない。子の代理人の親のように、法律によって、代理人やその権限が決められる場合の代理のことを'''法定代理'''という。成年後見制度における（成年被後見人の代理である）成年後見人などのように、成年被後見人・被補助人・被保佐人の代理も、法定代理である。（※ 参考文献: 有斐閣『民法総則』、加藤雅信、291ページ）

なお、高齢者などが後見人を任意で選ぶ任意後見の制度もあるので、混同しないように。（※ くわしくは『[[高等学校商業 経済活動と法/自然人の行為能力と制限行為能力者制度]]』）


* 委任（いにん）
任意代理で、代理人に代理権を与えるさい、普通、委任（いにん）という契約によって、代理権の内容を明確にしておく。

:（※ 編集者へ: 委任状の文例を募集中。）

委任で与える権限を明確にした契約文書を委任状（いにんじょう）という。本人が委任状を書くとき、普通は、委任で与える権限の内容を書いておく。そして、文末には、「以下余白」と書いておくことで、そこが文末である事を明示し、他人が勝手に権限を加筆できないようにしておくのが普通である。権限の内容をなにも書かずに空欄にした場合（このような場合を「白紙委任状」という）、他人が勝手に書き足す恐れがある。なので白紙委任は、しないようにすべきである。

なお、結婚や離婚の契約は、本人の意思が重要であるため、代理できない。（※ 検定教科書の範囲内。実教出版の教科書に記載あり。）

=== 代理と代表 ===
法人の場合、そもそも本人にあたる自然人がいないので、かわりに自然人である理事などが法人の意思として契約をする事は'''代表'''という。

== 問題点のある代理行為 ==
=== 無権代理と表見代理 ===
* 無権代理
代理権のまったく無いCが「Aの代理人である」と称してBと契約しても、原則として、このような代理人のした契約では、Aに効力は無い。（民113） なので、Bは、Cに対して責任追及せざるを得ない。

このような場合（まったく代理権のない者による代理行為）を'''無権代理'''という。
そして、Bは無権代理人である。

[[File:無権代理.svg|thumb|520px|left|無権代理]]
[[File:表権代理.svg|thumb|420px|right|表見代理]]

{{-}}
* 表見代理
例外的に、相手方Bが代理人だと誤信しても仕方無いような事情のある場合、有効になってしまう。このような場合を'''表見代理'''といい、AがCに過去になんらかの代理権を与えた場合であり、次のような場合がある。

:【代理権授与表示のある場合】 AがBに対して「Cを代理人にする」と伝えていたが、じっさいにはCに代理権が与えられていなかった場合。（民109）

:【越権行為の場合】 Cは代理人としてAの貯金30万円までの金銭の貸し借りを任されていたが、70万円の貸し借りを扱ってしまった場合のように、代理人に与えられた権限以上の行為をしてしまった場合。(民110)

:【代理権消滅後の場合】 Cは過去にAの代理人であったが、その期間が終わり、代理権が消滅していた場合にもかかわらず、Cが勝手に代理行為をした場合。（民112）

{{-}}
=== 自己契約、双方代理 ===
同一の契約において、Cが、Aとその契約相手Bの両方の代理人になることは、原則として禁止されており、Cは無権代理人として扱われる。このような代理を'''双方代理'''という。原則的に、双方代理の行為は無権代理として扱われる。

ただし、すでにAとBとの間で売買の契約が成立しており、その代金支払いの処理をCが代行するような場合なら、合法である場合もある。（※ 参考文献: 有斐閣『民法入門 第7版』川井健）</text>
      <sha1>n93u9vmcsv4cq4p1uzgb8r6v9e5scs2</sha1>
    </revision>
  </page>
  <page>
    <title>高等学校美術I</title>
    <ns>0</ns>
    <id>22684</id>
    <revision>
      <id>205782</id>
      <parentid>192537</parentid>
      <timestamp>2022-07-24T10:30:24Z</timestamp>
      <contributor>
        <username>Nermer314</username>
        <id>62933</id>
      </contributor>
      <minor />
      <comment>/* メルクマール */</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="64719" xml:space="preserve">{{Pathnav|Main Page|小学校・中学校・高等学校の学習|高等学校の学習|高等学校芸術|frame=1}}
[[{{PAGENAME}}]]では、高校における美術を学習します。

== 筆の持ち方 ==

絵を描くとき、絵筆などの持ち方は、指先の力（ちから）具合などの加減を正確にするために、中指を人差し指に添えます。

文字を書く時に良いとされる鉛筆の握り方とは、中指の位置が違っています。

== 絵を描く ==

学問に王道がないのだとしたら、美術にも王道はないかもしれません。

昔から絵画の勉強、練習には、過去の名画を模写することが良く行われてきましたが、現代では写真もありますし、やはり基本は現実の光景、事物を見て絵を描く練習をするのが、一番自然で妥当な事ではないでしょうか。

== 写実画 ==
[[File:Jan Vermeer - The Art of Painting - Google Art Project.jpg|424px|thumb|ヨハネス・フェルメール『絵画芸術の寓意』（1666〜67年頃）&lt;br&gt;ウィーン美術史美術館蔵（オーストリア）]]

美術の世界も人類の文化の発展とともに、大きく規模が広がり、その表現も多様になっていきました。

ですから、様々なアプローチがあるし、許されるはずですが、基本は目に見える光景をうつしとり、再現、表現することでしょう。

その意味で写実画は原点ですし、今後どんな絵を描いていくにしても、取り組み、時間を費やす価値がある画風だと思います。

右のフェルメールの絵ですが、昔の画家も、モデルにポーズをとってもらって、それを見ながら描いていた、という様子がよくわかりますよね。

== アタリ ==

絵を描くときに、いきなり描きたいものを本線で描かず、鉛筆の薄い線で、短時間で下書きのように描くといいですね。こういうのを、アタリ、アタリを取る、などと言います。

事物を適切に配置した場面構成は、レイアウトと呼ばれることも多いですよ。

画面構成の下描きは、円や長方形、円柱や錐など、単純な形を組み合わせて、簡単にわかりやすく描くといいと思います。下描き、アタリは消す場合も多いですが、そのまま残して、絵画の効果の一部になる場合もあります。

== 正中線 ==

主に人体で、体を左右に分ける垂直の仮想の線を正中線（せいちゅうせん）と言います。人間や生物を描くときは、この正中線を意識したり、実際に線で描いてみると、自分が描いている絵についての理解や意識が深まっていくと思います。

== 写生、写実画は、多くの場合大胆に省略、デフォルメされている ==

もちろん緻密、正確に書くことを目指してもいいし、試してみてもいいと思います。

しかし省略やデフォルメ、現実、事実を超えた表現は、芸術や美術の本領でもあります。

しかし一方写実画では、透視図法は理解しておさえておくのが正確に風景を描くためには重要になります。人間は二つの目で見た二つの光景を、一つの図としてとらえることで外界を見ています。しかも目のレンズのピントがありますから、ある距離の光景がはっきりしている一方、その前後はぼけて見えているはずです。

透視図法はこの世界の空間上のある一点を、人間の片目のレンズの中央として、そこから見た光景をその点の前面にある紙、平面に写し取っています。もちろん二つの目を持つ人間は、二つの光景を見たうえで、一つの図だと考えている訳ですが、これによって、遠近を知ることもできます。近似的には、両目のレンズを結ぶ線分の中点に、視点、世界を見る目のレンズの中心があると考えていいと思います。

&lt;gallery widths=250px heights=250px&gt;
Image:2-punktperspektive.svg|二点透視図法の例。二点透視は、見えている光景の真ん中を描く以上は、二点の消失点を結ぶ直線（アイレベル）は画面の中央点を通ります。（この場合は少し下ですね）
Image:Ministry of Justice Japan02s3200.jpg|二点透視図法のような構図の参考写真。　法務省旧本館　写真外に消失点がある
Image:Perspective with 2 points b.svg|二点透視図法。対象物を斜めから見る。
&lt;/gallery&gt;

&lt;gallery widths=250px heights=250px&gt;
Image:3-point perspective 1-px-line.svg|三点透視図法の例。&lt;br /&gt;対象物を斜め上から見る
Image:Century-Park-Tower.JPG|三点透視図法のような構図の参考写真。　大川端リバーシティ21センチュリーパークタワー。対象物を斜め下から見る。
Image:Perspective with 3 points.svg|三点透視図法。&lt;br /&gt;対象物を斜め下、または斜め上から見る。
&lt;/gallery&gt;

== エジソンは… ==

太陽の色が赤ではなくて黄色だと言って、親や教師と喧嘩した、という逸話が残っていますよ。（ただ、事実かどうかは不明です）。また、あるアニメーションスタジオでは、水って、結局何色なの？という議論で盛り上がったことがあるそうです。普通は青ですが、黒や白、無色透明、とかいろいろな意見が出てきますよね。

実際色に関しては、そしておそらくそれ以外も、固定観念にとらわれないと、面白いいい効果が出ることも多いですよ。ポスターイラストなどでは、少ない色数で、対象物を表現する場合も多いし、それが非常に見るものを引き付ける効果を持つことがありますよね。

結局、芸術、そしてそれ以外も自由なはずなんですが、一方で、自由があるからこそ、冷静で大局的な視点、ある種の節制やルール、何らかの苦難の受け入れ、が必要になると思います。

== 人物デッサン画 ==

人物デッサンの描き方の一例を示します。

=== 作業の流れ ===
下記のように
:アタリ → （エンピツで）全身の影の塗り → 修正 → 細部の塗り → 細部の修正
を繰り返して、1 サイクルごとに絵の質を高めることを目指していきます。

アタリは短時間。作品づくりの作業のほとんどを、（エンピツで）塗り、修正、塗りなおし などに配分すると、いいようです。

先に全身のバランスを押さえてから、あとで細部を作っていきます。

==== 人物画のアタリ ====
人物デッサン画を描く場合、シャープペンシルは使わないようにしましょう。普通はグラファイト鉛筆（ごく普通の鉛筆ですね）、グラファイトスティックや水溶性鉛筆、木炭鉛筆や木炭など、美術用の画材は各種ありますし、結局鉛筆の方が濃淡をよく表現できます。実際には製図用シャープペンシルとか、高校卒業以降はシャーペンで絵を描くことも多いですね。

まず、アタリを取りますよ。

たとえば、次のような手順で、アタリを取ってみましょう。
:1: アタリ用の図形として、だ円や長方形、円柱などの図形をつかった簡単なアタリを取って、画用紙に人物像が入りきるかを確認。
:2: 次に、ちょっとだけ細かく書き込んでいく。（あとで修正するので、あまり濃い線では書かない）。顔の向きを、おおよそ、画用紙上で描くこと。どこを向いてるのかを矢印などでメモ的に描く。いきなり目や瞳やまつ毛などを細かく描き込まない方が良い。また、見ている先はどこかを、だ円などで囲む。たとえば、書籍を読んでる人物についての人物画なら、視線の先は書籍にありますね。視線の矢印と、見ている先の物体を、曲線などで結んでおきましょう。
:3: 多くの作品ではモデル人物の視線が重要な場合が多いので、画用紙上に目を描いておくと、後のヒントになりやすい。なので、両目の、目の輪郭のおおよその形を描く。瞳のおおよその場所を描く。目や瞳を描いたついでに、まつ毛も軽く線で描いておくといいかもしれません。
:4: そして、口とか鼻とか耳とかを、おおよその形で描く。
:5: あまり顔にも深入りしない。胴体の描き込みに移る。この際、首をおおよその形で、うすく描いておく。首を過大に長く描くのは犯しやすいミス、難点です。なので、首はうすく描いておくのにとどめて、胴体を描きにいきます。
:6: 胴体は服を着ていますから、服のシワとかが重要な表現ポイントになりますね。 

==== 色を塗り始める ====
ある程度、全身のアタリを取ったら、影になる部位をうすめに黒く塗りにいく。

ただし、あとから修正するので、うすく塗っていく。

また、なるべく全身の各部位にある影部をバランスよく、黒く塗っていく。

とにかく、実際に影部を黒く塗ってみて、もし違和感を感じた部分は、消しゴムで修正していきましょう。

影の大きさや位置を調整したり、場合によってはアタリで引いた線を引きなおします。

違和感を感じにくくなるまで、修正を繰り返します。

消しゴムは消費しますが、消しゴムに関しては使う使わないでいろいろな意見がありますが、許容されている場合は大いに使って問題ないと思います。

=== 各論 ===
==== 黒い服、白いYシャツの影を書く場合 ====
===== 黒い服 =====
黒い服、制服の鉛筆デッサン。→黒いものに影つけするのが難しい。

:対策案1: 　濃く黒く見える部分を、「灰色だ」と思って描く。つまり、実物よりも薄い色として描く。
:対策案2: 　または、先に影になる部分を描いてから、そのあと、画用紙上での服の色を決める。つまり、あたかも、モデル役を「実物大の石膏デッサン人形」（デッサン用模型は白色であるのが通常）みたいな白色の人形だと思って描く。そして影を描き終わってから、服の色などを着色していく。

===== 白いYシャツ =====
白いシャツの鉛筆デッサン。→紙も白いから、どう描くか混乱する。

対策案手順
:1: とりあえず、Yシャツの輪郭線を、うすくエンピツで線を描いてしまおう。 
:2: 次にとりあえず、Yシャツで影になってて暗くなってる部分などは、エンピツで（うすく）灰色っぽく塗る。
:3: そのあと、Yシャツの表現をどうするか、考えよう。

「うすく」と書いた理由は、黒色のズボンを、やや うすめ の灰色で描く場合、それと合わせるため、Yシャツの白色の輪郭や影の色を、調節する必要があるからですね。

== 光源 ==
通常、光は上にあるから、上側にあるものほど明るい。

いっぽう、暗いところで顔の下から上に向かって懐中電灯を照らしたりして、面白がる時がありますよね。あのように、暗い夜道などで、懐中電灯を顔の下から上に向かって照らしたような場合、顔の下側のほうが明るい。

光源が上にある場合の人物画を書く場合でも、「顔のアゴ下だから暗い」と考えるよりも、「アゴ下はヘコんでるので、そこに光がほとんど差し込まないので、アゴ下は暗くなりやすい」などととらえた方が、光源と対象の見え方の理解が深まると思います。


* 光と影
たとえばリンゴの模型をもとにデッサンをする場合、光源の側に近い面は、明るくなってるし、逆に、その反対側の面は、影になってる。

人体では、次のような部位どうしが、光と影で逆関係に対応しやすい。

:・ ＜頭の上部（髪の生える部分）＞　.対.　＜アゴの下＞
:・ ＜肩の上、うでの付け根＞　.対.　＜ワキの下＞
:・ ＜女性の乳房の上側（乳頭から上の面）＞　.対.　＜女性の乳房の下側（乳頭から下の面）＞

こうなる理由は、重力方向的な上下関係の対応のほかに、球面に対してへっこんでいるという対応もしているからだろう。（乳房だけでは、乳房の上下とも球体的だが、しかし胴と組み合わせると、乳房が重力によって下方向に引っ張られるので、乳房の下側の面は、胴と乳房にハサまれてへっこんでいるし、逆に乳房の上側の面は、肩の前面から乳房にかけてのラインが平坦になりやすい。）


ワキの下の影をぬってる時、ついつい影を大きめに描いてしまいがちである。

:1: 人体の輪郭を描いた上に、
:2: その輪郭の描かれた絵の上に、つづけて影を描く、

このような手順で描くと、そうなりやすい。

そこで、
:1: 人体の輪郭を描いた上に、（※ ここまでは前述の手順と同じ）
:2: その輪郭の絵の上に、実物モデルを見て、光と影の対応場所を観察することで、 明るく照らされている人体部位 および 影になる部位 を、それぞれ探す。 
:3: そして影を描く際には、決して、明るくなっている部位には「影」が入り込まないように注意しながら、影を描く、

のように描くことをお勧めします。

その他、もし描画対象の人物が椅子にすわっているなら、いすの面に触れてる部分の付近は（たとえば尻および、尻から太ももの下側）、光が差し込みにくく、よって影になりやすい。

また、このように座っている場合、
:・ ヒザの表側　.対.　ヒザの裏側
は、明暗が対応しやすい。

服を着ている人物デッサンでは、胴体の隆起の他に、さらに衣服の隆起が加わる絵を描くことになるので、もっと複雑な絵になるので、とにかく実物を観察して、うまく工夫して描きましょう。

また、室内照明の場合、たいてい光源は決して一点ではなく、天井全体に蛍光灯などが分散的に配置されており、光源は天井全体に一面に広がっている。1つのある光源では光が差し込まずに影になる部分でも、他の別の光源による光が差し込み、影はつきづらい上複雑に、とらえにくくなります。

== その他 ==
空気遠近法などの技法について、『[[中学校美術/美術2・3下]]』に解説があります。

== デザイン画、および集団作業 ==
[[File:第三角法の説明図svg.svg|thumb|300px|正面図と側面図]]

ウルトラマンに出てくる怪獣など、空想上の生き物の着ぐるみを、もし新しく怪獣を考えて作るときは、考えた形を絵でデザインしてスタッフに説明する必要があります。

目的は、着ぐるみなどの実物をつくることですので、正面図だけでなく、側面図など別方向から見た図も必要になります。正面図だけでは、正面からは見えない部分の形が分からないからです。

側面図のかわりに背面図を書く場合もあります。また、正面図と側面図と背面図の3つを描く場合もあります。

いっぽう、上面図は、描かない場合も多いです。映像作品の着ぐるみなどの場合、正面図と側面図があれば、そこから形が分かる場合が多いのです。

また、こういった集団作業用デザイン画では、デザインの第一段階では色は塗らない（ぬらない）のが普通です。当面の目的は、形のデザインですので、輪郭線などの線を目立ちやすくする必要があります。影も、つけないのが普通です。

このように、集団作業のデザインでは、特に空想の生き物をデザインする場合、普通のイラストとは描き方がちがいます。集団作業用のデザイン画では、少なくとも2方向（たとえば正面図と側面図）が必要になる場合が多くあります。

[[File:Mirai Suenaga with summer school uniform and K-on character style 20110305.jpg|thumb|400px|アニメ風に描かれたキャラクター設定画の例（色つき）&lt;br&gt;作者 	Danny Choo&lt;br&gt;
このデザイン画では、全身像として正面図と背面図を描いている。※「色トレス」とは，線画の線に色がついている物ですね。]]
:※ 絵だけでは分かりづらい場合、デザインに重ならない位置に、文章で短く、たとえば「手の形は○○にする」などのコメントを追加したりして、明確に指定する場合もあります。目的は、絵だけで表現することではないのです。目的は、制作スタッフどうしで共通認識を作ることですので、もし目的のために必要ならコメントも追加します。

{{コラム|アニメーション作品『新世紀エヴァンゲリオン』について|

1995 年以降に日本のアニメーション業界は大きく変わっており、テレビ東京の知名度の躍進、深夜アニメの放映数の増大、角川書店がマンガ・アニメ関連の出版社として躍進、などの変化が起きた（その変化の多くが、この作品『新世紀エヴァンゲリオン』のヒットの影響を受けている）。

実は 1995年当時では、このアニメはあまり視聴率が高くない。他の一般のマイナーなアニメ―ションと同じで、せいぜい視聴率 7%程度という、（当時としては）低い数字である（当時からアニメ評論の書籍で視聴率など、そう指摘されている。岡田斗司夫氏の記した『東大オタク学講座』などのオタク文化評論の書籍等で指摘された）。映画公開前の総集編で深夜としては高い視聴率を出したという結果も言われているが、しかし、『笑ゥせぇるすまん』とか『行け!稲中卓球部』などの夜中アニメ～深夜アニメだって同じくらい高い視聴率を持っていただろう。

また、エヴァンゲリオンの当初の放送局は『テレビ東京』（いまの『テレ東』）という首都圏に限定する放映だったため、地方の人はそもそも作品自体を視聴できない状況であった（テレビ東京という放送局を地方の人が知らない場合も多いだろう）。しかし、例外的に、少数の地方ネット局も当時はあった。

そのため作品の売り上げや知名度なども今ほどは高くなく、はたして報道などの価値が本当にあったか視聴率などの統計数字的にはハッキリしない状況だが、しかし当時のマスコミ（テレビ東京以外のテレビ局も含む）が 1997年の映画版の前売りチケット即日完売の出来事をキッカケにこの作品を積極的に報道するようになった。

実はマンガ業界やゲーム業界などでは作品などの即日完売は珍しいことではなく、たとえばゲーム業界では『ファイナルファンタジー』シリーズの人気作（1990～95年はFF4～FF6など）が即日完売することもよくあったが、しかし、それでもそれらのFF4～6のブームは当時はまったくテレビ報道・新聞報道されなかった。FF8が発売された1990年代後半に、マスコミは積極的にFFシリーズを報道するようになる。

つまり、マスコミの人は、いろいろと情報は知ってるいけど、事情によって報道できないことがあるという事ですね。スポンサーと競合する作品のヒットとか、報道できない。そのため、実は報道のキッカケになる作品よりも何年も前に、報道対象の業界でのブームがもう既に発生しているんです。

たとえばゲームのドラクエシリーズは、ドラクエ3の発売日の 1988年に全国各地のゲーム販売店でのドラクエ3 の即日完売が起きたことが報道されたけど、じつは前作のドラクエ2の段階で即日完売が全国各地で発生していたことが、現在では知られています。

実はアニメ業界の売り上げなどの規模は、2005年の時点でゲーム業界の約10分の1という小さい規模です（経済産業省などのネット公開している統計・文書による）。（ただし2015年ごろには、ゲーム業界の7割くらいの規模にまで、アニメ業界は成長している。）

:※ 2017年の時点で経済産業省のサイトに「ゲームの国内市場規模は約１.８兆円」、「アニメの狭義国内市場規模は1,700億円。しかし広義では１.２４兆円に拡大」とある。
&lt;ref&gt;[https://www.meti.go.jp/statistics/toppage/report/archive/kako/20170727_1.html#cont2 『日本の２大コンテンツ、ゲームとアニメの制作企業の実像を比較する（その１）；アニメとゲームの国内市場規模では、「二次市場」の重要性が大きく異なる。ゲームの１.８兆円に対して、アニメ制作の直接市場は1,700億円。しかし、広義のアニメ市場規模は１.２４兆円に拡大。｜経済解析室ニュース｜経済産業省』] 2020年2月8日に閲覧して確認&lt;/ref&gt;

:2005年ごろの経産省の統計&lt;ref&gt;[https://www.city.kyoto.lg.jp/sankan/cmsfiles/contents/0000068/68937/2-siryou2.pdf 2009年経済産業省商務情報政策局] 2020年2月8日に閲覧して確認&lt;/ref&gt;では、2005年の時点で日本のアニメのビデオの国内販売は420億円。マンガのコミックス、コミック販売金額は約5000億円。その他の放送は3.7兆円。ゲームはパチンコを除外してもソフトとアーケードで1.2兆円。

2008年の日本のコンテンツ輸出高の98.2%はゲームソフト
&lt;ref&gt;[https://www.meti.go.jp/committee/kenkyukai/shoujo/creative_industries/pdf/001_s01_00.pdf 平成25年3月29日 経済産業省 商務情報政策局] 2020年2月8日に閲覧して確認
&lt;/ref&gt;。

:※ なお、日本国内のテレビ視聴率でも、2015年以降、アニメ番組よりも、NHK連続テレビ小説やNHK大河ドラマなどのNHKドラマ、他局の刑事ドラマや推理ドラマなどのほうが（アニメよりも）視聴率は一般的に高い。ビデオリサーチ社などの出す統計で調べられる。ドラマの視聴率が15％前後な一方、アニメは国民的アニメでも 5％前後である。

90年代のアニメ―ションの話に戻ると、マスコミはきっと、エヴァンゲリオンのヒットよりも前の時代に、テレビ東京の躍進などを示す統計や情報を（日本テレビやTBSなどの）他局のマスコミも手に入れてて、だけど競合他社の宣伝になってしまうから他局では報道できなかったんでしょう。そこで、ちょうどそのことをヒットしたアニメ（1995年）を題材に、遠まわしに報道をしたんですね。

実は1990年代の前半の時点で、「日本のアニメが海外でヒットしているらしい」という情報をマスコミは手に入れてて、国際文化番組の『世界まるみえ』などでも普通に日本アニメの海外ブームについてもよく取材されていました。

エヴァンゲリオンは95年のヒットのその後、地方でも他局の系列の地方放送局で放送されるようになる。当時はまだ、テレビ東京系列の地方放送局のシステムなんて、ほぼ無かったか、あったとしても組織化されてなかったんです。ただ、前述したように、例外的には、いくつかの地方局がありましたが…。日テレとかTBSとかフジとかテレ朝とかの人が、他局の作品だと分かっていて、それでもあえて地方局ではテレビ東京作品を放送したんですね。

ラジオ局だと、TBSラジオとか日本放送（フジ系列）とかが、1996～97年の映画前売りチケットの即日完売よりも前に報道しています。当時はネットが普及しておらず、ラジオも情報源として大きな役割を果たしていたんですね。

;エヴァンゲリオンの原作
このアニメ―ションの原作について「エヴァの原作の少年エース版漫画」と言われることがありますが、実際の原作はアニメ―ション版です。

テレビ公開よりも前にマンガ雑誌（角川書店の少年エース）で連載が始まったことや、当時の他局のアニメではマンガ原作のアニメが多かったので、「エヴァンゲリオンの原作漫画」と言われることがありますが、原作と呼ぶのはやや不適切です。

もし「漫画が原作」と言った場合、それは普通の意味では、漫画家が出版社に持ち込んだ原稿をもとにストーリーを考えて、絵柄も考えることになってしまうか、あるいはマンガ出版社がストーリーを考えることになりますよね。

しかし、エヴァンゲリオンは違う。エヴァンゲリオンのストーリーは、主にアニメ―ションの制作会社が考えたものであるとされています。

そして、漫画版のイラストを担当した漫画家・イラストレーターが、アニメ版のキャラクターデザインのデザイナーも担当している。

95年にエヴァンゲリオンがヒットするまでは、「漫画原作ではないアニメオリジナル作品は、例外としてジブリ作品を除外すると、まずアニメオリジナル作品はあまり売れない」、「アニメ本体のビデオテープやレーザーディスク（当時はDVD普及前）などは売れず、タイアップのオモチャ（ロボットアニメならプラモデルなど）のグッズ販売などで儲ける必要がある」というのがアニメ業界での通説だったのです（岡田斗司夫氏の記した『東大オタク学講座』など当時のアニメ評論の書籍で指摘されている）。しかし、このエヴァンゲリオンのヒットがその通説をひっくり返したわけですね。

また、エヴァンゲリオンのキャラクターデザインの作者と、この作品の監督は、別の人です。エヴァのロボットデザインの人と、キャラクターデザイン（碇シンジなどのキャラクターのデザイン）の人も、別人ですね。

アニメ―ション製作では、このように、担当作業ごとに、作家が異なり、専門的なスタッフに担当させるのが、よくある製作システムです。

いっぽう、ジブリ作品（『もののけ姫』などのアニメ―ションを制作する会社の名前がスタジオ・ジブリですね）だと、ジブリ作品の監督の宮崎駿氏の作家性が大きくかかわっていくので、監督がキャラクターデザインも担当していて、アニメ―ション業界全般がそういう製作体制だと想像している人も多い。しかし、ジブリのような製作システムは、アニメ―ション業界では例外のほうですね。
}}


;正面図と側面図
:※ 集団作業とは別に、彫刻を木彫り（きぼり）や石彫り（いしぼり）でつくるときも、彫られる（直方体の）木や石に、実物大で正面図と側面図を描きます。その図を参考に、彫っていきます。
:CGを制作する時も、多くの場合正面図と側面図を描いて、その画像を参考に各部分を入力していきます。

== 余談:ペンキ塗装 ==
{{コラム|ペンキ塗装や板金塗装について（「美術」からは少し外れますが、過去の経緯上掲載します）|

建築物で外壁の板金にペンキ塗装をしてある家庭が多い。ペンキ塗装する本来の目的は、サビなどの腐食を防ぐ事が、おもな目的である。

建築物で外壁の板金にペンキ塗装する時は、色のついた顔料の他にも、「上塗り」（うわぬり）および「下塗り」（したぬり）として樹脂製の塗料を塗っている。

ペンキで、外壁などに色をつける目的のひとつは、サビを防ぐための効果のある上塗り剤（うわぬりざい）・下塗り剤（したぬりざい）が年月の経過による劣化で落ちかけている場合に、目視で劣化を確認しやすくするための手段でもある。

一般的なペンキ塗装では、色のついた塗料を塗る工程の前後に、まず色塗りの前の工程として、ペンキの付着を向上するため及び（および）耐腐食性をあげるための下塗り（したぬり）をしており、また、色塗りの後の工程としてペンキが風雨で落ちないようにするため及び耐腐食性を上げるための上塗り（うわぬり）をしており、この下塗りと上塗りによって、耐腐食性を上げている。}}

== 作品の安全性・合法性 ==
作家が事前に、作品の安全性などを判断するのは、必要な事です。

たとえば、立体造形物を作る場合は、事故が起きないよう、十分な注意をしたい。
形状のとがった部分があれば、とがった部分で目を刺したりなどの事故をしないように、対策する必要があるでしょう。
万が一、とがった部分をつくらないといけない場合でも、やわらかい材質でつくるとか、先端を丸めておくとかの、対策をほどこす事が望ましいですね。

他の例としては、たとえばイスをつくるなら、そのイスは、けっして、座っただけで壊れてはいけないでしょう。人間が座ったり乗ったりするものは、普通の使い方では壊れないように、頑丈（がんじょう）に制作しておく必要があります。そのため、事前に、自分が使っても壊れない事を確認する必要がありますよね。

もし、こういう安全対策を行わなかった結果として、観客などが、その作品でケガをすると、治療費などとして、作家側は多額の損害賠償を請求されたり、または刑事罰を受ける場合があります。

作品の安全性には配慮が求められています。

== 美術作品、娯楽作品の鑑賞 ==
=== 有料、無料、作品の対価 ===
=== 古い作品 ===
=== 「プロパガンダ美術」とは ===

== 資料探し ==
たとえば、創作イラストとかで、日本の戦国時代の甲冑（かっちゅう）を装着した武者（むしゃ）を描きたいとします。

こういう場合、高校国語の資料集（国語便覧）や、あるいは高校の社会科の日本史の資料集などに、甲冑の写真や説明イラストが掲載されている。

空想上の生き物を描く場合や（朱雀（すざく）とか天使・悪魔など）、空想上の神々（シヴァとかヴィシュヌとかケツアルカトルとか）を描きたくて調べたい場合にも、資料集がある程度活用できます。

その他、現代に習慣の残ってない歴史上の文化や風習などをイラストで描きたい場合など、国語や日本史・世界史などの資料集を活用しよう。

ただ、たとえ教材のイラストとはいえ、著作権があるので、けっして、そのまま書き写して発表してはいけません。&lt;br&gt;
詳しくは、[[w:著作権|著作権]]などを参考にしてください。

これとは別に、美術イラストの資料集が書店で販売されています。ただ、年少者には情報が多すぎる、あるいは不要な情報が多い、著作権の取り扱いが煩雑、値段が高い、などの理由で、高校生にはあまり薦めない考えの人が多いです。

描きたい題材によっては、なかなか資料が見つからない場合もあります。その場合、例外として特別に人命などにかかわる絵でないかぎり（たとえば生物学の解剖イラストなど）、描きたい絵を描いてしまいましょう。

資料なしで描けば、間違った構造の絵を描くことになるかもしれませんが、間違いはあとから修正できます。

後から少しずつ直したり、普段から物事について知ること、調べることを心がけていけば、少しずつ美術、絵画に対する世界観は広がってゆきます。

== デフォルメ ==
漫画やアニメーションでは、わかりやすさを求めて、身体の特徴を強調することがあります。

たとえば、長身の人物は、より長身に描かれます。いっぽう、小さい人物は、より小さく描かれます。

たとえば、漫画やアニメーションで、登場する兄妹や姉妹が登場する場合に、たとえ成長期の終わった20歳すぎの兄妹や姉妹でも、年齢の大きいほう（兄や姉）を長身にデザインして、いっぽう弟や妹は、背を低くデザインするような手法があります。

観客は、自分が小学生のころの周囲の兄妹や姉妹のいる家庭などとの連想から、長身にデザインされたほうの人物が兄または姉だと分かり、いっぽう、背が低くデザインされたほうの人物が弟や妹だと分かる、というデザイン手法です。

このように、身体の特徴などを、作家が観客に、表現の意図をわかりやすく伝えるために、現実の人間や物体とは違うデザインを行うことを'''デフォルメ'''といいます。

身長にかぎらず、体重でも同様です。漫画やアニメーションでは、太っている人物をデザインする際は、太っている事をわかりやすく視聴者などに伝えるために、顔や手を、現実の太っている人間よりも太らせてデザインします。しかし、現実の人間では、顔や手には、ほとんど脂肪がつきません。現実での、太っている人間の顔や手の脂肪の量は、太ってない人の顔や手足の脂肪の量と、ほぼ同じです。

また、美術用の、19世紀や20世紀始めごろのアメリカやヨーロッパの古い美術理論を解説した書籍のなかにも、デフォルメをしているものが多くあります。

たとえば、人間の頭身が、8頭身くらいに描かれる美術書がありますが、現実の人間の体型とは違います。現実の人間の頭身は、6.5頭身くらいだと言われています。

これら欧米の古い美術書にあるデフォルメは、目や鼻や手や足の書き方だけは写実的なので、一見すると現実の人体どおりに描いていると考えがちですが、しかし実際は、当時のアメリカやヨーロッパの美術の流行に合わせて頭身のデフォルメをしています。部分的な強調、と、言えるでしょうか。

== 美術史 ==
日本の平安時代の古典文学『伊勢物語』（いせ ものがたり）をもとに、鎌倉時代につくられた『伊勢物語絵巻』（いせものがたりえまき）という絵巻物があります。

伊勢物語とは、在原業平（ありわらのなりひら）が東下り（あずまくだり）したりする文学です。（※ くわしくはwikibooks『[[高等学校国語総合/伊勢物語]]』）

:※ 著作権の都合で、wikiでの画像の紹介が困難なので、代わりに外部リンク [https://webarchives.tnm.jp/imgsearch/show/C0036494 伊勢物語絵巻] （リンク先は 東京国立博物館）

== 広角パースと望遠パース ==
パース＝パースペクティブ【perspective】 遠近法。透視図法。


実際の人間の目の見え方は、広角レンズ的なパースでもなく、望遠レンズ的な望遠パースでもないのです。

なお、広角レンズは、視野角が広いだけでなく、焦点距離が短いという特徴もあります。

一般の携帯用の手持ちカメラなどで、家族旅行などで皆が気軽に使えるカメラは大抵、広角レンズです。

望遠レンズは、視野角や狭いだけでなく、焦点距離が長いという特徴もあります（視野角が狭いことで、、遠くのものを大きく撮影する）。

ゲームで スーパーマリオ1 や スト2（ストリートファイター2）などの、真横から見たゲームがありますが、ああいうのが望遠パース的な構図です。

さて、漫画やアニメーションではよく、やや遠くから眺めた構図で描きます。つまり、漫画やアニメーションでは、望遠パースの掛かった絵柄で書くことが多いです。

スーパーマリオ1は、望遠パースのすごく強い画面です。

漫画やアニメーションでも、視界内での被写体の左右の位置関係を分かりやすくしたい場合に（けっして、スーパーマリオ1ほどの強い望遠パースではないが）、さらにより望遠っぽいパースを使うこともよくあります。特にアニメーションでは、セル（レイヤー）の合成のしやすさから、望遠パースが好まれます。

なので、多くの漫画・アニメーションの愛好者は、望遠パースに見慣れています。

パースの教本などでは、三点透視法とか二点透視法とかでよく人物にパースをつけて説明していますが、あれはパースを強調するために、かなり近くから人物を眺めた構図だったりします（つまり、焦点距離が短い　＝　かなり広角パースが強い）。

広角パースのほうが遠近による大小差が大きいためパースの仕組みが分かりやすいので、広角で説明図を描く教本のほうが多いのです。また、実際には人物にパースを強くつける機会は、あまりありませんが（人物よりも建築物にパースをつけるほうが多い）、しかし建築物は描くのが大変なので、かわりにマンガ調にデフォルメされた人物にパースを強くつけることが、イラスト教本でよくあります。

肩幅程度の横幅のポーズに人間ですら、人間にパースを30度くらい付けるイラスト教本は、よくあります。

[[File:Perspective and human in Komehakubutsukan-passage_B.png|thumb|500px|実際の人間の胴体の厚み程度では、写真のように、パースは、ほとんどつかない。]]

現実の風景を観察すれば一目瞭然ですが、たとえば自宅のベランダを（一般的な民家の広さとする）、室内のベランダから50センチくらい前から斜め前方のベランダ床を見ても（真正面のベランダ床を見ても、傾斜は0になる）、いちおう斜め前方のベランダ床にパースはついているのですが、しかしパースの角度はベランダすら、せいぜい角度にして片側15度くらいです。ベランダでなくとも、お風呂の床のタイルでもいいです。床に、直線状または格子状に模様があると、パースが分かりやすいです。

なので、ベランダやお風呂の床タイルの斜め前方に見下ろした視界では、パース自体はあるものの、ほとんどパースは目立たず、他人から「実はベランダにもパースがついているよ。ほら床を見てごらん」とか指摘されてようやく気づけるほどしか、パースはついていません。またベランダ直前のその室内から、となりの家の一般の民家の窓ガラスも、パースがついているかどうかも、分かりづらい程度です。

いっぽう、立っている人間の 肩幅 や 胴の厚さは、どう考えてもベランダなどの通路よりも狭いし、窓ガラスよりも直立人間の横幅・肩幅・胴厚は狭いので、現実の人間の観察のさいに50センチ以上遠くにいる人体にパースが目立つことは、（現実の人間の視界では）ないでしょう。（ただし、相手か自分のどちらかが寝そべっていたり、あるいは相手が両手を前後に広げていたりしたら（歌舞伎のポーズみたいに）、近くにいる相手にパースがやや目立つ場合はあるかもしれません。）

私たちが書籍などで普段みる人間の顔写真は、実はやや望遠ぎみです（撮影者が一般にレンズの焦点距離を公表しないので不明だが、広角で被写体の顔を近づけて撮影すると顔がかなり歪んで（ゆがんで）撮影されて見苦しいので、普通はやや望遠だと思われる）。

美術などで資料として使う写真には、そういうゆがみは避けたいので、人物の顔写真などは望遠で撮影されていると思われます。

なので、正面顔の写真なら、手前にある鼻と、やや奥にある耳とでは、すでに望遠レンズによる奥行きの圧縮がついていて、ああいう構図の写真になっているわけです。

望遠レンズで遠くの人物を撮影した時、顔が小さく映っていても，写真のプリントアウト時に拡大してみて顔の大きさが標準レンズ撮影時に同じになるようにプリントアウトすると、写真上での顔の形はほとんど同じに見えます。

よく、テレビ業界などで、まるでバズーカ砲みたいに大きさが人間の顔みたいに大きい大型カメラがあるが、あれは何かと言うと、大型の望遠レンズです。大きいカメラほど焦点距離が長く、視野角も小さいでしょう。

望遠的なレンズで撮影するぶんには顔の形は歪まないようですね。

なので、その望遠の状態からやや前後に被写体が動いたくらいでは、望遠では奥行きによるパースによる左右位置の変化の影響は小さいので無視できます。同様に、あるいは顔を斜めにしたくらいでは、ほとんどパースの左右位置の変化の影響は表れないでしょう。

:※ 望遠レンズによる奥行きの圧縮は、美術のほかにも、マスコミ報道の実写映像で応用されたり、または宣伝写真などでも応用される場合もあり、用途としては人数の密度を高めに錯覚させたい場合に使われる場合があります。たとえば商店街などが実際よりも混雑して盛況なように見せたい場合に、望遠レンズで写真撮影することにより奥行きを圧縮することで、写真を見た観客に、あたかもその商店街での客の密度が高いかのように錯覚させる撮影手法なども、昔からよくあります。

:※ 一般の人間の顔写真に近いのは、望遠レンズです。望遠100mmレンズ、135mmレンズ、200mmレンズでも、ほとんど撮影された写真での顔の各部の位置は同じです。広角で撮影する場合は、70mmレンズなどで撮影すると考えられる。（広角30mmで近い人の顔を撮影しても、あまりに歪んでおり、顔写真としては使い物にならない。近似計算だが、まるで反比例のグラフのように、0（ゼロ）mm近くでは急速に写真が変化するが、しかし基準となる数値（この場合は70mm～100mmあたり）を超えると、あまり写真が変化しなくなる。）

:※ もし幾何学的に正確に構図での被写体大小を計算するなら三角関数をつかった方程式で計算すればよいのだろうが、しかしそれだと計算が複雑すぎる。
:なので、計算の手間をへらすために反比例として近似を考えると、割と、実物の構図と近い構図になる。
:しかし、それだと絵を描くさいに作図が大変なので、さらに「近距離の場合だけ、被写体が離れると、マイナスの一次関数のように遠くほど被写体が小さくなる」、として近似している。

とにかく、あまり、通常の顔写真以上にパースの強調された写真というのは、発生しづらいのです。（遠くにあるものは、遠くにあるので縮小こそされているが、しかし拡大してみれば、形状はほとんど標準の距離の状態と（形が）変わらないのである。）

なので、被写体の顔がよほどカメラの近くにないかぎり（たとえば顔の どアップを至近距離（10～15センチくらい）で撮影してるのでもないかぎり）、けっして、よくみる顔写真以上のパースがつくことは通常、ありえないのです。

しかし一方絵の勉強として、あえて人物にパースを広角で強めにつけたイラストを練習することが必要な場合もあります。

また、漫画やアニメーションでも、あえてパースを実際にはありえないほどに強調する手法もあり、たとえば格闘マンガなどでカメラ方向（観察者のいる方向）に向かって出されたパンチをやたらと大きく描いて（この場合はパンチマンの）手のスピード感や迫力などを強調するような手法で、このような手法の呼び名はよく「嘘パース」（うそパース）と言われます。

また、アオリ、俯瞰という構図もありますね。
アオリとは、観察者が下側にいて、下側から上方向に向かって、物を見上げる構図です。

いっぽう、フカンとは、観察者が上側にいて、上側から下方向に向かって、下方を見る構図です。

例として、親子が立って、いたとしましょう。

親が、おさない我が子を見るとき、フカンの構図でしょう。

いっぽう、おさない子が、立っている親の顔を見るとき、アオリの構図でしょう。

演出的に「アオリ/フカンであり、なおかつ、広角パースを強調する」のような構図にする場合もありますね。

== 望遠パース推進と広角パース否定 ==
[[File:Compression Depth diagram japanese B.svg|thumb|650px|奥行きの長い立方体を描くなという主張&lt;br&gt;※　『[[中学校技術/材料と加工に関する技術を利用した製作品の設計・製作#キャビネット図|キャビネット図]]』とは、中学校の技術科で習う製図技法のひとつ。（※リンク先はwikibooks中学技術科）]]

世の絵描きの中には、画角の小さい望遠パースだけを採用して、その方針の下、割と教条的に絵画技法をまとめ上げて、実用に供している人たちがいるようで、そういう人たちのルールの一つに、直線を引いて一点透視や二点透視を近似的に描く透視図法は、遠くにある物を描く場合でしか使えない&lt;ref&gt;西澤晋『リアルなキャラクターを描くためのデッサン講座』 (漫画の教科書シリーズ No.03) 、誠文堂新光社、2009年7月31日発行、146ページ&lt;/ref&gt;、というものがあるようです。

本来1点透視は画面の中央に消失点があるものですし、2点透視の二つの消失点を結ぶ線分は画面の中央点を通るようにするのが，見えている光景の真ん中を描くためには重要な条件ですが、描く絵を望遠パースに限るとこの法則はそれほど適用しなくてよくなり、割と自由に1点や2点の消失点を置けるようになります。

そしてその場合，1点2点透視を使うのは，遠くにあるものを描くときだけ使えという主張ですね。

では近くにあるものを描く場合はどうするか。

望遠パースのみを採用する場合、我々が見ている光景を小さな画角で切り取り、絵として描く場合，消失点が画面に含まれている場合と、画面の外に行ってしまって画面内に消失点がない場合がありますね。

そこで近くの立方体を描く場合は，消失点が画面内にある場合は奥行きは短く、圧縮しなければいけませんし、画面外に消失点がある場合は、立方体の奥行きは割と長く広く描かれるようになるでしょう。

そして画面外に消失点があって立方体の奥行きが長く描かれるときは、いっそキャビネット図にしてしまうという方法があります。

キャビネット図とは、中学の技術家庭科の技術分野で習った、図法の一種です。

[[File:立方体のキャビネット図.svg|thumb|300px|left|立方体のキャビネット図]]
{{-}}
[[File:Cabinet drawing and perspective corresponding japanese B.svg|thumb|500px]]

キャビネット図も、右図の例のように、遠くに消失点のある透視図を近似的に描いた物であるとも解釈する事も出来ます。

ただし、キャビネット図（上左の図）そのものの描きかただと、側面・上面の圧縮が強すぎるので、美術用にリアルな絵を書く場合には、側面・上面の長さを右図のように、やや延長（おおむね1.5倍くらいに長さを倍増）して使うほうが自然に見えます。

ただしこういう教条的な絵画技法は、あくまで画角の小さい望遠パ―スだけを採用する場合に当てはまる事です。

画角の広い広角の絵を認めたうえで、リアルな、効果的な絵を描くためには、もう少し一般的な遠近法、透視図法の理解が必要になりますし、逆に教条的、教文的絵画技法は、絵画活動や画法理解の障害になる場合もあります。

==現実にない空間を作る==
美術では、作風にもよりますが、望遠パースと広角パースは、都合に応じて逆らって使われます。実写のカメラでは本来、望遠レンズと広角パースがひとつなぎののカットで混在する事はありませんが、しかし手描きの絵画やアニメなら、カメラでは不可能な映像を作ることも出来ます。

たとえば、有名アニメ映画監督の使う手法で、群集シーンなどで人物は望遠パースだが、建物などの背景は広角パースで描く、という手法もあります。有名な例では、アニメ映画『もののけ姫』や『千と千尋の神隠し』などで有名なアニメ会社スタジオジブリが、よくそういった望遠パースと広角パースとの混在で、群衆シーンなどの絵を書きます。（たとえば1998年ごろの日本テレビ系列の科学番組『特命リサーチ200X』で、ジブリのそういう作画技法がテレビで紹介された事もあります。また、同様の内容はドキュメンタリーDVD書籍『「もののけ姫」はこうして生まれた』でも確認できます。）もし広角パースを人物にも使うと人物も縮小してしまいますが、しかし演出の都合で人物をなるべく大きく表現したい場合が多々ありますので、そういった場合に、人物だけ望遠パース的に、縮小率を小さくしたりする場合もよくあります。屋外シーンなどでよく、望遠パースと広角パースの意図的な混在が使われます。

また、マンガなどでも、「嘘パース」（うそパース）と言って、演出などの必要に応じて、カメラレンズならありえない程度に極端に手前のものが大きくなったパースを使う場合もあります。よく格闘マンガなどで、パンチで突き出した拳が、実際の構図よりも手がかなり大きかったりしますが、これも嘘パースの例です。

しかし、このようなパース混在の手法が比較的に容易に実装できるのは、手描きの絵の場合です。コンピュータグラフィックの場合、そのソフトウェアのシステムにもよりますが、嘘パースや広角・望遠の混在パースなどは、実装が難しくなります。ＣＧで嘘パースなどを表現する場合、代替的に、そのシーンだけキャラクター3Dモデルを別途作成したりして、表現します。つまり、手前に来る人物だけ大きさを拡大した巨人のモデルにしたり、あるいは格闘のパンチシーンなら手だけ大きいキャラクターモデルを作ってそのモデルに入れ替えたりして表現します。たとえば2012年のアニメ映画『アシュラ』（ジョージ秋山 原作、東映アニメーション制作、プロダクションIG制作協力）でも、そのように3Dモデルを別途作成することで、CGでの嘘パースを実装しています。

嘘パースなどは、上述のように作成に手間が掛かるので、（アニメ映画なら可能かもしれませんが、しかしプレステ作品などの）ゲームソフトの3D映像で表現するのは難しいかもしれません。

演出によるウソの映像は、パースのほかにも、光源によるウソも比較的に芸術業界では有名な演出です。

太陽はひとつですので、太陽光も一方向からやってくるのが、自然な光です。しかし、ポスターイラストなどでは、被写体の立体感を強調するために、しばしば、観客に分からない程度にさりげなく、光源を2～3個用意した構図のイラストが描かれている場合も多々あります。

イラストだけでなく、女優モデルなどの写真撮影でも同様の撮影技法があり、被写体の立体感を強調するために光源を複数用意して、暗室などでメインの光源1つとサブ光源1～2個で被写体の女優を照らして撮影するというテクニックも、ときどき使われている事もあります。

== メルクマール ==
:（※ 一般の教科書には無い用語です）

文芸の用語で「メルクマール」というのがあります。もともとはドイツ語で、単なる「目印」（めじるし）という意味です。

しかし文芸で「'''メルクマール'''」といった場合には、やや特別な意味があり、その特別な意味とは、おおむね「なにかの流行や時代の代表例となる作品や作家のこと」のような意味です。

たとえば、漫画文化で、第二次世界大戦後の終戦直後や復興期のマンガ家として手塚治虫がよくとりあげられたり、彼・手塚の代表作『鉄腕アトム』がよく紹介されますが、このような例がメルクマールです。

さて、美術史やコンテンツ産業の歴史において、メルクマールは一つの目印（めじるし）であり、起源ではありません

たとえば、明治時代以降に日本でマンガを始めたのは、手塚が最初ではありません。『のらくろ』の田河水泡（たがわ すいほう）とか、手塚以前の時代の漫画家は、多くいます。

ゲーム機でも、1980年代のファミコンの発売と普及がよく紹介されるので（この例ではメルクマールはファミコンである）、ファミコンが家庭用ゲーム機の元祖だと考える人が多くいますが、しかし世界初の家庭用ゲーム機は欧米産のオデッセイですし、日本初の家庭用ゲーム機はエポック社のテレビテニスです。 

美術史でも同様で、室町時代に水墨画を広めた雪舟（せっしゅう）は、べつに水墨画の日本での最初の人ではないですよね。

==日本の小学校、中学校、高等学校における一般的な美術教育の傾向について。==
===漫画、アニメーション、芸術、学校美術科と進路===
この国では漫画やアニメーションが盛んですし、将来そういう分野の絵描きになりたいと思う高校生も多いと思います。前編集者S は学校での美術教育は商業的な漫画やアニメーション制作のための訓練や学習としては、不十分だし方向性も違うと大上段に語っていますが、そもそも高校までの普通科の美術教育は、ほんの絵画世界の片りんに触れているだけにすぎませんので、あえて得意げに語ることではないでしょう。職業として絵描きを目指す高校生は、それぞれ自分自身で情報を集め、絵の練習も繰り返しているでしょうし、学校には美術部がたいていあるでしょうし、学校以外でも絵画の勉強をできる場所はたくさんありますよね。そして進路に関しては学校の美術教師が相談に乗ってくれるでしょう。

学校の美術の授業さえ受けていれば、漫画家やアニメーターになれると思っている高校生なんて一人もいませんよね。

そしてそういう進路を目指す高校生は、みな、すでにおそらく1年生あたりから情報を集め、様々な活動、勉強、練習を繰り返しているでしょう。

進路として美大進学という道もありますし、美大出でなくてもアニメーターや漫画家になる人はたくさんいる。一方で美大や芸術短大を卒業した後、そういう職業に就く人も多いですよね。

兎に角芸術と娯楽、アニメーションと漫画と美術、いちいち分別してクドクドと理屈を振りかざすことほど馬鹿げたことはないでしょう。

===美術の言葉===
言葉というのは一般にそうですが、あいまいなもので、同じ言葉でも意外と場所や社会で意味が異なってくることもありますよね。

美術の世界でもそういうことは起こりますし、「デッサン」、「デザイン」、「スケッチ」、「パース」、「デザイナー」等、美術に関して馴染みのある言葉でも、構成員や場所によって微妙に違う意味で使われていることもあります。

職業の場でも、業界や会社によってさまざまな意味になったり言い方が変わったりしますよね。

ただ、それは言葉というものの一般的な性質ですから、そんなことはどこかの大先生に偉そうにくどくど解説されなくても、高校生ぐらいになれば、みんな分かっていることだと思います。

=== 日本の普通学校美術 ===
日本の普通の学校における美術教育は、世界的にみるとかなり特殊らしい。ある編集者（仮にAとする）がまず示した出典、2010年におけるニコニコ動画の投稿&lt;ref&gt;[https://www.nicovideo.jp/watch/sm12926060 村上隆の芸術闘争論#2　日本の美術教育はどう特殊なのか(vs森川嘉一郎)] 投稿日時 2010/12/03 17:11、2021年9月8日に確認&lt;/ref&gt;によると、二人の美術関係者がかなり長々と現状の学校美術教育を批判している。

編集者Aはさらに、アーツ・アンド・クラフツ運動と独国バウハウスについて言及しているが&lt;ref&gt;[https://www.mext.go.jp/content/20200609-mxt_jogai01-000007843_002.pdf 高等学校情報科「情報Ⅱ」教員研修用教材　第1章 - 20200609-mxt_jogai01-000007843_002.pdf] 『情報社会の進展と情報技術』 P40、2021年9月8日に確認&lt;/ref&gt;、前者は工業製品、大量生産品のオブジェクトとしての安易さ、粗悪さを批判しそれを改善することを目的としていただろうし、後者はデザインに合理性、機能性を求めた美術教育の話だが、どちらにせよ、日本の美術教育の傾向に絡める必要もない話だろう（※ ←個人的見解）。

最初の動画では、学校の美術のペラペラの教科書が批判され、然しこの人物のくどい説明に眩暈がしてきたので（※ ←編集者個人の体験）、結局どういう美術教育が良いと考えているのかわからなかったので、興味のある方々はリンク先のこの動画の方を観ていただきたい。

ちなみに村上隆はこの国の現代美術の分野でトップランナーとみなしていい芸術家で、高校美術の教科書でもたびたび紹介されている&lt;ref&gt;最近のものだと、たとえば [https://www.nichibun-g.co.jp/textbooks/k-bi/2022_bi01_2/textbook/  日本文教出版 （令和4年度新版教科書）「高校美術」 村上隆「五百羅漢」] （2022年1月7日に確認）&lt;/ref&gt;&lt;ref&gt;[https://www.mitsumura-tosho.co.jp/kyokasho/k_bijutsu/29bi/keisaisakka/index.html  ページ『掲載作家一覧 | 現行版 美術1 | 高等学校 美術 | 光村図書出版』、 ] 2022年1月7日に確認. &lt;/ref&gt;。然しこの頁の一編集者S は、彼の見解が別に世界の美術教育の多数説や有力説などと言う証拠もないので、興味なければ出典動画を見に行く必要は無いだろうと忠告している。

明治時代の日本における小中高の美術教育の方針は、工場労働者などの職人を育てるため、手先の器用さを育成したい、という意図があったようだ。特に当時の軍部が、美術教育によって、手工業職人的な手先の器用さ、物づくりの技術育成の教育が必要、重要だと考えていたようである。&lt;!-- 
もとの文章を書いた人の出典によると、彼はうろ覚えなので自信がないようですが、彼が挙げるには、たしか科学史家の村上陽一郎（むらかみ よういちろう）だったか、あるいは教育学者の天野郁夫（あまの いくお）の著作だか、あるいは実教出版の『[https://www.amazon.co.jp/%E8%B3%87%E6%96%99-%E6%97%A5%E6%9C%AC%E5%B7%A5%E6%A5%AD%E6%95%99%E8%82%B2%E5%8F%B2-%E5%B0%8F%E6%9E%97-%E4%B8%80%E4%B9%9F/dp/4407030526|資料 日本工業教育史]』（2001年、小林一也 ほか著）で、そういう事が書いてあったような気がすると、元編集者（編集者A）は主張しています。彼が言うには時期的には、だいたい2001±10年前後の著作です。

出典があいまいですが、出典が無いと今後のほかの編集者に負担が大いに掛かるので、出典を非表示タグで保管します。
  --&gt;

1990年代までの普通の学校での美術教育は、わりに写実画を重視していたが、2000年以降は、あまり写実にこだわらず、いろいろな発想で絵を描くように指導しているようだ。

== 出典など ==</text>
      <sha1>pu7sg5j2ftlraeti71q5a978fz3prpw</sha1>
    </revision>
  </page>
  <page>
    <title>高等学校日本史B/飛鳥の朝廷</title>
    <ns>0</ns>
    <id>22954</id>
    <revision>
      <id>205731</id>
      <parentid>123650</parentid>
      <timestamp>2022-07-23T13:57:12Z</timestamp>
      <contributor>
        <username>椎楽</username>
        <id>32225</id>
      </contributor>
      <minor />
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="11404" xml:space="preserve">{{Nav}}

※ いくつかの検定教科書では、飛鳥時代から「朝廷」という表現で、日本の中央政治の機構のことを表現しています。（実教出版、山川出版社など）
----
==仏教伝来==
6世紀なかば、欽明天皇のときに倭国（日本）は仏教を百済から公式に取り入れたとされる。このときの百済王は、'''聖明王'''（せいめいおう）である。日本が取り入れた仏教は、中国・朝鮮などを経由した北方仏教の系統である。

日本への仏教伝来の年代については2説あり、538年（『上宮聖徳法王帝説』（じょうぐうしょうとくほうおうていせつ）『元興寺縁起』（がんごうじえんぎ）などによる説）に仏教伝来したとする説と、552年（『日本書紀』による説）に仏教伝来したとする説がある。

当時、百済は高句麗や新羅と対立しており、そのため日本を味方につけようとしたのであろう。

しかし、この仏教伝来は公式に限定しての話であり、おそらく実際には渡来人によって、それ以前に日本に仏教が伝えられていたと考えられる。
また、6世紀には五経博士の渡来により、儒教も日本に伝えられた。

==飛鳥の朝廷==
また、この6世紀のなかば頃から、ヤマト王権は九州から関東までの広い地域に強力な支配を及ぼし、実質的にヤマト王権が日本を支配する王朝になっていた。現代の日本の歴史学で、古代日本の「朝廷」という場合、この6世紀頃からの日本の中央政治機構のことを意味する。

[[File:聖徳太子の系図.svg|thumb|400px|聖徳太子の系図&lt;br /&gt;四角で青く塗ってあるのが大王。赤字の人物は女性。数字は大王即位順。]]

6世紀なかば、日本では、物部氏と蘇我氏が対立していた。彼らは外国文化の受容の有無についても対立しており、積極的に外国から仏教などの先進文化を取り入れるべき（崇仏派）とする蘇我氏（蘇我稲目（そがのいなめ））と、伝統を重んじるべき（排仏派）とする物部氏（物部尾輿（もののべのおこし））とが対立していた。

587年、大臣（おおおみ）の'''蘇我馬子'''（そがの うまこ）が、大連（おおむらじ）の'''物部守屋'''（もののべの もりや）を滅ぼし、蘇我の血を引く泊瀬部皇子（はっせべのみこ）を大王に即位させた（'''崇峻天皇'''（すしゅんてんのう））。しかし、大王は馬子と次第に対立し、馬子は592年に崇峻天皇を殺害して自らの姪に当たる額田部皇女（ぬかたべのひめみこ）を大王に即けた。日本初の女帝、'''推古天皇'''である。そして推古天皇の甥の'''厩戸王'''（うまやとおう）（※ 厩戸王は聖徳太子と同一人物？）と大臣蘇我馬子が協力して大王を助ける政治体制が成立した。その体制の下で603年に'''冠位十二階の制'''が、翌604年には'''憲法十七条'''（けんぽうじゅうしちじょう）が制定された。

:※ 「厩戸皇子」と書いても正しい。検定教科書の出版社によっては、「厩戸王」ではなく「厩戸皇子」と検定教科書に書いてある出版社もある。


:※ 蘇我馬子が崇峻天皇を暗殺したりと、蘇我一族がたびたび暗殺などをしているイメージから、ついつい「立派な聖徳太子と、人殺しの悪人である蘇我一族とは、敵対しているハズだ！」と先入観を抱きがち（いだきがち）が、しかし歴史学的には、そんなイメージの証拠はない。　小中学校までの歴史知識では、ついつい蘇我馬子と聖徳太子の関係を勘違いしやすいので、要注意のこと。また、読者の高校生が将来、子供に歴史教育をする場合も、ここらへん、要注意である。家系図で推古天皇の先祖を見れば推古天皇の先祖に蘇我稲目がいる事からも分かるように、そもそも推古天皇は蘇我氏の一員である。（※ 山川出版社『大学の日本史 1 古代』でも、推古天皇が蘇我氏の一員であると指摘している。　参考文献: 『大学の日本史 1 教養から考える日本史 古代』、第1版、2016年第1版、76ページ）

聖徳太子のモデルは厩戸王だろうというのが有力説だが、別人だという説もあり、また聖徳太子は『日本書紀』の編纂時につくられた架空の人物だという説もある。なお、冠位十二階の制や憲法十七条を定めた人が厩戸王であるとは断定できる証拠はないのだが（憲※ 清水書院の教科書でも説明されている）、分かりやすさを重視して、上述のように、あたかも厩戸王と蘇我馬子によって、冠位十二階の制などが定められたかのように説明した。（※ 山川出版社などの教科書でも、あたかも厩戸王が定めたかのように書かれている。）

{| style=&quot;width:100%&quot;
|valign=top style=&quot;width:60%;text-indent:1em&quot;|

&lt;div style=&quot;border:1px solid #000000;&quot;&gt;
　'''憲法十七条'''（抜粋）　（『日本書記』）
:一（いち）に曰く（いわく）、和（わ）を以て貴し（とうとし）と為し（なし）、忤（さか）ふること無きを宗（むね）とせよ。（後略）&lt;br/&gt;
:二に曰く、篤く（あつく）三宝（さんぽう）を敬へ（うやまえ）。三宝とは仏（ほとけ）・法（のり）・僧（ほうし）なり。（後略）&lt;br/&gt;
:三に曰く、詔（みことのり）を承り（うけたまわり）ては必ず謹め（つつしめ）、君をば天（あめ）とす、臣をば地（つち）とす。&lt;br/&gt;
::（中略）
:十二に曰く、国司（くにのみこともち）・国造（くにのみやつこ）、百姓（おおみたから）に斂る（おさめる）ことなかれ。国に二君（ふたりのきみ）非（な）く、民に両主（ふたりのあるじ）無し、率土（くにのうち）の兆民(おおみたから）、王（きみ）をもって主となす。（略）&lt;br/&gt;
::（中略）
:十七に曰く、夫れ（それ）事は独り（ひとり）断む（さだむ）べからず。必ず衆（もろもろ）とともに宜しく（よろしく）論ふ（あげつらう）べし。（後略）

::（原漢文）
&lt;/div&gt;

|valign=top style=&quot;width:5%;text-indent:1em&quot;|
|valign=top style=&quot;width:35%;text-indent:1em&quot;|

一に言う、和を尊び、争うことのないように心がけよ。・・・

二に言う、熱心に三宝を敬え。三宝とは仏像、経典、僧侶のことである。・・・

三に言う、詔（ 天皇の命令の一種）を受けたなら、必ず従え。君主こそが天であり、臣は地のようなものだ。

十二に言う、国司や国造は、人民（＝「百姓」とは「多くの民」「人民すべて」などの意味）から税金を勝手にとってはならない。・・・

十七に言う、ものごとは一人では決めてはいけない。かならず皆と意見を話し合うべきである。・・・

|}

※ 現代語訳については、教科書や（参考書会社の）史料集ごとに微妙にちがうので、一字一句を覚える必要はない。
:たとえば「忤（さか）ふること」の意味が、教科書や参考書によっては、「反抗すること」だったり「争うこと」だったりと、書籍ごとに違ってくる。

西暦600年から607年にかけ、'''小野妹子'''が遣隋使として中国に渡った。
『隋書』によると600年に遣隋使が日本から派遣されたとされるが、日本書紀によると607年に遣隋使を派遣したとあり、微妙に時期がくいちがっている。

隋の皇帝・'''煬帝'''（ようだい）が受け取った、日本からの国書には、日本が隋に従属しないことが書かれていたので、煬帝は立腹し「無礼」と言ったという。


{| style=&quot;width:100%&quot;
|valign=top style=&quot;width:60%;text-indent:1em&quot;|

&lt;div style=&quot;border:1px solid #000000;&quot;&gt;
　遣隋使の派遣（抜粋）　（『隋書』倭国伝）
:'''大業（たいぎょう）三年、其の（その）王多利思比孤（たりしひこ）、使を遺して朝貢す。'''&lt;br/&gt;
:（中略）
:其の国書に曰く「'''日出づる（いづる）処（ところの）の天子、書（しょ）を日（ひ）没する処（ぼっするところ）の天子に致す（いたす）。恙無きや（つつがなきや）、云々（うんぬん）'''」と。帝（てい）、之（これ）を覧て（みて）悦ばず（よろこばず）、鴻臚卿(こうろけい)に謂いて（いいて）曰く（いわく）「蛮夷の書（ばんいのしょ）、無礼なる者（ぶれいなるもの）有り（あり）。復た（また）以って（もって）聞(ぶん)する勿れ（なかれ）」と。&lt;br/&gt;
:（後略）

::（原漢文）
&lt;/div&gt;

|valign=top style=&quot;width:5%;text-indent:1em&quot;|
|valign=top style=&quot;width:35%;text-indent:1em&quot;|

隋の大業3年、倭国の王多利思比孤（たりしひこ）からの使者が来て、朝貢してきた。
:（中略）
その国書には「太陽が昇るところの天子が、太陽の没するところの天子に、手紙を送る。おかわりありませんか。・・・」と書かれていた。帝（煬帝）は、この国書を見て不機嫌になり、外交関係の役職（鴻臚卿）の者に言った。「野蛮な書。無礼である。今後は上奏するな」と。

|}

「鴻臚卿」（こうろけい）とは、外交関係の官のこと。

※ 「聞する勿れ」の意味が、「上奏するな」か「奏上するな」なのかは教科書や参考書ごとに違う。

倭の五王の時代とは異なり、倭国は中国に服属しないことを、国書では匂わせていた。これに煬帝は立腹したが、高句麗と中国との戦争を有利にするため、翌608年には中国は使節・裴世清（はいせいせい、 ※ 人名）を倭国に派遣した。

妹子の遣隋使に同行した高向玄理（たかむこのげんり）・南淵請安（みなみぶちのしょうあん）・旻（みん、 ※人名）などの留学生が、中国に長期滞在し、そして中国の文化を日本に伝えた。

[[category:高等学校日本史|あすかのちようてい]]
「聖徳太子が小野妹子を遣隋使として中国に派遣した」という説があるが、妹子に派遣を命じたのが厩戸王だと断定できる証拠はない。（※ 清水書院の教科書で記載されている。）

==飛鳥文化==
伝来した仏教は倭国の文化に変化をもたらした。それまでの古墳に代わって寺院が、豪族の権威を象徴するようになった。'''法隆寺'''はその一例である。大和（やまと）の飛鳥（あすか）を中心に栄えた文化なので、この文化を'''飛鳥文化'''と呼ぶ。</text>
      <sha1>hpxkij7gqve6smclv5q1ga970rbtnk6</sha1>
    </revision>
  </page>
  <page>
    <title>高等学校日本史B/律令国家への道</title>
    <ns>0</ns>
    <id>24075</id>
    <revision>
      <id>205732</id>
      <parentid>176633</parentid>
      <timestamp>2022-07-23T13:58:10Z</timestamp>
      <contributor>
        <username>椎楽</username>
        <id>32225</id>
      </contributor>
      <minor />
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="25514" xml:space="preserve">{{Pathnav|メインページ|小学校・中学校・高等学校の学習|高等学校の学習|地理歴史|frame=1}}

{{Nav}}

&lt;!-- このページには導入部がありません。適切な導入部を作成し、このコメントを除去してください。 --&gt;

== 大化の改新 ==
=== 厩戸王の死後 ===
[[File:飛鳥時代の天皇の系図.svg|thumb|500px|飛鳥時代の大王の系図-青四角:大王（天皇）・赤字:女性・数字は即位した順]]

622年に厩戸王（聖徳太子）が、次いで626年に{{Ruby|大臣|おおおみ}}の{{中付きルビ|1=3|2=蘇我|6=馬子|3=そが|4=  |5=の|7=うまこ}}が死去すると、子の蘇我{{Ruby|蝦夷|えみし}}とその孫である蘇我{{Ruby|入鹿|いるか}}がヤマト政権で権勢をふるった。

当時の倭国は'''唐'''の外圧に対処するため中央集権を進める必要に迫られていたが、643年に蘇我入鹿が厩戸王の子である{{中付きルビ|1=3|2=山背|6=大兄|4=  |10=王|3=やましろ|5=の|7=おおえ|8=  |9=の|11=おう}}とその一族を滅ぼし、蘇我氏一族への権力集中を図った。このように強権的な蘇我氏に対して、豪族や大王（天皇）中心の国家体制を目指す勢力からの不満が高まっていった。

中央集権国家を目指す'''{{中付きルビ|1=5|2=中|6=大兄|10=皇子|3=なか|4=  |5=の|7=おおえ|8=  |9=の|11=みこ}}'''と、'''{{中付きルビ|1=3|2=中臣|6=鎌足|3=なかとみ|4=  |5=の|7=かまたり}}'''らが{{中付きルビ|1=7|2=蘇我|6=倉山|8=田|12=石川|14=麻呂|3=そが|4=  |5=の|7=くらやま|9=だ|10=  |11=の|13=いしかわ|15=まろ}}らと謀り、645年に蘇我入鹿を殺害した。蝦夷はこの事件を知り自殺して、蘇我宗家は滅んだ。これを{{Ruby|'''乙巳'''|いっし|の変}}という。

=== 大化の改新 ===
乙巳の変ののち、皇極天皇は退位し、弟の{{Ruby|軽皇子|かるのみこ}}が新たに大王に即位した（'''孝徳天皇'''）。なお、当時生前に大王が譲位するのは異例のことで、天皇譲位の初例とされる。皇太子となった中大兄皇子らが政権を主導し、政治改革を次々と行なった。この一連の改革を{{Ruby|'''大化の改新'''|たいかのかいしん}}という。645年に初めて元号を「{{Ruby|大化|たいか}}」に定めたとされる。

[[ファイル:Preceding naniwanomiya.jpg|thumb|300px|{{中付きルビ|1=3|2=難波|6=宮|3=なにわ|4=  |5=の|7=みや}}の復元模型（[[w:大阪歴史博物館|大阪歴史博物館]]）]]
大王は現在の大阪府にあった{{中付きルビ|1=|2=難波|4=長|6=柄|10=豊碕|14=宮|3=なにわ|5=なが|7=ら|8=  |9=の|11=とよさき|12=  |13=の|15=みや}}（'''難波宮'''）に[[wikt:遷都|遷都]]し、政治改革が進められた。新政権は右大臣に蘇我倉山田石川麻呂、左大臣に{{中付きルビ|1=|2=阿部|6=内|8=麻呂|3=あべ|4=  |5=の|7=うち|9=まろ}}、{{Ruby|内臣|うちつおみ}}に中臣鎌足をそれぞれ登用した。また、妹子の遣隋使に同行した{{中付きルビ|1=|2=高向|6=玄|8=理|3=たかむこ|4=  |5=の|7=げん|9=り}}・{{Ruby|旻|みん}}らは{{Ruby|国博士|くにのはかせ}}として登用された。

645年、中大兄皇子は有力な大王候補であった{{中付きルビ||2=古人|6=大兄|10=王|3=ふるひと|4=  |5=の|7=おおえ|8=  |9=の|11=おう}}を滅ぼし、649年には対立を深めた蘇我倉山田石川麻呂を滅ぼして政権から有力な豪族を排除、中央集権を強めた。

乙巳の変の翌年の646年に{{Ruby|'''改新の詔'''|かいしんのみことのり}}が出された。これはいわば新政権の施政方針であり、『日本書紀』にその本文が見られる（ただし、一部後世に付け足したと思われる内容も散見される）。

'''公地公民'''（こうちこうみん）、'''班田収授'''（はんでんしゅうじゅ）、租（そ）・庸（よう）・調（ちょう）などの税制の整備、'''戸籍'''・'''計帳'''の創設、'''国司'''（こくし）の設置等が主な内容であった。
* '''公地公民'''
これまで豪族や王族たちが持っていた土地や人民は、すべて朝廷のものであるとした。また、朝廷が管理できない土地、人民の存在を禁止した。
* '''班田収授'''
租を徴収するため、人民に田を与えて稲作をさせること。ただし実際に班田収授が行われるのはまだ先のことである。

== 国際情勢 ==
７世紀半ばになると、朝鮮半島で戦乱が起こる。新羅(しんら、しらぎ、シルラ)が唐(とう)と連合して、百済(ひゃくさい、くだら、ペクチェ)を侵攻し、660年に百済は滅亡した。
倭国(わこく)は百済と親交があり、百済滅亡により倭国は朝鮮半島での影響力を失った。倭国のヤマト政権は百済の復活を名目として朝鮮半島での影響力を取り戻すため、663年に中大兄皇子の指導により朝鮮半島に軍を送り、倭国軍と新羅軍が軍事衝突して'''白村江の戦い'''(はくすきのえのたたかい、はくそうこうのたたかい) が勃発した。この戦いで倭国軍は新羅と唐の連合軍に敗れた。

白村江の敗戦を受けて中大兄皇子は、唐と新羅の倭国への直接攻撃に備えるため、九州の防備を強化する。九州北部に九州防衛のための兵士である'''防人'''(さきもり)を置き、'''水城'''(みずき)という水の満たされた濠(ほり)を持った土塁が築かれた防御地点を各地に築かせた。

(※ 発展的な話題: )九州で国防の拠点になった'''太宰府'''(だざいふ)の背後の山の頂に大野城(おおのじょう)がある。このような山にある城のことを一般に'''山城'''(やましろ、やまじろ)という。(※ 中学歴史の日本文教出版、教育出版の教科書で紹介の話題。)

== 天智天皇の即位 ==
孝徳天皇が死去すると大王を退位していた宝皇女(たからのひめみこ、皇極天皇)が重祚(ちょうそ、天皇が再び即位すること)し、'''斉明天皇'''となった。引き続き中大兄が政権を率いたが、白村江の戦いのさなかに斉明天皇が死去した。中大兄は大王に即位せずにそのまま政務をみた('''称制''')。667年に、中大兄は都を今の滋賀県近江付近の'''大津宮'''(おおつのみや)に移した。この遷都は唐と新羅の連合軍の攻撃に備えてのことだと考えられる。

668年に中大兄皇子は大津宮で大王に即位し、のちの'''天智天皇'''(てんじてんのう)となる。同年、法典である'''近江令'''(おうみりょう)が成立したとされる。近江令は天智天皇が中臣鎌足に命じて編纂(へんさん)させたものであった。また天智天皇は、670年に日本最初の全国的な戸籍である'''庚午年籍'''(こうごねんじゃく) を作成する。

== 壬申の乱 ==
[[画像:Ｆuhon-sen.JPG|thumb|180px|right|富本銭(複製品)。　天武天皇のころに作られた日本で最初の銅の貨幣。]]
[[File:Fuhonsen Asukaike end of 7th century copper and antimony.jpg|thumb|180px|right|富本銭(ふほんせん)。(複製品)]]
671年に天智天皇が死去すると、672年に大王位をめぐって天智天皇の弟の'''大海人皇子'''(おおあまのおうじ)と、 近江朝廷を率いていた天智天皇の子の'''大友皇子'''(おおとものおうじ)が争った。この'''壬申の乱'''(じんしんのらん)は、大海人皇子が勝利し、敗れた大友皇子は自害した。大海人皇子は飛鳥浄御原宮(あすかのきよみはらのみや)に移り、天武天皇(てんむてんのう)として即位した。天武天皇は684年に天皇を中心とした新しい身分制度である'''八色の姓'''(やくさのかばね)を制定し、豪族の身分を再編した。この時代に、日本初の貨幣である'''富本銭'''(ふほんせん)が発行されたとされる。

｢倭国｣に代わる「日本国」という国号や、｢大王｣に代わる「天皇」という称号は、このころ使われ始めたという説が有力である。

(※ 註脚 )八色の姓には、真人(まひと)・朝臣(あそみ・あそん)・宿禰(すくね)・忌寸(いみき)・道師(みちのし)・臣(おみ)・連(むらじ)・稲置(いなぎ)の8つの姓がある。

689年には'''飛鳥清御原令'''(あすかきよみはらりょう)を施行し(※ 飛鳥清御原令は史料が現存しておらず内容が不明)、翌年には戸籍である'''庚寅年籍'''(こういんねんじゃく)を作成した。

== 藤原京 ==
天武天皇の死後、皇后が天皇として即位した('''持統天皇'''(じとうてんのう))。
天武天皇が'''藤原京'''の建設を始めたが、完成前に死去したため、完成は持統天皇の時代となる。694年に都を飛鳥から現在の奈良の藤原京に遷都させた。藤原京は、道路が碁盤(ごばん)の目のように、格子(こうし)状に区画されており、この都の碁盤目のような区画は、唐の都'''長安'''を参考にしている。

== 白鳳文化 ==
[[File:Takamat1.jpg|thumb|高松塚古墳壁画(奈良県、明日香村)&lt;br&gt;唐や高句麗の壁画の影響を受けていると、よく指摘される。&lt;br&gt;なお、この壁画は1972年に発見された。]]
[[ファイル:Yakushiji Nara11s5bs4200.jpg|thumb|left|薬師寺 東塔&lt;br&gt;三重(さんじゅう)の塔である。]]

天武・持統朝のころの文化は、宮廷を中心とした仏教調の文化であった。これを'''白鳳文化'''(はくほうぶんか)という。
天武天皇の時代には大官大寺(だいかんだいじ)、薬師寺(やくしじ)が建設された。
絵画では、法隆寺金堂壁画や、高松塚古墳(たかまつづかこふん) 壁画がある。

[[Image:Triad of Yakushi Nyorai.JPG|thumb|薬師三尊像]]

彫刻では、薬師寺の三尊像(さんぞんぞう)や、興福寺(こうふくじ)の仏頭(ぶっとう)がある。

[[File:Buddha Head Yamadadera.JPG|thumb|center|興福寺仏頭&lt;br&gt;火災で胴体を消失し、頭だけになった。]]

文学では、漢詩文が流行し、大津皇子(おおつみこ)がすぐれた作品を残した。
また、和歌もこの時代に五七調(ごしちちょう)の型式を整えた。歌人でもある額田王(ぬかたのおおきみ)や柿本人麻呂(かきのもとのひとまろ)は、この時代の人物である。

{{-}}

== 大宝律令 ==
:(たいほう りつりょう)
701年の文武天皇(もんむてんのう)のときに、 &lt;span style=&quot;color:red&quot;&gt;'''大宝律令'''&lt;/span&gt;(たいほうりつりょう) という法典が完成する。大宝律令は、唐の&lt;span style=&quot;color:red&quot;&gt;'''律令'''&lt;/span&gt;(りつりょう)という法律を参考にしています。

:※ 大宝律令は原文が現存しておらず、内容は不明であるが、718年の養老律令と似た内容だろうと推測されている。なお、この養老律令も原文は現存していないものの、後年に著された注釈書から内容が復元されている。

「律」は罪人をさばくための刑法で、「令」(りょう)は役所や役人などに対する法律です。

この大宝律令は、 '''藤原不比等'''(ふじわらの ふひと) らが中心となって編纂(へんさん)された。藤原不比等は、中臣鎌足(なかとみのかまたり)の子である。

政府の中央組織には 二官八省(にかんはっしょう) が置かれた。二官には、神々をまつる祭祀を行なう '''神祇官'''(じんぎかん)と、一般の政務をおこなう '''太政官'''(だじょうかん)がおかれた。

太政官には、 '''太政大臣''' を始めとして、 '''左大臣''' 、 '''右大臣''' など、様々な官職が置かれた。

太政官の下に、大蔵省などの八省が置かれた。
八省は、宮内省(くないしょう)、大蔵省(おおくらしょう)、刑部省(ぎょうぶしょう)、兵部省(ひょうぶしょう)、民部省(みんぶしょう)、治部省(じぶしょう)、式部省(しきぶしょう)、中務省(なかつかさしょう)である。

&lt;div style=&quot;font-size:120%;&quot;&gt;
&lt;pre&gt;
　　　　　　　　                                               　┏━━中務省
　　　　　　　　　　┏━ 左大臣   ━┓           ┏━ 左弁官 ━━╋━━式部省　
　　　┏━ 太政官 ━╋━ 太政大臣 ━╋━ 大納言 ━╋━ 少納言    ┣━━治部省                   
　　　┃　　　　　　┗━ 右大臣   ━┛           ┃              ┗━━民部省
天皇━┫　　　　　　　                           ┃            
　　　┃　　　　　　　                           ┗━ 右弁官 ━━┳━━兵部省      
　　　┃　　　　　　                                   　        ┣━━刑部省
　　　┗━ 神祇官　                                     　     　┣━━大蔵省
　　　　　　　　　                             　                ┗━━宮内省
  
&lt;/pre&gt;
&lt;/div&gt;


:中務省(なかつかさしょう)の仕事は、詔(みことのり)や勅(ちょく)の作成。
:式部省(しきぶしょう)の仕事は、役人の人事や教育。
:民部省(みんぶしょう)の仕事は、戸籍や租税。
:兵部省(ひょうぶしょう)の仕事は、軍事や警備。
:刑部省(ぎょうぶしょう)の仕事は、刑罰や裁判。
:大蔵省(おおくらしょう)の仕事は、物資の管理や財政。
:宮内省(くないしょう)の仕事は、宮中の事務や庶務。
:治部賞(じぶしょう)の仕事は、儀式や外交。


また、重要な地域には、専門の統治機構をもうけた。

太宰府(だざいふ)も、そのひとつである。筑紫が国防上の重要地点だったので、筑紫に太宰府を設けたのである。太宰府は、九州全域を統轄した。

京都には京識(きょうしき)を設け、左京職と右京職の2つの京職があった。

さらに、摂津(せっつ)は外交上重要なので、摂津に'''摂津職'''(せっつしき)を置き、難波(なにわ)を管轄させた。(摂津はいまでいう兵庫県あたりの場所。海(大阪湾など)に面するので、外交上重要だったのだろう。難波(なにわ)は、大坂の地名。)


* 官吏の取り締まり
官吏を対象とする取り締まりのため、'''弾正台'''(だんじょうだい)が置かれた。


* 警察・軍事
京都の宮殿の警備のため、5つの''衛府''(えふ)が置かれ、あわせて五衛府(ごえふ)といわれた。また、京都の警備をする者たちは衛士(えじ)と呼ばれた。

また、一般の国々の軍事・警察のため諸国には'''軍団'''(ぐんだん)を置き、九州の防衛には'''防人'''(さきもり)を置いた。


* 人事制度
各官庁の官職は、原則として４等級て構成されており、こうした制度を '''四等官'''(しとうかん)制という。四等官は、長官(かみ)・次官(すけ)・判官(じょう)・主典(さかん)である。


官人の階級は、全部で30の階級に分けられた。

官人の仕事は、原則として、位階に相当する官職に任命された('''官位相当制'''(かんい そうとうせい) )。

五位以上の官人は'''貴族'''(きぞく)と呼ばれた。(一位に近いほうが、階級が高い。)

また、五位以上の官人の子には、(役所への就職時に)父や祖父の位階に応じた位階を与えられた('''蔭位の制'''(おんいのせい))。(※ 親が一位なら子は五位からスタート、のようなシステム。)


官人の給与では、位階に応じて、「食封」(じきふ)や「禄」(ろく)が与えられた。食封とは、定められた数の戸から、そこからの租税をもらえる制度。

また、位階に応じて「位田」(いでん)や「位封」(いふ、いふう)などの給与が与えられ、官職に応じて「官田」などの給与が与えられた。

また、下級官人の子が官人になるためには、「大学寮」や「国学」などに入学して官人になるための教育を受ける必要があった。

* 刑罰
司法制度では、刑罰に、笞(ち)・杖(じょう)・徒(ず)・流(る)・死(し)の5つの刑があった。また、国家・天皇・尊属に対する罪は八虐(はちぎゃく)と言われ、とくに重罰とされた。

* 地方の人事

&lt;div style=&quot;font-size:120%;&quot;&gt;
&lt;pre&gt;
　　　　　　国　(国司)
　　　　　　┃
　　　　　　郡　(郡司)
　　　　　　┃
　　　　　　里　(里長)

&lt;/pre&gt;
&lt;/div&gt;
政府の組織や、地方行政の組織にも、改革が加わります。
まず、日本全国をいくつかの 国(くに) に分けて管理し、国は郡(こおり)に分けられ、郡は里(さと)に分けられます。

国には、中央の朝廷から、&lt;span style=&quot;color:red&quot;&gt;'''国司'''&lt;/span&gt;(こくし)という役人が派遣され、この国司によって、それぞれの国が管理されます。

郡を管理する役職は、&lt;span style=&quot;color:red&quot;&gt;'''郡司'''&lt;/span&gt;(ぐんじ)という役職の役人に管理させます。たいてい、その地方の豪族が郡司です。

また、地方の役所を図にまとめると、次のようになる。
&lt;div style=&quot;font-size:120%;&quot;&gt;
&lt;pre&gt;
(地方)　
　　　　　　　国司━━郡司━━里長

&lt;/pre&gt;
&lt;/div&gt;

中央貴族を国司に任命し、地方豪族を郡司に任命することが多かった。

また、地方と都との連絡のために、駅(えき)がつくられた。駅には、馬とその乗り手が配置され、伝令の仕事をした。


;まめ知識
貴族の人数は、全国あわせて200人ほどだと考えられている。(※ 中学の東京書院の教科書で紹介の話題。) なお、朝廷の役人は1万人ほど。平城京の人口は10万人ほど。(※ 中学の自由社の教科書より。)唐の長安の人口は100万人ほど。(※ 中学の自由社の教科書より。)

日本において、国ごとに置かれた役所のことを国府(こくふ)という。

この頃の時代の日本では、役所では、印鑑(いんかん)を文書に押して証明書とする制度が整った。

== 農民などの暮らし ==
大宝律令のころに、班田収授や租庸調(そようちょう)も定められた。

人々の身分は良(りょう)と賤(せん)に分かれていました。「賤」は奴隷などのことで、いわゆる「奴婢」(ぬひ)です。男の奴隷が奴(ぬ)で、女の奴隷が婢(ひ)です。奴婢は、売買もされたという。
「良」の人々の多くは、いわゆる農民などのことです。奴婢は全人口の1割ほどで、奴婢以外との結婚を禁じられるなどの差別を受けていました。

政府は人民を管理するために'''戸籍'''(こせき)を作り、人民に耕作をさせるための&lt;span style=&quot;color:red&quot;&gt;'''口分田'''&lt;/span&gt;(くぶんでん)という田を与え耕作させます。

この当時の戸籍とは、人民をひとりずつ、公文書に登録することで、住所や家族の名や年齢、家の世帯主、などを把握することです。

この奈良時代に、すでに「戸籍」という言葉がありました。

このような情報の管理は、税をとることが目的です。税の台帳である'''計帳'''(けいちょう)をつくるため、戸籍が必要なのです。

現在の日本での戸籍とは、「戸籍」の意味が少しちがうので、注意してください。「計帳」という言葉は、この飛鳥時代の言葉です。詔の本文に書かれています。

詔の本文に、「初造戸籍計帳班田収授之法。」とあります。現代風に読みやすく区切りを入れれば、「初 造 戸籍 計帳 班田収授之法。」とでも、なりましょう。


目的は、収穫から税収をとるためです。前提として、公地公民が必要です。
６年ごとに人口を調査します。
税を取るにも、まずは人口を正しく把握しないと、いけないわけです。女にも口分田(くぶんでん)が与えられます。

原則として、&lt;span style=&quot;color:red&quot;&gt;'''６才以上の男女'''&lt;/span&gt;に田を与えます。男(６才以上)には２反(720歩=約24アール)の田を与え、女(６才以上)には男の３分の２(480歩=約16アール)の田を与えています。５才以下には与えられません。

死んだ人の分の田は、国に返します。

これらの制度を&lt;span style=&quot;color:red&quot;&gt;'''班田収授法'''&lt;/span&gt;(はんでんしゅうじゅほう)と言い、唐の均田制(きんでんせい)に習った制度である。


* '''租'''(そ)・'''庸'''(よう)・'''調'''(ちょう)
{| class=&quot;wikitable&quot; style=&quot;float:right&quot;
|+ 一般の人々の負担
! colspan=&quot;2&quot; |　&lt;span style=&quot;font-size: large;&quot;&gt;種類&lt;/span&gt; ||&lt;span style=&quot;font-size: large;&quot;&gt;内容&lt;/span&gt;
|-
| rowspan=&quot;4&quot; |&lt;SPAN STYLE=&quot;FONT-WEIGHT:NORMAL;&quot;&gt;&lt;span style=&quot;font-size: large;&quot;&gt;　税　&lt;/span&gt;&lt;/SPAN&gt;
|&lt;SPAN STYLE=&quot;FONT-WEIGHT:NORMAL;&quot;&gt;&lt;span style=&quot;font-size: large;&quot;&gt;租&lt;/span&gt;&lt;/SPAN&gt;
|収穫の約3%の稲
|-
|&lt;SPAN STYLE=&quot;FONT-WEIGHT:NORMAL;&quot;&gt;&lt;span style=&quot;font-size: large;&quot;&gt;調&lt;/span&gt;&lt;/SPAN&gt;
|地方の特産物(糸、絹、真綿、塩、&lt;br /&gt;魚、海藻、鉄、・・・)などを納める。
|-
|&lt;SPAN STYLE=&quot;FONT-WEIGHT:NORMAL;&quot;&gt;&lt;span style=&quot;font-size: large;&quot;&gt;庸&lt;/span&gt;&lt;/SPAN&gt;
|麻の布を納める。(労役の代わり。)
|-
|&lt;SPAN STYLE=&quot;FONT-WEIGHT:NORMAL;&quot;&gt;&lt;span style=&quot;font-size: large;&quot;&gt;出挙&lt;/span&gt;&lt;/SPAN&gt;
|強制的に稲を農民に貸し付け。&lt;br /&gt;5割の利息を農民が払う。
|-
| rowspan=&quot;2&quot; |&lt;SPAN STYLE=&quot;FONT-WEIGHT:NORMAL;&quot;&gt;&lt;span style=&quot;font-size: large;&quot;&gt;&lt;br /&gt;　労　&lt;br /&gt;　役　&lt;/span&gt;&lt;/SPAN&gt;
|&lt;SPAN STYLE=&quot;FONT-WEIGHT:NORMAL;&quot;&gt;&lt;span style=&quot;font-size: large;&quot;&gt;雑徭&lt;/span&gt;&lt;/SPAN&gt;
|土木工事など。年間60日以内。
|-
|&lt;SPAN STYLE=&quot;FONT-WEIGHT:NORMAL;&quot;&gt;&lt;span style=&quot;font-size: large;&quot;&gt;運脚&lt;/span&gt;&lt;/SPAN&gt;
|税(租庸調)などを都へ運ぶ。
|-
| rowspan=&quot;2&quot; |&lt;SPAN STYLE=&quot;FONT-WEIGHT:NORMAL;&quot;&gt;&lt;span style=&quot;font-size: large;&quot;&gt;&lt;br /&gt;　兵　&lt;br /&gt;　役　&lt;/span&gt;&lt;/SPAN&gt;
|&lt;SPAN STYLE=&quot;FONT-WEIGHT:NORMAL;&quot;&gt;&lt;span style=&quot;font-size: large;&quot;&gt;衛士&lt;/span&gt;&lt;/SPAN&gt;
|都で兵士を1年。
|-
|&lt;SPAN STYLE=&quot;FONT-WEIGHT:NORMAL;&quot;&gt;&lt;span style=&quot;font-size: large;&quot;&gt;防人&lt;/span&gt;&lt;/SPAN&gt;
|九州北部で兵士を3年。
|-
|}
税(ぜい)の種類です。

&lt;span style=&quot;color:red&quot;&gt;'''租'''&lt;/span&gt;(そ)とは、田の収穫量の、およそ &lt;span style=&quot;color:red&quot;&gt;'''3%の稲'''&lt;/span&gt; を国に納めよ(おさめよ)、という税です。
'''調'''とは、絹や地方の特産物を国に納めよ、という税です。

'''庸'''(よう)とは、都に出てきて年10日以内の労働をせよという労役(ろうえき)か、または布を納めよ、という税です。

前提として、公地公民(こうちこうみん)や班田収授(はんでんしゅうじゅ)などが必要です。

これとは別に、出挙(すいこ)という、国司が強制的に農民に春に稲を貸し付けて、秋に5割の利息を農民から取る制度があり、税のように考えられていました。

この他、一般の人々の負担には兵役(へいえき)や労役(ろうえき)などがあり、兵役では'''防人'''(さきもり)として3年間ほど九州に送られたり、'''衛士'''(えじ)として都の警備を1年間 させられました。

労役では、'''雑徭'''(ぞうよう)として土木工事などの労働を60日以内(1年あたり)させられたり、'''運脚'''(うんきゃく)として庸・調を都まで運ばされました。


農民の負担が重い一方で、貴族は税などを免除されました。


* 国・郡・里
&lt;div style=&quot;font-size:120%;&quot;&gt;
&lt;pre&gt;
　　　　　　国　(国司)
　　　　　　┃
　　　　　　郡　(郡司)
　　　　　　┃
　　　　　　里　(里長)

&lt;/pre&gt;
&lt;/div&gt;
政府の組織や、地方行政の組織にも、改革が加わります。
まず、日本全国をいくつかの 国(くに) に分けて管理し、国は郡(こおり)に分けられ、郡は里(さと)に分けられます。

国には、中央の朝廷から、&lt;span style=&quot;color:red&quot;&gt;'''国司'''&lt;/span&gt;(こくし)という役人が派遣され、この国司によって、それぞれの国が管理されます。

郡を管理する役職は、&lt;span style=&quot;color:red&quot;&gt;'''郡司'''&lt;/span&gt;(ぐんじ)という役職の役人に管理させます。たいてい、その地方の豪族が郡司です。


{{clear}}

[[category:高等学校日本史|りつりようこつかへのみち]]</text>
      <sha1>9obstsbef055awxl391js46cq68tnke</sha1>
    </revision>
  </page>
  <page>
    <title>高等学校日本史B/奈良時代</title>
    <ns>0</ns>
    <id>24153</id>
    <revision>
      <id>205733</id>
      <parentid>124493</parentid>
      <timestamp>2022-07-23T13:59:35Z</timestamp>
      <contributor>
        <username>椎楽</username>
        <id>32225</id>
      </contributor>
      <minor />
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="8137" xml:space="preserve">{{Nav}}

== 権力闘争 ==
奈良時代の初期には、藤原不比等が権力をにぎった。（なお、大宝律令を制定したのも、彼が中心。また、中臣鎌足の子。）

藤原不比等は娘の宮子（みやこ）を文武天皇と結婚させた。さらに、文武天皇と宮子の間に生まれた皇太子（のちの'''聖武天皇'''）に、娘の'''光明子'''（こうみょうし）を嫁がせた。

（724年、三世一身（さんぜい いっしん）の法（ほう）。）

（724年、聖武天皇が即位。）

不比等が死去すると、後続の'''長屋王'''（ながやおう）が権力をにぎって、長屋王は左大臣まで登りつめたが、不比等の子の4兄弟の策謀により、729年に長屋王は謀反の疑いをかぶさられ、729年に長屋王は自殺に追い込まれた（'''長屋王の変'''）。

なお、不比等の子の4兄弟はそれぞれ、武智麻呂（むちまろ）・房前（ふささき）・宇合(（うまかい）・麻呂（まろ）。

ところが、長屋王の事件後、この4兄弟は全員、病死してしまう。

その後、皇族の'''橘諸兄'''（たちばなの もろえ）が政権をにぎり、唐から戻ってきた僧 玄昉（げんぼう） や吉備真備（きびのまきび）を登用した。

太宰府に派遣されていた藤原広嗣（ふじわらの ひろつぐ）は、これに不満をつのらせ、740年に九州で反乱を起こしたが、鎮圧された。


こうした政情不安や、疫病の影響もあってか、この乱が起きてからしばらく、聖武天皇は遷都をして、都を転々とした。遷都先は、恭仁（くに）、難波（なにわ） 、紫香楽（しがらき）である。（745年に平城京に戻る。）


そして、聖武天皇は仏教によって国を安定させようと思い、741年に'''国分寺建立の詔''' （こくぶんじ こんりゅう の みことのり）を出した。（国ごとに国分寺の建立しようとした。） つづいて743年に'''大仏造立の詔'''（だいぶつぞうりゅう の みことのり）を出した。


聖武天皇は749年に孝謙天皇（こうけん てんのう）(←女)に譲位してしまう。その後、'''藤原仲麻呂'''（ふじわらの なかまろ）が権力をにぎる。そして、橘諸兄（たちばなの もろえ）の子の奈良麻呂（ならまろ）が反乱をくわだてたが、発覚して鎮圧される。

なお、つぎの淳仁天皇のとき、藤原仲麻呂は「恵美押勝」（えみの おしかつ）と改名する。

孝謙天皇はまだ生きてるが、758年に淳仁天皇が即位した。そして、この淳仁天皇の時代に、藤原仲麻呂は'''道鏡'''（どうきょう）と対立する。（※ 「道鏡」は人名。僧侶。）

そして、追い詰められた藤原仲麻呂は反乱を起こすが、藤原仲麻呂は敗死する（恵美押勝の乱 （えみのおしかつ の らん） ）

そして、孝謙天皇がふたたび天皇になり、称徳天皇（しょうとく てんのう）として即位する。（つまり、孝謙天皇と称徳天皇は同一人物。）

:（なお、こういう、引退した天皇が再び即位することを重祚（ちょうそ）という。）

道教は法王の地位まで登りつめたが、孝謙天皇の死後は道鏡は勢力を失い、道教は下野（しもつけ）の薬師寺（やくしじ）に追放された。

そして、次の天皇には、天智天皇の孫である光仁天皇（こうにん てんのう）がたてられた。（なお、光仁までの天皇は、天武天皇の系統だった。）


== 経済など ==
人口が増えたので口分田は不足した。国の仕組みが整うにつれて、税の仕組みも整い、税の負担は重く、口分田を捨てて逃げ出す農民が増えた。なお、この時代に鉄製の農具が普及してきて、農業の生産力が上がった。

722年、政府は「百万町歩の開墾計画」 （ひゃくまんちょうぶ の かいこんけいかく）を出した。（しかし、実際に百万町歩が開墾されたのではないようだ。現代では、単なるスローガンにすぎないと思われている。）

朝廷は税を増やすため、田を増やす必要があり、そのため、法律を変え、開墾した3代にわたり、田を所有できるように法を制定した。これが &lt;big&gt;三世一身の法&lt;/big&gt;（さんぜい いっしん の ほう） であり723年の出来事である。

さらに743年（天平15年）には、期限が無く所有し続けられる &lt;span style=&quot;color:red&quot;&gt;&lt;big&gt;墾田永年私財法&lt;/big&gt;&lt;/span&gt;（こんでん えいねん しざい の ほう） が制定された。


* 税について。&lt;span style=&quot;color:red&quot;&gt;&lt;big&gt;墾田永年私財法&lt;/big&gt;&lt;/span&gt;（こんでん えいねん しざい の ほう）
この時代に農民は貧しくて、税の負担は重く生活が苦しく、多くの農民は竪穴住居に住んでいた。&lt;span style=&quot;color:red&quot;&gt;&lt;big&gt;山上憶良&lt;/big&gt;&lt;/span&gt;（やまのうえの おくら）のよんだ&lt;span style=&quot;color:red&quot;&gt;&lt;big&gt;貧窮問答歌&lt;/big&gt;&lt;/span&gt;（ひんきゅう もんどうか）には、このころの農民の苦しい生活のさまが歌われている。

　　　　＊
:貧窮問答歌（要約）
::人並みに田畑の仕事で働いているのに、服はボロボロなのを着ていて、家はつぶれて曲がっているようで、地面にはワラを直接に敷いている。父母は私のマクラのほうで嘆き悲しみ、妻子は私の足のほうで嘆き悲しんでいる。かまどには煙も立てられず、こしき（米の蒸し器）にはクモが巣を張り、飯をたくことも忘れてしまったというのに、それでもムチを持った里長（さとおさ）が税を取り立てようとする声が、寝屋まで聞こえる。こんなにも、つらい事なのか、世の中に生きることは。

::世の中を　憂しとやさしと　思えども　飛び立ちかねつ　とりにしあらねば
::（世の中を、つらくて身もやせるほどだと思っても、鳥では無いから、飛び立つこともできない。）


また、人口が増えたので口分田は不足した。国の仕組みが整うにつれて、税の仕組みも整い、税の負担は重く、口分田を捨てて逃げ出す農民が増えた。なお、この時代に鉄製の農具が普及してきて、農業の生産力が上がった。

朝廷は税を増やすため、田を増やす必要があり、そのため、法律を変え、開墾した3代にわたり、田を所有できるように法を制定した。これが &lt;big&gt;三世一身の法&lt;/big&gt;（さんぜい いっしん の ほう） であり723年の出来事である。

さらに743年（天平15年）には、期限が無く所有し続けられる &lt;span style=&quot;color:red&quot;&gt;&lt;big&gt;墾田永年私財法&lt;/big&gt;&lt;/span&gt;（こんでん えいねん しざい の ほう） が制定された。

これは、つまり公地公民の原則を廃止したことになる。

また、貴族や豪族は、これを利用し、私有地を広げた。この貴族の私有地は、のちに &lt;big&gt;荘園&lt;/big&gt;（しょうえん） と呼ばれることになる。


* 貨幣（かへい）、和同開珎（わどうかいちん、わどうかいほう）
[[File:Wadokaichin coin 8th century Japan.jpg|thumb|left|200px|和同開珎]]
経済では、この奈良時代の都では、&lt;span style=&quot;color:red&quot;&gt;&lt;big&gt;和同開珎&lt;/big&gt;&lt;/span&gt;（わどうかいちん、わどうかいほう）という貨幣が708年（和同元年）に発行され、流通していました。
これより古い貨幣には、７世紀後半の天武天皇の頃に富本銭（ふほんせん）という貨幣がつくられています。

{{clear}}
[[category:高等学校日本史|ならしたい]]</text>
      <sha1>kwzwjgsugeccdodqfrvpfwonz0cc96u</sha1>
    </revision>
  </page>
  <page>
    <title>高等学校日本史B/天平文化</title>
    <ns>0</ns>
    <id>24154</id>
    <revision>
      <id>205734</id>
      <parentid>184790</parentid>
      <timestamp>2022-07-23T14:00:12Z</timestamp>
      <contributor>
        <username>椎楽</username>
        <id>32225</id>
      </contributor>
      <minor />
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="909" xml:space="preserve">{{Nav}}
== 天平文化（てんぴょうぶんか） ==

奈良時代の美術では、立体造形が進歩した。

従来の木像と銅像に加え、さらに'''塑像'''（そぞう）と、'''乾漆像'''（かんしつぞう）が、加わった。

:塑像は、木の芯のまわりを粘土で作る方法。（基本的に焼かない。自然乾燥させる。）
:乾漆像は、木や粘土でおおよその形をつくり、その上に麻布をはりつけ、漆（うるし）で ぬりかためる方法。
* 塑像
**東大寺 法華堂 執金剛神像（しつこんごうしんぞう） 
**東大寺 法華堂 日光菩薩・月光菩薩
**東大寺 戒壇院（かいだんいん） 四天王像 
* 乾漆像
**興福寺 阿修羅像
**興福寺の八部衆像
**聖林寺（しょうりんじ）の十一面観応像
[[category:高等学校日本史|ほうけんへいしのらん]]</text>
      <sha1>3fqfhs1wa9kjiemio9epr50d9unjdm7</sha1>
    </revision>
    <revision>
      <id>205738</id>
      <parentid>205734</parentid>
      <timestamp>2022-07-23T14:03:39Z</timestamp>
      <contributor>
        <username>椎楽</username>
        <id>32225</id>
      </contributor>
      <minor />
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="903" xml:space="preserve">{{Nav}}
== 天平文化（てんぴょうぶんか） ==

奈良時代の美術では、立体造形が進歩した。

従来の木像と銅像に加え、さらに'''塑像'''（そぞう）と、'''乾漆像'''（かんしつぞう）が、加わった。

:塑像は、木の芯のまわりを粘土で作る方法。（基本的に焼かない。自然乾燥させる。）
:乾漆像は、木や粘土でおおよその形をつくり、その上に麻布をはりつけ、漆（うるし）で ぬりかためる方法。
* 塑像
**東大寺 法華堂 執金剛神像（しつこんごうしんぞう） 
**東大寺 法華堂 日光菩薩・月光菩薩
**東大寺 戒壇院（かいだんいん） 四天王像 
* 乾漆像
**興福寺 阿修羅像
**興福寺の八部衆像
**聖林寺（しょうりんじ）の十一面観応像
[[category:高等学校日本史|てんひようふんか]]</text>
      <sha1>gfj14xjzfjttp6pwndtpkp11z1ni7p6</sha1>
    </revision>
  </page>
  <page>
    <title>高等学校日本史B/平安初期</title>
    <ns>0</ns>
    <id>24156</id>
    <revision>
      <id>205735</id>
      <parentid>174515</parentid>
      <timestamp>2022-07-23T14:01:19Z</timestamp>
      <contributor>
        <username>椎楽</username>
        <id>32225</id>
      </contributor>
      <minor />
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="12349" xml:space="preserve">{{Nav}}

== 平安時代 ==
[[ファイル:Miniature Model of Rajomon.jpg|thumb|平安京の羅城門（らじょうもん）の復元模型（京都文化博物館）]]

かつての天平文化の仏教保護の政策などにより、仏教の僧や寺院の影響力が強くなる。

のちの天皇や朝廷は、これらの仏教勢力を嫌がり、そのため、光仁天皇のあとをついだ桓武天皇（かんむ てんのう）により、寺院の多い現在でいう奈良県から京都府へと都をうつす。まず784年に都を山背国（やましろこく）の長岡京に移した。

しかし、新都造営（しんとぞうえい）の中心人物であった藤原種継（ふじわらのたねつぐ）が暗殺されたり、政情不安が続いたので、794年に都を平安京に移した。

== 政治 ==
桓武天皇は、国司に対する監督をきびしくするため、'''勘解由使'''（かげゆし）という役人を置きました。

:※ 『[[高等学校国語総合/土佐日記#門出（かどで）]]』に出てくる「解由」（げゆ）とは、このカゲユシ関連の書類である。著者の紀貫之（きの つらゆき）は、国司として、取り締まりされる側の立場。くわしくはリンク先で。

勘解由使に、国司の交代の際には、前任の国司に不正がなかったことを証明するための解由状（げゆじょう）を審査させた。


:※ 中学校で習った『[[中学校社会 歴史/平安時代]]』も参照せよ。


桓武天皇の政策として、辺境の他では徴兵をやめ、辺境の他では従来の軍団を廃止して、あらたに郡司の子弟で弓馬にたくみな者からなる健児（こんでい）を設けた。

また、このころ、都の造営と、蝦夷との戦いからなる二大事業が、国家財政や民衆の負担だった。

貴族間で、この事業の存続をめぐる論争が起き、桓武天皇はこの二大事業を中止した。

桓武天皇は、二大事業の存続の件で、管野真道（すがのまみち）と藤原緒嗣（ふじわらおつぐ）という2人の参議に論争させた（徳政論争）。（菅野が存続派。藤原が打ち切り派。）


桓武天皇の死後、平城天皇（へいぜいてんのう）、つづいて809年に'''嵯峨天皇'''（さがてんのう）になった。

:※ 社会の変化により、従来の家柄や血筋による人事制度がうまく機能しなくなったため、嵯峨天皇らは、従来の官職を残しつつも、新たに、家柄にとらわれない新設の官職も設置して活用した。&lt;br&gt;&lt;br&gt;

{| style=&quot;width:100%&quot;
|valign=top style=&quot;width:60%;text-indent:1em&quot;|
嵯峨天皇（さがてんのう）のとき、'''薬子の変'''（くすこのへん）が起きた。しかし、薬子の変は失敗に終わった。
|valign=top style=&quot;width:5%;text-indent:1em&quot;|
|valign=top style=&quot;width:35%;text-indent:1em&quot;|
----
'''薬子の変'''とは、810年に藤原薬子（ふじわらの くすこ）とその兄 藤原仲成（ふじわらの なかなり）が、平城太上天皇（平城上皇）をふたたび天皇の地位につけようとして失敗した事件。「'''平城太上天皇の変'''」ともいう。

（※ 範囲外: ） 薬子（くすこ）とは、平城太上天皇の愛人の名前。かつての学説では、薬子が事件の首謀者に近いと思われていたが、歴史研究では、単に上皇の罪を薬子が なすりつけられただけとかの別の可能性が否定できず、現代の学校教科書では この事件の呼び名で「平城太上天皇の変」という呼び名も西暦2003年ごろから増えてきた。とはいえ、では平城上皇が首謀者かというと、その証拠もとぼしく、真相は不明である。歴史的な事実としては、最終的に薬子は自殺したとされている。

|}

{| style=&quot;width:100%&quot;
|valign=top style=&quot;width:60%;text-indent:1em&quot;|
嵯峨天皇は、あらかじめ'''蔵人所'''（くらうどのところ）を設置し、機密をあつかった。
蔵人所の長官を'''蔵人頭'''（くらうどのとう）という。蔵人頭（くらうどのかみ）には、藤原冬嗣（ふじわら ふゆつぐ）らが任命された。

また、京都の治安維持・警察をつかさどるために'''検非違使'''（けびいし）を置いた。


|valign=top style=&quot;width:5%;text-indent:1em&quot;|
|valign=top style=&quot;width:35%;text-indent:1em&quot;|
（※ 参考: ）検非違使が創設される前は、京都の治安維持・警察などの仕事は、複数の官庁（衛府（えふ）、刑部省、弾正台、京職など）に分散されて処理がされていた&lt;ref&gt;相澤理『歴史が面白くなる　東大のディープな日本史【古代・中世編】』、株式会社KADOKAWA (中経文庫)、2016年7月15日 第1刷発行、P173&lt;/ref&gt;。つまり、検非違使長の創設により、それらの処理がひとつの官庁に一元化された事になる。一説には、いわゆる「縦割り行政」の弊害を解消するという目的もあって京都という地域限定だが検非違使が設けられたのだろう、という説もある。&lt;ref&gt;相澤理『歴史が面白くなる　東大のディープな日本史【古代・中世編】』、株式会社KADOKAWA (中経文庫)、2016年7月15日 第1刷発行、P173&lt;/ref&gt;
|}


{| style=&quot;width:100%&quot;
|valign=top style=&quot;width:60%;text-indent:1em&quot;|
これら新設の官職は令（りょう）には規定がないので、'''令外官'''（りょうのげかん）と呼ばれた。

検非違使も、令の規定によらずに犯罪人の取り締まりができた。（※ 東京書籍の見解）

また、これら令外官では、家柄にとらわれずに有能な人材を登用できた。（※ 東京書籍の見解）

|valign=top style=&quot;width:5%;text-indent:1em&quot;|
|valign=top style=&quot;width:35%;text-indent:1em&quot;|
----
:※ （東京書籍や明成社が言うには、）令外官はべつに嵯峨天皇が始めたのでなくって、702年の「参議」や、705年の「中納言」も、令外官である。ただ、令外官が重要な要職になったのが、嵯峨天皇の頃からである。

|}

{| style=&quot;width:100%&quot;
|valign=top style=&quot;width:60%;text-indent:1em&quot;|
また、嵯峨天皇は、律令を補足した'''格'''（きゃく）と、官庁で施行する際の細則である'''式'''（しき）とを整備した。

嵯峨天皇のもとで、820年ごろ、'''光仁格式'''（こうにん〜）が出来た。
|valign=top style=&quot;width:5%;text-indent:1em&quot;|
|valign=top style=&quot;width:35%;text-indent:1em&quot;|
----
のちの天皇のもとで、「貞観格式」（じょうがん〜）・「延喜格式」（えんぎ〜）が出きた。これら3つ（光仁格式、貞観格式、延喜格式）をあわせて三代格式という。
|}

{| style=&quot;width:100%&quot;
|valign=top style=&quot;width:60%;text-indent:1em&quot;|
（823年に嵯峨天皇は、つぎの天皇に皇位をゆずって退位する。）

（833年には、）令（りょう）の条文の解釈を統一するための注釈書として『'''令義解'''』（りょうのぎげ）がつくられた。

（842年、嵯峨 元天皇が死没。）

|valign=top style=&quot;width:5%;text-indent:1em&quot;|
|valign=top style=&quot;width:35%;text-indent:1em&quot;|

|}

== 平安初期の密教文化 ==
{| style=&quot;width:100%&quot;
|valign=top style=&quot;width:60%;text-indent:1em&quot;|
唐で仏教を学んだ'''最澄'''（さいちょう）と'''空海'''（くうかい）が日本に帰国して、仏教の知識も日本に持ち帰る。

空海は、唐では、インドから中国に伝えられたばかりの真言密教（しんごん みっきょう）を学んでいた。

空海が日本で'''密教'''（みっきょう）を広めた。（いっぽう、最澄が広めたのは法華経（ほけきょう）。）

空海は、高野山（こうやさん）に金剛峰寺（こんごう ぶじ）を建て、密教にもとづく'''真言宗'''（しんごんしゅう）をつくった。

また、最澄は比叡山（ひえいざい）に'''延暦寺'''（えんりゃくじ）をひらき、天台宗（てんだいしゅう）をつくった。

天台宗・真言宗の寺院の多くは、山中に建てられた。
:（空海の宗派の寺だけが山中にあるのではなく、最澄の宗派の寺も山中に建てられたことに、注意。）

天台宗も、しだいに密教の影響を受け、最澄の弟子の円仁（えんにん）・円珍（えんちん）が唐に留学して密教の知識を日本に持ち帰り、天台宗は密教化した。

真言宗の密教を'''東密'''（とうみつ）という。いっぽう天台宗の密教を'''台密'''（たいみつ）という。

また、従来の宗派でも山岳修行をしていたが、これらが天台・真言宗とむすびつき、'''修験道'''（しゅげんどう）が流行した。

|valign=top style=&quot;width:5%;text-indent:1em&quot;|
|valign=top style=&quot;width:35%;text-indent:1em&quot;|
----
密教の特徴として、加持（かじ）祈祷（きとう）など、呪法（じゅほう）的なお祈りで悟りが開けるとされる。

これらの特徴が、現世利益（げんぜりやく）を求める貴族に好まれた。また、密教は、経典よりも山岳修行などの修業を重んじる傾向がある。

なお、既存の仏教など、経典を重んずる宗派のことを、密教の用語で「顕教」（けんきょう）という。

|}

いっぽう、奈良時代の後半から既に、日本古来の神々と仏教とをむすびつける'''神仏習合'''（しんぶつ しゅうごう）の考えがあった。

このため、神社の境内（けいだい）に神宮寺（じんぐうじ）を建てたり、神前（しんぜん）で読経（どきょう）する風習などがあったが、密教の普及とともに、これらの風習も普及した。


[[File:Murou-ji 4.jpg|thumb|室生寺（むろうじ）]]
大和の室生寺（むろうじ）では、伽藍（がらん）も地形に応じて自由に配置された。

:※ 伽藍とは、寺院の建物全体や、その構成のこと。

文芸では、漢詩・漢文が流行した。

勅撰漢詩文集の『凌雲集』（りょううんしゅう）、『文華秀麗集』（ぶんかしゅうれいしゅう）、『経国集』（けいこくしゅう）などが編纂（へんさん）された。

また、空海の漢詩文をあつめた『性霊集』（しょうりょうしゅう）もつくられた。


書道では、唐風の書が好まれ、嵯峨天皇・空海・橘逸勢（たちばなの はやなり）は'''三筆'''（さんぴつ）と呼ばれた。

{| style=&quot;width:100%&quot;
|valign=top style=&quot;width:60%;text-indent:1em&quot;|
有力な氏族たちは、一族から優れた官吏（かんり）を出すために、氏ごとの塾・予備校的な寮（りょう）の'''大学別曹'''（だいがくべっそう）を建てた。

また、空海は、大学や国学に入学できない庶民が仏教・儒教などを学べる'''綜芸種智院'''（しゅげいしゅちいん）を開いた。

|valign=top style=&quot;width:5%;text-indent:1em&quot;|
|valign=top style=&quot;width:35%;text-indent:1em&quot;|
'''大学別曹'''　和気（わけ）氏の弘文院（こうぶんいん）、藤原氏の勧学院（かんがくいん）、橘（たちばな）氏の学館院（がくかんいん）、在原（ありわら）氏の奨学院（しょうがくいん）、などがある。
|}


{{-}}
* 美術など
[[Image:NYOIRIN KANSHINJI.JPG|thumb|歓心寺 如意輪（にょいりん）観音像 （大阪・観心寺）]]
絵画では、密教の世界観をあらわす'''曼荼羅'''（まんだら）が描かれた。

彫刻では、一本の大木を彫って作る'''一本造'''（いっぽんづくり）が流行した。

また、不動明王（ふどう みょうおう）の絵画や彫刻がつくられた。

{{-}}
== 参考文献 ==
&lt;references/&gt;
[[category:高等学校日本史|へいあんしよき]]</text>
      <sha1>6aw3phugj0mu2aybj2dhpij2evbmr92</sha1>
    </revision>
  </page>
  <page>
    <title>高等学校日本史B/藤原氏の台頭</title>
    <ns>0</ns>
    <id>24158</id>
    <revision>
      <id>205736</id>
      <parentid>141992</parentid>
      <timestamp>2022-07-23T14:02:11Z</timestamp>
      <contributor>
        <username>椎楽</username>
        <id>32225</id>
      </contributor>
      <minor />
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="2771" xml:space="preserve">{{Nav}}

[[ファイル:Ban dainagon ekotoba.jpg|thumb|550px|応天門（おうてんもん）の炎上（『伴大納言絵詞』より）]]

藤原北家の藤原冬嗣（ふゆつぐ）は、嵯峨天皇の信任を得て、冬嗣は蔵人頭に任命された。また、冬嗣の娘は、皇太子の妃になった。

冬嗣の子の'''藤原良房'''（よしふさ）が、842年の承和の変で、大伴・橘氏の勢力をそいだ。

858年に、幼少（9歳）の清和天皇が即位すると、藤原良房が外祖父として実権をにぎり、良房は'''摂政'''（せっしょう）になった。


{| style=&quot;width:100%&quot;
|valign=top style=&quot;width:60%;text-indent:1em&quot;|
さらに応天門の変で、伴氏などが失脚し、ますます藤原氏が権力をにぎった。

'''応天門の変'''（おうてんもん の へん）ののち、良房は正式に摂政に就任した。

|valign=top style=&quot;width:5%;text-indent:1em&quot;|
|valign=top style=&quot;width:35%;text-indent:1em&quot;|
----
'''応天門の変'''　大納言 伴善男（ばん よしお）が、左大臣 源信（みなもとの まこと）に罪をきせるために応天門に放火したとされる事件。この事件の処罰として、伴は流罪に処せられた。

この事件は、良房の陰謀という説もある（※ 実教出版が紹介している。）

|}

ついで、良房の甥（おい）から養子になった'''藤原基経'''（もとつね）が、幼い陽成天皇（ようぜい〜）の摂政になり、884年には光孝天皇（こうこう〜）を即位させ、また、基経は'''関白'''（かんぱく）の地位についた。

（897年に基経は死亡。）


基経の死後、宇多天皇は、摂政・関白を置かずに、'''菅原道真'''（すがわらの みちざね）を重用した。

しかし、つづく醍醐天皇のときに、藤原時平（〜ときひら）の策謀により菅原道真は太宰府に左遷（させん）された。

醍醐・村上の両天皇は、摂政・関白を置かず、天皇みずからの親政を行った。

== 時事 ==
:966年に藤原道長（ふじわらの みちなが）が生まれるよりも前に、935年に関東で平将門の乱（たいらのまさかど の らん）が起きた。
:※ 小中学校では、のちの源平合戦とのつながりから、藤原道長よりも後に将門を紹介する。しかし、実際の歴史的順序は、けっして藤原氏が衰えてから将門の反乱が起きたのではない。
:939年の西国での藤原純友の乱（ふじわらのすみとも の らん）も、道長の生まれる前の出来事である。

[[category:高等学校日本史|ふしわらしのたいとう]]</text>
      <sha1>mvv4yynwilp9eh0edxbrwcf273w3e2y</sha1>
    </revision>
  </page>
  <page>
    <title>高等学校日本史B/保元・平治の乱</title>
    <ns>0</ns>
    <id>24164</id>
    <revision>
      <id>205723</id>
      <parentid>204617</parentid>
      <timestamp>2022-07-23T13:47:20Z</timestamp>
      <contributor>
        <username>椎楽</username>
        <id>32225</id>
      </contributor>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="6926" xml:space="preserve">== 保元・平治の乱 ==
=== 保元の乱 ===
{| class=&quot;wikitable&quot; style=&quot;float:right&quot;
|+ 　保元の乱
! 　 !! 　上皇方&lt;br&gt;（負）　 !! 　天皇方&lt;br&gt;（勝）　
|-
! 天皇家
| 　崇徳上皇（兄） || 　後白河天皇（弟）　
|-
! 藤原氏
| 　左大臣 藤原頼長（弟）　 || 　関白 忠道（兄）　
|-
! 源氏
| 　為義（父）&lt;br&gt;　為朝（弟）　 || 　　&lt;br&gt;　義朝（兄）
|-
! 平氏
| 　忠正（叔父）　 || 　清盛（甥）　
|-
|}
鳥羽法皇は源平の武士を組織し、荘園を集積していったことで絶大な権力をえた。しかし、このことは鳥羽法皇の権勢の継承という問題を引き起こすことになる。1156(保元元)年、鳥羽法皇が死去すると、次の治天の君の地位をうかがう{{ruby|'''崇徳'''|すとく}}'''上皇'''と'''後白河天皇'''の対立が表面化する。

また、鳥羽法皇の治世末から藤原氏も摂関家の継承をめぐって、関白・'''藤原'''{{ruby|'''忠通'''|ただみち}}と左大臣・'''藤原'''{{ruby|'''頼長'''|よりなが}}が対立していた。

崇徳上皇は権力を取り戻すために頼長らと手を結び、さらに源為義・為朝父子や平忠正らの武士を招集した。一方の後白河天皇は、鳥羽法皇の側近だった'''藤原{{ruby|通憲|のりみち}}'''('''信西''')を参謀として、源義朝・平清盛・源頼政らの有力武士たちを動員し、上皇方に先制攻撃を加えた。兵力に劣る上皇方はすぐに総崩れとなり、崇徳上皇は降伏した。この戦いを'''保元の乱'''という。

この結果、崇徳上皇は讃岐に流され、為義らは処刑された。この戦後処理では、400年ぶりに上皇が島流しとされたこと、約350年ぶりに死刑が行われたことで当時の貴族たちに大きな衝撃を与えることになった。そして、武士が単なる警護役ではなく政治闘争にも関わるようになったことも貴族層に強く印象付けることになった。後に『'''愚管抄'''』を記述する'''慈円'''はこの乱によって「'''{{ruby|武者|むさ}}の世'''」になったと評した。

{{-}}
=== 平治の乱 ===
保元の乱ののち、後白河天皇は退位し、院政を開始した。この時に政治の主導権を握ったのが藤原通憲であった。通憲は平清盛と手を結び、荘園整理や悪僧・{{ruby|神人|じにん}}の取り締まりなどを行い、時代の変化に対応した政治を行った。しかし、今度は後白河上皇の近臣同士の対立が激しくなり、権勢をもつ通憲への反発が強まった。

{| class=&quot;wikitable&quot; style=&quot;float:right&quot;
|+ 　平治の乱
! 　 !! 　勝ち　 !! 　負け　
|-
! 院近臣の貴族
| 藤原通憲（→自殺） || 藤原信頼（→斬首）　
|-
! 武士
| 　平清盛&lt;br&gt;　平重盛　 || 　源義朝（→謀殺）　&lt;br&gt;　源義平（→斬首）&lt;br&gt;　源頼朝（→伊豆）
|-
|}

1159(平治元)年、通憲に反感を持つ'''藤原{{ruby|信頼|のぶより}}'''は、清盛が熊野詣に出かけた隙をついて源義朝とむすんで挙兵し、通憲を自害に追い込み、後白河上皇と二条天皇を幽閉した。しかし、帰京した清盛が六波羅の自邸にもどり、二条天皇を脱出させて信頼・義朝討伐の宣旨(命令)を得ることに成功する。そのため、清盛は多くの武士をまとめることに成功し、信頼・義朝らを倒した。信頼は処刑され、義朝は再起を図るために東国に向かう最中に殺害された。そして、義朝の子の頼朝は伊豆に流された。これが'''平治の乱'''である。

保元・平治の乱の結果、藤原氏の力はさらに落ち込み、源氏をはじめとする多くの武士も没落・滅亡した。一方で、平清盛の地位は、唯一の'''武家の棟梁'''として急速に高まっていった。

== 平氏政権 ==
=== 平家の繁栄 ===
平氏は清盛の父・忠盛の頃から日宋貿易に力を入れていた。11世紀後半から日本・宋・高麗との間での商船の往来は活発化しており、貿易の利益は清盛にとって重要な経済基盤となっていた。

こうした豊かな財力を背景にした後白河上皇への奉仕と軍事力は清盛の権勢を大いに高め、1167(仁安2)年には武士として初めて太政大臣に就任する。清盛本人だけではなく、嫡子・重盛をはじめとした一族も高位高官にのぼり、最盛期には10数名の公卿、殿上人30数名を輩出することになる。

清盛は娘の{{ruby|徳子|とくこ}}({{ruby|建礼門院|けんれいもんいん}})を高倉天皇の中宮に入れる。徳子と高倉天皇の間に皇子が誕生し、'''安徳天皇'''として即位すると清盛は外戚として権勢を誇るようになる。

その間に荘園は500余りを所有するようになった。こうした清盛を中心とした政権を'''平氏政権'''、あるいは'''六波羅政権'''という(六波羅は清盛の邸宅の場所)。

=== 日宋貿易 ===

=== 政権の動揺 ===
平氏政権は従来の朝廷の組織にのっとったもので、平家一門が官職を独占して政権を運営していた。一方で、清盛らとの縁の薄い貴族や他の武家は政権から排除されていたため、徐々に平氏政権に対する不満が高まっていった。また、後白河法皇と清盛との関係も微妙なものとなっていた。そうした中、1176年に後白河法皇の妃で清盛の妻の姉妹であった建春門院滋子が病没し、清盛と法皇・近臣との対立が深まっていった。

1177年、後白河の近臣である藤原{{ruby|成親|なりちか}}や信西の弟子であった西光、僧の{{ruby|俊寛|しゅんかん}}らが京都郊外の鹿ケ谷で平氏打倒の計画をするが失敗した（'''{{ruby|鹿ケ谷|ししがたに}}の{{ruby|陰謀|いんぼう}}''' 。

そして1179年、清盛の嫡男であり法皇と清盛の調整役であった平重盛が死去するなどの出来事が積み重なると対立は決定的なものとなる。同年11月、清盛はクーデターを起こして関白をはじめとした多くの貴族たちを左遷または官職を{{ruby|剥奪|はくだつ}}し、後白河を幽閉した。受領も平氏または平氏に近い者に交代させられ、一門の知行国は32か国に急増した。

こうして、平氏は独裁的な強権を手に入れた。しかしこのことがかえって平家一門への反感を強め、反平氏の勢力を結集させることになる。

{{category:高等学校日本史|ほうけんへいしのらん}}</text>
      <sha1>qo0r056j86knld3c0jg88mzlpwxwg5y</sha1>
    </revision>
    <revision>
      <id>205725</id>
      <parentid>205723</parentid>
      <timestamp>2022-07-23T13:51:15Z</timestamp>
      <contributor>
        <username>椎楽</username>
        <id>32225</id>
      </contributor>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="6926" xml:space="preserve">== 保元・平治の乱 ==
=== 保元の乱 ===
{| class=&quot;wikitable&quot; style=&quot;float:right&quot;
|+ 　保元の乱
! 　 !! 　上皇方&lt;br&gt;（負）　 !! 　天皇方&lt;br&gt;（勝）　
|-
! 天皇家
| 　崇徳上皇（兄） || 　後白河天皇（弟）　
|-
! 藤原氏
| 　左大臣 藤原頼長（弟）　 || 　関白 忠道（兄）　
|-
! 源氏
| 　為義（父）&lt;br&gt;　為朝（弟）　 || 　　&lt;br&gt;　義朝（兄）
|-
! 平氏
| 　忠正（叔父）　 || 　清盛（甥）　
|-
|}
鳥羽法皇は源平の武士を組織し、荘園を集積していったことで絶大な権力をえた。しかし、このことは鳥羽法皇の権勢の継承という問題を引き起こすことになる。1156(保元元)年、鳥羽法皇が死去すると、次の治天の君の地位をうかがう{{ruby|'''崇徳'''|すとく}}'''上皇'''と'''後白河天皇'''の対立が表面化する。

また、鳥羽法皇の治世末から藤原氏も摂関家の継承をめぐって、関白・'''藤原'''{{ruby|'''忠通'''|ただみち}}と左大臣・'''藤原'''{{ruby|'''頼長'''|よりなが}}が対立していた。

崇徳上皇は権力を取り戻すために頼長らと手を結び、さらに源為義・為朝父子や平忠正らの武士を招集した。一方の後白河天皇は、鳥羽法皇の側近だった'''藤原{{ruby|通憲|のりみち}}'''('''信西''')を参謀として、源義朝・平清盛・源頼政らの有力武士たちを動員し、上皇方に先制攻撃を加えた。兵力に劣る上皇方はすぐに総崩れとなり、崇徳上皇は降伏した。この戦いを'''保元の乱'''という。

この結果、崇徳上皇は讃岐に流され、為義らは処刑された。この戦後処理では、400年ぶりに上皇が島流しとされたこと、約350年ぶりに死刑が行われたことで当時の貴族たちに大きな衝撃を与えることになった。そして、武士が単なる警護役ではなく政治闘争にも関わるようになったことも貴族層に強く印象付けることになった。後に『'''愚管抄'''』を記述する'''慈円'''はこの乱によって「'''{{ruby|武者|むさ}}の世'''」になったと評した。

{{-}}
=== 平治の乱 ===
保元の乱ののち、後白河天皇は退位し、院政を開始した。この時に政治の主導権を握ったのが藤原通憲であった。通憲は平清盛と手を結び、荘園整理や悪僧・{{ruby|神人|じにん}}の取り締まりなどを行い、時代の変化に対応した政治を行った。しかし、今度は後白河上皇の近臣同士の対立が激しくなり、権勢をもつ通憲への反発が強まった。

{| class=&quot;wikitable&quot; style=&quot;float:right&quot;
|+ 　平治の乱
! 　 !! 　勝ち　 !! 　負け　
|-
! 院近臣の貴族
| 藤原通憲（→自殺） || 藤原信頼（→斬首）　
|-
! 武士
| 　平清盛&lt;br&gt;　平重盛　 || 　源義朝（→謀殺）　&lt;br&gt;　源義平（→斬首）&lt;br&gt;　源頼朝（→伊豆）
|-
|}

1159(平治元)年、通憲に反感を持つ'''藤原{{ruby|信頼|のぶより}}'''は、清盛が熊野詣に出かけた隙をついて源義朝とむすんで挙兵し、通憲を自害に追い込み、後白河上皇と二条天皇を幽閉した。しかし、帰京した清盛が六波羅の自邸にもどり、二条天皇を脱出させて信頼・義朝討伐の宣旨(命令)を得ることに成功する。そのため、清盛は多くの武士をまとめることに成功し、信頼・義朝らを倒した。信頼は処刑され、義朝は再起を図るために東国に向かう最中に殺害された。そして、義朝の子の頼朝は伊豆に流された。これが'''平治の乱'''である。

保元・平治の乱の結果、藤原氏の力はさらに落ち込み、源氏をはじめとする多くの武士も没落・滅亡した。一方で、平清盛の地位は、唯一の'''武家の棟梁'''として急速に高まっていった。

== 平氏政権 ==
=== 平家の繁栄 ===
平氏は清盛の父・忠盛の頃から日宋貿易に力を入れていた。11世紀後半から日本・宋・高麗との間での商船の往来は活発化しており、貿易の利益は清盛にとって重要な経済基盤となっていた。

こうした豊かな財力を背景にした後白河上皇への奉仕と軍事力は清盛の権勢を大いに高め、1167(仁安2)年には武士として初めて太政大臣に就任する。清盛本人だけではなく、嫡子・重盛をはじめとした一族も高位高官にのぼり、最盛期には10数名の公卿、殿上人30数名を輩出することになる。

清盛は娘の{{ruby|徳子|とくこ}}({{ruby|建礼門院|けんれいもんいん}})を高倉天皇の中宮に入れる。徳子と高倉天皇の間に皇子が誕生し、'''安徳天皇'''として即位すると清盛は外戚として権勢を誇るようになる。

その間に荘園は500余りを所有するようになった。こうした清盛を中心とした政権を'''平氏政権'''、あるいは'''六波羅政権'''という(六波羅は清盛の邸宅の場所)。

=== 日宋貿易 ===

=== 政権の動揺 ===
平氏政権は従来の朝廷の組織にのっとったもので、平家一門が官職を独占して政権を運営していた。一方で、清盛らとの縁の薄い貴族や他の武家は政権から排除されていたため、徐々に平氏政権に対する不満が高まっていった。また、後白河法皇と清盛との関係も微妙なものとなっていた。そうした中、1176年に後白河法皇の妃で清盛の妻の姉妹であった建春門院滋子が病没し、清盛と法皇・近臣との対立が深まっていった。

1177年、後白河の近臣である藤原{{ruby|成親|なりちか}}や信西の弟子であった西光、僧の{{ruby|俊寛|しゅんかん}}らが京都郊外の鹿ケ谷で平氏打倒の計画をするが失敗した（'''{{ruby|鹿ケ谷|ししがたに}}の{{ruby|陰謀|いんぼう}}''' 。

そして1179年、清盛の嫡男であり法皇と清盛の調整役であった平重盛が死去するなどの出来事が積み重なると対立は決定的なものとなる。同年11月、清盛はクーデターを起こして関白をはじめとした多くの貴族たちを左遷または官職を{{ruby|剥奪|はくだつ}}し、後白河を幽閉した。受領も平氏または平氏に近い者に交代させられ、一門の知行国は32か国に急増した。

こうして、平氏は独裁的な強権を手に入れた。しかしこのことがかえって平家一門への反感を強め、反平氏の勢力を結集させることになる。

[[category:高等学校日本史|ほうけんへいしのらん]]</text>
      <sha1>3oihoutyy1ewwi9i1fd67bj7lrydza2</sha1>
    </revision>
  </page>
  <page>
    <title>ゲームプログラミング/バランス調整</title>
    <ns>0</ns>
    <id>27004</id>
    <revision>
      <id>205781</id>
      <parentid>202704</parentid>
      <timestamp>2022-07-24T10:09:11Z</timestamp>
      <contributor>
        <username>Nermer314</username>
        <id>62933</id>
      </contributor>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="119968" xml:space="preserve">{{substub}}
:※ 現在の版の著者が、全く、ゲーム中の戦闘の調整の経験のない人なので、現状では全く、本ページの内容は調べ物としては役立ちません。
:経験ある人の協力をお待ちしております。

== 本ページの目的 ==
本科目『ゲームプログラミング』は、科目名に「プログラミング」とあるとおり、ゲームクリエイターのための教材ではなくプログラマーのための教材です。

従って、話題がプログラミング的な技術的な話題に片寄っています。一般のゲームクリエイターを目指す人には、本書のバランス調整の記述は到底、役立ちません。

プログラマーが、とりあえず何か趣味でゲームを作る際、バランス調整についての調べ物の手間を少なくするためだけの目的の教科書です。


== バランス調整 ==
バランス調整とは、そのゲームの易しさ・難しさを決めるために、具体的に敵の強さなどを決めたり、あるいは主人公の強さを決めたり、あるいはそれらの要因の調査のためのテストプレイなどである。

なお、難易度の調整に限らず、バグ修正ではないが操作性の改善のために仕様および実装を更新するなど、そのゲームをさらに面白くするために様々な改善をすることをまとめて、ゲーム業界用語では「チューニング」という。「バランス調整」は、「チューニング」の項目のうちの一つである。

英語では、難易度の調整のことを「レベルデザイン」と言う。しかし英語の「レベルデザイン」のレベルとは、けっして日本のRPG的な経験値稼ぎによる「レベル上げ」などのレベルのことではなく、欧米で過去に流行した3Dゲームにおいてそのマップエディタではマップの高低差（※wiki注: これが英語の「レベル」の意味）を調整していたのだが、そのマップエディタのことを欧米では「レベルエディタ」と英語では言っていたのが経緯である。それらの3Dゲームでは、マップのデザインによって難易度が大きく変わるので、しだいにレベルデザインが難易度デザインのような意味になっていった、と考えられている&lt;ref&gt;川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日 第1版 第1刷、P.57&lt;/ref&gt;。

書籍『ゲームプランとデザインの教科書』では、図中だが「難易度デザイン」という表現を用いている&lt;ref&gt;川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日 第1版 第1刷、P.58&lt;/ref&gt;。

また、レベルデザインにはマップの処理もあるので、書籍『ゲームプランナー入門』（吉冨賢介 著）によると、3Dゲームにおける「レベルデザイン」担当者には、MAYAなどの3Dグラフィックツールの技能が要求されることもあるとのことです&lt;ref&gt;吉冨賢介『ゲームプランナー入門』、P234&lt;/ref&gt;。

=== 「詰み」防止の確認 ===
商業ゲームでは、クリア不能な状況にてプレイヤーがセーブしてしまい、ゲームを最初からプレイしなおす状況にプレイヤーが追い込まれること（いわゆる「詰み」（つみ） ）を絶対に防がなければなりません。

文献『ゲームクリエイターの仕事 イマドキのゲーム制作現場を大解剖』によれば、このためバランス調整でも、プレイヤーがそういう「詰み」に追い込まれないようにする必要があります&lt;ref&gt;蛭田健司『ゲームクリエイターの仕事 イマドキのゲーム制作現場を大解剖』、翔泳社、2016年4月14日 初版 第1刷 発行、P78&lt;/ref&gt;。

まず前提として、平均的なプレイヤーなら普通にクリアできる調整をしておく必要があります。

その上で、詰みを防止するためには、ゲームがとてもうまいプレイヤーでよいので、最低でも1人が、そのゲーム中で想定できる理論的に最もクリア困難な状況からですらも挽回してクリアできるという、クリア実績が必要です。

時間の制約などもあるからか、文献によれば、非常に上手い人が一度でもクリアしたという実績があれば良いという調整になるようです&lt;ref&gt;蛭田健司『ゲームクリエイターの仕事 イマドキのゲーム制作現場を大解剖』、翔泳社、2016年4月14日 初版 第1刷 発行、P78&lt;/ref&gt;。

もちろん、前提として平均的なプレイヤーの多くが平均的な練習でクリアできるようになっているという環境の上です。

=== プレイヤーの面倒くさがること ===
『ゲームプランとデザインの教科書』によると、ゲーム中で一般的なプレイヤーの面倒くさがることとして、

覚えること、計算すること、配ることを面倒だと感じると言われています&lt;ref&gt;『ゲームプランとデザインの教科書』,P342&lt;/ref&gt;。

=== 消費者の趣向の変化 ===
家庭用ゲーム黎明期の1980年ごろと比べて西暦2000年以降では、消費者に好まれるゲームの難易度バランスが違っています。

;用語「難しい」の変化
ファミコン時代の昔と21世紀の今とで、ゲーム消費者の感じる「難しい」という言葉そのものの程度や意味が、昔と今で、やや違います。

文献『ゲームプランナーの新しい教科書』によると、たとえば携帯ゲームにおいて、平均的なゲームプレイヤーがクリアまでに5回ゲームオーバーになるように調整されたゲームは、21世紀の現代では「難しい」に分類される場合もあります&lt;ref&gt;『ゲームプランナーの新しい教科書』、P210&lt;/ref&gt;。

一方、同文献によると「やさしい」とは、「平均プレイヤーならゲームオーバーにならない」という程度の意味です。

「難しいゲームの○○が人気！」などのニュースを目にしても、もしかしたら、そのジャンルのターゲット層の考える「難しい」の意味が、ファミコン的な昔の意味とは違うかもしれません。気をつけましょう。


その他、文献の情報ではないですがテレビ番組ですが（番組名は忘れた）、2011～2013年頃のテレビ番組で、ゲーム業界を取材した番組があったのですが（番組名は忘れました。たしか夜中の番組でした。）、
ゲーム会社だかゲーム業界の人がインタビューで
:「 昔の子供は、難しいゲームをプレイしたとき、「このゲームは難しい」と答えていたが、今の子供は「このゲームはつまらない」 と答える」という話をしています。当時、アニメ業界やゲーム業界などを取材した番組がいくつかあったのです。

=== どの程度の難易度を狙うべきか ===
『ナナのリテラシー』というビジネスノウハウ系の漫画があるのですが、これの2巻がゲーム会社勤務回です。また、著者の漫画家もゲーム雑誌で漫画を掲載していた経験もあります。

さて、その漫画『ナナのリテラシー』によると、「誰もが飛び越せる絶妙な難易度の壁をクリアさせる」のがコツだと、作中のゲーム会社の老人経営者は言います。あくまで創作中の人物であり、また、作品の主張ではないですが。

この漫画の取材の程度として、
「PS」（プレステ）のロードは、「1回のロードで2WMが限界なんで　どんなマップも2メガに入れなくちゃいけない　会話も音楽も全部ね」
という情報を入手できている程度には取材のされている作品です。

高難易度（むずかしめ）ゲームや低難易度（やさしめ）ゲームを作るにしても、まず基準がこうであることを知っておきましょう。

ただし、すべての人に丁度いいバランスに調整することは、非常に難しいです。なので書籍『ゲームプランとデザインの教科書』では、ターゲット層をある程度はしぼりこむ必要があると述べています&lt;ref&gt;『ゲームプランとデザインの教科書』、P.97 &lt;/ref&gt;。

ほかの書籍でも、塩川洋介『ゲームデザイン プロフェッショナル』では、やや文脈が違いますが、「遊んだプレイヤー全員が満足するものを、目指さない」と記述があります&lt;ref&gt;塩川洋介『ゲームデザイン プロフェッショナル』、技術評論社、2020年10月3日 第1刷発行、P.173&lt;/ref&gt;。（ただし、これはターゲット層の限定のほかにも、テストプレイヤーの意見に振り回されないように、という意味もあるので、文脈が少し違う。）

ターゲット層の設定で重要なことは、少なくとも、実在する最低1人の人間を、想定することです。「20代社会人男性が」とかではなく、自分の知人・友人・家族とか、そこまで具体的なレベルで想定するべきだと、塩川氏の著書では述べられています&lt;ref&gt;『ゲームデザイン プロフェッショナル』、P205&lt;/ref&gt;。

{{コラム|カラケオ音楽の難易度も似ている|
なお、ゲームではなく音楽文化ですが、80年代～90年代にカラオケが流行しましたが、実は当時の歌謡曲も似たようなカラオケでの難易度を意識して作曲されています。練習しないと歌うのが難しいが、素人でも練習すれば上手く歌える歌になるように、メロディが作曲されています。

たしか90年代後半、岡田斗司夫などが、こういったことを評論していました。

よく、音楽評論などでは、作曲家の小室哲也の曲が典型的にそうだと言われています。


なお例外もあります。

カラオケブームにより、90年代前半には、アニメソングでも子供が気軽に歌える歌が減ってしまったので、1995年のアニメ『新世紀エヴァンゲリオン』の主題歌の作曲では、監督やスポンサーのレコードー会社プロデューサーは、子供でも歌いやすいように作曲してくださいと作曲家に依頼しています。90年代後半の何かの書籍のインタビューで、スポンサーのレコード会社のキングレコードのプロデューサー（当時）大月俊倫がそう答えていました。
}}


{{コラム|作者ではなく購入客たちによって是非が決まる|
商業作品であるなら、最終的には売上によって作品の是非が決まるわけですので、ゲーム産業なら間接的には購入プレイヤー/課金プレーヤーが作品の是非を決めることになります。

決して作家が是非を決められることではないのです。

文脈は違いますが、文献『ゲームデザイン プロフェッショナル』でも、「味の善し悪しはプレイヤーが決める」と記述があります&lt;ref&gt;『ゲームデザイン プロフェッショナル』、P.167&lt;/ref&gt;。（ただしその参考文献では、ターゲット層を決めるべきだという文脈で味の善し悪しをプレイヤーが決めるという話をしていますので、本wiki本ページのニュアンスとは違います。）


ゲームに限らずアニメ産業でも同じであり、作者や監督でも決められないことが多くあります。

ジブリアニメの『となりのトトロ』は、子供たちにアニメばかり見ずに外で遊ぶように啓蒙するようなストーリーを作者・監督の宮崎駿は目指したと言われています。

しかし実際には、視聴者からファンレターで、子持ちの母親からのファンレターで、「うちの子は、よく宮崎先生のアニメを見ています。面白いアニメを作ってくださり有難うございます」みたいな感謝のメッセージが来たりと、つまり、肝心の「アニメばかり見ないで外で遊べ」というメッセージが伝わりませんでした。

ガンダムやエヴァンゲリオンでも似たような逸話がアニメ評論ではありますが、説明を省略します。
}}

=== チュートリアルの分離などの検討 ===
文献『ゲームプランとデザインの教科書』では、チュートリアルは別モードにすると良い場合もあると薦めています&lt;ref&gt;『ゲームプランとデザインの教科書』、P401&lt;/ref&gt;。

伝統的な難易度デザインの書籍では、「段階的に難易度をステップアップ」のような設計論が語られている書籍もありますが、しかしそれだと長編ゲームなどでは中後半のゲーム性の本筋に入る前に長々と本筋でない部分をプレイさせられてしまいかねません。そこで、チュートリアルを別モードに分けることで、あまりにも中盤の難易度から掛け離れた部分を、ゲームの本編からは切り離すことができる場合もあるとの事です。

商業ゲームの実例としては『不思議のダンジョン２　風来のシレン』というゲームが、このようなチュートリアル分離の手法を活用しているとのことです。

=== 教育的視点でのバランス調整 ===
==== バランスを通じた教育 ====
バランス調整を成功させるための対策はいくつかあります。一つ例を挙げると、プレイヤーに習得してもらうプレイ技法をある程度想定しておくことです。

プレイヤーがそういうプレイ技法を習得し、実践できるようになったら、敵キャラを簡単に倒せるようにするのが良いでしょう。

文献『ゲームプランナー集中講座』（吉沢秀雄 著）でも、ニュアンスはやや違いますが「教育的難易度」という用語を使っています&lt;ref&gt;吉沢秀雄『ゲームプランナー入門講座』SBクリエイティブ、2015年12月29日 初版　第1刷発行、225ページ&lt;/ref&gt;。

:※ ただし、この文献でいう「教育的難易度」とは、ある敵を攻略するのにプレイヤーがなんらかの操作を要求する敵は、まず1個だけのその敵の撃破用の操作技能だけをプレイヤーが修得できれば攻略できるようにしろという意味です。なので、本wikiでいう「教育的視点」とはニュアンスが若干（じゃっかん）、違います。

教育と言葉を使いましたが、プレイヤー視点では「学習」です。文脈は違いますが参考文献『ゲームプランとデザインの教科書』では、「学習」という言葉を用いています&lt;ref&gt;『ゲームプランとデザインの教科書』、P.61 &lt;/ref&gt;。

ただし、このように教育的な視点が有効な場面は、あくまでバランス調整だけでしょう。企画などのアイデア出しは、教育的視点ではなく、もっと大衆娯楽エンタメ視点で行うのが定石です。（なお一般的に、ゲーム業界にかぎらず企画手法の定石として、面白い事どうしの組み合わせ、というのがあります。）

また、少なくない多くのプレイヤーたちが、ゲームを通じて自身の思考力が磨かれて成長したかのような感覚を味わうのが好きだという統計・アンケート結果があります&lt;ref&gt;[https://www.teu.ac.jp/ap_page/koukai/2019_03_3endo.pdf  [[w:遠藤雅伸]] 『ゲーム道に通じるユーザーの振る舞いとゲームデザインへの応用』66ページ、3.3.3. 面白さに関する考察  ]&lt;/ref&gt;。


なお、コンピュータ的なゲーム産業と、教育との関係性にすでに気付いて注目しているゲーム作家もいます。ナムコ出身の岸本好弘がそうです。また、学問的にも、ゲーム設計技術の教育への応用として『ゲーミフィケーション』などと言う概念が提唱されています。

ゲームフィケーションに関する説明は長くなるのでコラム化します。
{{コラム|ゲーミフィケーションに関すること|
野球ゲームの『ファミスタ』シリーズで有名なナムコ出身の岸本好弘などが、ゲーミフィケーションをゲーム作家の立場から推奨している。&lt;ref&gt;[https://news.denfaminicogamer.jp/kikakuthetower/190731a ファミスタの父が「日本ゲーミフィケーション協会」発足──ゲームの力で世の中はもっと面白くなる
2019年7月31日 14:41 公開]&lt;/ref&gt;

2019年に岸本がゲーミフィケーション学会を設立したが、なにもこの時点で概念が産まれたわけではなく、既に2013年あたりの時代には、たとえばテレビの夜中の経済ニュース番組などで、ゲーミフィケーションを企業の新人研修に応用する事例などが報道されていた亊もある（ただし、これに岸本氏が関わっているかは知らない）。

岸本が言うには「ゲームの本質っていうのは、人間が頭で想像することの素晴らしさ」である&lt;ref&gt;[https://www.fantasy.co.jp/edutainment/article/interview16    『“遊び”と“学び”はまったく同じ！？
ゲームと教育の専門家二人が語るゲーミフィケーション教育（前編）』  2021.07.08 UP]    &lt;/ref&gt;。

岸本が言うには、今から40年前（※1980頃 ？）を振り返り、すでにゲームセンター用のアーケードゲーム業界では、
:「そのころアーケードゲームのデザインで言われていたのは、初めてそのゲームに挑戦したプレイヤーでも3分間程度は遊べるようにすること。「もう一度チャレンジしたら、先に進めそうだ！」と、プレイヤーの気持ちが動くように制作すること」
:「これって、現在IT業界で言われるUX、ユーザーエクスペリエンスですよね。ゲーム業界では理論化、言語化していなかったけれど、40年前から現代に通じることをやっていたんだなと思いました。」
と言われている&lt;ref&gt;[https://www.fantasy.co.jp/edutainment/article/interview16    『“遊び”と“学び”はまったく同じ！？
ゲームと教育の専門家二人が語るゲーミフィケーション教育（前編）』 藤本 徹氏・岸本 好弘氏, 2021.07.08 UP]    &lt;/ref&gt;。


岸本「ゲームって全部「そそのかし」なんです。ゲームをプレイしていて、Ａの洞窟に行きなさいとか、Ｂの洞窟には行くなとは言われないですよね。プレイヤーが2つの洞窟をぱっと見たときに「こっちの洞窟に宝があるかも！」って見えるように作っているんです。これを「そそのかし」って言うんです。間違っても、ストレートに「Ａの洞窟に宝物があるなどという看板を立ててはいけません（笑）。」

（抜粋）「先生は答えを教えるのではなく、生徒が自分で「わかった！」、「僕が一人で気が付いた！」と思わせることが大切。」

「ゲームをデザインするのも授業をデザインするのも同じです。楽しいと思うことやワクワクすることは脳の働きを最大限にする。だから、つらいことを我慢するのはよくない。脳が楽しいと感じることがとても大切なんです。」&lt;ref&gt;[https://www.fantasy.co.jp/edutainment/article/interview17   『“遊び”と“学び”はまったく同じ！？
ゲームと教育の専門家二人が語るゲーミフィケーション教育（後編）』藤本 徹氏・岸本 好弘氏, 2021.07.15 UP] &lt;/ref&gt;


必ずしも現代のゲームが上述のように教育的配慮にもとづいて設計してもヒットするかは不明である。21世紀の現代と20世紀のファミコン黎明期とでは消費者ニーズも違っているから、もしかしたら今後は教育的配慮ある作品が全く売れないのかもしれない。

だが、とりあえず1980年代前後のゲーム文化の根底には、このような教育的な発想が色濃く存在していたのもまた事実であろう。
}}

{{コラム|オタキング岡田はこういった|
また、ゲーム業界人だけでなくアニメ業界人からも、1998年までの時点で似たようなことが指摘されています。

既に1990年代後半の時点で、アニメ評論家の岡田斗司夫により著書などで、市販のゲームソフトの多くは達成感を味合わせるものだと指摘されている。
たしか岡田の著書『世紀の大怪獣!!オカダ―岡田斗司夫のお蔵出し 』に、そういった話題が書かれており、マリオカートが例に出されている。

岡田に言わせれば、ゲーム文化以前の人生の趣味の多くは、必ずしも努力の量と、上達とが比例しない。たとえばスポーツとか、絵画とか、何でもいいが、たしかに練習を多くしても必ずしも上達に結びつくとは限らない。

しかしファミコン以降のコンピュータ式のゲームはそうではなく、ほぼ必ずといっていいくらい、少なくとも初心者レベルの範囲でなら、プレイして練習すれば上達するように設計されていると、彼の著書では述べられている。

岡田が言うには、人生はゲームみたいに甘くないし、もしかしたらゲームは現実逃避で不健全かもしれないけど、でも大人だって親だって達成感をもっと感じたいんだぜ・・・だから今日も娘といっしょにマリオカートをプレイしている、というような感じのことを著書で述べていた。
}}

{{コラム|岡田斗司夫はゲーム会社社長でもあった|
なお、岡田らの創業したアニメ会社の「ガイナックス」は、現在では『新世紀エヴァンゲリオン』をつくったアニメ会社として語り継がれていますが、実はゲームソフトも開発していました。

多くは美少女ゲームだったりしたのですが、その中に、1991年に開発した『プリンセスメーカー』という当時としては斬新な育成シミュレーションゲームがありました。（少女を育成するゲームとしては、おそらくプリンセスメーカーが世界初。なお、競馬の競走馬を育成するゲーム（ダービースタリオン）1991年12月発売よりもプリンセスメーカー（1991年5月24日）のほうが発売が早い。）

文献『ゲームプランナーの新しい教科書』でも、美少女や少年などのキャラクターを1人または少人数のキャラクターを育成するジャンルを確立したゲーム作品が、このプリンセスメーカーであると述べられています&lt;ref&gt;STUDIO SHIN『ゲームプランナーの新しい教科書』、翔泳社、2018年3月10日 初版 第2刷 発行、P182&lt;/ref&gt;。

さて、1998年ごろにゲーム評論家の阿部広樹（あべひろき）が言うには、
98年当時はコナミ社『ときめきメモリアル』という、美少女と恋愛するための男主人公を育成する育成ゲームがほぼ社会現象のような流行だったのですが（たとえばジャンプ漫画の　こち亀（略称。長いので）　にも、
明らかに『ときめきモリアル』（略称：「ときメモ」）のようなゲームを話題にした作品が、
社会現象作品として登場しています）。                                                        

阿部が言うには、ときメモのような育成ＳＬＧは、ゲーム業界での系譜としては、まずプリンセスメーカーが娘の育成ゲームとして登場し、
おそらくは、それを参考にしてPCゲーム会社「エルフ」が美少女アダルトゲーム「同級生」（ゲーム中に男主人公の育成がある）を開発し、
さらにそれを参考にしてコナミ社がときメモを開発したという流れになる、と阿部は著書などで述べています。


あくまで阿部氏が著書でそう思っている旨を述べていただけなので、
もしかしたらエルフ社やコナミ社の当時の関係者からすれば元ネタが違う点もあるのかもしれませんが、
少なくとも他社やマニア消費者からはそう思われている（プリメ→同級生→ときメモ　という流れを思われている）というワケです。


さて、ときメモの話をしたいのではなく、岡田の話をしたいのです。

岡田は当時はゲーム社長だったので、常識的に考えて、プリンセスメーカーの開発に関する情報は、ある程度は耳に入っていると思われます。（ただし、岡田本人はゲームファンではなく、アニメファンかどうかも怪しく、どちらかというとSFファンでした。）

いくら岡田がゲームに詳しくないといっても、信頼できる部下にゲーム開発指揮を任せているとしても、岡田が社長である以上、最低限の開発工程の概要や全体像に関する情報が岡田の耳には入っているハズです。


そういう経験のある岡田が「ゲームはプレイ時間に応じて、上達するように設計されている」と具体的に言うわけですから、岡田のマリオカート評論当時の意見を、過去のゲーム業界人の意見としても、それなりに意見を参考に聞き入れるべきでしょう。
だから「岡田はアニメ評論家じゃねえか」とか言って意見を無視するのは、不見識です。


また、プリメ→同級生→ときメモ　という流れから分かるように、一般にゲーム会社は他社の人気コンテンツを真似ています。

攻略本やゲーム雑誌などには一切書かれていませんが、大人の事情で書かれていないだけですので、大人の事情を真に受けないようにしましょう。当然、ときメモ以降の他社の育成ゲームや美少女ゲームも、社会現象になった「ときメモ」を真似しています。誤解のないように再度書きますが、上記で紹介したゲーム郡のうち、岡田経営のガイナックスのゲームは『プリンセスメーカー』だけです。ほかのゲームは他社コンテンツですので、誤解なきよう。
}}

{{コラム|プリメとデスペナ|
プリンセスメーカーには育成システムのほかにも比較的に画期的なところがあって、それは戦闘での全滅時の損失の軽さです。プリメのしリーズでは、戦闘で全滅しても、拠点に戻されることと、育成パートでのターンが1ターン経過するだけです（1ヶ月が1ターンに相当する）。この指摘は別にwikiのオリジナルではなく、1990年代の後半に雑誌『ゲーム批評』で指摘されていたことである。

1年に12ターンしか行動できないので、シミュレーションゲームの視点で考えると損失は大きいかもしれませんが、RPGの視点だけで見ると損失は軽い、というわけです。

日本の現代的なゲーム評論では、全滅時の損失のことを和製英語でデス ペナルティといいます。英語では dead damage というらしいです（DDと略すようです）。英語ではデスペナルティ death penalty とは「死刑」の意味です。

つまりプリンセスメーカーは、デスペネルティが軽くても面白いRPGを作れることを実証したかもしれない可能性があります。


;デスルーラ
なお、全滅しても拠点に戻るだけのシステムだと、拠点に戻りたい場合にわざと全滅する方法を使えますが、これを和製英語で「デスルーラ」といいます。ルーラとはドラクエの移動魔法のルーラのことです。

さて、全滅したときに拠点に戻るゲームでは、標準的な方法では、決してイベントなどで拠点に戻らないようにするのは不可能です。

なぜなら、たとえば拠点の町に戻る橋を通せんぼしているボス敵がいたとして、ボス敵が「この橋を通りたければ、私を倒すが良い」とか言われてボス戦になったとしても、そのボス戦闘で全滅するとパーティは拠点の町に戻るので、そもそも通せんぼイベントの意味がありません。

ただし、もしイベント用の特殊なプログラムとして、全滅時には他の町に戻るなどの戦闘の処理を組めば可能ですが。

}}

{{コラム|デスペナ関連の話題|
&lt;!-- この話題は、後述の商学書『メイド・イン・ジャパンは負けるのか』の話題と関連するので、残す必要がある。  --&gt;
;帰り道の通せんぼイベントと詰みのリスク
そもそも、拠点への通せんぼ系のイベント自体、クリア保証の観点からは難しい点もあります。サガのようにどこでもセーブできるゲームの場合は、帰り道の通せんぼイベントを上手に設計しないと、クリア不能につながるおそれがあります（いわゆる「詰み」（つみ））。

だから実際、ファミコン～スーファミ時代のドラクエやファイナルファンタジーやGB版サガやロマサガなどでは、このような帰り道の通せんぼイベントを見かけないか、あったとしてもスグには思い出せません。

どこでもセーブできるロマサガ1の氷結城の帰り道で通せんぼするボス敵がいますが、しかし会話選択肢などによりボス戦を回避可能ですので、詰みにはなりません。


なお、古い時代のサガ系やロマサガなどでは、基本的に、ダンジョン奥まで探検したあとの帰り道には、帰り道の短縮のためにダンジョン最深部に出口への一方通行をマップ側で用意済みというダンジョン設計もよく見られました。このダンジョン設計は、テンポ感向上の基本手法である「プレイヤーが既に理解していることを再度要求しないこと」にもつながりますので、一石二鳥です。

ただし、一方通行出口がないダンジョンがあれば、「帰り道でボス戦があるんだな」とプレイヤーに予感させてしまい、プレイヤーへのネタバレになります。だから、ドラクエがそのような一方通行出口をまず用意しないのも一理あります。

このように、ゲームのルールの設計により、実装可能なイベントやマップなどがある程度は限定されてしまいます。
}}


さて上記のデスペナルティのコラムで説明したように、ゲームのシリーズ作品は、そのシリーズを通してルールがおおむね一緒です。

このことと、「ゲームのルールによって搭載されるイベントがある程度は決まる」という事を合わせて考えると、どうなるでしょうか。

そう、シリーズ作品によって、搭載されるイベントの傾向が決まってしまうのです。


問題は、これがマンネリ化につながるおそれがあること、少なくともビジネス書ではそう見られていることです。

これは別にwikiのオリジナル意見ではなく、文脈は違いますが、商学書『メイド・イン・ジャパンは負けるのか』という2010年ごろの書籍で、
シリーズ化とマンネリ化との相互関係が語られています。

さらにその書籍によれば、基本的に家庭用ゲーム機の作品群の多くはゲーム性の根幹が90年代あたりから以降の作品は変わっておらず、変わったのはグラフィックが細かくなっただけ、というふうに見られています。

ただし、書籍は2010年ごろの出版物なので、もしかしたらスマホゲームやソシャゲの流行している2020年代の現代なら、分析結果は違うのかもしれません。

もっともゲーム会社からすれば反論もあるかもしれませんし、たとえば、

「でも消費者が、新シリーズや新ジャンルを出してもロクに買わねえじゃねえか・・・」とか

「グラフィックよりゲーム性とか口先では消費者は言うけど、でもそういうグラ軽視のゲームを消費者は買ってくれないんだよね」とか

「素人はみなそう言うんだよね。でも自分じゃ作ってくんないし少しでも試作品の手本すら見せてくんない」とか思うかもしれませんが、

とりあえず、世間にはそういう意見があります。

けっしてゲームオタクだけがそういうマンネリ化の意見を言ってるのではなく、外部の商学あたりからもそう見られています。ただし書籍の商学者の分析が正しいかどうかは知りませんが。

1980年代のような家庭用ゲーム黎明期や1995年頃のソフト容量が飛躍的に伸びたプレステ1時代ならともかく、そうそう新しくて画期的かつリアリティと説得力ありそうなルールなんて、思いつくものではありません。難しい問題です。また、マンガ産業やアニメ産業は黎明期をとっくに過ぎてしまいましたが、それでもマンガもアニメも産業は続いています。2010年台のゲーム産業だって、もしかしたらスマホゲーム黎明期、ソシャゲ黎明期なのかもしれません。2010年以降の現代のゲーム産業については、当wikiは中立性の立場上、これ以上は解説しません。

{{コラム|岡田斗司夫のアノマリー理論|
古典的な理論を言うと、アニメ評論家の岡田斗司夫が「アノマリー」（「片寄り」という意味の用語）で言ってる例ですが（『東大オタク学講座』にある理論）、ゲームのバランス調整にはそもそも、岡田の理屈によると普遍性はなく、どうしても作者の世界観が反映されます。

たとえば、『シムシティ』というアメリカ人の作った都市運営シミュレーションのゲームでは、原発が効果的な投資であるのですが、そして火力発電所よりも原子力発電所が効果的なのですが、岡田はこれを作者のアメリカ的な都市政策観の反映だとしています。                                                                                
そのほか、岡田は、ドラクエシリーズに対して、「なぜ作者の堀井さんは、作中で父親と子の関係に、どの作品でも、こだわりたがるんだろう？　なにかあったんじゃねえの？」的なゲスい勘繰りもしています。

作家の「個性」というのは、一般人から見れば「異常性」でもあるわけです（ただし、法律を守る程度の最低限の一般性は作家だろうが必要ですが）。個性というのは長所ではなく、欠点の裏返しでもあるわけであり、その欠点すら大人はうまく自分で活用しなければならないのでしょう。
}}

==== 本文 ====
もちろん作品によっては例外もあるでしょうが、しかし上述で紹介したような様々な視点の異なる複数のゲームクリエイターなどゲーム業界人が、「教育」や「成長」などあたかも学習的な用語を使っている事は、念頭に置くと良いかと思います。

ゲームにおける教育的な要素はもちろん擬似的なものです（ゲームに限らず一般のアニメや漫画も同様です。もし本格的に世間一般で通用する意味での「学習」をしたいなら高校～大学レベルの国語・数学・英語・理科・社会科などの参考書などを読もう）。


さて調整の話題に戻ります。

たとえば、アクションゲームの調整なら、

もし敵が飛び道具を使ってくるなら、まずプレイヤーは物陰に隠れて移動して近づくとか、あるいはプレイヤーも飛び道具で応戦するとか、そういうプレイ技法が必要でしょう。


文献『ゲームプランナー集中講座』（吉沢秀雄 著）でも、飛び道具を使ってくる敵には、ゲーム序盤では、まず物陰にかくれて敵の攻撃を避けるなどのプレイ技法をプレイヤーに習得できればよいというくらいまで、（序盤の）難易度を簡単にすべきだと、その文献『ゲームプランナー集中講座』では主張されています&lt;ref&gt;吉沢秀雄『ゲームプランナー入門講座』SBクリエイティブ、2015年12月29日 初版　第1刷発行、226ページ&lt;/ref&gt;。

まず、序盤の飛び道具つかいの敵なら、プレイヤーが上述のような物陰に隠れる技法を実践できていたら、その敵を簡単に倒せるように難易度を調整します。


このため、序盤ではけっして、敵の攻撃をさけるための物陰の部分には、ゲーム作者はワナなどを仕掛けないでおき、物影には敵も配置しないようにするくらいで、良いのです&lt;ref&gt;吉沢秀雄『ゲームプランナー集中講座』SBクリエイティブ、2015年12月29日 初版　第1刷発行、226ページ&lt;/ref&gt;。


たとえば、飛び道具を使ってくる敵は、そいつに攻撃を当てるまでは難しいが、しかし敵の防御力を低くしておいて、もし敵が（プレイヤーからの）攻撃を受けたら、敵はすぐに倒されてしまう・・・のような強さの敵としてパラメータ調整しておくのが良いでしょう。

つまり、プレイヤーに教えたいスキルとして、そのアクションゲームを通して、飛び道具を使ってくる敵の対処法を教えるのです。


ゲーム後半で難易度を上げる場合は、けっして敵を単にやたらと頑丈にするのではなくて、
敵の強さはそこそこでいいので、

たとえば

ステージのギミックや敵の行動などを今までの敵と複合化させたりする等の設計により、過去にプレイヤーの習得したプレイ技法の組み合わせの練習・習得をプレイヤーに要求したりとかして、プレイヤーに今まで習得した単一のプレイ技法の複合の習得を要求するようにすると、プレイヤーも成長できますし、あきづらくなるし、いいことづくめです&lt;ref&gt;吉沢秀雄『ゲームプランナー集中講座』SBクリエイティブ、2015年12月29日 初版　第1刷発行、228ページ&lt;/ref&gt;。

（ただし、あまりにも膨大なプレイ技法どうしを組み合わせるような過大な技法をプレイヤーに要求しないように、（作者がプレイヤーに）要求する技法の数にも限度は必要でしょう。）


なお、余談だが、「難易度」の「高い」「低い」の意味は、
:「むずかしい」＝「難易度が高い」
:「やさしい」＝「難易度が低い」
である。

ゲームを難しくする目的は、プレイヤーに創意工夫を呼び起こすためです。創意工夫を呼び起こさない難しさは不要かもしれません。

書籍『ゲームプランナー入門』によれば、ボス戦などの難しいエリアの目的は、プレイヤーが自らのプレイスキルの程度を試したり、あるいはRPGなどならキャラクターユニットの成長を試すためのものです&lt;ref&gt;吉冨賢介『ゲームプランナー入門』、P60&lt;/ref&gt;。また、「歯ごたえ」などの表現の意味も、こういった意味であると書籍では述べています。               

;制限の必要性
制限の必要性とは、たとえば、ゲーム中での主人公が丈夫で死にづらいのは構いませんが、しかしどんなに敵の攻撃を食らっても死なずに倒れずに不死身なのは駄目です。

また、主人公の所持金が多いのは構いませんが、しかし所持金が無限大なのは駄目なのです。

また、敵の動きが少し単純なのは構いませんが、しかし、プレイヤーが油断しすぎているのにプレイヤーが負けないのは駄目です（たとえばアクションゲームで一時停止ボタン（ポーズボタン）を押さずにトイレに行ってウンコを数分してきても、ウンコから戻ってきてもキャラが負けてないのは明らかに駄目）。

このような駄目な例のゲームのままでは、プレイヤーが創意工夫をしなくなってしまいます。


このため、そのゲームでのゲームオーバー条件を、作者は早めに決めておきます。ゲームオーバーが用意されていないと、スリルが出ないのです&lt;ref&gt;川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日 第1版 第1刷、P.254&lt;/ref&gt;。

あまり気が乗らないでしょうが、しかし、ゲームにはゲームオーバーや敗北の条件が必要ですし、プレイヤーには敗北を回避するように努力してもらわなければなりません。

;解法を1つに限らない
書籍『ゲームプランナー入門』（吉冨賢介 著）によると、たとえばスーパーマリオ1のステージ1-1の最初の敵のクリボーの対処でも、クリボーを踏んでやっつけるか、それともジャンプして飛び越えて次に進んでしまうか、マリオがブロックの上に乗ってクリボーが通り過ぎるのをやりすごすか、などなど幾つもの選択肢があると、例を挙げています&lt;ref&gt;吉冨賢介『ゲームプランナー入門』、P55&lt;/ref&gt;。けっして、「たった一つの正解」ではないと述べています&lt;ref&gt;吉冨賢介『ゲームプランナー入門』、P55&lt;/ref&gt;。

このように解法を複数用意することで、プレイヤーに創意工夫を呼び起こしやすくなります。

==== 他メディアとの違い ====
===== マンガ・アニメのバランス調整との違い =====
マンガやアニメのバランス調整というか、物語での敵の強さの見せ方と、ゲームでの敵の強さのありかたは、少し差異があります。

マンガ・アニメだと、たいてい強敵は、主人公がなんとか苦戦しながら倒せるギリギリの強さになっています。たしか1982年『鳥山明のヘタッピマンガ研究所』（1982年『鳥山明のヘタッピマンガ研究所』）の時点で、すでに、マンガやアニメや特撮（ウルトラマン）などの敵の強さは、そういうふうに設計されていることが説明されています。

しかしゲームでは普通、このようなギリギリの強敵にしてないほうが安全です。

マンガやアニメの強敵よりも、やや弱めにしておく必要があります。そうしないと、プレイヤーに創意工夫が生まれません。

具体例を考えるなら、分かりやすい例が、先ほど漫画家の鳥山明さんを例にあげましたが、その鳥山さんのドラゴンボールの原作マンガとゲーム版でのボス敵の強さの違いです。ゲーム版『激神フリーザ』だと、たとえばクリリンでもちょっと鍛えて頑張ればザーボン（ナメック星編の中ボス敵）を倒せるようになっています（原作マンガだとクリリンはザーボンを倒せない）。別に鳥山さんの作品だけでなく、ほかの多くの作家のマンガやアニメのゲーム版も、大体、同様に、原作マンガや原作アニメでは倒せなかったボス強敵がゲーム版では頑張れば倒せるようになっています。

理論的に考察するなら、マンガやアニメでは、一回の戦闘での強敵の倒しかたが一通りしかなく、いちばん読者に魅力的に見える奇想天外・破天荒な倒しかたで、敵を倒します。なのでマンガやアニメでは、ギリギリ倒せる強さのほうが良いのしょう。

しかしゲームの強敵では、多くのプレイヤーの、それぞれ異なる色々なアイデアに対応した倒し方を何通りも準備する必要があるので、ゲームでの強敵の強さは、ギリギリ倒せる状態よりも少し弱めにする必要があります。

==== 「廃人」 ====
ゲーム用語で「廃人」（はいじん）という表現があります。「廃人」とは、たとえば通信機能のあるネトゲRPGなどで、普通の社会人だとレベル上げが引きこもりプレイヤー追いつかずに（社会人が）クリアできないようなゲームにおいて、高レベルプレイヤーである引きこもりプレイヤーや無職プレイヤーなどを揶揄する意味です。

2010年以降の近年は課金ゲームなどにも「廃人」という言葉が使われます。一般の市販ゲームは高くても1万円程度ですが、それと比較して多額すぎる数十万円や数百万円の金額をゲームに課金するプレイヤーのことです。


書籍『ゲームプランとデザインの教科書』でも、この問題をサラっとですが、きちんと紹介しています。書籍中では「廃課金ユーザー」という表現を使っています&lt;ref&gt;『ゲームプランとデザインの教科書』、P66&lt;/ref&gt;。書籍『ゲームデザインとぼくらの教科書』でも、廃課金ユーザーが社会問題化したことに触れられています&lt;ref&gt;『ゲームプランとデザインの教科書』、P66&lt;/ref&gt;。


アニメーターだってゲームをする暇があるなら絵を描いていたからアニメーターとして通用しているわけです。アニメーターの就職前の第一趣味はゲーマーではないでしょう（イラスト制作やアニメ制作のはずです）。

=== ゲーム作家の体感の難易度はズレやすい ===
プログラミングというよりゲームデザインの話題かもしれないが、そのゲームの簡単さ・難しさといった難易のバランス調整も、コツがいろいろとある。

==== 具体的な方法 ====
結論から言うと、多くのゲームデザインの文献で、やや簡単めに調整されたバランスでゲームを作るのが安全であると主張されている。

たとえば書籍『ゲームプランナーの新しい教科書』（STUDIO SHIN 著、翔泳社）でも、作者がやや簡単だと思うくらいに作ると良くなる場合が多いという経験則が語られている&lt;ref&gt;STUDIO SHIN 著『ゲームプランナーの新しい教科書』、翔泳社、2018年3月10日 初版第2刷発行、54ページ&lt;/ref&gt;。

また、書籍『ゲームプランナー集中講座』（吉沢秀雄、SBクリエイティブ）でも同様に、調整で迷って、プレイヤーにとっては易しいほうの案Aと難しいほうの案Bとがあったら、ゲーム本編には、やさしいほうの案Aを採用するのが良い、と主張しています&lt;ref&gt;吉沢秀雄『ゲームプランナー入門講座』SBクリエイティブ、2015年12月29日 初版　第1刷発行、235ページ&lt;/ref&gt;。

難しいほうの案Bは、クリアに不要なサブ・ステージとか、そういうステージに流用すればいいのです&lt;ref&gt;吉沢秀雄『ゲームプランナー集中講座』SBクリエイティブ、2015年12月29日 初版　第1刷発行、P207および235ページ&lt;/ref&gt;。

ちなみに、文献『ゲームプランナーの新しい教科書』によれば、RPGにおいて、クリアに不要なイベントのことを「任意イベント」と言います。一方、クリアに絶対な必要なイベントのことは「強制イベント」といいます&lt;ref&gt;STUDIO SHIN著『ゲームプランナーの新しい教科書』、P198&lt;/ref&gt;。

つまり、サブ・ステージや任意イベントの難易度については、本編の強制イベントの難易度よりも少し難しくしても構わないのです。文献『ゲームプランナー集中講座』によれば、むしろ、多様なプレイヤーに対応するためにサブ・ステージや任意イベントの難易度の設計は、本編強制イベントとは難易度を変えるほうが望ましいというか、そういう設計テクニックとしてサブ・ステージや任意イベントが用意されているような側面もあるようです&lt;ref&gt;吉沢秀雄『ゲームプランナー集中講座』SBクリエイティブ、2015年12月29日 初版　第1刷発行、P208&lt;/ref&gt;。


書籍『ゲームプランナー入門』（吉冨賢介 著）でも、基本的に作り手は「簡単」だと思っていても、初めてプレイするプレイヤーには難しいという現象がよくあることを述べています&lt;ref&gt;吉冨賢介『ゲームプランナー入門』、P56&lt;/ref&gt;。

==== 例外 ====
例外的なプレイヤーもいます。プレイヤーの中には、たとえばRPGなら、レベル上げそのものが好きな人もいます。

また、たとえばゲーマーでない一般人でも、たとえば電卓で「+1」を押しまくって計算結果をカウントアップしていく暇つぶしをしたことある人も多いでしょう。


ですが、レベル上げが好きなRPGゲーマーでも、彼らがプレイしたがるゲームの多くは、なぜか、レベル上げがそれほど好きでない種類のゲーマーも楽しめるゲームばかりです。

ドラクエ、ファイナルファンタジー、女神転生、テイルズ、・・・などなどのシリーズは、どれも商業の人気ゲームは、レベル上げがそれほど好きでなくても、ストーリーや戦術性などでも楽しめるようになっています。

本当にレベル上げだけが好きなら、ストーリー一切無しのレベル上げだけのゲームをプレイすれば充分ですし、フリーゲームなどでそれに近いゲームはあります。しかし、商業の世界では、そういうストーリー無し、あるいは戦術性が無しのゲームの話を聞きません。

これはどういうことでしょうか。

ゲームでなくマンガ業界の例で考えて見ましょう。

たとえば、少年ジャンプの読者には、メインの読者層は若い男の子ですが、
しかし実際には成人男性の読者もいますし、それどころか女性読者もいます。

しかし少年ジャンプは、あくまでも、メインの読者層が男の子であることを貫く編集姿勢であることが、
ジャンプ漫画の裏側を描いたマンガ『バクマン』では描かれています。


バクマンによると、たとえ少女の読者がいても、その少女は、
「男の子が読んでるマンガを自分も読んでみたい」と思うような女の子なので、
だからジャンプの取るべき編集姿勢としては、あくまで男の子向けを貫かないといけない、
といった内容が説かれています。

ゲームも同様でしょう。

==== 背景事情 ====
一般的にゲーム作家の側は、自作のゲームをプレイしたときの体感の難易度（なんいど）が、（他のプレイヤーよりも）自作ゲームを「やさしめ」に感じてしまいまちである。

つまり、本当は難しいゲームなのに、作家自身は「やさしい」と錯覚しやすい傾向がある。なお、この現象を俗に（ぞくに）「作者バイアス」と日本では言う。

;歴史
まず、1990年代のゲーム雑誌『ゲーム批評』にもある歴史的事実として、下記のような事例がすでに1990年代から知られています。

すでに1990年代の時点でゲーム評論雑誌『ゲーム批評』において、新人のゲームプランナーは企画提案の際に既存ゲームを難しくアレンジした提案をしがちだという報告がありました。

雑誌『ゲーム批評』によると、たしか、たとえばもし自社がスーパーマリオのようなゲームを作ろうとしている場合、新人はよく、「マリオのこの部分が簡単すぎるから、わが社はここを難しくしましょう」という提案をしがちだということです。

たとえば、スーパーファミコン版マリオ（スーパーマリオワールド）では、地上ステージでは多くのステージで、マリオに空を飛ばせれば、敵に遭遇せずにステージのゴールまで行けるように設計されています。

それを新人は「飛んでしまうと簡単なので、つまらない」と考えがちらしく、なので「空中に敵キャラを多く配置しましょう」という感じの案を提出しがちだということです。

たとえば
「空中に狼（オオカミ）を配置するのはどうでしょう？　アメリカの昔のSFドラマに『超音速攻撃ヘリ　エアーウルフ』という作品もありますので、パロディにもなって大人にもウケます」みたいな提案を出したりしがち、らしいです。（このほか、ゴルフゲームでウルフを空飛ばせる駄洒落（ゴルフでウルフ）アイデアなどの披露もあるとかゲーム批評では書かれていた気がするが（というか元々ゴルフゲームの提案で、上司役からのダメだしの根拠にマリオを例にする批評記事だったかもしれないが、本wiki本ページの文脈にあまり関係ないので、ゴルフの話は割愛させてもらう。）

ですが、マリオの地上ステージの空中に敵が少ないのは、ゲームが苦手なプレイヤーのための救済措置だったり、あるいは既に途中まで攻略したけどミスでステージ冒頭に戻されたあとの再チャレンジなどで興味ない体験済みステージ前半を無視するための工夫だったりするので、よって空中の安全性は必要な要素でしょう。

しかし、エアーウルフ的な提案では、そういう分析が抜け落ちています。

ともかく、このように、バランス調整では「予備知識が無いと、多くのゲーム製作者は、ゲームを難しく設計しがち」だというゲーム業界の経験則がもう1990年代からあります。私たちは、歴史にも学びましょう。


:※ ある編集者Aがなんとなく印象でゲームデザイン本などに「ゲーム作家はあまりネットの批評を参考にしない。ゲームを作った事のない人の批評なので、トンチンカンな批評も多いからだ」といったような情報があったような気がしたのですが、
:しかしあらためて書籍を確認してみると、少なくとも『ゲーム作りの発想法と企画書の作り方』や『ゲームプランとデザインの教科書』や『レベルデザイン指南書』では、そのような記述は確認されませんでした。
:下記のコラムは、その情報も背景にしています。
:どうやら、もしそういう記述の文献があっても、必ずしも商業ゲーム業界の多数意見とは限らないようです。
:あるいはその情報は、もしかしたら書籍による情報ではなく、ゲーム雑誌などのwebサイトの意見だったかもしれません（※ 読者に出典などをご存知の方がいたら、情報提供の編集をしていただけると、さいわいです）。よくゲーム雑誌の会社がwebサイトなどに商業ゲーム作家へのインタビュー文など掲載しています。

:一応、『ゲームデザイン プロフェッショナル』では、書籍後半のセクションの題名で大きく「一次情報以外、個性には役立たない」と銘打って、
:「インターネットやSNS」などについて、「そうした情報は知識として役に立つことはありますが、ゲームデザイナーが個性を発揮するうえではあまり役に立ちません」と説明している&lt;ref&gt;『ゲームデザイン プロフェショナル』、P314&lt;/ref&gt;。


{{コラム|マリオメーカーのクリアチェック、ほか|
マリオついでに話すと、『マリオメーカー』という任天堂のつくった、マリオのゲームの素材を使って、
マリオメーカー購入者でも自分でマリオ風アクションゲームを作れるというゲームがあります。

このマリオメーカーというゲームでは、自作したゲームを任天堂のwebサイトに投稿・公開する際、クリアしてからでないと、投稿・保存できない仕組みになっています。

実は、マリオメーカーが発売される前、インターネット上には「改造マリオ」といって、マリオのROMを違法改造して、自作ステージをつくって無料公開などをする人たちがいました。

改造マリオはそもそも著作権侵害であり違法なのですが、その他にも問題点として、作成されたステージがやたらと難しすぎてクリア困難なステージばかりで溢れていた、という問題もありました。


しかしインターネット上では、そのようなクリア困難なゲームが、ネットのマニア達にはウケており、動画サイトなどではそのような超絶な高難度ステージが話題だったのです。

社会科学の格言で、「犬が人をかんでもニュースにならないが、人が犬をかむとニュースになる」という有名な格言があります。つまり、実際には統計的には少ない事例のほうがニュースとして話題になりやすいという、社会の法則があります。

また、アンケート調査などの心理学的ノウハウとして、「あなたは○○を買いますか？」と「あなたは○○を好きですか？」と聞いたときでは、
アンケート結果の傾向がかなり異なり、多くの人が、「○○を好きですか？」と質問されても決して実際に好きなものを答えるのではなく、
世間から賞賛されそうな趣味趣向の場合にだけ回答で「はい、好きです」と答えるようであるという、分析結果があります。

まさに改造マリオと本来の合法マリオの関係がそれです。                                                

マリオメーカーでクリアチェックが必須なのは、せめて作者自身がクリアできるゲームをつくれ、常識的なプレイ時間で上達してクリアできるゲームをつくれ、というような任天堂の思いが伝わってきます。

おそらく任天堂の社内でも開発ゲームでは、各ステージのクリアチェックなどが行われているのでしょう。
}}

{{コラム|ネット民の感性は信用できるか?|
インターネット上には無料コンテンツがあふれておりますが、そのような無料コンテンツを楽しむ人たちのセンスは、一般の消費者のセンスとは異なりますし、もし仮に有料だとしても自分がカネを払うつもりもないものを平気で「面白い」と言える人たちも多く居ます。

それでも実際にプレイをした上での感想を言うならまだしも、しかしプレイヤーの人数よりも世界には無料動画の視聴だけをして感想を言うだけの人たちのほうが多いのです。

しかしそれすらも動画サイトでゲーム画面を長時間見ているので、まだしもマシなほうで、もっと酷いのになると、匿名掲示板で誰が言ったかも分からない批評や評論を真に受けて、あたかも実際にプレイしたかのように表面を装う人たちすらも多くいます。

マンガ業界も同じ問題に気づいてるようです。マンガ『ラーメン発見伝』（小学館ビッグコミックスペリオール ）では、作中のライバル役のラーメン屋経営者（いわゆる「ラーメンハゲ」）が、ネットの情報をもとにラーメンの実際の食べたときの味を無視してラーメン評論をする自称ラーメンマニアに陰口で悪態をついています。これにリアリティを感じるマンガ出版社があるわけですから、つまりマンガ出版社の目からも、世間一般の人って多くがそういうネットの風評に左右される人達だよねと見られているわけです。

本wikiもネットの情報の一部なので、鵜呑みにしないでください。お金は掛かりますが、参考文献などとして記載されているゲーム関連に役立ちそうな書籍を、読者は実際に何冊か買って、書籍の実物を読むなどしてください。あるいは実際にゲーム制作やプログラミングをするなどして、確かめてください、


文献『ゲームデザイン プロフェッショナル』では、著者の塩川氏が言うには、口コミやレビュー、プレイ動画によって「知った気になる」ことを有害であると戒めています&lt;ref&gt;『ゲームデザイン プロフェッショナル』、P.282&lt;/ref&gt;。

だからゲーム作品を調査するなら、実際にクリアするまでプレイするか、あるいは十分なプレイ時間を投じてプレイしてみなければ、ゲームデザイナーにはあまり役立たないと、塩川氏は忠告しています。

たとえ短時間のプレイでは楽しく感じても、長時間のプレイや繰り返しの演出をされた場合には楽しくないような場合もあるので、だから長時間のプレイをして確認してみる必要があるとのことです。（以上、『ゲームデザイン プロフェッショナル』を参考にした。著作権の事情のため、言い回しや文体は多少は変えてある。）

ただ、これは一見するとゲーム作家には、「偏見なく自作を最後までプレイをしてもらえそう」とか思えそうですが、しかしプロの作家は暇人ではないので、同人ゲームまで含めて何でもかんでもプレイすることはできません。

塩川氏は、著作の別のページでは。若者に進めるゲームプレイとして、とりあえずゲーム業界志望なら、まずは人気作や、過去の人気作、自分が作っているゲームのジャンルに近いものを選ぶのが良いと言ってます&lt;ref&gt;『ゲームデザイン プロフェッショナル』、P280&lt;/ref&gt;。

これは裏を返すと、もし人気作や商業的な成功作でなければ、そもそもプレイすらしてもらえない、ということを意味します。塩川氏本人はそう言ってなくても、現実世界の時間は有限であるので、作品1つあたりのプレイ時間を延ばすことはつまり、1多くのプレイしてもらえない作品が生まれます。

つまり、塩川氏のプレイスタイルは、前提として、あるゲームについてプレイを開始するまでの条件が、めちゃくちゃ厳しいわけです。


イラスト業界でも類似の指南の事例があり、「アニメ私塾」といわれる有名イラストレーターは、YouTube動画などでプロのアニメ作品の模写の練習を進めていますが、しかし、おおむね発言内容「アニメ線画の模写ですら時間が何十分も掛かるので、練習に入る前にまず、その構図やデザインなどが自分にとって模写をする価値があるものかどうかを判定して、もし価値あると判定できた場合だけを模写しろ」と、判定にけっこう頭を使いなさい、と指南しています。

しかも「アニメ私塾」氏は、1枚の模写をどの程度まで模写すればいいかという質問に対しては「（模写先の手本に）似るまで模写しろ」とまで言っています。まるで、その1枚の手本を、模写のゲームクリアをするまで模写し続けるわけです。


さて、色々とゲームファンの問題点をいくつか前の段落で言いましたが、それでもゲームはアニメや漫画と比べるとまだしもマシであり、なぜならゲームではプレイヤーと、プレイしてない人たちの区別がしやすいからです。

これがアニメや漫画になると、もはや違法サイトで違法配布されたマンガを読んでるだけの人なのか、
実際に購入してプレイした人なのかの区別が困難になります。

実際、中国や韓国などでは、違法の無料配布されてしまったマンガがネットに溢れてしまった時期があり、
そのような事情もあり金融業界などはマンガ産業への投資を渋り、代わりに課金をしやすいオンラインゲームに投資をしたという経緯があります。
}}


文献『ゲームプランとデザインの教科書』によると、アナログゲーム（カードゲームやボードゲームなど）の設計の例ですが、ネット上の意見ではなく実際の目の前のテストプレイヤーの意見であっても、気を使ったりして本音を言わないことも多いので、意見や感想よりも実際のプレイを観察して、「プレイヤーがルールを勘違いしてないか？」など色々と観察するのが良いといわれています&lt;ref&gt;『ゲームプランとデザインの教科書』、P338&lt;/ref&gt;。

{{コラム|イナズマイレブンの人気投票呼びかけ事件|
イナズマイレブンという、男子小中学生くらいの子供をターゲットにした、サッカーのゲームおよびそのアニメ化作品があります。実際、ゲームなどでも平仮名を多用しているし、アニメなどでも振り仮名が多いですので、常識的に小学生くらいの子供がターゲットでしょう。

さて、このイナヅマイレブンの公式サイトが、ネット上での登場キャラクターの人気投票を行いました。


作品中で、「五条」（ごじょう）というマイナーな中学生キャラで、おっさんぽい顔のメガネで目が隠れて何を考えて分からない不気味な雰囲気の悪役っぽいキャラがいるのですが、ある有名な匿名掲示板のスレッドで、このキャラクターへの組織票の投票を呼びかけました。

その掲示板は、どう考えても子供が見ないような掲示板なのですが、しかし投票の結果、五条が一位になりました。

もし「ターゲット層の小学生の子供達が実は五条が一番好きだった」という理由ならそれでも構わないのですが、しかし投票の前後で「五条が子供に一番人気」という現象は特に観測されませんでした。「五条も子供に人気」という現象はあるかもしれません。ですが、「五条が子供に人気」という現象は結局は起きていないでしょう。


ネットの投票では、このような不合理な亊がたびたび起きます。

まず、年齢制限などをすることが不可能な場合が多いです。

また、本来なら「一人一票」などとしたくても、技術的な理由で不可能な場合もあります。

例えば、一人一票のために例えばツイッターなど外部サイトのアカウントを要求しようにも、しかし子供だとネット上のアカウント持つこと自体が不可能な場合もあります。たとえばツイッターの場合、年齢制限として13歳以下は利用不可能ですので、結果的に、小学生むけのアニメの人気投票をツイッターからの投票を呼びかけようとしても、技術的に不可能です。

アイドルグループのAKBなどでは、発売するCDに投票券などをつけることで、本当にカネを出して商品を購入したターゲット層だけが投票できるように工夫する場合もあります。ただし、AKB方式はこれで別の問題があり、一人の熱心なマニアが何票も投票したくて一人で何枚も同じ曲のCDを買うなどする、一般人とはかけ離れた購入行動をする事例があります。

また、アカウントなどを要求しない投票の場合、一日ごとに追加投票できてしまう場合があります。だから暇な人ほど、多くの投票をしてしまいます。

;「美人投票」
経済学で、「ケインズの美人投票」という理論があります。これは、金融における株の購入行動では、人々は自分が良いと思っている株を買うのではなく、世間が「この株は上がるだろう」と思っているだろうと予想した株を買うというものです。

ですが、この五条の投票の場合はもはや美人投票ですらありません。ネットのある集団が、自分たちのコミュニティをアピールするために、意図的に、子供からは美男子・美形・好印象だと思われないであろうと予想したキャラに投票しているわけです。まるで逆美人投票です。


;ノイジー・マイノリティ
世の中には、「口数は多い割には、人数は少ない」という集団があるのです。そのような集団を称して ノイジー・マイノリティ と言い、「うるさい少数派」という意味です。

しかし、うるさいだけの人に限って、企業などからは嫌われるので仕事がなかったりして、ネット上では口数が多いのです。

よく仕事や学生でも学校や家の軽作業などで、「口ばっかり動かしてないで、手を動かせ」などと年上から注意される事があると思いますが、まるでその逆の集団です。手を動かさない人は、口数でしかアピールできないのです。投票とは、そういう人にすら投票権を与えるという意味でもあります。

アニメやマンガなどの投票に関わらず、現実の政治の国会議員などへの投票でも、ある政治家へのネット掲示板などでの賛同は多いが、しかし実際に選挙をしてみると支持票がそれほど多くないという事例もよくあります。

また、暴力団などでは「総会屋」と言って、企業の株を少数でいいので購入し、株主総会での意見をよそおって、難癖をつけるぞとおどすことで、金品を要求するという手口も平成初期までは、よくありました（現在は規制されており、総会屋しづらくなっています）。一株など少数の株でも発言できてしまうので、こういう悪事が出来てしまったのです。
}}

文献『レベルデザイン徹底指南書』では、現実世界で自分が新しいスキルを1つ覚えたら、古いスキル1つはどれか封印する必要があることを説いています。たとえば会社で自らの希望によってグラフィッカーからプランナーに役職が変わったら、グラフィッカー時代のスキルは封印する必要があります&lt;ref&gt;大久保磨『レベルデザイン徹底指南書』、2016年12月14日 初版 第1刷発行、P81&lt;/ref&gt;。（参考文献では「デザイナー」と言ってますが、デザイナーは多義語でありイラストレーターの他にも開発リーダーなどの事を言う場合もあるので、本セクションでは「グラフィッカー」に言い換えた。）プランナーがグラフィッカーの仕事まで掛け持ちしたら、過労死してしまいます。

現実世界の仕事では時間が限られているので、そういうスキル封印が必要なのです。

{{コラム|一人で何でもできるか?|
「と学会」の人が2010年ごろにニコニコ生放送の番組に出演したときに言ってたのですが、どこかのマンガ出版社に対して、「と学会」のその人はマンガ原作者にネタ提供したことあるとの事です。

大衆は、漫画家を一人で何でもできる万能の人だと錯覚したいので、そういう大衆を喜ばせるために、アドバイザーが隠れて、漫画家の知らないネタでしかも読者にウケそうなネタのアイデアを提供をするのです。マンガ作品のクレジットには書かれませんが、そういうビジネスがあります。

もっとも、業界によってはアドバイザーがクレジットに記載される場合もあります。たとえばテレビドラマやアニメなどだと、「考証」や「監修」などで、関連するジャンルの専門家がアドバイスすることもあります。たとえばNHKの歴史大河ドラマなら、東大あたりの大学教授で歴史学教授といったプロの歴史学者が、監修についている場合もあります。

アニメではそこまで行かなくても、ミリタリー物のアニメなどで、実際に銃器を仕事であつかった経験のある人が監修をついていたり、軍事雑誌の記者などが監修についたりとか、そういうこともあります。
}}


{{コラム|可処分時間|
21世紀のビジネス用語で「可処分時間」という概念があります。

もともと「可処分所得」という経理などの用語があり、
「可処分所得」とは労働者が給料のうち、税金や社会保険料など支払いが義務付けられているものを差し引いた、
残りの（法的には）自由に使えるぶんの金額です。

実際には、水道光熱費といった公共料金など自由といえるかどうか分かりませんが、この議論では本質的ではないので深入りしないでおきます。


さて、可処分時間とは、可処分所得になぞらえて、可処分時間とは、おおむね、「1日のうちの自分の起きている時間のうち、労働時間などを差し引いた、残りの自由に使える時間」という意味です。


可処分所得に限りがあるように、可処分時間にも限りがあります。だから、商売の競争とは、消費者の可処分所得の奪い合いであると同時に、消費者の可処分時間の奪い合いでもあるのです。

1つの他人の作品に投じる可処分時間を増やしたら、当然ですが、他の作品への可処分時間の投入量が減ります。

こういう厳然たる事実があります。「可処分時間」という用語までクリエイターが覚える必要はないでしょうが、しかし消費者の時間に限りがあるという事実からは決して逃げることができないのです。しかもよく評論で「エンタメ界隈は、可処分時間の奪い合いの産業である」とも言われます。

クリエイターだって時間に限りがあります。たとえば、休日にもし自主制作の作品をつくっていたら、当然ですが、他人の作品を鑑賞する時間は減ります。
}}

=== クリア保証と戦術性のジレンマ ===
==== クリア保証 ====
ドラクエのレベル成長のシステムは画期的であり、どう画期的かを一言でいうと「クリア保証」である&lt;ref&gt;[https://news.denfaminicogamer.jp/column05/170905b　『「レベルを上げて物理で殴る」の素晴らしさをゲームデザイナー視点で語ろう。ドラクエで学ぶ「RPGメカニクス」の3大メリット【ゲームの話を言語化したい：第四回】』2017年9月5日 16:30 ] 2020年12月21日に閲覧して確認.&lt;/ref&gt;。どういう事かというと、参考文献のリンク先の記事にも書いてあるが、ファミコン以前の1980年代のアーケードゲームではプレイヤーが上手い操作を学習しないとクリアできなかったが、しかしファミコン以降の家庭用RPGでは、プレイヤーの興味ないことは学習しないでも、代わりにレベル上げなどに多少の時間を掛ければゲームクリアできるようになったのである。

たとえば、プレイヤーが攻略法のわからないダンジョンでも、最悪の場合でも経験値かせぎに多少の時間を掛ければ、そのダンジョンのボスを倒せるなどして、かならず最後にはゲームクリアが出来る、というような事でもある。

その他の例では、たとえばゲーム終盤になってから未探検だった序盤の一部ダンジョンを冒険する際、プレイヤーには既にもっと難しいダンジョンを冒険してるのでその未探検ダンジョンから学習できることは少ないが、プレイヤーキャラのレベルが高いために未探検の序盤ダンジョンの敵はプレイヤーにはすでに弱くなっているので、その残っていた未探検ダンジョンにあまり苦労せずに時間を掛けなくてもダンジョンクリアできるように、難易度が上手い感じに自動調節&lt;ref&gt;[https://news.denfaminicogamer.jp/column05/170905b　『「レベルを上げて物理で殴る」の素晴らしさをゲームデザイナー視点で語ろう。ドラクエで学ぶ「RPGメカニクス」の3大メリット【ゲームの話を言語化したい：第四回】』2017年9月5日 16:30 ] 2020年12月21日に閲覧して確認.&lt;/ref&gt;されるなど、RPGのレベルシステムおよび類似システムにはそういった側面もある。


要するに、
:* クリア保証、
:* 難易度の自動調整機能、
の2つが、ドラクエ的なレベルシステムの面白さの本質的・醍醐味であるとのことである。


リンク先の人の意見ではないが、このクリア保証のないデザインのRPGは（RPGでも古いゲームやフリーゲームなどで時々みかける）、表面的にはドラクエ的なインターフェースやステータス画面であっても、中身は似て非なるものであろう。

ファミコン時代の古いゲームなどのバランス調整の失敗（作者にとっては意図的かもしれないが）でよくある失敗として、レベルの上昇の上限を低いところに設定しすぎて、クリア困難になる事例があった（ドラクエ2がそれに近い）。なので、現代への教訓としては、そもそもレベル制限は十分にとるのが安全であろう。


RPGに限らず一般に、ゲームの後半に行くに従って、次ステージ攻略などのための事前準備の増加や、試行錯誤の時間の増加に時間のかかるようになっていく事が多い。そして、ステージクリアに必要な時間の増加が、ゲームを苦手とするプレイヤーに、そのゲームのクリアを諦めさせて挫折感を味あわせてしまう原因になる場合が、少なからずある&lt;ref&gt;[http://endohlab.org/paper/whydoplayersdrop.pdf  遠藤雅伸『ひとはなぜゲームを途中でやめるのか？－ゲームデザイン由来の理由－』6.まとめ] 2020年12月21日に閲覧して確認. &lt;/ref&gt;。

=== 自由度 ===
文献『ゲームクリエイターの仕事』（翔泳社）によると、一本道のゲームではなく攻略ルートが複数あって自由度があるゲームの場合、それら複数のルートも考慮する必要があります。ゲームの自由度が多くなれば、その「場合の数」に応じて、調整の際に考慮する事項も増えます&lt;ref&gt;『ゲームクリエイターの仕事 イマドキのゲーム制作現場を大解剖！』、P78&lt;/ref&gt;。


=== 勉強の方法論 ===
※ バランス調整に限った話題ではないが、他に適した単元が見つからないし、メインページに書くほどでもないので、間借り（まがり）的にバランス調整のページで書くことにする。

==== 共通言語 ====
ゲーム業界人たちは商売人なので、いろんなゲームをプレイするように推奨します。しかし現実には、それは費用的にも時間的にも不可能です。

商業ゲーム会社でゲームデザイナーになりたいのなら、人気作のゲーム知識は必要です。手本とするためという理由の他にも、スタッフなどに開発コンセプトなどを説明するためにも過去作のゲーム知識が必要になります」（いわゆる「共通言語」）&lt;ref&gt;『ゲームデザイン プロフェッショナル』、P278&lt;/ref&gt;。

とりあえずゲーム業界志望なら、まずは人気作や、過去の人気作、自分が作っているゲームのジャンルに近いものを選ぶのが良いといわれています&lt;ref&gt;『ゲームデザイン プロフェッショナル』、P280&lt;/ref&gt;。

==== 前後比較 ====
ゲーム制作において、人気作や人気シリーズを、手本の中心にすえる必要があるが、しかし、けっして人気ゲームだけをマネしようとしてはいけない。名作が名作である意義を確認するためには、同時代の他社の作品や、それ以前の過去の作家の作品に、どういう欠点があったを把握する必要がある。そうした前後関係の比較により、理解が深まる&lt;ref&gt;[https://news.denfaminicogamer.jp/interview/200615a/3 吉田寛・松永伸司『“ゲームらしさ”をもっと深く語りたい！そんなあなたのためのゲームスタディーズ入門』、電ファミニコゲーマー、2020年6月15日 12:02 ] 2020年11月27日に閲覧して確認.&lt;/ref&gt;。

なお、同様のノウハウはアニメ研究の業界でも1990年代から語られており、たとえばアニメ評論家の岡田斗司夫や氷川竜介などが、絶版になってしまったが岡田らの共著『国際おたく大学―1998年 最前線からの研究報告』などの書籍の中で例を述べており&lt;!-- 手元にその本が無いので、もしかしたら別の著作かもしれないが、岡田らの共著のどれかではある。 --&gt;、たとえばアニメのガンダム初代がリアリティゆえに名作であることを評論したいならば、それ以前の時代のロボットアニメが如何にリアリティが欠けていたかを実際にビデオなどで視聴するなりして確認しなければならないと岡田・氷川らは述べていた。

ともかく、ゲームでも、名作ばかりプレイしていてもダメであり、つまり知名度だけでプレイするゲームを選んでいては、他のクリエイターに利用されて養分になるだけであろう。


岡田斗司夫と「と学会」の著作した『 岡田の国際おたく大学―1998年 最前線からの研究報告』では、書籍中で、ゲーム作家を経験した演劇作家の鴻上尚史（こうがみ しょうじ）の失敗例を東大生が取材したレポートを紹介しているのですが、岡田がそのレポートを評して言うには、おおむね「成功例から学ぶたがる人は多いが、しかし成功例だけから学ぶのは素人。プロは失敗例にこそ学ぶ。」というような感じのことを言っています。

工学の世界では、『失敗学』という概念が畑村洋太郎によって提唱されており、2002年の畑村の論文&lt;ref&gt;[https://www.jstage.jst.go.jp/article/jjlp1960/43/2/43_2_182/_pdf  『失敗学のすすめ』]&lt;/ref&gt;や、2000年には畑村の著作『失敗学のすすめ』が出版されています。
（wikipedia日本語版には「2005年」に出版とあるが、間違いである。2002年の論文で、2000年の畑村の著作が参考文献とされている&lt;ref&gt;[https://www.jstage.jst.go.jp/article/jjlp1960/43/2/43_2_182/_pdf  『失敗学のすすめ』]&lt;/ref&gt;。）

実は、2000年よりも前に、ゲーム産業限定ですが岡田が「失敗にこそ学ぶべき」といった内容のことを提唱しています。なお、畑村の論文の末尾の参考文献欄には、『 1) 畑村 洋太郎 編 著:続・続 実際の設計― 失敗に学ぶ .日刊工業新聞社,1996.』とあります。

{{コラム|失敗とスポーツの例え話|
ビジネス書で昔からよく言われるのですが、新しいことへのチャレンジには失敗はつきものです。

でも、新しいことにチャレンジして経験を蓄えることが、今後の成功につながるのです。もし失敗をおそれて新しいことにチャレンジしなくなったら、もはや次の成功にはつながりません。

失敗しないけれど成功もしないで市場から淘汰されることになるよりも、失敗してもいいのでそれ以上の大成功をおさめて市場で行き続けることができればいいのです。

よくビジネス評論ではスポーツに喩えられるのですが、スポーツのサッカーや野球などの試合にたとえれば、3点を奪われても、こちらが5点を得て結果的に勝てればいいのです。

逆に、1点しか奪われなくても、こちらの得点が0点なら、試合には負けます。

だから、「試合での負け」に相当するような致命的な失敗さえ、回避できればいいのです

「たとえ失敗しても、試合に負けなければいい」のです。「失点しても、試合に負けなければいい」のです。

塩川氏も、失点しても試合に勝てれば良いという内容のことを書籍で発言しています&lt;ref&gt;『ゲームデザイン プロフェッショナル』、P.334&lt;/ref&gt;。

さて塩川氏の著作では、失点でない単なる「ミス」を「不具合の発生」、「失点」をユーザーの不利益、「負け」を「売り上げの低下やユーザーの離脱」（長いので抜粋）などと定義しています。


塩川氏の意図は分かりませんが、少なくとも新しいことにチャレンジすれば、未知の失敗は起きますので、ITソフト業界なら、それによる不具合の発生が起きます。

その不具合の結果、ユーザーに不利益が一時的に生じることはあります。しかし、そういう一時的な不利益は、新分野の開拓では避けられません。

ユーザーで実験する前の、最低限の手元や仲間内での実験は必要でしょうが、しかし未然の実験で今後のすべてのミスを防止することは不可能です。
}}

=== 異業種の立場を想像しよう ===
ゲームにかぎらず、文芸でもイラスト趣味でも、、狭いコミュニティ内の内輪ウケばかりに特化していって衰退していっている文化は多い。そうならないように気をつけよう。

内輪受けのマニア化による初心者忌避による衰退をうまく表現できている言い回しとして、プロレス業界の格言ですが「マニアが業界を潰す」という格言があります。なお、この発言は2012年に新日本プロレスリングを買収したゲーム会社のブシロードが買収時に述べた発言「すべてのジャンルはマニアが潰す」が元になっているので、まさにゲーム業界の反省にもとづく考察でもあります&lt;ref&gt; [https://newspicks.com/news/4135958/body/  『【最終話・木谷高明】すべてのジャンルはマニアが潰す』 2019/10/5 ] 2021年11月7日に確認&lt;/ref&gt;。（ブシロードの文脈とは違うかもしれませんが（出展の外部リンク先が有料なので読んでいないので）、本wikiでもおそらく後述していますが、ゲーム業界では1990～2000年の一時期、ジャンルによってはゲームが高難易度化した作品が多くなって、そのため新規参入者が苦手と感じてプレイヤーが減って衰退縮小していったジャンルが幾つかありました。）

なので、ゲーム製作のこういった予備知識のないファンコミュニティの意見ばかりを鵜呑みにして聞いていると、初心者を遠ざけた高難易度ゲームと化してしまうおそれもあります。

特にゲームセンターにある対戦格闘ゲームでは、「初心者狩り」といって、初心者が筐体で練習したくても、熟練プレイヤーが参入して初心者を負かして初心者がゲームプレイヤーになるので、初心者は練習できない。・・・その結果、気がついたらそのゲームの新規参入層が減っていった・・・という事例がありました。

ゲームにかぎらず、スポーツなどの競技の人気でも、似たような現象が見られます。競技というジャンル自体が技巧などを競うものなので仕方ない面もありますが、なんとかして初心者を遠ざけない工夫はゲーム屋には必要でしょう。

ともかく、上述のような色々な理由で、作家側は、体感の難易度が、本当は難しめのゲームなのに「やさしめ」に感じがちである。

実際、日本のゲーム史でも、1990年代の前半ごろは、ゲームの難易度が「むずかしめ」に調整されがちであった。しかし、その結果、世間では「最近のゲームは難しい」と感じる人が増え、日本のゲーム人気は一時期、衰退し、アニメ産業などに人気を取られる事態になった。

{{コラム|作者は答えを知ってしまっている|
バランス調整とは少し違いますが、作者はネタバレを知ってるので、シナリオに感動できないわけです。

これは、ハドソン（ゲーム会社名）の『新桃太郎伝説』（スーファミ版）の攻略本『新桃太郎伝説　究極本』（KKベストセラーズ 刊）で、作者の　さくま　あきら　が、読者インタビューに答える形でそう言っています。

ゲーム雑誌での読者からの「ゲーム中、もっとも印象に残ったシーンはどこですか？」という旨の質問に対し、さくま氏は「作者はシナリオの答えを知ってるので、もっとも印象に残るとかそういうのはありません」的な内容の返答をしています。
}}


;ティッシュテスター
さて、作者バイアスでバランスが分からなくなるのは作者だけではなく、テストプレイヤーやデバッガーも、そのゲームに慣れてゆくと、次第に感覚が一般プレイヤーとズレていき、テストプレイヤー達もゲームの適切なバランス側が分からなくなっていく。

このことを比喩した表現として、「ティッシュ テスター」（tissue tester）という用語がある。使い捨てティッシュが1枚あたり1度しか使えないように、そのゲームに予備知識の無いテスターも、一度しか使えないのである。「フレッシュミート」（新鮮な肉、fresh meat）とも言います。

かといって、テストプレイヤーの人数にも限りがあるので、ゲーム作者は、たとえ自作ゲームのバランス調整が不完全でも、最低限の調整をしたら、もう「えいやっ」と（フリーゲームや同人ゲームなら）ゲームのver1.00および以降バージョンを出さざるを得ない。

単にバグを探すだけのデバッグ用テストならティッシュテスターでなくても可能ですが、しかしバランス調整ではティッシュテスターがいたほうが効率的です。


=== 要素の相互関係 ===
==== 概要 ====
文献『ゲームデザイン プロフェッショナル』によると、調整は、関連あるものを、まとめて同時期に、ただし1個ずつ調整していきます&lt;ref&gt;『ゲームデザイン プロフェッショナル』、P.182&lt;/ref&gt;。                                                                                                                    
このため、まだ関連ある要素を実装しきっていない段階では、調整しません。だから開発の最初から調整することは、まず無いでしょう。

しかし、場合によっては、要素の実装をそろうの待つと調整開始の時期が遅くなりすぎてしまい、計画に支障が出る場合があります。そういう場合、ある程度のまとまりのある実装ができた段階で、調整をするようです。

具体的な調整の判断基準については、参考文献『ゲームデザイン プロフェッショナル』を買ってお読みください。

もし読者が練習として、てっとり早くレベルデザイン・バランス調整の経験を積みたい場合、角川書店（現: KADOKAWA）の『RPGツクール』という制作ツールで実際にゲームを作ってみるのが良いでしょう。文献『レベルデザイン徹底指南書』（大久保磨 著）でも、RPGツクールによる練習・勉強を進めています&lt;ref&gt;大久保磨『レベルデザイン徹底指南書』、2016年12月14日 初版 第1刷発行、P81&lt;/ref&gt;。


==== マップと敵の相互関係 ====
ゲームバランスを決めるのは、敵の強さだけでなく、マップの構成、さらにRPGのダンジョンなら宝箱の中にあるアイテムや装備品の強さ、などなどのさまざまな要素が加わります。

宝箱もマップの構成要素ですから、広い意味では宝箱もマップだとすると、つまり敵そのもののの強さだけでなく、マップもバランス調整に大きく影響します。だから、もし仮に時間が無限にあるのなら、理想的には、ダンジョンなど各ステージののマップが実装されてからバランス調整を行うのが理想でしょう。

しかし、実際には、マップの実装は、なかなか時間の掛かることです。特に、マップを考えることは、そのステージの世界観などを考えることでもあるので、そういった理系的ではない文系的なことも考えなければなりません。

マップに敵を組み込む方式で調整する場合だとマップの実装を待っている間にはバランス調整が出来ないのも、なかなか難しい問題です。

だからマップと敵の調整の順序は、おそらく人や会社によって色々な方式があると思います。たとえば、
:マップを作ってからそのマップに敵を組み込んでみてプレイしてみて、敵の強さを決めるのか、
:それとも敵の強さを決めてから、マップを決めるのか、
:あるいはマップと敵を別々に決めてから、最後に組み合わせて微調整するのか、
などなどです。

ご自身の作品にあった方式をお選びください。

===== 始めよければ全てよし =====
さて、ゲームが長編になる場合、まずはプロトタイプ的に、序盤をやや多めに通しプレイをして、とりあえず序盤のバランスがゲームとして面白くなるように調整すると良いでしょう。

書籍『ゲームプランナー集中講座』でも、ゲームの初めと終わりの印象がよければ、途中のバランスが少しくらい悪くても楽しんでもらえると述べています&lt;ref&gt;『ゲームプランナー集中講座』、P236&lt;/ref&gt;。

:※ なお、アニメ産業でも、実はテレビアニメは、第1話と最終話だけ、他のエピソードよりも予算が多めに作られるのが普通です（特に公言はされてないが、多くの作品で明らかにクオリティが違う場合が多い）。

とはいえ、ゲーム制作当初は、そもそも終盤のストーリーがまだ未完成だったりするので、意図せずとも、こういったプロトタイプ的に序盤をやや多めに調整する方法が自然に行われる事になるでしょう。

商業作品でも、たとえば攻略本やファンブックなどに書いてあるゲーム開発裏話などを見ると、RPGでは、（プレイヤーからは数値の見えない）敵の強さのほうを動かすことで、バランスを調整するという事例などもよく紹介されています。よくある話が、最終ボスなどの能力値です。原理的には、敵側の能力値ではなく、味方の能力値で調整したり、あるいは装備品で調整したりしてもイイはずですが、しかしよく開発裏話に出てくるのは、なぜか敵側の能力値の話題ばかりです。

たとえば、スーファミRPG『新 桃太郎伝説』では、最終ボスのパラメータのほうを調整していることが、KKベストセラーズ（出版社名）から出た攻略本『新桃太郎伝説究極本』に書かれています。（調整前はボスはもっとHPが多かった。）
:※ただし、あくまでRPG限定の話題。アクションゲームなどでは、違うかもしれない。


また、こういった調整順序の前提として、調整はゲーム序盤から順番に、ゲーム後半に向かって調整していくしかありません。

そのため、古いゲームなどでは、よくゲーム後半で、調整不足のために、極端に難しかったり、あるいは逆にあっけなく簡単すぎる後半だったりなどの話題も、よく聞きます。ドラクエ2の後半ダンジョンであるロンダルキア洞窟とその次ステージが典型です。

さて、プレイヤーに目立つ部分（たとえば味方キャラの能力値や装備品の性能など）を基準にして調整するといって、けっして全く数値をイジラないというワケではないのです。あくまで、（調整による変動幅の大きい敵能力値と比べたら、）「比較的には、味方キャラ関連の数値は、調整による数値の変動の幅が小さめ。敵の能力値は、調整による変動の幅が大きい。」という事にすぎません。


{{コラム|ノイマン「ゲーム理論」で説明できないのがテレビゲーム|
日本の人類学者の中沢新一は、ノイマンのゲーム理論で説明できないのが昨今のコンピュータゲームの特徴だと言っています。その発言の出典は忘れたのですが、人類学者で有名な中沢新一は近年、ゲーム産業に関心を持ち、たとえばナムコ出身の遠藤雅信などとも対談しています&lt;ref&gt;https://news.denfaminicogamer.jp/kikakuthetower/nakagawa-endo_bb/2   『ゼビウスからポケモンGOまで… 国内ゲーム史を遠藤雅伸氏と『現代ゲーム全史』著者が振り返る。中沢新一氏も壇上に登場！【イベントレポ】』 2017年4月12日 12:30 公開 ] 2022年1月18日に確認. &lt;/ref&gt;。（なお、リンク先イベント記事の司会役の「中川」氏とゲストの「中沢」氏は別人なので、混同しないように）


ゲーム理論の用途としては、現代日本の学問では、政治的局面での外交戦略などを語る際によく政治学書で用いられたりします。ただし、そのゲーム理論でも、中沢新一によると、それでコンピュータゲームを語るのは不足だという事です。

中沢は特に言及していないですが、数学的にモデル化するなら、政策応用なら「国際情勢」など外交的な制約によって出力にとりうる値1個あたりの幅や個数が2～3個に限定されたりのような、値の個数が十分に小さくて有限の整数個の場合でないと、なかなかゲーム理論の応用は効果を発揮しません。

（20世紀の天才数学者 フォン・ノイマンの）『ゲーム理論』のような出力値に選べる個数が極端に少ない理論は、コンピュータゲームの調整では不足でしょう。本ページでも、ノイマンのゲーム理論については、版にもよりますが、このコラム以外では特に言及していないだろうと思います（2022年1月までの時点では、ノイマンのゲーム理論には言及していない）。

さて中沢の意見ではないですが、そもそもゲーム理論についてノイマンについての出典として、たしか数学者の森毅（もり つよし）のエッセイ本だったと思いますが、ゲーム理論はもともとノイマンが第二次大戦中の亡命中か何かにトランプのポーカーを参考に考えついたらしいです。


ネット上のゲーム評論では、経済由来の表現でよく使われる表現は、ゲーム理論ではなく「インフレ」「デフレ」などといった表現です。

経済学を知らなくてもゲームは製作できるでしょうが、どうしても経済学を参考にするなら、ゲーム理論よりも物価政策のほうを勉強したほうが良いかもしれません。

一応、書籍『ゲーム作りの発想法と企画書の作り方』ではゲーム理論も紹介されていますが、しかし具体的にどうゲーム作りにゲーム理論を応用するかは書かれていません&lt;ref&gt;『ゲーム作りの発想法と企画書の作り方』、P64&lt;/ref&gt;。
}}

=== 各論（デザイン的なこと） ===
どの程度、レベル上昇でキャラクターを強くすればいいかについては、ハドソン社あたりでの有名な慣習があり、新しく訪れたダンジョンなどでは「レベルが3上がると、敵を1撃で倒せるようにすべし」という有名な基準があります&lt;ref&gt;『ゲームプランとデザインの教科書』、P.94、 ※ 著者のひとりの「平川らいあん」氏はハドソン出身&lt;/ref&gt;。他社ゲームでは別かもしれませんが、だいたいスーファミ時代の桃太郎伝説シリーズはこんな感じに調整されているはずです。

== RPGのダメージ計算式 ==
=== 特化型が有利になりやすい ===
文献『ゲームプランとデザインの教科書』によると、ファミコン時代のゲームに限らず、21世紀の現代的なゲームでも、「なんでも平均的にできる」キャラクターよりも「○○だけなら自分が一番強い」といった感じの特化型のキャラクターが戦闘では強くなりやすい傾向があります&lt;ref&gt;川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日 第1版 第1刷、P.227&lt;/ref&gt;。対して、バランス型は「器用貧乏」になりやすいのが現状です&lt;ref&gt;川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、、2018年11月1日 第1版 第1刷、P.227&lt;/ref&gt;。

なお文献『ゲーム作りの発想法と企画書の作り方』によると、ダメージ計算式を考えるのは（プログラマーの仕事ではなく）ゲームデザイナーの仕事です&lt;ref&gt;『ゲーム作りの発想法と企画書の作り方』、P145&lt;/ref&gt;。


では、特化型が有利になりやすい原理を、これから説明していきます。

たとえば、キャラクターに能力をプレイヤーが自由に選んで振り分け配分できるシステムのゲームがあったとしましょう。（商業ゲームでも、いくつかの作品で、似たようなシステムのRPGがあります。）

説明の単純化のため、合計値が必ず100だとしましょう。

つまり、たとえば下記のようになります。

;作成キャラの能力例
:（※ 合計100）
 ちから: 10
 たいりょく: 30
 しゅびりょく: 10
 すばやさ: 40
 きようさ: 10


さて、別の作成キャラ例を考えます。

;平均型キャラA
 ちから: 20
 たいりょく:20
 しゅびりょく: 20
 すばやさ: 20
 きようさ: 20
:（※ 合計100）

のように、能力値を平均にふりわけたキャラクターと

合計値は同じですが、特定のパラメータに特化して能力値を振り分けした

;特化型キャラB
 ちから: 40
 たいりょく:20
 しゅびりょく: 30
 すばやさ: 5
 きようさ: 5 
:（※ 合計100）

のようなキャラクターを、

コンピュータ上でRPGの戦闘システムのアルゴリズム上で対戦させた場合、

ほとんどの20世紀のRPGのアルゴリズムでは、特化型のキャラBのほうが勝ち、つまり特化型のほうが強くなってしまいます。

さらに言うと、たいてい「攻撃力」のような、敵にダメージを与える意味のパラメーターに振り割ったほうが、キャラクターが強くなるゲームのほうが多いです。（ファミコン時代から、ウィザードリィ1の攻略本でそういわれていました。敵モンスター『ワイバーン』あたりの攻略法として「攻撃は最大の防御」という格言を出しています。表紙の黒かった攻略本なので、たぶんゲームアーツの本。『ウィザードリィ攻略の手引き』(MIA BOOKS)かと思われます。）

なぜこうなるかと言うと、なぜなら、もし攻撃力が上がると、敵を倒すのに要するターン数も減少するので、結果的に敵を倒すまでに自キャラの受けるダメージ量も減るからです。（なお、現実の軍事学でも、似たような事が言われており、戦術論ですが、クラウゼヴィッツ（近代ドイツの軍事学者の一人）は防御重視の作戦よりも攻撃重視の作戦のほうが有利だと述べています。防御だけで攻撃しなければ、現実でもゲ－ムでも戦闘では絶対に勝てません。）


裏を返せば、平均型能力のキャラは、多くのゲームシステムでは弱くなりがちです。

パラメータの振り分けは自由ではないですが、ドラクエ2（ファミコン版）でいう、サマルトリア王子が弱くなる現象です。ファイナルファンタジー3・5の赤魔導師も、似たような弱点を抱えています。


理由はいろいろとありますが、バランス側の弱くなりやすい理由のひとつとして、参考文献などは特には無いですが、
:・ウィザードリィやドラクエなどの古いRPGのアルゴリズムが、特化型に有利になっているという歴史的な経緯。
:・命中率などの確率に関わるパラメータ（「器用さ」）のある場合、パラメータ割り振り前から既にある程度の底上げ補正がされている場合が多いので、わざわざ命中率を上げると割り損になる。
:・「すばやさ」（素早さ）が攻撃の順番にしか影響しない場合、素早さが低くても1ターンに1度は攻撃できるので、素早さを上げると損。
などの理由があるでしょうか。


命中率に関しては、多くのRPGで、攻撃が外れるのは、プレイヤーに不満感を与えるので、たいていのゲームでは、ゲーム序盤のレベル1のキャラであっても、数値上での「命中率」や「器用さ」などの表向きの命中率が低くても、たとえば「命中率 40」と表示されていても、実際のゲーム内部での命中率はたとえば＋20%されてて本当の命中率が60%だったりするような場合もあります。


このような底上げ命中率のあるシステムだと、20%底上げされる場合、命中率を80%以上に育てるのは損です。なぜなら100%以上には上がりようが無いからです。

命中率が101%以上の場合に特殊な追加スキルなどを獲得できるなら別ですが（たとえば、クリティカルヒットの確率がけっこう増えるとか）、たいていの古いゲームでは、そこまでの手入れをしていません。おそらく調整に時間が掛かるからでしょう。

=== ダメージ計算式 ===
さて、RPGの戦闘におけるダメージの計算式（「ダメージ計算式」といいます）に、アルテリオス計算式というのがあります。これは、昔のゲーム『アルテリオス』で採用された計算式なのですが、
 攻撃側の攻撃力 － 守備側の守備力 ＝ 守備側のダメージ
という計算式です。

ドラクエやファイナルファンタジーのシリーズの計算式はもっと複雑なのですが、どのRPGでもダメージ計算式の基本的な設計思想・方針はアルテリオス計算式と同じです。


アルテリオス以外のダメージ計算式でも、たとえば
:1.3×攻撃側の攻撃力 － 0.75 × 守備側の守備力 ＝ 守備側のダメージ
というような感じの計算式である作品も多いです。

せいぜい、変数の前に定数係数が掛かっている程度です。

なぜ、どの会社のRPGでも、この程度の中学校レベルの単純な計算式なのかというと、バランス調整が簡単だからです。

バランス調整するのは人間なので、もし、ダメージ計算式があまりに複雑な方程式であると（たとえば量子物理のシュレーディンガー方程式みたいなのだったりすると）、そもそもバランス調整担当の社員が理解できません。


そして、このアルテリオス式を見ると分かるのですが、
:攻撃側の攻撃力 － 守備側の守備力 ＝ 守備側のダメージ
もし自軍の攻撃力が0の場合、敵にダメージを与えられないので（ダメージが0）、絶対に負けてしまいます。つまり、攻撃力が敵の守備力を下回る場合も、絶対に負けるのです。

一方、「すばやさ」パラメータが戦闘の先攻/後攻の順番にしか影響しない場合、素早さが0であっても、勝つことは可能です。

また、守備力が0であっても、勝つことは可能です。

このように、パラメータの種類ごとに、そのゲームにおいて重視・軽視の差があり、不公平になっている事が多いのです。


また、バランス型の能力値のキャラクターの場合、せっかく「ちから」を上げて攻撃力を上げても、守備側の守備力を下回っていると、ダメージ0になってしまい、絶対に負けます。

つまり、
 自分の攻撃力 ＞ 敵の守備力
でないと、アルテリオス式では必ず負けるのです。


一方、
:1.3×攻撃側の攻撃力 － 0.75 × 守備側の守備力 ＝ 守備側のダメージ
のように係数を掛けた計算式の場合、

守備力を1ポイント増やしても、その効果は25%減少されます。（たとえばレベルアップの際に上昇パラメータを一種類選べるシステムの場合、守備力を選ぶと損になる場合が多い。）

いっぽう、攻撃力を1ポイント増やすと、効果は30%増しです。

このように、計算式によって、有利/不利なパラメータという格差が生じます。


=== DPS （Damage Per Second） の概念 ===
:※ 出典は無いが、あまりに有名な概念なので、さすがに消さない。

最近のRPGゲームには攻撃コマンド選択時に「二段斬り」などのスキル選択ができます。

スキルを設計するとき、昔の初心者のやりがちなミスとして、最近は減ってきましたが、スキルの結果の見かけの数値にゴマかされて、実はスキルが強くなってない特技を設計してしまうミスが時々ありました。

たとえば典型的なのは特技『ためる』です。これは、次回ターン時のダメージを数倍に倍増し、次回ターンの1回だけ、ダメージを倍増させる特技です。

この『ためる』は必ず、次回ターン時のダメージが2倍を超えないと（たとえば2.5倍にならないと）、無意味です。

なぜなら、『ためる』コマンドを選択したターンは、攻撃をしてないからです。


つまり、スキルを使わずに普通に2ターン通常攻撃した場合、ダメージ量は単純計算で
:1+1=2
より、2ターンぶんのダメージです。

いっぽう、『ためる』コマンドを使えば、それがもし2倍しかダメージが倍増しない場合、
:0+2＝2
で、結果は同じ通常攻撃2発ぶんのダメージのままです。


計算すれば子供でも分かる理屈ですが、しかしファミコン時代には市販の商業ゲームですら、こういうミスがありました。たとえばファイナルファンタジー3の職業『空手家』のスキル『ためる』です。


このようなミスを犯さないために必要な概念としては、'''DPS''' （'''D'''amage '''P'''er '''S'''econd） の概念が便利でしょう。DPS とは1秒あたりのダメージ量、という意味です。

もともと欧米のアクションゲームについての理論研究に由来する用語なので、単位が 秒 （second）になっていますが、RPGに応用する場合には単位をターンに変えるなどして工夫しましょう。


このDPSの概念を使って、上述の『ためる』コマンドの設計ミスを説明すれば、つまり、1ターンあたりのダメージ量（DPS）が上昇していないのが問題点です。


では、私たちが改善策を考えましょう。数学的に考えれば中学レベルで充分で、
: 0 + x ＞ 2
を満たす変数xを設計するだけの問題です。

なので、たとえば、『ためる』後の攻撃ダメージ量を「2.5倍」とか「3倍」とかの数値に設計すればいいのです。


では、次に応用問題を考えましょう。

「『ためる』を2回続けると、さらにダメージ量がアップ」などのシステムを導入するときも、必ずDPSが増えるようにしましょう。

たとえば、この場合、ダメージを与えるのに最低3ターンが必要なので、不等式を考えれば、

変数xについての
:0 ＋ 0 ＋ x ＞ 3
を満たさないといけません。


つまり、『ためる』2回後のダメージ量は、最低でも「3.5倍」のように3を超える数値、あるいは整数に限定すれば、たとえば「4倍」とか「5倍」とかになっている必要があります。

== KPI ==
Key Performance Indicator という経営的な指標があり、『レベルデザイン徹底指南書』P140 および 『ゲームプランとデザインの教科書』P70 によると、共通しているのは後述の内容です。なお、『ゲームプランとデザインの教科書』P67 によると、オンラインゲームの運営などで使われる用語ですが、別にゲーム業界限定の用語ではありません。


;DAU（Daily Active User） 
:デイリー・アクティブ・ユーザー

DAUとは、その日に遊んでくれたユーザーの人数です。


;MAU（Mathly Active User） 
:マンスリー・アクティブ・ユーザー

MAUとは、その月に遊んでくれたユーザーの人数です。


;WAU（Weekly Active User） 
:ウィークリー・アクティブ・ユーザー

WAUとは、その週に遊んでくれたユーザーの人数です。


;PU（Paying User） 
:ペイング・ユーザー

課金ユーザーの人数のことです。その日を課金ユーザー人数をDPU、その月の課金ユーザー人数をMPUと言います&lt;ref&gt;『レベルデザイン徹底指南書』、P140&lt;/ref&gt;。


;課金率
たとえば、ある月のユーザ数のうちの課金ユーザーの割合など、
一定期間中の課金ユーザーの割合を言ったりしますす&lt;ref&gt;『レベルデザイン徹底指南書』、P140&lt;/ref&gt;。

あるいは、全ユーザーのうちの課金ユーザーのことだったりしますす&lt;ref&gt;『ゲームプランとデザインの教科書』、P70&lt;/ref&gt;。（書籍によって、内容が微妙に違う）


;継続率
前月と比べて今月はどんだけユーザーが残っているかとか、あるいは前週と比べて今週はどんだけユーザーが残っているかのことを、
継続率といいます。


（以上）

このほかにも、色々な指標があります。

== 参考文献・脚注など ==</text>
      <sha1>g4xrsrupoimkk6t8gu3bag8q657cdma</sha1>
    </revision>
  </page>
  <page>
    <title>ゲームプログラミング/デバッグ</title>
    <ns>0</ns>
    <id>27352</id>
    <revision>
      <id>205773</id>
      <parentid>204945</parentid>
      <timestamp>2022-07-24T07:13:47Z</timestamp>
      <contributor>
        <username>はいかぐら</username>
        <id>45848</id>
      </contributor>
      <comment>/* 漢字ミスや誤字脱字 */</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="234398" xml:space="preserve">== ゲームのデバッグ ==
映画監督の川村元気（かわむら げんき）と任天堂の宮本茂（みやもと しげる）との対談『理系に学ぶ』によると、宮本茂いわく「プログラマーはバグを出さないことに責任がある」とのことです。
なのでプランナーやディレクターなどは、「彼らにどう納得してもらえるか」に努力をすることになります&lt;ref&gt;川村元気『理系に学ぶ』、ダイヤモンド社、2016年4月21日 第1刷発行、P.94&lt;/ref&gt;。

=== 概要 ===
ゲームにかぎらず、一般にソフトウェアのバグを取り除く修正のことを「デバッグ」といいます。

本書では、主に、ゲームにおける主に公開ベータテストにおけるデバッグおよびテストプレイの方法を説明します。


ゲームにかぎらず「ベータ版」（β版）とは、おおむね「バグが多いかもしれないけど、とりあえずソフトウェアとして最低限は機能するバージョン」のような意味のバージョンのことです。

いっぽう、「そもそも起動しない」とか「コンパイルできない」とか、「クローズボタンを押して無いのに、いきなりアプリが異常終了する現象が頻発」とか、「画面が、ずっと、まっくら」とか「データが勝手に消える」みたいな重大バグの多いバージョンは、アルファ版（α版）というか、または、単に開発初期のバージョンです。


ベータよりも前のアルファ版は、プログラマー側だけでチーム内部でチェックしたほうが、ラクです。

いわゆる、「テストプレイヤーを広く募集してテストプレイ」という外部に体験版ゲームを公開してのテストをするには、とりあえず開発チーム内部で試しプレイとして「通しプレイ」（そのゲームをニューゲームからクリアまですること）を先にした後に、最低限1～2回の「通しプレイ」が終わってから外部へのベータ版の公開をすると良いでしょう。「通しプレイ」とは、ゲームをスタート画面の最初からエンディングの最後のクリアまで、そのゲームをプレイする事です。

ゲームに限らず、こういう、プログラマー外部のテスト者にも協力してもらって、ベータ版をテストしていくことを、「ベータテスト」（βテスト）といいます。

「ベータ版」と、商品として発売した「リリース版」との違いは、相対的なものでしかなく、実際にはリリース版であっても、バグが含まれるのが一般的です。

ゲームに限らず、現代の複雑化・高度化したソフトウェアでは、すべての潜在的なバグを発見するのは、人員の限りや時間の限りがあり、ほぼ不可能なのです。

そのため、デバッグの最終目標は、けっして「バグをゼロにする」ではなく、「もしバグが残っていても、アプリの致命傷にならないようにする」などの、フェイルセーフ（fail safe）的な方針でデバッグしていく方法になります。そのため「影響度の大きい重大バグから、潰していく」などのような方向性で仕事していくことになるでしょう。


;内部テスト
公開βテストの前に、まずはチーム内部で軽く、一般プレイヤーと同じ目線で軽くプレイする事や（俗に「フリープレイ」と言います）、あるいはβ公開後でも開発チーム内部でも引き続きテストプレイを時々することを「内部テスト」などと言います。俗に「内部デバッグ」とも言いますが、「デバッグ」とは本来はプログラム修正のことなので、正確には「内部テスト」というべきでしょう。

よって順番としては、
:とりあえずの体験版などの完成　→　内部テスト　→　バグ修正　→　公開βテスト　→　体験版の修正　→　リリース版にむけての作りこみ　
のような順番になります。

=== 賃金など ===
ゲーム業界のテストプレイは、賃金が安いです。特に文献などは無いですが、よく「テストプレイヤーの給料は安い」と言われています。

テストプレイヤーは、比較的に就職しやすいので業界経験にはなりますが、しかしテストプレイしているだけでは、どんなに頑張っても、そこからプログラマーやプランナーなどに転職するのは容易ではありません。

分かっているとは思いますが、ゲーム業界は年功序列などのある業界ではないのです。ご参考までに。

しかし賃金が安い一方で、日本語のチェック（漢字の誤字脱字など）などもテストプレイヤーの仕事であるので、よって日本人（ここでは日本語を母語とする人の意味）がテストプレイをする必要があります。対比としてアニメ業界ならアニメでは動画は海外発注などをされますが、しかしゲームではアニメ業界とは違い、ゲームのテストプレイでは日本語チェックをするので日本国内に発注することになります。

また後述しますが、シナリオの矛盾点などもチェックする必要があるので、読解力が意外と要求されます。読解力が要求される割には、賃金が低い仕事です。

;新人向けの仕事でもある
なお、ゲームに限らず、ソフトウェアのテストは、IT企業では、よく新人がやらされる仕事でもあります。新人研修に組み込まれていたり、研修明けによく与えられる仕事でもあります。
なぜなら、自社ソフトウェアの内部構造の知識が乏しくてもテスト自体は可能だからです。

ゲーム業界でも、プランナー志望の新人がよくテストプレイを任せられることが多いです&lt;ref&gt;STUDIO SHIN『ゲームプランナーの新しい教科書』、翔泳社、2018年3月10日 初版 第2刷 発行、P250&lt;/ref&gt;。

ただし、最近はテストプレイは外注することも多いです&lt;ref&gt;STUDIO SHIN『ゲームプランナーの新しい教科書』、翔泳社、2018年3月10日 初版 第2刷 発行、P250&lt;/ref&gt;。

=== プログラマー用の自分用デバッグ報告文について ===
まず、あなたがプログラマーだとして、自作ゲームのテストプレイで、バグを発見したとしましょう。

その修正方法がもし簡単に思いつけば、その通りに修正すればいいのです。


ですが、なかなか修正方法が思いつかなかったり、あるいは考え付いた修正方法が間違っていて上手くは修正されない場合などは、なかなか大変です。


こういう場合、どうやってバグの事態を打開するかというと、
:自分で自分にバグ報告メールのような文章を書くことです。


例を示します。たとえばRPGの作成中、装備コマンドで、アイテム無限増殖のバグが起きたとしましょう。
その場合、なかなか上手く直せずに、てこずったとしましょう。

ならば、書きのように自分で自分にバグ報告メールを書くのです。（もっとも、送信の必要は無い。あくまで思考を整理するために書くだけである。）

;プログラマー自身による自己確認用のバグ報告文の例
&lt;pre&gt;
【バグ概要】
アイテムの無限増殖バグ。
装備コマンド時に、アイテム無限増殖バグが発生する。


【バグ発生条件】
装備武器と選択武器が違う場合に発生。

装備中の武器が1行目にあり、
一方で選択中の武器はアイテム欄の2行目以下にある場合に発生する。

この条件で、決定キーを押すと、バグ発生する。


【起きる結果】
選択中の武器の個数　＋１　したものが、
選択カーソルの一つ上の武器（テスト時には、決定ボタンの直前に装備していた武器）の個数としてセットされる。（これがバグ）


なお、選択中の武器の個数に関しては、正しく－１される。 


【期待される挙動】
一つ上の武器の個数（決定ボタンの直前に装備していた武器としてセットされるべきものは、
「選択中の武器の個数＋1」ではなく、
一つ上の武器（決定ボタンの直前に装備していた武器と同じ武器の個数＋1であるはず。

以上。
&lt;/pre&gt;

のように自分で書くのです。（再現性などはプログラマー自身で把握しているので、この場合（自分用の報告の場合）は書かなくていい。）

コツは、
 選択カーソルの一つ上の武器（テスト時には、決定ボタンの直前に装備していた武器）の個数としてセットされる。（これがバグ）
における
「決定ボタンの直前に装備していた武器」という記載のように、文節「選択カーソルの一つ上の武器」というゲーム中で実際に起きた現象だけでなく、さらにその現象の意味することを別の言葉で説明することです。


プログラマーの書いたバグありのコードを見れば、上記メモの「起きる結果」の通りにコードが書いてあるから、バグが起きるのです。なので、「期待される挙動」に書かれている通りに、コードを直せばいいのです

つまり、「【起きる結果】」と「【期待される挙動】」の報告文の内容を、バグ修正時には修正済みコードへと置き換えることになります。

よって、プログラマー自身による自分用のバグ報告メモでは、必ずこの2つの項目が必要です。

=== 公募プレイヤーなどのバグ報告の片寄り ===
公開βテストなどで募集した一般プレイヤーは、ゲーム制作においては素人・初心者だったりしますので、デバッグの手法を知りません。

このため、公募プレイヤーのバグ報告パターンには、報告されるバグに、やや片寄りがあります。

よくある片寄りとして、
# プレイヤ－に有利なバグは報告しない。
# クリア不能にならないバグは見つけても報告しない。
# 開発者でないため正常な仕様を知らないので、仕様と不一致のバグに遭遇しても気づかない。
などの片寄りがあります。


たとえば、具体例として
:* 本来、BGMがボス戦（中ボス用）に変わるはずのシーンなのに、小ボス用のボス戦BGMのままのバグだけど、プレイヤーは正常仕様を知らないので気づかないので報告しない。
:* 誤字脱字を見つけても、プレイヤーにとってはクリアに支障ないので報告しないプレイヤーも多くいます。

のような事例が、時々よくあります。

仕様と違う挙動をするという類のバグは、ゲームの快適性を確実に下げますが、しかし、初見プレイヤーはそのバグが「これはバグである」という事自体に気づかないので、バグとして報告されないという、厄介な問題があります。

なので、テストプレイヤーの人数と、取り除けたバグの量は、必ずしも比例しません。公募プレイヤーが報告する傾向のあるバグは、たいてい、クリア不能バグの類ばかりです。

なので、そのゲームの実際のバグの合計数については、公募プレイヤーの報告しなかった細かいバグが、公募プレイヤーからの報告数の何倍やヘタしたら十数倍もゲーム内に隠れていると思ったほうが良いでしょう。

なのでゲーム作者は、自分でも体験版などをときどきテストプレイする等の自己的なチェックが必要です。


さて、大きな更新などをした直後の場合などは、デバッグモード使用などでも良いので通しプレイをすると、バグがよく見つかります。

しかも、この手の大規模更新の影響を受けて発生したような細かいバグほど、初見プレイヤーには気づきづらい細かい箇所で発生するので、初見プレイヤーが遭遇しても報告されないという傾向があります。なのでゲーム作者は、通しプレイをとにかくデバッグモードを使ってでも何でもいいので定期的または大規模更新の直後などに行うことが必要です。

デバッグモード自体のバグによるチェックミスを防ぐため、ときどきデバッグモードを使わないでの通しプレイも行ってみると良いでしょう。また、もしそのゲームがデバッグモードを使わないとプレイ時間が莫大に掛かってしまい、ときどきの通しプレイすらもしたくなくなるゲームなら、そもそも大元のバランス調整が不適切な可能性があります。

=== 守秘義務とか ===
デバッグに限らず、有料ソフトウェア制作に参加する人は、仕事で知りえた非公開情報を、けっして社外やチーム外には漏らしてはいけません。

仕事における、こういう企業秘密などを守る義務のことを「守秘義務」（しゅひぎむ）と言います。もしゲームテスターのアルバイトなどをする場合、守秘義務の契約書などを書かされるでしょう。当然、守秘義務の契約は守りましょう。

ゲーム業界やIT業界に限らず、一般の商社やメーカーや小売業や土建業などでも同様に、業務上の企業秘密は漏らしてはならないですし、それらの業種でも自社および取引先の企業秘密を守る義務があって、その義務のことを「守秘義務」と言います。

ともかく、「守秘義務」は社会人の常識です。

もし守秘義務に違反すると、たとえば損害賠償などを請求されたり、場合によって刑事罰を受けて逮捕される可能性もあります。


テスターの場合、「〇〇社でテスターのバイト経験があります」程度のことなら公表しても平気でしょう（就職活動にも公表の必要な情報なので）。ですが「〇〇社の△△のゲームをテストしました」（△）のような具体的な作品名のある情報は、（ゲーム会社からの）公開許可を貰わない限り、守秘義務により秘密にすべきでしょう。

まして、「あのゲーム、実は裏仕様では□□なんだぜ」（×）的な情報は、絶対に秘密にすべきです（もし機密を漏洩したら、損害賠償などを確実に起こされるでしょう）。

テスターには多くの人数が必要なので、そのゲームのクレジット（エンディングなどで流れるスタッフ一覧）にはテスター名は載らない場合もあります。（クレジットに名前が載るテスターは、居たとしてもテストチームの代表者など一部でしょう。）


;フリーゲームや同人ゲームなど
さて、フリーゲームや同人ゲームなどの場合はどうかというと、特に契約書などは書かないですが（作者も面倒ですので）、しかし社会常識的に、ゲームテストで知りえた裏仕様などの裏情報は、なるべく黙っておきましょう。特に有料同人ゲームの場合、有料である以上は、もし裏仕様やネタバレなどの漏洩をしたら損害賠償などに発展する可能性もあるでしょう。

フリーゲームでも常識的に、裏仕様などは、もしテスト中に知っても、（裏仕様を）秘密のままにしましょう。

なお、フリーゲームでもある程度の作品ならテスターは多人数に上るので、クレジットにはテスターは記載されないのが普通です。

=== テストプレイは開発段階によってテスト内容が異なる ===
開発当初は、ゲームが意図通りに動いているかを確認する目的で、プランナーやディレクターが自ら確認します&lt;ref&gt;川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、、2018年11月1日 第1版 第1刷、P.137&lt;/ref&gt;。

ゲームデザイナーは、発注したものが意図どおりに制作されているかを確認するために、実際に発注素材をゲームに組み込んだ状態のものを自分でプレイして確認します&lt;ref&gt;塩川洋介『ゲームデザイン プロフェッショナル』、技術評論社、2020年10月3日 第1刷発行、P.50&lt;/ref&gt;

==== 解説 ====
同人ゲーム程度の小規模な商業ゲームや、あるいは高品質なフリーゲームなどのテストプレイをする際、開発中の中盤くらいの段階でのテストプレイか、それとも発売直前・ダウンロード公開直前かの段階かで、必要とされるテストプレイのノウハウは、大きく異なります。

その理由は、まず外注アート素材などの出来上がってくるのが、けっこう後のほうだからです。

外注イラストや音楽などは作成に時間が掛かり、またもしイラストや音楽などのアート部品にミスがあった場合には修正の手間が大きくなるので、よってイラストなどは出来上がるのが、かなり開発の後半になります。

逆に、比較的に早い段階で出来上がるのは、テキスト部分です。


このため、開発の後半になるまで、画像などの納品待ちをしてい素材などのテストプレイは、初期段階のテストプレイでは不可能になります。

ラフ画や仮音楽などを初期段階テストプレイでゲームに組み込むという方法もありますが、しかし開発後期の本番むけテストの際にも、もう本番用のイラストや音楽などに置き換えてから一度テストプレイをしなおす必要があります。

こういった事情から、チェックシートなどを使ってでの、総当り的な本格的なテストプレイは、実は開発の後期になってからになる事が考えられます。（また、このため外注テストも、後半の段階からだろうと考えられる。）


開発の前期～中期では、あまり細かくテストプレイをしすぎる必要はありません。開発の前半では、これから仕様がコロコロと変わるので、開発前半で一時的にバグがゼロになっても、これからまた仕様変更により、開発前半で確認した場所にバグがまた発生する可能性も高いからです。

もちろん、開発前半でもサラっとテストプレイをしたほうが良いのですが、でもサラッとした感じで充分です。ここら辺の感覚はゲーム開発チームで無いと分からないでしょうから、外注はされない確率が高いと思われます。


さて、開発初期～中期でのテストプレイの場合、チェックシートなどは全く出来上がってないので（そもそも仕様書（設計仕様）が未確定の可能性もありうる）、なのでテスタトではメールなどを使っての文章でのバグ報告のヤリトリが多くなるので、あまりテストプレイヤーを増やすべきではないです。（初期段階からテストプレイヤーを増やしすぎると、メール対応が大変になります。）


==== 開発前期のテストプレイ方法 ====
開発後半のチェックシートなどを使ってのテストプレイは、外部サイトなどで元ゲーム業界の人達がチラホラとノウハウを公開してくださってますので、ソレを参考にしてテストプレイをすると良いでしょう。

ですが、開発前期のテストプレイ方法は、なかなか公開されてません。（一応、任天堂がゼルダなどを例に手法を公開している。）


開発前期の場合、そもそもチェックシートが無い場合が普通でしょう。仕様自体が今後の仕様変更で変わる可能性もありますのでチェックシートを作るメリットも薄いです。このような事情もあり、あまり細かくチェックする必要も無いでしょう。

なので、基本的に、一般プレイヤー目線での「通しプレイ」による通常のプレイ方法を中心にしてのテストプレイをする事になります。


さて、同人ゲームやフリーゲームなどの場合、開発初期のテストプレイヤーの人数は、せいぜい4～5人など一ケタ人数になります。この程度の一ケタ人数でのテストプレイの場合、バグ報告などのヤリトリは、メールで行う場合が普通でしょう。

こういった開発初期でのテストプレイでもしバグを見つけて、これからメールでバグ報告をする場合、バグのあった箇所を報告する際に、さらにどこまでゲームを進行させたかを追記的に数行ていどで報告すると良いでしょう。

たとえば、
&lt;pre&gt;
第4章の〇〇のシーンで、下記のバグを発見しました。
【バグ内容】
※ 中略


【追記】
第6章までクリアしました。第5話の結婚イベントのヒロイン選択では、花嫁にはビビアンを選びました。ビビアンの見た目で選びました。なぜなら金髪ツインテールは正義だから。ビビアンかわいい。
&lt;/pre&gt;
みたいにです。

このようにクリアした範囲を報告する理由としては、報告を受ける側としては、プレイヤーがどこまでプレイしたか、分からないです。

たとえば、全10章のゲームで、第4章にバグが特に多く報告されている場合、はたしてプレイヤーが
:第10章まで進んでクリアした上で、第4章のバグを多く報告しているのか？、
それとも、
:第4章や第5章までの前半～中版のステージでプレイヤーが行き詰ってるのか？、
といった事が、バグ現象だけの報告では不明だからです。

もし、テストプレイヤーが第4章か第5章から先に進めない場合、作者はバランス調整やヒント追加などとともに、テストプレイについても作者側で、テストプレイヤー側が未検証が第6章以降をテストプレイする必要も生じます。

また、ゲーム中のフラグ管理に大きな影響を与えそうな重大な選択肢のあるイベントなどでは、どういった選択を選んだかも追記すると、作者側と情報共有しやすいでしょう。


たとえば上記の例のゲームの「第5章」の花嫁選択の場合、たまたまテストプレイヤーが3人いる花嫁候補のうち、ビビアンばかりを選んだりするかもしれません。

なぜなら開発初期～中期のテストプレイでは、開発後期でのテストプレイとは違うので、いちいちテストプレイヤーどうしでチェック作業を分担したりしません。というか、そもそもテストプレイヤーはお互いには連絡しません。これはゲーム作者や開発チーム管理者に情報を一元的に集中させる必要があるので、テスターどうしでの情報共有は自粛すると言う側面もあるからでしょう。（伝言ゲームみたいな情報劣化を防ぐため、開発初期の小人数テストプレイでは作者と直接やりとりをするので。）

その結果、そのゲーム中に選択肢イベントのある場合、別々のテスターどうしでも重複して同じ選択肢をたまたま選ぶ場合もあります。


また、開発後半のデバッグでは、チェックリストなどを作って、「〇〇月○〇日の時点では、どこにバグが無かったか」というバグの無かった箇所も確認する必要があるのですが、しかし開発の初期で、いちいちそこまでのチェックシートを作るのは面倒ですし、開発初期は今後の仕様変更の可能性も高いのでチェックシートを初期からいきなり作っても無駄になる可能性があります。

そこで、他のバグ報告の際に、追記的に、ゲーム内でどこまで進行したかの情報も書くことにより、「どこにバグが少ないか？」という情報についてを、作者は間接的に知ることが出来るからです。


なお、バグ報告が無い場合に、いちいちプレイのたびに、「どこにバグが無かったか？」のメールを送ると、メールの量が増えたりして、読む側の作者も面倒だし、書く側のテスターも面倒です。

ただし、上記の方法は、あくまで開発初期～中期での、さらに少人数（せいぜい5人ていど）でのテストプレイの場合です。


;商業ゲームのテストプレイは全くの別
プレステ作品や任天堂ゲーム機作品などの商業ゲーム作品などを作る場合は、もっと多くのテストプレイヤーが必要になりますし、「通しプレイ」だけでなくチェックリストなどを作ってのブルドーザ的な総当たりの点検も必要になってきます。

なお、商業ゲームの外注テストプレイの場合、いちいち開発メンバーにメールしません。なぜなら、普通は開発の後期に外注テストは開始され、この段階になるとテスターの人数が多いことなどや、すでにバグ報告用サーバーの投稿フォームなどが整っているので、そちらサーバー側の投稿フォームのほうに、会社などで定められた書式のとおりに投稿します。

商業ゲームのテストの場合なら、テストチームのリーダーなど現場リーダー的な人が、テスト全体の計画を考えて、部下である各テスタ－たちに指示を具体的に出しますので、テスターはその指示に従ってテストをする事になるでしょう。（テスターがいちいち、次にテストする内容を考えたりしないと思います（それを考えるのは現場リーダーの仕事だし、各テスターに考えさせると人によってテスト程度のバラツキが発生しかねないので、テスト品質を一定に保つためにあえて現場リーダーに管理を任せます）。）

部下テスターは指示されたとおりのテストが終わったら、それを現場リーダーに報告します。すると現場リーダーは、全体のテスト状況やゲーム仕様などをもとに、次のテスト内容を部下テスターに指示します。

どういった内容が次のテスト内容になるかは状況にもよりますが、よく指示で出されると言われるのは、まだテストが不足していたりして遅れている箇所の手伝いとか、そういった箇所のテストの指示が出される可能性が高いと思います。
:（実は同人ゲームなどのβテストでも、テストをボランティアなどで手伝う場合、テストが遅れている箇所のテストなどを同人ゲーム作者からテスターが依頼される場合もありますが、ハナシがややこしくなるので、ここでは同人ゲームの話は省略する。）

=== 最初から「面白いバグ」はまず無い ===
また、バグは原則、発見したら、なんらかの修理的な処置により直すべきです。

よく、「面白いバグは裏技として残す場合もある」と言われますが、たとえ最終的に裏技として残す場合であっても、とりあえず発見者はそのゲームの問題点のある挙動を『バグ』として報告し、判断を担当者に任せます。

そして「バグ」報告を受けた担当者は、その「バグ」をたとえ裏技として残す場合であっても、現状ではテストプレイヤー視点ではバグ的に見えるわけですから、そのゲーム中の挙動には、なんらかの修正対処が必要です。

そもそも、ゲーム開発序盤では、そのままでは「面白いバグ」というのは、ありません。

たとえ有名ゲームの面白い仕様の挙動が、バグ由来の現象でも、そのプログラムコードはゲームの実装開発中に何度も修正を受けて改善されてきています。

つまり、「改善すれば、面白くなりそうなバグ」なら、あるかもしれません。

バグ報告を受けた担当者は、そのバグが「改善すれば、面白くなりそうなバグ」なら、その挙動が一般プレイヤーにとっても面白くなるように、修正していく必要があるのです。

=== 総論 ===

ゲームのデバッグのためには、まずバグを発見する必要があります。

しかし、すべての潜在的なバグを発見するのは、人員の限りや時間の限りがあり、ほぼ不可能です。


なので、まず製作者は、プレイヤーのよくやる行動をゲームプレイで再現してみて、そして遭遇したバグから直しましょう。

:※ 「仕様書やチェックシートなどをもとに確認しなくていいの？」と思うかもしれませんが、（想像ですが）本格的な仕様書・チェックシートが作成される時期は、ゲーム開発の中期あたりからでしょう。
:なぜかというと、仕様書を作成する前にまず、試作品ゲームソフト（プロトタイプ）をある程度はキリよく遊べるところまで作ってから、その試作品にデバッグをして大きなバグや目につくバグを潰してから、通しプレイをするなどしてマトモに遊べることを確認してから、ようやく仕様書などの書類を作ることになるからです。仕様書が無い段階では当然、チェックシートなんていうモノも無いのです。
:もし「仕様書」（設計書）があっても、仕様書の内容と、実際の開発版のソフトのプログラムの内容が異なっている場合も、開発初期などでは考えられます。（開発初期は仕様変更をコロコロとするので。ただし開発後半では、『仕様書』のソフト実物の内容とが一致してないとマズい。）
:試作品（プロトタイプ）とは言っても、バグは早めに直しておく必要があります。そのゲームが、万が一にバグが起きてもバグを直しやすいシステムになってるかどうかを確認するのも、試作で行うべき確認事項のひとつです。しかし、試作品ですので、あまり多くの人員をテストに導入できないので、なので、プレイヤーのよくやる行動で遭遇するバグから先に潰していく必要があります。

さて、プレイヤーのよくやる行動を優先する理由は、極端な例を挙げると、例えば、もし普通のプレイヤ－のやらない行動をしてみてバグを見つけて直しても、
たとえば、RPGで、薬草の使用をキャンセルするのを20000回連続で続けると遭遇するバグがあったとして、もし製作者がそのバグを直しても一般プレイヤーは気づきません。

1960年代のような古いコンピュータのデバッグ方法と、現代のデバッグ方法は違います。

つまり、パソコン黎明期の科学計算のデバッグやファミコン黎明期（1980年代）のゲームのバグの探査方法と、現代の廉価or無料のパソコン用ゲームのバグの探査方法は、微妙に違います。

アセンブラなどをいじくる必要のあったテレビゲーム機の黎明期の時代のバグ発見の方法は、現代では、あまり向いていません。

現代のゲームでは、バグ修正は、ネットワーク通信ゲームなら、公開後にもネット経由でアップデート修正することもできます。

また、有料ゲームでも、販売前に体験版などを配布してプレイヤーにテストプレイしてもらう事で、プレイヤーの遭遇しやすそうなバグを探せます。


一方もしゲームでなく、たとえば自動車用の組み込みプログラムや、あるいは工作機械などの組み込みプログラム組み込みなどのバグ探索ならば、バグが人命の死につながりかねないので、たとえば、電源ケーブルや通信ケーブルなどの抜き差しをしたりとか不安定な状態にしてバグを探したりとか、温度をあげたり下げたりとかまでしたりとか、そういうハードウェアとの関連のありそうなバグも様々な方法で徹底的に探します。

しかし、現代のゲーム開発では、そこまでしてバグを探す必要は無いでしょう。

また、こういったハードウェア関連のバグは、ＯＳメーカーやあるいは業務用の組み込み機器メーカーなどが探すべきバグです。
けっしてPC用ゲームメーカーの探すべきバグではないです。

（もし任天堂やソニーのような、）新発売されたばかりの新ハード用の対応ゲームをハードメーカーやＯＳメーカーが制作しているならともかく、（中小ゲームメーカーのような）既存のパソコン用の無料ゲームや廉価ゲームなどでは、そこまでしてハード関連のバグを探す必要は無いでしょう。


なお、IT業界において、デバッグは一般的に品質管理（QA）部門の仕事です。（※ 異業種の人に説明する際、こう説明しよう。）

=== 何が「バグ」か ===
ゲームにおける「バグ」は、クリア不能などは当然「バグ」です。

ですが、クリア可能であっても、仕様と違っていたらバグです。


==== 仕様と違えば「バグ」 ====
たとえば、武器「鉄の剣」を装備したとき、本来の仕様なら攻撃力が15アップなのに、攻撃力が12しかアップしなかったら、それはバグです。

なので、商業ゲームのテスターは、仕様書などを参考に、そういうパラメータもひとつひとつ、最終的に完成まではにはチェックする必要があります。


==== ボタン入力後の状態遷移バグ ====
典型的なバグとしては、連打などボタン操作による、状態遷移のミスによるバグがあります。

けっして連打そのものが目的ではなく、状態遷移ミスを見つけるのが目的ですので、目的を勘違いしないように。なので、連打中に十字キーを入力してみるとか、そういうふうに色々と確認します。

たとえば連打だけでなく、別々のボタンの同時押しなども、商業ゲームでは、よくあるバグ調査手法です。

たとえば
:決定: Zボタン
:キャンセル:Xボタン
などの仕様が決まっているなら、ZとXの同時押しなども確認します。

ゲームの説明書があれば、操作説明などが説明書に書いてありますが、説明書は鵜吞みにしないようにしましょう。

あるいは、画面が変わる途中（「画面遷移」）などに、何かのボタンを連打したり、色々と試してみましょう。

特に、ゲーム中で特殊なキー入力イベントがある場合、そのキー入力イベントなどでは、このようなボタン関連の状態遷移バグが多発しやすいので、要チェックでしょう。

RPGツクールなどの既製品のゲーム制作ツールでは、標準設定のUIでは、この手のバグは少ないです。しかしツクール作品などでも、作者の自作したUIなどだと、こういうバグも時々ありますので、テストプレイなどで確認してみましょう。つまり、開発で追加されたばかりの新UIがあったら、テスターはまず下記のモンキーテストによるテストを試してみましょう。

;モンキーテスト
なお、キーパッドやキーボードなどのボタンをデタラメに押しても異常動作が起きないかをチェックすることを「'''モンキー テスト'''」と言います。猿のように、理解もせずにデタラメに操作するからです。

モンキーテストではデタラメに入力するので、仕様にないボタンも入力する事になります。上述のようなボタン受付のテストや状態遷移テストなどで、よくモンキーテストが使われます。

==== 漢字ミスや誤字脱字 ====
ゲーム制作において、誤字脱字もバグに分類します。

たとえば道具「ポーション」（potion）が「ボーション」（botion？）になってたりとか、そういうのもバグです。日本人のキーボード入力ならありえないミスですが、中国など人件費の安い海外にプログラミングを発注していると、似た文字をよく間違えます。なので、文字が正しいかもチェックします。

「エアロ」（aero）が「工ア口」（こうあろ）とかになってたりとか、字体の似ている文字どうしは要注意です。


誤字どころか、原文自体がオカシイ場合もあります。

本来なら、たとえば「さあ、行くわよ！」と女性キャラのセリフを書くべきところを、

バグでは、助詞の使い方は外国人には難しいので「わ」と「よ」が入れ替わって「さあ、行くよわ！」みたいになっている場合もあります。

他にも「い行くわよ」みたいに、フリガナを勘違いして前後に出している場合もあります。こういうのも仕事では「バグ」として種類「誤字」などとして報告します。

「気づく」が「気ずく」になってるような、「づ」と「ず」の間違いも、海外系ではチラホラあります。「貴様の殺気に築かないとでも思ったか！」みたいな「きずく」だと変換に「気づく」が出てこないので、変換に出てきた「築く」を使った誤記とか。


なのでテスターの誤字修正のための学力の要件として、最低でも中学卒業レベルの国語力は必要です。もちろん、けっして偏差値30の底辺高校の合格なんて国語力では不十分です。偏差値55くらいのそこそこ賢そうな高校に国語教科だけなら合格点を取れそうな国語力ぐらいは、大人なら習得しときましょう。

こういう仕事は一見、出版業界でいう「校正」や「校閲」の仕事に近そうですが、しかし本当は、どっちかと言うとゲームの誤字デバッグは翻訳家（外国語→日本語）のほうがイメージに近いです。ある程度、英語の勉強もしておきましょう。中学～高校初級の英語レベルは、身につけておくと便利でしょう。

世間的には「翻訳」で説明したほうが分かりやすいでしょうが、業界用語的にはゲームの「日本語ローカライズ」でしょう。たとえ日本企業のゲーム会社の作品でも、なんらかの大人の事情で、中国などに一部の工程を外注していたりする場合もあるので、テストプレイの際には日本語ローカライズみたいに文章チェックもして、誤字脱字やカタコトっぽい表現などを報告して修正させます。


さて余談ですが、出版業界の校正・校閲でも、誤字脱字は修正の対象です。日本人の作者でも、タイプミスなどで、ときどき誤字脱字をしますので。「わがはいははネコである」みたいに、日本人だって「は」を2回続けるようなタイプミスもする場合だってあります。

ですが、「校正」と言った場合、老人っぽくて若者には分かりづらい表現を現代風に言い換えさせたりとか（時代遅れの表現とか）、差別用語や放送禁止用語などが含まれているかを見つけて修正したりとか、そういうのも含みますので、誤字修正とはニュアンスが異なります。ちなみに校正や校閲も、（PCデータではなく）実際に印刷物として試し刷りした状態の印刷物（「ゲラ刷り」）で、確認をするようです。ドコの業界でも、製品に近い状態でチェックをする傾向があるようようですね。


さて、校正というほどではないですが、誤字脱字の確認のために、国語辞典が必要になります。なので、テスターには国語辞典も必要です。そもそもシナリオライターがシナリオ作成術を磨く時点で、国語辞典を活用しています。

勉強法として、普段から暇なときに国語辞典を読んでおく習慣を提唱するシナリオライターもいるくらいです&lt;ref&gt;『ゲーム作りの発想法と企画書のつくりかた』、P.151&lt;/ref&gt;。ランダムで、パラパラと空いた時間などに読むというものです。一方、1ページ目から読むと挫折するとのことです。

しかし、テスターとしては、ここで問題があるのですが、国語辞典には口語が全く掲載されていません。たとえば接続詞「あと」ですら載っていません。なのでゲーム中の会話文で口語を多用する事の多いゲームでは、国語辞典は不十分です（「なので」も載っていなかったりします）。そして困ったことに国語辞典の代わりになる『口語辞典』というものはありません。なので国語辞典の活用は、せいぜい名詞の確認ぐらいに留めておきましょう。国語辞典には、出版社によっては、どうでもいい一過性の流行語が載っているくせに、数十年前から使われている口語は載っていないなど、とてもフザケた編集姿勢です。なお「でも」や「だって」は国語辞典に普通にあります。

なので、実は海外の日本語学習者には、日本の中学校高校で教えられているような文法は、疑われています。実際、留学生や在日外国人のための日本語教科書を読むと、日本の中学高校で教わったような理論体系とは、まったく異なります。

根本的には、現代日本語は、近代英語のような文法の原理原則を先に決めたアプリオリな言語とは、文法の確立の経緯が大きく異なります。つまり日本語はけっしてアプリオリな言語ではないのです。だから辞書や教科書による日本語学習には、早いうちで限界が来ます。ですから、市井（しせい）の日本語にも耳を傾けましょう。


デバッグではないですが、そもそもシナリオライター側の時点ですでに、書籍『ゲーム作りの発想法と企画書のつくりかた』によると、ゲーム中での表示文については「正しい日本語」を書く必要がないとのことです（かぎカッコはwiki側で追記）。たとえば、ゲームの画面は本と違いますので、ゲームでは画面中に表示される行数を気にしないといけません&lt;ref&gt;『ゲーム作りの発想法と企画書のつくりかた』、P.154&lt;/ref&gt;。ゲーム画面には、こういう種類の制限や要求事項が他にも多くありますので、そういった制限などの中で、シナリオライターはプレイヤーにとってプレイしやすい文章を書かなければならないからです。

ゲーム中の文章の著作とは、けっして国語教師を目指すことではないのです&lt;ref&gt;『ゲーム作りの発想法と企画書のつくりかた』、P.154&lt;/ref&gt;。

ゲームとしての良い文章の作り方は、特にルールといったものはないですが、ともかく、ゲームのしやすさに役立つ文章でなければなりません。

{{コラム|シナリオライターは文系職|
シナリオライターはなんだかんだで文系の人材の仕事です。

参考文献『ゲーム作りの発想法と企画書のつくりかた』では、国語辞典を使った勉強法の例として「水」「おひや」「ウォーター」という単語を上げています。

理系では「おひや」なんて単語、使う機会がないです。

（なお、声優も文系だと、よくネットの評論では言われます。脚本・台本を描くシナリオライターが文系であるのだから、その台本を読んで声を吹き込む声優も必然的にも文系的に読解力が必要になります。）

よくレポートの作文術などで「起承転結ではなく、結論から書け」の指南があります。しかしシナリオ制作では、起承転結を書かなければならない場合が多くあります。

モチはモチ屋。テスターなどの理系的な作業者は、文系の領分に踏み込まないようにするのが良いかもしれません。

もっとも、理系の知識も、たとえばロボットSF物の作品などのアドバイザーとしては役立つ場合もありますので、けっして「全く理系知識が役立たない」と悲観する必要もないです。ですが、消費者の多くは、別にゲームやアニメのロボットSF作品には、科学的な正確さを求めていません。そもそも「SFは、科学的にはウソ」という根本問題もあります。また、ロボットSFファンの客層でも、必ずしもハードSFを読みたい人だとは限りません。

リアリティとリアルは違います。

たとえばアニメのガンダムのファンの多くが、電子機械エンジニアを目指して理工学を勉強したがっているなんて事は、常識的に到底は考えられないです。
}}


{{コラム|海外翻訳の実情|
なお、多くの業界で翻訳の仕事は通常、翻訳先の現地の国のその言語を母語にしている現地人が、最終的に自国語に翻訳します。

たとえば、日本語に翻訳するなら日本人が最終的に翻訳します。同様に、英語に翻訳するなら、アメリカ出身のアメリカ人が翻訳するのが普通です。

この慣習はIT業界だけでなく、裁判などでも同様で、たとえばアメリカで海外展開している日本企業の裁判は、アメリカ出身で英語を母国語としている弁護士が訴訟活動を行います。たとえ日本出身の日本人弁護士がどんなに英語に堪能でも、その日本弁護士はせいぜい、アメリカ弁護士に依頼をするまでしかせず、最終的にアメリカの法廷で法廷闘争するのは、日本企業や日本人弁護士から依頼を受けたアメリカ出身弁護士です。「国際弁護士」と言う肩書きの人は、それぞれの国の現地の弁護士に依頼するのが仕事です。けっして、国際弁護士本人が、各国の法廷で直接に訴訟や弁護を展開するわけではないのです。

よく、漫画やアニメとかだと、日本人の自称「国際弁護士」がなぜかアメリカの法廷で直接に訴訟してたりしますが（たとえば実際、1990年ごろにアニメ映画版『ルパン三世』の金曜ロードショーのやつで、ヒロインの峰不二子が弁護士に経歴詐称して、アメリカで荒稼ぎしていた）、アレはフィクションです（90年代当時、流行語で「キャリアウーマン」という用語が流行してたので、そのような女性にも不二子は変装できる能力もあるという演出にすぎない）。映像的なテンポを優先しただけの演出です。けっして真に受けてはイケマセン。

弁護士の国際活動の話はあくまで類似例としての一例でして、とにかく翻訳をするのは、現地の人です。
}}

=== 何が「バグ」ではないか ===
:・ゲームの難易度が、「やさしすぎる」または「難しすぎる」などの改善点は、「バグ」ではないです。
:・ゲームのここが「つまらない」または「こう改善すれば、もっと面白くなる」などの改善点は、バグではないです。


「バグ」とは、明らかなミスだけが「バグ」です。具体的には、プログラムの誤動作や、漢字の誤字脱字、仕様書と実装が異なる場合など、客観的に「間違い」と誰でも判定できるのがバグです。


ゲームが「やさしい」とか「難しすぎる」とかは、個人の好き嫌いや趣味の問題なので、バグではないのです。（ただし、難易度調整のプログラム自体にミスがある場合などは例外。たとえば高難易度モードでは本来なら敵の攻撃力が1.5倍になるべき仕様のはずが、プログラム時のキーボード入力ミスで1.2倍になっていた場合とかは、バグである。）

難易度の調整は、テストやデバッグではなく、「バランス調整」という別の部署の担当業務です。


「バランス調整」と「デバッグ」との違いは把握しましょう。

=== 優先順位づけ ===
ともかく、ゲーム産業にかぎらず一般のIT業界でも、発見されたバグは、修正の優先順位にもとづいて格付けをされます。

医学における、どの患者から先に治療すべきかという概念である「トリアージ」という医学用語になぞらえて、IT業界でもバグの修正対応の優先順位（priority）の格付けのことを外国でも「トリアージ」と言います。

このことは、ゲーム作家の側には「トリアージ」などの用語の暗記は不要ですが、どちらかというとプレイヤーのテスト協力者などに考え方を知ってもらう必要があるでしょう。

もし科学者が科学計算ソフトウェアで世界最先端の開発を目指すのなら、（予算が国から与えられる限り）好奇心や興味のおもむくままに研究して、「トリアージ」の概念を無視するのも可能かもしれません。しかし一般のIT産業やゲーム開発では、予算の制約が厳しく、人員や設備の制約も厳しく、そうはいかないので、「トリアージ」的な優先順位づけが必要になります。

ゲーム業界でも当然、このようなバグ修正の緊急性の格付けは行われております。（参考文献: STUDIO SHIN 著『ゲームプランナーの新しい教科書』）&lt;ref&gt;STUDIO SHIN 著『ゲームプランナーの新しい教科書』、翔泳社、96ページ、2018年3月10日 初版第2刷発行、262ページ&lt;/ref&gt;


;デグレやエンバグなどを防ぐには
書籍『ゲームクリエイターの仕事 イマドキのゲーム制作現場を大解剖』によれば、バグを直すためにプログラムに変更を加える場合でも、なるべく変更が少なくなるようにする必要があります。この理由は、プログラムの変更により他の部分でバグが新規に発生するのを防止するためです&lt;ref&gt;蛭田健司『ゲームクリエイターの仕事 イマドキのゲーム制作現場を大解剖』、翔泳社、2016年4月14日 初版 第1刷 発行、P102&lt;/ref&gt;。

なおIT用語で、「バグを直そうとしてプログラムをいじったら、修正したつもりのコードの内容が間違っていて、別のバグを埋め込んでしまった」的なミスのことを、ニュアンスは不正確ですがIT用語では「デグレ」degrade とか「エンバグ」enbug などと言います。


;3D-CGで壁CGにキャラCGが、めり込む場合
また、これとは別に、3D-CGのあるゲームなどで、人類のCG技術的な限界により、わずかにだけ人物キャラクターが壁などに数センチ程（たとえば指の長さ程度）だけ、めり込んだりとか、そういうのは「バグ」ではなく「仕様」とするのが一般的だと言われます。技術的な限界により、少々の画像めり込みは、仕方ないのです。

もっとも、（通行設定ミスなどで）壁貫通を出来たりして向こう側にキャラが行けてしまってゲームのストーリーが変わってしまうとか、そういうのは「バグ」扱いですが。

テスト用語で、ゲーム中の壁のバグなどの「通行設定ミス」という言葉がありますが、裏を返せば、壁については通行設定さえミスしてなければ、少しくらい壁にキャラが めり込んだりしてしていても、構わないわけです。

=== バランス調整との関係 ===
==== バランス調整との違い ====
敵の強さなどの設定のバランス調整も、デバッグのためのテストプレイも、一見すると似ていて、ゲームを延々とプレイしたり、問題点を発見したら場合によってはレポートを書いたりして開発チームとコミュニケーションする場合もあるので、似ているかもしれません。


ですが、目的が違いますし、そして重要な相違点として、要求されるゲーム内知識が違います。


バランス調整のためのテストプレイヤーには、なるべく、そのゲームに詳しくない人のほうが最適です。（英語では「ティッシュ テスター」とか、「フレッシュミート」と言います。ティッシュとはもちろん、鼻をかむチリ紙のティッシュの事です。フレッシュミートとは「新鮮な肉」の意味です。）

そのため、バランス調整で開発者は、テストプレイヤーにあえて情報を伏せたりする事も考えられます。いっぽう、バランス調整テストプレイヤーも、あまりそのゲームの裏事情を知り過ぎないように気をつける必要があります。

ただし、バランス調整チームのリーダーだけ、そのゲームの裏事情を知ってたりします（でないと、他部門とコミュニケーションが取れなくなりかねない）。


一方、デバッグに参加している人のことを、和製英語で「デバッガー」といいます。

デバッガーは、なるべく、そのゲームの裏事情や開発事情などにも精通し、そして、そういった知識も動員しつつ、バグの起きそうな所をテストプレイで探して、バグを発見する必要があります。
:※ バグの報告をする人を「テスター」という場合もありますが、本wikiではバランス調整用のテストプレイヤーとの区別のため、「デバッガー」と呼ぶことにします。また、バグ報告を受けてプログラムを修正する人だけを限定して「デバッガー」という場合もありますが、本書ではやはりバランス調整との区別のため、バグ報告マンも、バグ修正プログラムのプログラマーも、まとめて「デバッガー」と呼ぶことにします。

:英語では、デバッガ debugger とは、ソフトウェアの一種で、デバッグのためにログなどをとるソフトのことです。タイプライターが人間ではなく機械なのと同様、英語の debugger は人ではなくソフトウェアです。 


バグの中には、そのゲームの仕様に精通しないと気づきづらいバグもあります。気づきやすいバグというのは、たとえば「画面がノイズだらけになる」というバグなら誰でも気づきます。しかし、そういう分かりやすいバグばかりではないのです。たとえば「あるシーンでの登場人物のセリフが微妙に、前後の話の流れにあってない。特殊イベント管理フラグのミスか？」みたいなバグも起きうるのです。なので、デバッグ作業では仕様をデバッガーが知る必要があるのです。


また、似たようなプログラムを使っている2つの特殊イベントの片方にバグがあったら、もう片方にもバグがあると考えるのが自然です。デバッガーにはそういう論理性が要求されます。また、こういうデバッガーの論理思考に協力するため、プログラマーなどもデバッガーにアルゴリズムの要点などの情報提供を適度にする必要があります。

なお、初心者の視点のほうが気づきやすいバグもあるので（たとえばチュートリアル説明などのバグ）、デバッグテスターも最初は仕様の知識の無いところから始めますが、デバッグ作業の進行に応じて仕様制定者（プランナー）や上長などからデバッグ状況に応じて仕様を随時、教えてもらうことになったり、仕様書をもらいます。

このように、上長などは、デバッガー系テスターに、そのゲームの設計図や仕様の一部を随時に教える場合もあります。商業ゲームの場合なら、デバッガーは最終的には仕様書（そのゲームの設計図）を見ながら、そのゲームのすべての仕様を一通りはチェックすることになります。


一方、バランス調整テストプレイヤーでは、逆にそういうヒントは、一般プレイヤーとは異なる先入観を与えてしまう結果になってしまうので、こういうヒントは与えてはいけないのです。


デバッグの当初は、デバッガーもバランス調整テストプレイヤーも、知識が少ないとこから始めるので、知識事情が似通っていますが、次第に要求されるゲーム内知識が違ってきます。


なお、デバッグは、人数が多いほうが有利です。なるべく、異なった視点で色々なプレイするほうが、色々なバグを発見できます。


バランス調整はややコツが必要ですが、それと比較すると、バグを発見するためのプレイは、比較的にコツが少なめで済みます。

なので、もし同人サークルなどチームでゲーム製作している場合、なるべくチームメンバーの多くでデバッグしたほうが、より簡単に見つかるでしょう。

==== バランス調整されてからテストプレイが望ましい ====
基本的に、細かいテストプレイを開始するのは、バランス調整後です。

文献『ゲームプランナー入門』によれば、ゲーム制作の流れは基本的に、

:プロトタイプ→アルファ版→ベータ版→調整→デバッグ
の流れです&lt;ref&gt;吉冨賢介『ゲームプランナー入門』、P18&lt;/ref&gt;。

なお、アルファ版とは、ゲームの全体像が分かる一部分を、「商品レベル」で作ることです&lt;ref&gt;吉冨賢介『ゲームプランナー入門』、P17&lt;/ref&gt;。

ベータ版とは、会社によって意味が多少違いますが（たとえば『ゲームデザインプロフェッショナル』と『ゲームプランナ－入門』とで微妙に違う）、おおむね、とりあえずのゲーム最初からエンディングまでの完成間近をひととおり遊べる状態のことです&lt;ref&gt;『ゲームデザインプロフェッショナル』、P170&lt;/ref&gt;。


α版などのゲームのテストプレイをしていると、作者がまだバランス調整を終わってないエリアが、そのエリアの（バグ発見などの）テストもまだ終わってない場面もあります。

もしアルファ版の段階でテストプレイに協力しているなら、バランス調整のまだ終わってないエリアの存在する場合、できるだけバランス調整が終わったエリアから優先的にテストしたほうが効率的です。

というのも、せっかく仮に、ゲーム中にあるバランス調整が終わってないエリアをテストプレイをしても、バランス調整後にそのエリアにおかしな所が追加されてないかをチェックする二度手間が発生してしまうからです。

文献『ゲームクリエイターの仕事 イマドキのゲーム制作現場を大解剖』の中盤では、アルファ版あたりの段階でのテストプレイにも言及しており、ニュアンスは本wikiのこのセクションと違いますが、文献ではこの段階でのテストプレイではゲーム全体のクオリティにも気を配る必要があると説明しています&lt;ref&gt;蛭田健司『ゲームクリエイターの仕事 イマドキのゲーム制作現場を大解剖』、翔泳社、2016年4月14日 初版 第1刷 発行、P80&lt;/ref&gt;。ただし文献では、セクショナリズムに陥らないように他人の担当範囲も積極的にカバーしようという意味での「全体のクオリティ」という表現を用いています。


;若干の例外
ただし、バランス調整前のテストプレイにも若干の利点もあります。作者がバランス調整すら終わってない、ほぼ未検証のエリアなので、もしかしたら大きなバグがある場合があります。そのような大バグがあるかないかを知れるのは、情報としては若干の価値があります。

とはいえ、やはり上述のように未調整エリアのテストプレイは二度手間になってしまうので、できるならば、なるべくバランス調整が終わった箇所からテストプレイでチェックしていくほうが効率的です。

無料ゲームならば、もし、なにかの締切などまでに間に合わず、バランス調整の追いつかないエリアが締切日に残ってしまったとしても、対応としては、単にその未調整エリアを一時的に封鎖する仕様にして対処すればいいだけなのです。（そして後日のアップデートで、バランス調整の終わったエリアを公開していく仕様に更新するなどの対応すれば済むので。）

なので、やはり、バランス調整しおわったエリアから順番にテストプレイするほうが、二度手間が無くなるので、効率的ではあります。

=== すべての組み合わせの検証は無理 ===
たとえばRPGなら、武器や防具といった装備の組み合わせは、
:もし武器（剣や槍や斧や杖や弓など）が合計で100種類、
:頭防具が合計で50種類（カブトや帽子）、
:胴ヨロイや服が合計で50種類、

だとしたら、組み合わせは装備だけでも合計で 100×50×50 ＝ 250000種類 （25万）にもなってします（いわゆる「組み合わせ発散」）。

つまり、もしすべての組み合わせを検証しようとすると、作業が指数的に増えてしまいます。しかし、こんなに多くの組み合わせを検証するのは個人では無理ですし、無駄です。

デバッグ検証はせいぜい、武器なら100種類の装備をすべて装備してみて、装備できるキャラクターが装備しても異常が無いかとか、戦闘で実際に攻撃を見て以上が無いかとか、そういうことを確認すればいいのです。

同様に、防具のデバッグ検証もそうです。

これなら、装備の検証作業は、100＋50＋50＝200種類なので、大幅に作業が減ります。

つまり、足し算、加算的に検証すれば、十分です。


実際の市販のRPGなら、さらに装備の数が多くなるでしょう。

また、どのキャラクターが装備するかとか、どこのエリアで装備するかとか、いろいろな組み合わせが実際のプレイにはありますが、もちろん、そんな検証をすべてするのは無理で無駄です。


上記の例ではRPGの装備システムを例にとりましたが、別にRPGやシミュレーションゲームなどのパラメータの多いジャンルのゲームに限らず、
異なるジャンルのたとえばアクションゲームやアドベンチャーゲームなどのゲーム内の各種システムでも同様です。

なのでデバッグは、ゲーム内の各種のアイテムやコマンドなどのデバッグなら、せいぜい、とりあえず、そのアイテムやコマンドなどを選択したり実行しても異常が無いかを1回だけ試せばいいのです。

そもそも、ゲームのシステムは基本的に、プレイヤーごとに異なる多様なプレイスタイルに対応するために多くのアイテムやパラメータやイベントをゲーム内部に持っていて、そういった組み合わせの意外性などをシミュレートして楽しむものです。

なので、組み合わせは膨大になるのが普通なので、全組み合わせの掛け算的な回数の検証は無理です。


テレビゲーム黎明期の1980年代なら、装備アイテムの数などが少なかったので、もしかしたら組み合わせをすべて試すのも可能だったかもしれませんが、しかし現代では、アイテムの数などは膨大に増えており、もう無理です。


なので、プログラマー視点では、もしバグがあっても、そのゲームをクリアできるようにゲームを設計する必要があります。このためにはどうするかというと、デバッグの困難な箇所は、そのゲームのクリア要件から外す、という手法で簡単に出来ます。とはいえ、イチイチ考える必要はなく、一般のゲームのクリア条件は普通、そういうふうになっています。たとえば対戦格闘ゲームなら、敵を打撃してライフをゼロにまで持っていけば、途中経過は問わないワケです。こういうふうに、クリア要件さえ満たせば途中経過は問わない、というふうにクリア要件を設定すればイイだけです。


また、現代の複雑化したゲームでは、ver1.00以降の発表後にも、アップデート修正が必要になる可能性が高いです。なので、ver1.00の発表前に事前にアップデート版の配布が可能な環境を整えておきましょう。

さらに、もし有料ゲームのアップデート配布の場合なら、なるべく
:有料版ソフトを買った人'''だけ'''に、'''無償で'''アップデート適用ずみの'''フルパッケージ版'''を配布できるような環境
があるかを事前に環境準備しておく必要があります（「修正パッチだけ無料公開」とかではなく、すでに修正パッチを適用した状態でのフルパッケージ版という意味。消費者が有料で購入しているのだから、修正パッチ適用などの手間を掛けさせない。）。

いちおう、差分アップデート的な修正パッチ適用という方法もありますが、しかしバグが比較的に軽微な場合にのみ有効な方法です。バグがもし致命的な場合、差分パッチでは修正が不可能になることもあります。


個人でそういう配布の環境を構築するのは困難なので、個人の場合には、ネット上のいくつかの企業がソフトウェア公開・販売環境を提供している企業がいくつかあるので、そのサービスを利用すると良いでしょう。

さらに、アップデート版のソフトウェア内部のシステムでは、過去バージョンの有料ゲームから、最新の修正後バージョンへのプレイデータの引継ぎをできるようにする必要があります（たとえばRPGの場合、プレイヤーにレベル1の序盤から再開させるワケにはいかない）。このデータ引継ぎの工夫は、ソフトウェア販売サービス提供の企業では無理なので。
:（なおこのため、セーブデータの構造を変更するような修正は不可能か、大幅に制限があります。アップデートによるキャラ追加などは可能ですが、パラメータの構造そのものの変更などは、リリース後は不可能または困難でしょう。ゲーム中のシナリオ進行度合いの保管なども同様、リリース後の変更は困難です。）


もし、上述のようなアップデート配布が不可能な環境にあるのなら、そのゲームが個人製作のゲームの場合には、無料ゲームソフトにしておきましょう。

ゲームにかぎらず一般に有料ソフトを販売した場合には、開発元のメーカーは「保証期間」または「アフターサービス」のような社会的責任として、発売開始後から数年ていどは無償で不具合対応などのアップデートをすべきという社会的な責任があります。

食料品やティッシュペーパーのような消耗品でないかぎり、ソフトウェアにかぎらず一般の工業製品などでも企業は商品の有料での販売においては、発売開始後から数年は、「保証期間」などとして無償または低価格の不具合対応などの社会的責任が要求されます。

無料のソフトではそこまで保証する義務は無いですが、まあ実務の練習だと思って「保証期間」的なものも頭の片隅に意識しておいたほうが無難でしょう。

=== ソースファイルにモニター（監視）機能を入れる ===
主にアルファ版や新機能の追加時のテスト方法ですが、

もうひとつのバグ発見の方法として、「'''printf デバッグ'''」と俗に（ぞく）言われる手法があります。

これは単純で、printfなどの文字表示をするためのプログラム文で、バグに関連しそうなパラメータを画面中に表示して、異常がないかを監視する方法です。

ただし Windows のVisual C++ デスクトップアプリの場合、コンソール用の printf では文字表示できないので、  TextOut 文で表示する事になります。（※ Windows API プログラミングについては  wikibooks『[[Windows API/文字表示の命令]]』などを参照せよ。） Visual C#でも命令文は異なりますが、同様に printf ではなく別の命令文ですので、それぞれのプログラム言語にあわせた文字表示命令の関数をつかうことになります。


ゲーム内のシステム内部の監視のためのデバッグ用メッセージ（「現在のパラメーター herosPower は 134 です。」のようなメッセージ）を表示するモニター的な機能は、（ユーザーに公開するゲーム実行ファイルではなく）ソースファイル側で行うとよいでしょう。

なぜなら、プレイヤーが細かいシステムメッセージを見ても退屈ですので。

一般にゲーム開発では、作者用のソースファイルと、プレイヤー用のファイルを分けるので、作者用のソースファイルにデバッグ用の機能をいくつか入れておく方法もあります。


;まずテストプレイしよう
アルファ版でもベータ版でも、まずバグ発見のためには、モニター機能プログラムを書くよりも先に、まず先に実際にゲームを起動してゲームをプレイしてみることです（いわゆる「テスト プレイ」）。テストプレイで挙動のオカシイ部分があったら、そこで、ソースコードで、挙動のおかしい箇所のプログラムの近辺で、変数の内容を表示する機能のあるモニタープログラムを自分で書きます。

なお、モニタープログラムは本wiki本ページの独自用語です。ゲーム業界でどう言ってるのか知りません。


;ブレークポイントは後回し
なお、WindowsのVisual Studio には、ブレークポイントという、デバッグ用にコード中に強制停止するポイントを設定する機能があり目的の箇所でコードを停止させ、変数を表示させる機能がありますが、しかしこの機能（ブレークポイント）をいきなり使うのは、ゲーム製作では、あまりオススメできないです。

なぜなら、ゲームが止まってしまうので、実際のプレイ中でのパラメータの変化が不明です（ブレーク時点での変数の値しか、分かりません。）。


ブレークポイントを使う場合は、起動そのものの不可能なバグとか、ゲームが異常停止していまうようなバグの場合などの、テストプレイそのものが困難な重篤なバグの場合にだけにしましょう。

テストプレイが可能なていどのバグなら、なるべく実際にゲームをテストプレイして、モニタープログラムでバグの性質をさぐったほうが早いです。


;モニタープログラムは最小限にするのがコツ
しかし、まだバグの見つかって無い段階で、モニタープログラムを入れるのは、オススメできません。なぜなら、ソースファイルが見づらくなるからです。

だからバグが見つかってから、関連しそうな変数を表示するモニタープログラムを書きましょう。つまり、モニタープログラムは最低限にするのがコツです。

そして、バグが修正し終わったら、そのモニタープログラムのコードは、量が多くなってきたら場合は、さっさとソースコードから該当する変数のモニタープログラムをコメントアウトするなどして、非表示にしてしまいましょう。

なんでもかんでもシステム内メッセージを画面に表示したとしても、メッセージを読みきれないので無理です。

また、あまり、ソースファイル独自の機能を追加しすぎると、一般にソースコード自体が読みづらくなります。

=== 典型的なバグ ===
==== 配列のバグ ====
ゲームを作る場合、典型的かつ重大なバグは、配列に関するバグです。どのゲームでも、配列を使います。

極端な事を言うと、配列以外の変数名などの不一致のバグなどは、Visual C++ で作っている場合なら、変数名のバグはそもそもコンパイルできない場合が多いので、コンパイラが自動的に変数名のバグを発見してくれます。

必然的に、残されたバグは、配列のバグと、あとはゲームの仕様に一致してないという類のバグです。

仕様に一致しているかどうかは、コンパイラでは発見できないので、プログラマーやテスターなどが自力でテストプレイによって発見する必要があります。


配列のバグでよくあるバグは、下記のようなプログラムミスが多いでしょう。

* 典型例
;宣言数よりも番号が多いバグ
配列で、たとえば &lt;nowiki&gt;hairetu[10]&lt;/nowiki&gt; の10個までしか宣言してないのに &lt;nowiki&gt;hairetu[13]&lt;/nowiki&gt; を呼び出すなどのように宣言した数以上に呼び出したり、よくあるバグです。


;数え間違え
また、配列の番号は0番から数え始めるので、 &lt;nowiki&gt;hairetu[0]&lt;/nowiki&gt; から &lt;nowiki&gt;hairetu[4]&lt;/nowiki&gt; までの5つしか値を用意してないのに &lt;nowiki&gt;hairetu[5]&lt;/nowiki&gt; を呼び出してフリーズしたりなど、よくやるミスです。


==== 音声バグ ====
プログラミングは集中力を使うので音声をオフにしてプログラミングする場合もあります。

ツクールやウディタなどで制作ツールで開発している場合はそこまで集中力が無くても何とかなりますが、
しかしC++などプログラミング言語で開発している場合、かなり集中力を要します。

よって、このような場合、プログラマー側でのテストプレイ時に音声をオフにしている場合があります。


だからテスターとしては、こういう事情も見越して、音声を聞きながらテストプレイする必要があります。


特にゲーム中で1回しか起こらない特殊イベントなどは、そのプログラムを特注的にプログラマーが作っているので、
バグが混入しやすくなります。

たとえば、テスター依頼を受けたRPGで特殊イベント「封印の壁の破壊」というのがあったとして、仕様では、
:貴重品アイテム「魔法の爆弾」が、
:場所「封印の壁」のすぐ前で使うと「ドッカーン」と音声とともに1回だけ爆発して、
:壁が崩れて通行可能になる、
という仕様だとしましょう。

この際、バグで「ドッカーン、ドッカーン、ドッカ－ン、ドッカーン（以下略）」と1個しかないのに何発も爆発する音声が流れ続けるバグなど、
ありがちです。

あるいは、最初にこの「封印の壁の破壊」イベントを実装したバージョンでは何事もなく正常でも、その後のプログラム改修によって不整合が起きて、この部分にバグが起きたとしても、プログラマー側のテストプレイではたびたび、こういう音声バグは見落とされます（集中力のため音声オフにしている場合が多いので）。

だからテスター専門として活動している場合は、必ず音声を聞きながらテストプレイしましょう。


=== バグの発見後の原因調査の方法 ===
バグそのものの有無は、テストプレイによって発見できます。

ですが、そのバグを引きおこしている原因の探査は、テストプレイだけでは不可能です。

こういったミスを発見する方法も、上述のように、printfデバッグ的にモニタープログラムを書くことでパラメータの動向を追う事で、バグのありかを限定していきます。

（正常な値の数値がprintfデバッグの画面に表示されている場所にはバグがないので、つまり、まだ確認されてない残りの場所にバグが潜んでいます。）

そして、上記printfデバッグのような方法でテストプレイ中にモニタリングしつつ、バグ発生箇所の周囲でテストプレイを色々なパターンで試していくことにより、バグの発生原因などを絞り込んでいきます。

なお、通しプレイは、このプログラミング段階でのデバッグでは（通しプレイは）不要です。この場合、すでにバグの発生箇所は限定されて分かっいるので、上述のように局所的なチェックによるテストプレイをしていきます。


そして、バグ原因を突き止められてコードが修正し終わったら、コードの修正後に再度、局所的なテストプレイで何種類かの行動パターンでチェックします。ここでは、テストプレイは不要です。（通しプレイは後でまとめて行う。）

一つのゲーム開発につき、バグ発生箇所は何十個や何百個も存在しており個数が多いので、通しプレイは 後で まとめて 行いますので、この段階ではまだ通しプレイは行いません。


=== 共通作業の自動化・省略化　 ===
文献『ゲームデザイン プロフェッショナル』（塩川洋介 著）では、「調整」の説明ですが、「手動で毎回行っている繰り返し作業を、あらかじめ登録した一連の処理として自動的に実行するプログラム」を作っておくと、調整が効率的だと、塩川氏は述べています&lt;ref&gt;『ゲームデザイン プロフェッショナル』、P.159&lt;/ref&gt;。

塩川氏の意見ではないですが、開発中ゲームのプログラマーによるデバッグでもこのような繰り返しの場面はよくあります。

たとえば、所持アイテム数がなぜか8品（8種類のアイテムを持っているとする）ある場合にだけ画面がフリーズするバグがあったとして、
そのゲームの初期状態では所持アイテムは0品（アイテムがない状態）だとしましょう。

プログラム修正は、けっして一度で修正できることはまずないので、五回や十回とか、何度もテストして、修正できているか確認することになります。

この場合、プログラム修正作業中のテストを何回もするたびに、いちいちアイテムを0から開始して8品目まで買い揃えたり、そのために敵を倒してゴールドを稼ぐのは、面倒です。

だから最初から、アイテム8品をもった状態のデータをゲーム中に作っておきましょう。そうすれば、テストが効率的です。要するに、テスト作業中に何度も繰り返す工程の自動化です。


すでにバグがあると分かっている箇所や、通常プレイだとテストしたい状態の準備に著しく時間が掛かる部分など（たとえばゲーム後半の状態や、やたらと長いダンジョンの出口の直前または直後の状態など）、あらかじめその直前の状態にワープできるシステムがあると、テストが効率的です。経験値やゴールドをためるのも時間が掛かるので、何らかの方法でプログラマー側では作業をカットできるようにして、つまり既に主人公が高レベルで強い状態に設定変更できるなど、そういう機能が必要になるでしょう。

ゲームのオリジナルの初期値データを書き換えると他のバグを起こして怖いので、デバッグルームにそういう機能を導入するなどして、けっしてオリジナルデータとは混在しないようにする必要があります。上手く自動化をしてください。

こういうデバッグ機能を使ったテストが、プログラマー側による局所的チェックのひとつになるでしょう。

ゲーム開発初期のデバッグでは、そこまでする必要はないでしょうが、しかしゲームの完成度がだんだん上がっていくにつれ、次第にそういう自動化の必要性が出てきます。

また、こういう設定準備の自動化の機能は、バグ修正テストだけでなくバランス調整にも活用できるので、こういった機能があると一石二鳥です。というか、もともと文献『ゲームデザイン プロフェッショナル』では、バランス調整のための機能として紹介されているくらいです。

=== デバッグルームなど ===
==== デバッグルームとは ====
ゲーム内でめったに起きないイベントなどのデバッグは、通常のプレイ方法では、めったに遭遇しないために発見が困難になります。

たとえば、ゲーム内でくじ引きがあり、1000分の1で大当たりが出るとしましょう。（※ 説明の単純化のために、極端に確率を低くしている。実際のゲーム製作では、低すぎる確率は避けたほうがデバッグしやすく安全である。）


通常のプレイでは、このくじ引きを1回だけしか出来ないとしましょう。


このようなイベントのデバッグ検証の場合、「大当たり」にバグがないかは、デバッグ用に、ゲーム作者だけ、くじびきを何百回も続けてチャレンジできるようにしたりとか、あるいは、ゲーム作者だけ、くじ引きの結果を操作できるようにして強制的に「大当たり」が出たりするようにするとか、

そういう作者だけの特殊システムが必要になります。一般プレイヤーには、デバッグルームには入れないように、対策する必要があります。

たとえばファミコン版のドラクエ2やドラクエ3には、「死のオルゴール」という、使用するとパーティが全滅するという謎のバグアイテムがあり、普通のプレイでは絶対に入手できません（バグ技などを使う必要がある）。おそらく「死のオルゴール」はデバッグ用のアイテムだろうと思われています。

これがもし「全滅スイッチ」とか「全滅ボタン」とかだったら、なんか機械的で、ドラクエの中世西洋ファンタジーの世界観に雰囲気に合いません。もしバグでプレイヤーに「全滅スイッチ」が見つかったら、プレイヤーの抱いていた世界観のイメージが崩れます。

でも「死のオルゴール」なら、もし万が一、プレイヤーが発見しても、「オルゴール」という中世からある楽器の名前なので、なんとかゴマかせます。


このような、デバッグ用の作者専用システムのことを、俗にゲーム業界では「デバッグルーム」とか「デバッグモード」とかいいます。デバッグルームとは「デバッグの部屋」という意味です。作品によっては、実際にゲーム内に「デバッグルーム」というエリア、ステージを用意する場合もあります。

この機能を作者が使うことを「デバッグルームに入る」とか「デバッグモードをオン（ON）にする」いいます。

名前こそ「デバッグルーム」や「デバッグモード」などというものの、しかし、その場所ではバグそのものの退治・修正はしないですし、そもそも、ゲーム起動中にバグ修正は不可能です。

最終的にバグを修正するには、（ゲームをシャットダウンさせてから）ソースコードを開発ツールなどで直す必要があります。

「デバッグルーム」とは、単にゲーム内でバグ探しの作業をしやすいように、プレイヤーキャラクターを強化したり、あるいは敵を弱体化させるなどの環境を調整するだけなのが、デバッグルームです&lt;ref&gt;STUDIO SHIN 著『ゲームプランナーの新しい教科書』、翔泳社、96ページ、2018年3月10日 初版第2刷発行、264ページ&lt;/ref&gt;。


背景として、基本的にはプレイヤーキャラクターが強めのほうが、ゲーム内世界をいろいろと探検しやすいのでバグは発見しやすくなります。


なぜならゲームでは、たとえばRPGでゲーム終盤の強敵を倒したときに発生するバグなどは、主人公がゲーム序盤の弱いキャラクターの状態では無理です。一方、ゲーム序盤の弱い敵に主人公が負けるなら、単に油断したり無防備になればいいだけなので、主人公は強いままでもデバッグ可能です。

「大は小を兼ねる」といいますが、ゲーム内では強めのキャラは弱めのキャラを兼ねます。

しかし、その逆は困難です。


なので、たとえ、デバッグ用の機能の名前に「デバッグルーム」などの名前がついていなくても、もし裏技や隠しアイテムなどでプレイヤーを強化するものがあれば、実質的にデバッグモードでしょう。

また、ゲームクリア後に、初回プレイよりも強い状態でニューゲームを出来る機能があれば（いわゆる「強くてニューゲーム」）これも実質的にデバッグ機能として活用できます。ゲーム序盤～前半のイベントに潜むバグなどを探すには、「強くてニューゲーム」のような機能があれば便利でしょう。


プレイヤーによっては、「デバッグ」などのIT用語を嫌がる人もいるので、そういうのに気をつける必要もあります。

また、ゲームのジャンルによって、近未来SFファンタジーやSFアクションなどでは、ゲーム中のシナリオにもIT用語が出てくるので、そういうのと区別するために「裏技」などの言い換えをしたほうがいいかもしれません。

==== デバッグルームの建築 ====
さて、デバッグルームを建築する際は、なるべく、既にそのゲーム内にあるシステムを流用します。なるべく、一般プレイヤーにも公開されている機能を組み合わせてルームを作る必要があります。そうしないと、デバッグルーム独自機能の検証の手間が増えてしまうので、かえって、メンドウになってしまいます。


デバッグルームの中では、普通のプレイヤーが操作できないものを操作できるようにします。たとえば、RPGなら、プレイヤーキャラのレベルをある程度の上昇させたり下げたりとか、主人公の入手している武器や防具ある程度の範囲でを操作したりとかの機能が必要です（けっして、完全に数値をピッタリ調整する必要はないです。最終目的はあくまでバグ発見です。けっして数値をピッタリと調整することは目的ではないです）。

RPGなら、たとえば、強めの武器や防具をいくつかデバッグルーム内においておいたりとか、あるいは、通常プレイでは商店では非売品の武器・防具をデバッグルーム内では有料（ゲーム内の通貨）だが販売しておくとかすれば、万が一、一般プレイヤーがデバッグルーム内に進入してしまっても安全です。

あるいは、デバッグルーム内に、経験値アップや、レベルアップなどのアイテムとかをいくつか置いておくと、レベル上げの手間が減ります。

このようにデバッグルーム内に強化システムを配置しておくと、ゲーム後半のイベントなどの検証も、ラクになります（キャラクターの育成などに掛かる時間などが短くなるので）。


くじ引きの「大当たり」などのイベントをデバッグ検証で容易にしたいなら、デバッグルーム内に、たとえば「幸運のお守り」のような感じのアイテムを置いておいて、それを装備すると、ゲーム内のくじ引きなどの大当たりの確率が100％になるとか50％になるとかの機能をつけておいて、そういうふうなアイテムを作っておけば、くじ引きなどの検証がラクになります。


さて、一般プレイヤーには、デバッグルームには入れないように、対策する必要があります。

まず、デバッグフラグをオフにします。デバッグフラグがオンの状態でないとデバッグモード起動しないようにプログラムします。

しかし、それだけでなく、さらなる安全策が必要です。

たとえば、作者のファイルにだけ、デバッグルームに入れるアイテム（「デバッグルームの鍵」など）とかを、そのままの名前だと万が一プレイヤー側にバレると世界観が壊れるので、なんかファンタジーっぽい名前に変えるなどして作者データに設置するとかして、実装します。一般プレイヤーに配布するゲームデータには、デバッグルームの鍵などを与えないようにします。デバッグルームの場所は、ゲーム内の中盤や後半に隠して立てておくと安全です。

あるいは隠すのではなく正式な公開機能として、ゲームクリアしたプレイヤーに、デバッグルームの一部を開放するなどする方法もあります。こうすると、あまり気にやまなくても済みます。

または、ゲーム開始のオープニング画面中に、画面には表示されてないが実はパスワード入力を受け付けしている状態を起動させておいて、パスワードが正しければデバッグモードがオンになった状態でゲームを開始できるようにするとか、そういう方法もあります。パスワードの受付をしているのを、プレイヤーには見せないようにします。

アクションゲームなど、あまりRPGのようなアイテム配布をしづらいようなシステムの場合は、この裏技のような方法のほうが便利でしょう。


裏技システムの場合、もし一般のプレイヤーがたまたまデバッグルーム用パスワードと同じキー配列を入力しないように、パスワードは十分に複雑にしておくとかの工夫が必要です。万が一、パスワードを運よく一般プレイヤーが知らずに偶然に入力してしまってゲームを開始した場合でも、プレイヤーがゲームプレイを楽しめるように、「これは裏技モードです」とかとでも冒頭で紹介しておいて、プレイヤーキャラクターの強さを（通常モードと比べて）やや強めに変更するくらいの設定にしときましょう。

1980年代のファミコンなどの市販ゲームで、こういう「裏技」（うらわざ）がよくあります。おそらく、そのソフト開発者がデバッグ用に残した機能だったのでしょう。


{{コラム|プログラマーの小部屋づくり|
実は、Visual C++ などのプログラミングでRPGを作るとき、

おそらく最初に作ることになるだろうマップが、

プログラマーが作成コードのデバッグ用にいろいろとキャラクターを操作するための、デバッグルーム的な小部屋です。


たとえば、その部屋の中に、位置固定のモンスターがいたり（戦闘チェック用）、武器防具屋や宿屋があったり（買物チェックおよび全回復チェック）、村人Aがいたり（会話イベントチェック）、冒険者の酒場の受付嬢がいたり（パーティ編成チェック）、とかです。

なぜモンスターと冒険者酒場の受付嬢が同じ場所にいるのか、ストーリー的には意味不明ですが、しかしプログラマーが動作確認する目的ならば何の問題もありません。

だって、たとえば戦闘のコードのテストをするのに、いちいちオープニングイベントとかを2分間も見たあとに王宮から城下町を通って洞窟に行くのを、テストのたびに繰り返すの、とても面倒じゃないですか。

あと、本編マップとか考えるのも面倒くさいです。


ツクールやウディタだけでゲーム制作していると気づきませんが、まあこういうプログラマーのための小部屋づくり（ゲーム業界で何というのか知りません）が、C言語などでのRPG制作にはあります。


さて、仮にプログラマーがデバッグ抜きでゲーム本編をとりあえず一通り作り終えたとします。

これからデバッグのために（上記のプログラマー部屋ではなく）デバッグルームを作る際、よくよく考えたらゼロからデバッグルームを作る必要はなく、以前に作ったプログラマー部屋を流用するだけで済みます。

たとえばいきなりレベル99とかにしたいなら、

すでにプログラマー部屋のほうで、どうせ戦闘デバッグ用に固定モンスター出現イベントとか作ってるので、そこに経験値999999999999とかでHP1とかHPゼロの弱いザコ敵でも置いとけば済みます。

あるいは、主人公がLv1の状態で最強武器（たとえばエクスカリバー）をいきなりゲットしたい場合でも、どうせプログラマー部屋のほうに宝箱とかあるんだから、その宝箱にエクスカリバー1本を入れとけば済みます。

とても楽チンです。
}}

=== 個別チェックと通しプレイ ===
==== まずは個別チェック・局所チェック ====
===== 総論 =====
ゲームで新しい機能を追加した場合、たとえばデバッグモードなどの機能を使ったりしてでもいいので、

まず、その追加したばかりの機能が実際に動作しているかを、（デバッグモードでいいので）プログラマー自体がチェックします。

もし集団作業なら、これはプログラマー本人がまず率先して、ある程度は自分たちでデバッグモードによるチェックをやる必要があるでしょう。（いちいち他の部署に作業を回すと、かえって時間が掛かってしまう。）

また、集団作業でなく個人製作でも、まずデバッグモードでも何でもいいので、追加したばかりの機能をチェックします。この個別チェックというか局所的なチェックでは、けっしてバランス調整などをする必要は無いです。

個別チェック・局所チェックと、バランス調整とは、目的が異なります。個別チェック・局所チェックでは、単に、デバッグモードなどで、その項目だけをチェックします。

もしデバッグモードの機能が無いゲームの場合や、製品に近くデバッグモード不搭載のバージョンの場合には、デバッガーは、なるべくデバッグモード利用時に近いプレイ方法で、個別にチェックしていきます。

===== 異業種との関連 =====

ソフトウェア業界だと、個々の部品ごとにチェックすることを「単体テスト」といいます。一方、全体的に組みたててみてチェックすることを「ビッグバンテスト」と言います。


{{コラム|両立するには、とりあえず「交互」|
「交互」に関する余談だが、週刊少年ジャンプに2008～2010年連載していた『ヘタッピマンガ研究所R』またはジャンプ中のその関連記事では、
読者などからの相談・質問などの 「どうやったら立体感もあってデフォルメもされた絵を上手く描けますか？」
という問いに対し、回答者の漫画家・村田雄介は、おおむね「交互に、写真の精密模写と、マンガ絵のデフォルメの練習を、僕はしてきました」といったような感じの回答を言いました。

私たちのゲーム用の教訓としてこの考えをアレンジするなら、初めて挑む分野でスケジュールの配分やらの何やらの良く分からない仕事は勉強や、とりあえず「交互」にすればいいのです。あれこれ理屈ばかり悩む前に、さっさと交互に実行を始めれば済みます。

なおこの漫画家の村田氏は、子供時代にカプコンのゲーム『ロックマン』の敵ロボの募集企画に応募したハガキが採用される（「ダストマン」が採用された）ぐらいにはゲームキャラのデザインの実績ある実力者でもあります。


写実練習ついでに別の余談を話すと、同じ2008～2010年ごろ、たしか少年ジャンプあたりの雑誌で、かつてボボボーボ・ボーボボの連載してた若手（当時）の漫画家と、ハンターハンターの漫画家との対談で、
:若手が「自分はデッサン練習する前に漫画家デビューしてしまいましたが、どういう練習したらデッサン力つきますか？」という内容の問いに対し、
:ハンターハンター作者は「マール社のポーズカタログ集（※wiki追記: というヌードポーズ集がある）を模写するのが、おすすめだよ。あれやるだけで、僕ぐらいのマンガ絵に必要な程度のデッサン力なら、かなり近づく」というような感じのことを言いました。


そういう美術用の専門のヌードポーズ集があるのです。パンツ一丁のモデルの男女をそれぞれ別に、正面カメラ、横カメラ、斜めカメラで撮影した写真集があるのです。

だからいちいち、エロ本を購入する必要はありません。大体、エロ本なんて掲載ポーズが片寄っています。まあ当然です。ポーズ集ではないのですから。

エロ本は、不自然に腰をくねらせていたり、腹をひっこめていたり、腕を寄せて乳房を抱えていたり、ポーズが片寄っています。

しかしデッサン練習では、まずはモデルが普通に力を抜いて起立して立ってたり、あるいは普通に正座してたり体育ずわりしてたり、そういうポーズが必要なのです。そういう基本のポーズ集を模写して人体の比率を頭に叩き込むのが、漫画業界的な写実デッサン練習です。


エロ本などが必要なのは、エロマンガを描くときです。だからエロ漫画家の江川達也は、少なくとも90年代はAV（アダルトビデオ）マニアで有名です。江川のGOLDEN BOY のOVA版でも、最終話のアニメ会社勤務回では、作中のアニメーターが江川作品のアニメ製作ではエロ本を参考にしてます、とメタ発言しています。
}}


重要なのは、ゲーム開発のデバッグにおいても、実際に「通しプレイ」というビッグバンテストが必要だという事です。「ビッグバンテスト」という名称の知識は、割とどうでもいいです（知識の無いよりかは、あるに越した事はありませんが・・・）。

本書は製造業ではなくゲーム開発の教科書なので、これ以上の製造業でのチェック方法への深入りを避けます。

なお、アニメ業界でも、1990年代くらいまでは、アニメ業界での分業による生産システムを説明するのに、自動車産業などでの分業になぞらえてアニメの分業を説明したりする説明手法がよく行われていました。


デバッグではないですが、バランス調整や各種の演出・シナリオなどの面白さの確認でも、実際に通しプレイで確認する必要があります。商業ゲームでも、任天堂が『ゼルダの伝説　時のオカリナ』では、社員300人で通しプレイで最初から最後まで実際にプレイして確認したという手法でチェックしているというノウハウを公開しています&lt;ref&gt;[https://news.denfaminicogamer.jp/projectbook/zelda/4#i-2   『まず2Dゲームで開発、社員300人で1週間遊ぶ!? 新作ゼルダ、任天堂の驚愕の開発手法に迫る。「時オカ」企画書も公開！ 【ゲームの企画書：任天堂・青沼英二×スクエニ・藤澤仁】』 2017年3月2日 12:03  ] 2020年12月1日に確認.  &lt;/ref&gt;。

ネットのバイト紹介記事などだと、こういう社員での通しプレイによるチェックなどは紹介されませんが、順序的には、チェックシートによる細かいチェックよりも、まず通しプレイチェックのほうが先です。

任天堂の場合も、デバッグを開発初期と終盤とで別々の方法に分けて、開発序盤からデバッグしています。（[https://game.watch.impress.co.jp/docs/news/1078888.html  岩泉茂『【CEDEC2017】「ゼルダの伝説」作成を裏から支えたエンジニアたち　大規模プロジェクトをいかに効率的に乗り切るか』 、2017年9月4日 07:00]。） 開発初期のデバッグでは、ゲームの面白さに関わる部分のデバッグを優先的に修正していきます。開発終盤では、製品化やリリースなどにむけて、今まで後回しにしていた細かいバグも修正していきます。

大規模なゲーム開発になると、開発初期からデバッグしないと、発売日・リリース予定日・公開日までに間に合いません。

しかし開発初期ではまだ全体像が出来ていないので、ゲームの土台の面白さが確認できたあとには、先にゲームの全体像を（細部はいいので）作らせることを優先します。これは任天堂だけでなく、女神転生シリーズのアトラスも類似の開発手法をとっています。アトラス社では「ゲーム全体に血を回さなければならない」という格言があります&lt;ref&gt;[https://news.denfaminicogamer.jp/projectbook/191030a/2  『【ゲームの企画書】『ペルソナ3』を築き上げたのは反骨心とリスペクトだった。赤い企画書のもとに集った“愚連隊”がシリーズを生まれ変わらせるまで【橋野桂インタビュー】』2019年10月30日 11:30] 2020年12月1日に閲覧して確認.&lt;/ref&gt;。

このように、実際にゲーム全体をゲーム序盤からエンディングまで一通り作ってみないと分からないので、まずは先にエンディングまで作ります。そのあと、細かい作りこみやデバッグなどの細部を仕上げていきます。

まとめると、順序としては、
 ゲームの土台の面白さ確認（2Dなど単純なものでよい）
 → ゲーム全体を作る
 → ゲームのエンディングまでのとりあえずの完成後、細部の作りこみ
のように、段階が分かれていきます。

なので、それぞれの段階に適して調整方法なりデバッグ等の方法を変えていきます。

また、社内デバッグでは、テスター専門のヒト以外にも、各種のアーティストやプログラマーなどもテストプレイに参加しましが、彼らは本業のアート素材制作（ゲームに組み込みためのイラスト素材、音楽素材などの制作）で忙しいので、バグ報告後の次バージョンでの修正チェック確認などはテスターが受け持ちます（任天堂がそうしています）。

===== 各論 =====
;全装備品の装備、全アイテムの使用など
たとえば、RPGの装備品のシステムが正常に動作しているかどうかを確認するためなら、とりあえず、すべての装備品をいったん装備および装備解除してみる、というような作業をします。

これは、一般プレイヤーがゲームを楽しむ方法とは、異なります。

ですが、デバッガーは、こうして確認をしていきます。

たとえばRPGなら他にも、すべての道具をとりあえず最低1回ずつは使ってみるとか、

到達可能なマップチップには、すべてのマップチップの上を歩いてみるとか、そういう事をします。


とはいえ、これらは普通のゲームプレイでも、プレイヤーによっては、アイテム効果確認や隠しエリア探索などのために、よくやる事でもありますので、これはまだ楽しいほうです。

;通行止めの確認
さらに商業ゲームでは、たとえば、壁（かべ）の通行不能の処理が、本当に壁として行き止まりになっているかとか、通行止めであるかとか、そういう行き止まりチェックみたいな事も、します。

なお、この、本来なら行き止まりであるべきの壁が通れるバグのことを通称「壁抜けバグ」と言います。壁以外の海とかガケとかの行き止まりも含めて一般的な言い方をすると、「通行（つうこう）判定バグ」または「通行設定バグ」などと言います。

なお、「進行（しんこう）不能バグ」は、これとは意味が異なります。「進行不能バグ」とは、ゲームのストーリを進められなくバグのことです。


デバッグ（テストプレイ）でツライ事の一つは、この「通行（つうこう）設定バグ」の有無のチェック、つまり行き止まりチェックでしょう。

もし、スーファミ風のドラクエ・ファイファン的なゲームのようにマップがマス目で作られている2D-RPGの場合、デバッグ仕事でなら、すべての壁マスの通行設定を確認する事になります。

アクションゲームやアクションRPGの場合、すべての壁を1ドットずつ通行設定をチェックするのは、不可能です。なのでアクションゲームなどの場合、
:とりあえず壁にぶつかって突進ボタンを押しつつ、横移動ボタンも押して移動するなどして、確認したりとか、
:横移動ボタンを一瞬入力して少しだけ横移動した後にカベに突進、その後、また横移動ボタンを一瞬入力して横移動した後にカベに突進を繰り返す、・・・を繰り返してカベの右端から左端までチェックするのを、さらに何周も繰り返すとか、
でしょうか。(ということは、アクションRPGゲームまたはそれ風のマップ移動システム搭載のRPGでの壁通行設定チェックは、とてもハードな業務だという事になります。一方、アクションRPGでも、もし移動の単位が1ドットではなくマス単位だったら、頑張って1マスずつカベ通行設定をチェックするべきなのでしょう。)


ゲーム中で特に重要そうな壁のテストの場合、おそらく上記テストに加えてさらに、たとえば壁に向かって突進するのを何十回も、毎回微妙に突進先の位置を変えつつ突進するとか、あるいはナナメ移動とかジャンプしながら壁に突進するとか、色々と試すのかもしれません。

当然、とても面倒です。

なのでフリーゲームだと、この行き止まりチェックはよく、省略されます。なのでフリーゲームでは、ver1.00公開直後には、よくあるバグで、本来なら行き止まりのハズなのに通行可能になる壁のようなモノの存在するバグが、よくあります。

{{コラム|いくつかの通行バグの典型例|
;壁の窓や草など
壁のテストは基本的にはすべてチェックすればいいのですが、時間が無いときなどに短時間でチェックするために特にバグが発生しやすい場所をしいてあげるなら、

2D-RPGの場合、たとえば住宅の壁なら窓があったり絵が飾ってあったり、とにかく壁に何かあったら、まず通行バグを用心するのが鉄則でしょう。

屋外での崖や洞窟や壁や、海や湖などの仕様上では通行不能な場所でも、壁に石や草や花などがあったり、水辺に木片とか何か落ちてたら、まず通行バグを用心するのが鉄則です。


;斜め壁のバグ
この他、テスターでない人には周知されにくい話題ですが、斜めの壁も用心です。

斜め移動システムのあるゲームの場合が問題であり、たとえ上下左右の4方向移動だけなら通行止めできていてもい、しかし斜め移動の通行止めができていないケースがあります。

具体的に言うと、下記のようなマップ配置では、斜め壁は、斜め移動で貫通できてしまいかねません。A地点からB地点に一直線に貫通できるバグが、少なからずあります。

* バグの多い例
&lt;pre&gt;

         A
          ／壁壁壁壁
          壁／
          壁  B
          壁
&lt;/pre&gt;

だからこの場合、下記のように修正しなければなりません。

* 修正後
&lt;pre&gt;
         A
          ／壁壁壁壁
          壁壁壁壁壁
          壁／
          壁
&lt;/pre&gt;

このように、バグ防止のために南北方向の壁の厚さが変わります。つまりRPGのマップ配置は、実はデバッグの都合によっても左右されています。

もし斜めの壁のあるマスがプログラムに絶対に通行不能な仕様なら良いのですが、しかし作品によっては立体感を出すために斜め壁のあるマスが通行可能マスになっている作品もあり、そういう作品では上記のようなバグに用心する必要があります。


;斜め壁が2マス以上つづく場合の想定が必要
さて、前段落の方法とは別の解決法として、とえばA地点側にキャラがいるとき、「キャラの真下とキャラの真右が通行不能だった場合には、斜め右下には通行不可能」というプログラムを組んで、とりあえずの通行止めをしたとしましょう。

実はこの改修プログラムには欠点があります。しかし、下記マップのように、うすい壁が2つ続いている場合が想定モレであり、貫通バグの発生です。

:バグあり
&lt;pre&gt;

          A ／壁壁壁
   C      ／／       D
          壁  B
          壁  
          壁
&lt;/pre&gt;

上記マップは、たとえプログラム改修済みであってもAからBに貫通できてしまいます。なぜなら、A地点の右となりも真下も通行可能の斜め壁ですので。

なおC地点から一直線にD地点に向かっても貫通できてしまいます。

A側の壁が1つしかなければ貫通を止められるのですが、しかしA側の壁が2つ以上ある場合はもう貫通を止められません。

他の解決法としては、そもそも斜めの壁のマスを通行不能にするという方法もありますが、その場合はもう、斜めの壁に密着することはできませんので、そういう演出はできません。

あるいは、上記マップのような2マス続いている薄い壁にだけ、専用の通行判定プログラムを採用する、などの方式もあります。


結論として、どういう方式を取るにせよ、マップ配置はデバッグの影響を受けますし、マップ上で採用したいナナメ壁際でのキャラのグラフィック演出などもデバッグの影響を受けます。

;創作するつもりがないなら、創作技法の余計な勉強はしないのが安全
前段落のように、ゲームの演出はデバッグの影響を受けます。だから、観客がゲームの仕組みをあまり知りすぎると、観客はゲームを素直に楽しめなくなってしまいます。手品と同じようにタネや仕掛けが分からないからこそ面白いのです。あるいは推理小説のようなもので、トリックが分からないから楽しめるのです。

ゲームにかぎらずマンガやアニメも同様でしょう。エンタメ系コンテンツの作家が仕組みや技法を黙っているのは、別に消費者への嫌がらせではなく、観客が素直に演出を楽しめるようにするために余計な情報は与えないでおこうという配慮でしょう。

ゲームに限らず、たとえばアニメ評論家の岡田斗司夫も、だいぶ昔の著作ですが1998～89年くらいに、岡田はおおむね「自分はアニメ製作の仕組みをしってしまっているので、テレビアニメを見ても、『このシーン、撮影台はこう動かしているな』とか思い浮かんでしまうので、一般の観客と同じような方法では楽しめない」という感じのことを言っています。

岡田だけに限らず、評論家以外の多くの漫画家やアニメーターも、似たようなことを言っている人は多く、程度の差はあれ、一介の観客だった時代とは大衆娯楽作品に見方が変わってしまう体験を、たびたび各所で色々な人が言及しています。

だから、あまりゲームのプログラミングに興味のない人は、この教科書『ゲームプログラミング』は読まないほうが良いでしょう。
}}


;選択肢の総確認
他にもデバッガーのすべき事は、たとえば、ゲーム中にもし、なんらかの選択肢の入力がある場合、選択肢すべての（当面の）結果を確認します。

たとえば、もしRPGのストーリー中の重要なシーンでのコマンド選択肢で、善行と悪事との選択肢があった場合、2つのセーブデータを用意して、両方の選択肢とも試してみて、とりあえず数分は動作しているかを確認します。

このように、とりあえず、どちらの選択肢を選んでも、当面の数分はバグの無く、正常に動作しているかを、（デバッグモードや、セーブデータの複数用意などで）なんらかの方法で確認します。


なお、一般ユーザーのプレイ傾向としては、もしゲーム中に選択肢で、善行と悪事の選択肢があったら、なんだかんだで普通のプレイヤ－は善行を選びます。

なので、もし普通のプレイヤーに任せていては、いつまで経ってもゲーム中では、ゲーム中の悪事の確認は、なかなか、できないです。

このためデバッガーは、意識的に、自分のプレイスタイルとは異なる悪事の選択肢でも、デバッグして動作確認する必要があります。


;全滅テスト、自殺テスト
また、一般プレイヤーは、上手にプレイしたがるので、わざとゲームオーバーする自殺プレイを嫌がります。

なので、デバッガーは、ところどころで、自殺プレイをします。ゲームオーバーや全滅などのイベントが正常動作するかを、ときどき確認します。

難易度の高いゲームなら、意図的に自殺プレイしなくてもよく全滅しますが、たとい難易度の低いゲームでも、わざと自殺プレイをします。


特にボス戦などは、ソースコードでは特殊なフラグ処理が入りこんでいるのでバグの混入している可能性も高く、そのため、たとえ弱いボスであっても、ワザと敗北したりする自殺プレイが、デバッガーのすべき事です。


;カウンターストップのチェック
たとえば、RPGのゲームの上限レベルが「99」の場合、きちんとレベル99で止まるかを、とりあえずデバッグモードでチェックします。

こうしたデバッグを短時間で出来る用途のために、やたらと経験値の高い敵でも一体、ゲームのソースファイルにでも混ぜて、作っておきましょう。

レベル98からレベル上げをしてみたりとか、レベル97から一気に2レベル上がったらどうなるかとか、いろいろと確認しましょう。

また、所持金や道具の個数なども同様に、上限できちんと止まることをデバッグモードなどを活用して確認します。


さて、とにかく上述のように個別デバッグ・局所デバッグをして、まずはデバッグモード（またはデバッグモードに近いプレイスタイル）で正常動作するようになるまで、まずプログラムを修正していきます。

もちろん、デバッグモードで正常動作したからといって、けっして、必ずしも通常起動のモードでも正常とは、かぎりません。

ですが、もしデバッグモードですら異常動作をするなら、これはもう通常起動時にも異常動作をするだろう事は、ほぼ確実です。（数学でいう「必要条件」と「十分条件」の関係みたいなもんです。）

なので、まずデバッグモードで正常動作するようになるまで、まずプログラムを修正していきます。


このように、追加した幾つもの機能を、それぞれデバッグモードで即座にチェックしていきます。


また、もし機能を新たに追加したい場合には、まず前の機能のデバッグモードでの正常動作を確認し終えてからにしましょう。なぜなら、こうしないと、集中力が落ちるし、また、もしバグが発生した場合の修正が、とても複雑になってしまいます。


IT業界の格言ですが、「デバッグされてないコードは、（資産ではなく）負債である」という格言があります。なので、コードを書くことよりも、自分で書いたコードをひとつずつデバッグすることのほうが重要です。

ともかく、このように、機能をひとつずつ、個別的にチェックしていきます。


;ボタン連打や、壁に何度も衝突など
ボタンを1回だけなら押しても異常は無くても、ボタンを何度か押すと異常のあるバグも、ときどきあります&lt;ref&gt;STUDIO SHIN 著『ゲームプランナーの新しい教科書』、翔泳社、96ページ、2018年3月10日 初版第2刷発行、257ページ&lt;/ref&gt;。

とはいえ、ゲーム中の全てのシーンで何度もボタンを押していたら、ゲームが進行せずにデバッグも進行しないので、たとえばゲーム中で使用頻度の多いメニュー画面などでボタン連打するとか、あるいはイベント進行などで「ここが、もしかしたらバグが潜んでいる可能性がありそうだな」とか思ったところだけボタン連打するとか、工夫しましょう。


同様に、通行止めの壁などの場所なども、ときどき何度も壁に衝突したりしましょう。


わざと弱めのボス敵などに負ける全滅テストも、ときどき、2回以上はワザと全滅してみましょう。


;壁衝突やボタン連打などのチェック中のデータは、なるべく混ぜない。
セーブ機能のあるRPGやシミュレーションや長いアクションゲームなどで、上述のようなボタン連打や壁衝突などのプレイを確認するとき、原則的にあまりセーブしないようにするほうが効率的でしょう。

なぜなら、もしそのゲームのあとのプレイで何らかのバグが発見された場合、原因として、ボタン連打などの影響を考慮する手間が増えてしまうからです。


1つのセーブデータで、複数の異常プレイの実験をしてしまうと、たといバグが発見できても、その原因が果たしてボタン連打の処理ミスなのか、それとも悪事のフラグミスなのか、ミスの箇所が不明になってしまいます。

なので、まずひとつのセーブデータでは１つの異常プレイだけにします。

もし、複数の異常プレイを一人のデバッガーがする場合には、セーブデータを別々に分ける必要があります。


同様に、ボタン連打にかぎらず、もし何らかのバグが発見された場合でも、たとい報告のためにセーブする必要があっても、そのデータはまだバグを発現していない未発症データとは分けて別データとしてセーブしましょう。

==== 次に、通しプレイ ====
さて、こうして、いくつか機能をデバッグモードで局所チェックしていき追加していくのが完了したら、今度は次に、ゲームを最初から始めて、エンディングまでプレイをします。

このように、ゲームをオープニングからエンディングまでプレイすることを、「通しプレイ」（とおしプレイ）といいます。

===== 概要 =====
;デバッグモードは原則的に封印
「通しプレイ」では、デバッグモードは原則的に使わないほうが安全です。通しプレイは、できるだけプレイ条件を一般プレイヤーに合わせる必要があります。

文献『ゲームプランナーの新しい教科書』でも、特に通しプレイとは限定していませんが、デバッグモードは限定的に用いるべきであることが巻末近くのコラムで述べられています&lt;ref&gt;STUDIO SHIN『ゲームプランナーの新しい教科書 基礎からわかるアプリ・ゲームの発想と仕掛け』、翔泳社、2018年3月10日 初版 第2刷 発行、P264&lt;/ref&gt;。


RPGなら、よくある確認ミスで、たとえデバッグモード自体にはイベントなどのフラグに直接の影響を与える機能が無くても、本来なら入場不可能なゲーム内の場所にプレイヤーが入場してしまうと、その影響でフラグが変わってしまう場合もあるという、間接的にフラグに影響を与えてしまう確認ミスもあるので、なので通しプレイではなるべくデバッグモードは避けるべきです。

;どうしてもデバッグモードを使う場合はファイルを分ける
どうしても通しプレイでもデバッグモードを使わざるを得ないゲーム内現象をテストのために確認したい場合は、通しプレイのゲームファイルをデバッグモード使用バージョンと非使用バージョンとに分けましょう。セーブデータ分けだけではなく、ゲームファイルごと別々に分けるのが安全です。
ｓ
しかし、そこまでしてファイル分けをしても、よくあるミスで、ファイルが本来「デバッグモード使用バージョン」なのに、間違えて「デバッグモード非使用バージョン」として保管してしまうミスもあります。

後述ですが、ゲームファイルやセーブデータをプログラマーからの確認待ちなどのため、複製してファイル数が何十倍にも増えますので、ファイルが多すぎるので、よくあるミスで、デバッグモードの使用バージョンと非使用バージョンとのファイルがときどき混入してしまいます。

なので、原則的に通しプレイではデバッグモードは封印する、などの自己規律的な方針をもっておくほうが安全です。


また、デバッグモードを使わないとレベル上げなどに時間の掛かりすぎるゲームの場合、そもそも、そのゲームのゲームバランスやレベルデザインなどが調整不足で崩れている可能性があります。（ただし、バランス調整チームとテストプレイチームとは別々のチームであるのが一般的ですが。）

そういった意味合いを含めて、とにかく通しプレイではなるべくデバッグモードを封印しましょう。


;保管中のゲームファイルが10～20倍に増える
また、通しプレイでは、バグ報告後のプログラマーからの返事待ちとかのゲームファイルも保管するので、1つの作品あたりゲームファイルを20個～30個くらい最終的に複製したりするので、パソコンに保管するゲームファイルの数がかなり多くなります。たとえば作品1個は500メガバイト（0.5ギガバイト）のサイズでも、保管中のゲームファイルのサイズが合計で10ギガバイト超えとかになる場合も多々あります。

フリーゲームや同人ゲームなどゲームファイルのサイズが比較的に小さい（高々1ギガ程度）なら、データの控えのための複製の際は、ゲームファイルごとセーブデータとセットで複製してしまうほうが安全です。もっとも、さすがに20ギガ以上もあるような商業ゲームの大作ではファイル複製は非効率でしょうが、しかし高々1ギガ程度の作品ならゲームファイルごと複製して通しプレイしたほうが安全です。

;その他
さて、とにかく通しプレイは時間にかぎりがあるので、たとえばある程度の週の間隔を置いて、前回のクリア以降に新バージョンが出てたら行うとか、そういうふうに工夫します。（もし機能の追加のたびに通しプレイすると、時間が不足する。）


さて、商業作品の場合、通しプレイでは、けっして上手にプレイするのが目的ではないのです。

とりあえず、色々なことをそのゲーム中でしてみて、それでもバグが起きないことを確認するためのモノです。

===== 手順 =====
;1回目の通しプレイ
とはいえ、最初の1回目の通しプレイでは、まず普通に、自分のやりたい自分本来のプレイスタイルでプレイするのもイイでしょう。（もしもゲームのクリア所要時間が長すぎる場合や、クリア困難な難易度の場合には、とりあえず数時間ほどのプレイで区切るべきだろう。）

なぜなら、世間の他人から見れば、アナタのプレイスタイルも、他人にとっては「色々なプレイスタイル」のひとつですから。

また、そのゲームの中でどういった行動が可能なのかを知るためにも、とりあえず最初の1回は、普通にプレイする必要があります。

なお、特に仕事的な規律も無く、気の向くままにプレイすることを「フリープレイ」と言います。つまり通しプレイの最初の1回目は、フリープレイ的なプレイでよいでしょう。


;2回目以降の通しプレイ：パターンA
さて、とりあえずの1回目の通しプレイが終わったら、2回目以降の通しプレイでは、プレイスタイルを変えます。

けっして、通しプレイの目的は、「エンディングに最短時間で到達する」（×）とかではないし、「上手にプレイする」（×）とかでもないのです。


自分のプレイスタイルではなく、自分以外のスタイルで、他の多くのプレイヤーがやりそうなプレイをします。


とはいえ、プレイスタイルを変えてみるのも、（自分の性格にもよりますが）そんなにツマラナクは無く、1回目では見過ごしていたイベントを発見できたりとかも出来ますので、さまざまなプレイスタイルを自身で再現してみることで今後の自分のゲームとの付き合い方の勉強にもなります。（というか、コレがツマラナイと感じる人は、そもそも性格的にデバッガーに向いてないので、別の職種を頼むべきかと。）

また、1回目と同じプレイスタイルでプレイしても、どうせ1回目で見たことある現象と同じ現象しか見られないので、むしろ2回目以降はプレイスタイルを変えたほうが面白くなるでしょう。


;2回目以降の通しプレイ：パターンB

普通のプレイヤーは、ある程度は上手にプレイしようと目指します。

また、ゲーム中の選択肢で、善行と悪事のどちらかを選ばせる選択肢がある場合、たいていの一般人は善行を選びます。


なので、彼ら一般人と同じプレイスタイルでは、たとえばもし、ゲーム序盤のとても弱い敵に負けた際に発生するバグがあったとしても、そういうのは発見されづらくなります。


なので、ときどき意図的にヘタな通しプレイをします。

事前のデバッグモードなどでの局所チェックでも、このような確認はしているハズですが、確認モレがあったり、あるいは通しプレイ時にしか発生しないバグなどもありうるので、念のため通しプレイでも、意図的に下手なプレイをします。


;壁衝突やボタン連打などのチェック中のデータは、混ぜない。
通しプレイでも、ときどき壁衝突のテストや、ボタン連打などの異常プレイのテストは必要ですが、しかしそれらのセーブデータは、なるべく、（自分以外の）通常プレイヤーの行動再現のセーブデータには、混ぜないようにしましょう。

また、さまざまな選択肢を選んでプレイしているセーブデータにも、ボタン連打プレイなどのプレイデータは混ぜないようにしましょう。


もし今後、何らかのバグが発見された場合に、もしひとつのセーブデータにて壁衝突・ボタン連打プレイ・通常プレイヤー再現プレイ・選択肢チェックのデータをセーブしてしまうと、せっかくバグ発見できても、想定されるバグ原因としてボタン連打などの影響の可能性などが増えてしまうからです。


ただし、通しプレイの場合、さまざまなプレイスタイルの再現中に、ゲーム中の選択肢などで、やや変わった選択肢をする場合もあるし、ややゲームの苦手なプレイヤーの行動を再現する場合もあるので、（つまり、選択肢プレイと苦手プレイは）そういうのまではセーブデータを分ける必要はないでしょう。（もしそこまでセーブデータを分けると、セーブデータ数が膨大になり、管理しづらくなる。）

よほどの異常プレイでないかぎり、セーブデータを分ける必要は無いでしょう。

しかし、かなり異常なプレイを意図的にする場合には、セーブデータを分けるか、あるいはセーブしないようするなど、工夫しましょう。

バグを発見したときに、原因の特定が容易になるように、セーブデータを分類して管理しましょう。

==== 全体の流れ ====
さて、一般プレイヤーの行動を再現しただけの通しプレイがなぜ重要なのかというと、コレによって、重症なバグの有無を確認できます。

「クリア不可能バグ」のような重症なバグは、実際に通しプレイをしてみないと、分かりづらいのです。

また、クリア不能バグでなくとも、もし一般プレイヤー的な通しプレイなのにバグが発見された場合、これは発生確率の高いバグなので、どちらにせよ優先的に直す必要があります。

デバッグで重要なことは、けっして単に多くのバグ報告の件数を増やすだけではないのです。

件数ではなく、重度の高そうなバグから発見する必要があります。単にバグ報告の件数を増やすだけなら、通しプレイをせずに、個別チェックだけをしたほうが、形式的にはバグ報告の件数が上がります。しかし件数だけではなく重度も気にするべきなのです。

裏を返すと、いったん、一般プレイヤーの行動を再現した通しプレイをしたら、しばらくは通しプレイをする必要は無いです。なので、個別チェックと通しプレイとを交互に繰り返すのが効率的でしょう。

よって全体の流れとしては、おおむね、

# プログラマーなどがデバッグモードでもいいので新機能の個別チェックをして
# 次に、通しプレイによって大きいけど少ないバグを潰し、
# 再度の個別チェックによって、小さいけど件数の多いバグを潰します。
# その個別チェックが終わったら、また通しプレイ。
# 同様に、個別チェックと通しプレイとを交互に繰り返し。

のようになります。また、このようにすることで、バグの大きさと潜伏範囲とをどんどん小さく狭めていけるので、効率的にバグを潰せていきます。

;個別チェック漏れのチェック
個別チェックなどで事前に、それぞれの機能のチェックをしているハズですが、
しかしチェック漏れのある場合もあります。

なので、上述の手順のように、通しプレイと個別チェックとを交互に繰り返します。

=== 集団制作におけるソフトでのバグ報告の書式 ===
ゲーム業界に限らず、IT業界ではバグ報告の書式がおおむね、下記のように決まっています。最低限、次の情報がまともなバグ報告には必要です。
:・バグの症状 :
:・バグの発生方法 :
:・発生の頻度 :
:・バグ発生したソフトのバージョン :

と言った情報が最低限は必要であり、その報告が『バグ報告』である事とともに伝えます。

要するに、サラリーマンの社内の『ホウ・レン・ソウ』（報告・連絡・相談）のメールやIT企業などでのバグ報告メールなどと同様の書式です。


個人作業では不要ですが、集団作業の際などに、ご参考に。

ゲーム業界に限らず、リナックスなどのオープンソースのソフトウェアなどのバグ報告サイトでも、こういったバグ管理手法をしています。（というか、そういった海外プログラマーのバグ管理手法を、日本プログラマーが真似たと思われる。）

ゲーム業界でも同様に、こういったバグ管理手法です&lt;ref&gt;STUDIO SHIN 著『ゲームプランナーの新しい教科書』、翔泳社、96ページ、2018年3月10日 初版第2刷発行、258ページ&lt;/ref&gt;。

つまり、会社などで業務としてバグ報告をする場合には、ダメな報告の例としては「ゲームが壊れた！ どうにかして！」とか「ゲームが止まった！ どうにかして！」みたいなのは、論外という事です&lt;ref&gt;STUDIO SHIN 著『ゲームプランナーの新しい教科書』、翔泳社、96ページ、2018年3月10日 初版第2刷発行、258ページ&lt;/ref&gt;。

また、誰が決定するかはともかく、
:修正の優先順位
という項目も、ゲーム業界でも一般IT業界でもあります。ゲーム業界の場合、クリア不能バグや、強制終了バグなどは、優先して修正しなければなりません&lt;ref&gt;川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日 第1版 第1刷、P.70 &lt;/ref&gt;。

そのほか、現在の状態（手つかずか、修正中か、検証中か、など）の項目もあります。

さらに日本のゲーム業界の場合、画像のスクリーンショットも添えて説明することも多くあります。

まとめると、
:・バグの症状 :
:・バグの発生方法 :
:・発生の頻度 :
:・バグ発生したソフトのバージョン :
:・修正の優先順位
:・スクリーンショット
:・状態
となります&lt;ref&gt;川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日 第1版 第1刷、P.70 &lt;/ref&gt;。


文献『ゲームプランとデザインの教科書』によると、バグが起きたときに、それを騒ぎたてる人は、開発現場では、嫌がられるようです。プログラマーは集中力を使っていたりして、神経質なのです。なので、「そっ」と教えてほしいようです&lt;ref&gt;『ゲームプランとデザインの教科書』、P.71 &lt;/ref&gt;。

さて、下請け仕事でデバッグをする場合、自分は客ではないので、「ゲームが壊れた！ どうにかして！」みたいな報告は論外です。


とはいえ報告の時点では、まだバグの原因が不明ですので、けっして、完全にピンポイントな原因特定をした報告は、不可能です。


なお、IT企業などでは、バグ報告については、社内サーバーに専用のページが用意されていたり、あるいは社内サーバーのバグ報告用エクセルなどに記入する方式だったりしますが、いずれの方式にせよ、上述のバグ発生方法・頻度・バージョン・症状などの記入が必要です。

「バグトラッキングシステム」（BTS）というバグ報告用の社内サーバが開発されているので(Redmine やJIRAやTracやMantisやBacklogなど)、それを設置したり、あるいはもっと単純にエクセルみたいなので代用されていたり、などです。なお、JIRAとBacklogは有料です。一方、RedmineとTracとMantisはオープンソースなので無料でも使えます。


なぜサーバが必要かというと、
2人以上の集団でのデバッグ作業の場合、自分の発見したバグを、自分よりも前に他のデバッグメンバーが発見して既に報告ずみの場合もあります。

なので、サーバでバグ情報を公開しておかないと、報告が重複してしまい、非効率になってしまいます。プログラマー側も、それぞれの報告に別個、報告するのは、とても面倒です。

2人ていどなら、まだイイですが、5人以上とかになると、まずメールなどで個別に連絡するのは無理です。


ただし、小規模なサークルでは、こういった社内サーバーの設置は難しいでしょう。とにかく、なんらかの方法で、バグ報告があまり重複しないようにしてください。このため、あまりにも開発初期の段階では、あえてデバッグメンバーを少数に限って、メールでやり取りする事もありえます。（いちおうメールにも、CC(カーボンコピー)などの機能がある。）

とはいえ、サーバ無しに他のテスターの報告状況なんて分からないので、ある程度はバグ報告が重複するのは、やむをえません。

また、時には報告の重複が役立つ場合もあります。それは解決方法がまだ不明で未解決バグになっている場合には、他人の報告による追加情報と合わせて、よりバグの原因をしぼりこめます。


さて、サーバを使う場合、自分がバグ調査して得た情報のうち、まだ報告されていない情報があれば、サーバーのバグ記入欄に追加の情報を記入するぶんには、構いません。（ゲームに限らず、GitHubなどのバグ報告欄でも同様の慣習です。）

べつに特許や発明ではないので、最初の一人だけが名誉と権限を独占する必要は無く、みんなで協力しあってバグ解決という問題解決するのが仕事です。


さて、バグ報告の手本として、もしメールで報告する場合、一例を書くと、たとえば

:例
 【バグ報告】 ウッキークエスト ver0.87 。ハジメガルド武器屋オヤジの会話時のキャラチップ表示ズレ
 
    ・[バグの症状]   ゲーム中盤でのハジメガルド武器屋の親父の会話時のキャラチップ位置表示ズレです。 
 
    ・[発生の頻度]  当の武器屋オヤジに話しかけるたび、毎回バグ発生です。3回、確認しました。
 
    ・[添付ファイルの内容] メール添付画像は、バグ発生時のオヤジ画像チップが店の壁に乗ってしまってるナゾ画像です。
     
    ・[バグの発生方法]   ゲーム序盤の第1章から行ける街・ハジメガルドの武器屋の親父に、
       ゲーム中盤の第三章になってからハジメガルドに行き、
       自軍パーティ構成が戦士・戦士・僧侶の3人パーティの
       味方平均レベル28くらいの状態で武器屋親父に話しかけると、
       なぜか親父が話しかけるたびに、
       バグによって親父のキャラチップの表示位置が1マスぶん右にズレます。
 
     ・[参考情報]
       私の今回のテストプレイでは、まだ「伝説の剣」は入手していません。
      「伝説の盾」は、このバグ発生の時点で入手しています。
       伝説の盾を守っている中ボス・暗黒大王も撃破してあります。
       
      今回のプレイでは、装備はまだハガネ装備です。ミスリル装備は、していない状態です。
      ミスリル鉱山の街をすでに帝国軍から解放しましたが、プレイヤー所持金を節約するためハガネ装備のままです。
      ハガネ装備のままレベル28まで上げて暗黒大王を倒しています。

みたいな感じでしょうか。（もしメール方式でなくサーバー方式の場合でも、こんな感じの書式で報告・連絡を入れる欄があるハズでしょう。サーバの場合の詳しい書式は会社によって違うので、説明は省略します。）

:※ 「バグ発生原因などを報告前に特定しなくていいの？」と思うかもしれませんが、発生原因の特定は（あとで必要だけど）後回しです。先にまず、再現性のある（何度も起きる）バグを発見したことを、なるべく早く（「なるはや」で）、上司などにメールでも何でもいいので報告します（理由: 何度も起きるバグは、重要度が高いので）。なぜなら、発生原因の特定には、時間がけっこう掛かるからです。なので、まずバグ発見を報告したあと、そのあとに返事を待つ間などに、発生原因などを絞り込んで生きます。


なので、バグ報告は、1件のバグにつき基本、
:1回目のバグ発見の速報（そくほう）と、
:翌日（翌営業日）の2回目の詳報（しょうほう）とで、
最低でも2回以上、行うことになるのが通例です。


もし、バグ発生時の画面をキャプチャ（「スクリーンショット」ともいう）した画像があると、伝わりやすいです。

ウィンドウズでは、ショートカット・キー &lt;nowiki&gt;[Fn] + [Alt] + [Prt Sc] &lt;/nowiki&gt; で選択中のアプリウィンドウごとにキャプチャでき、それをWindows アクセサリ『ペイント』のキャンバスに貼り付けしてセーブ保存すれば、キャプチャ画像が作成できます。

なので、バグ発生中のソフトのキャプチャ画像を作りましょう。


さて、バグの報告では、実際に起きたバグの症状を、主観を交えずに、見たままに報告します。

要約などを書いてもいいですが（「どこを要約すべきか」という判断も主観です）、しかし必ず報告の文中に、必ず、実際に起きた事だけを報告する段落・節などが必要です。なので、要約の文とは、段落などを分離したほうが良いかもしれません。

バグ報告に限らず、一般企業のサラリーマンのトラブル報告などの報告文などでも一般に、段落として（分析を交えずに）実際に起きた事だけを報告する専用の段落などが必要です。

なので、実際に起きたバグの症状の現状とは別に、バグ発生原因かもしれない関連情報・参考情報を併記する場合には、あくまでその関連性は推測に過ぎないので、段落を別々に分けましょう。上記の報告メール例でも、「バグの症状」と「参考情報」というふうに別々の節に分けて報告しています。


なお、報告メールの際、参考情報などで、とりあえずバランス調整に関係ありそうなテストプレイ時の行動も書いておくと、バランス調整チームがデバッグついでにバランス調整のための資料にも出来るので、一石二鳥です。また、ひょっとしたら、そのバランス関連の参考情報で書かれたテストプレイの行動も、バグ発生条件に関係しているかもしれない場合もあります。

（ただし、商業作品の場合は、バランス調整はデバッグよりも前のほうに、ある程度は終わらせておく必要があるだろう。）


しかし、あくまでバランス調整に関するテストプレイ報告については、後回しの付属的な情報です。メインに報告すべきは、バグに関係ありそうな情報から優先的に報告です。バランス報告については、せいぜい5行くらいまでで充分でしょう。

また、「バランスがイイ」だの「バランス悪い」だのといった良否の判断は、これはバランス調整者側の判断することでありますので、デバッガー分野の判断することではないです。

デバッグのついでのバランス報告では単に「レベルは○○くらいです」「装備は○○くらいです」とか「中ボスの△△戦では負けて1回全滅しました」とかプレイ事実だけを報告するべきであり、良否の判断はプレイヤー側ではしないのがポイントです。


このように、バグの発生方法についての説明は、バグが起きた時やその前にゲーム中で主人公のしていた行動を記述します。

（実際のプレイ行動だけを先に報告文面で書いた上での）追加情報として、「おそらく、バグの原因はコレだと思われます」という分析があるぶんには、構いません。


また、バグを報告する場合は、けっして即座に報告するのではなく、できれば最低限あと2回は同じ行動をしてみて（つまり合計で3回以上はしてみて）、それから同じバグが発生するかどうかを確認できたら報告します。

もし最初の1回しかバグが起きなかった場合は、もしかしたら、ソフト側ではなくハード側のその瞬間での不調などの原因も考えられますので、対応をやや後回しにできます。

ただし、ランダム性の高いバグなどの場合、本当はソフト側のバグなのに、2回目に試しても発生しない場合もあります。
なので、もし再現性が悪くても、けっして「ハード側のバグだな」と早合点せず、とりあえずは再現性の情報とともにバグ報告します。

再現性の悪いバグの場合、報告の文面では、たとえば
 このバグの再現性は、3回試しましたが、1回しか発生しませんでした。
などという、再現性の悪いことを併記した説明書きとともに、バグ報告をします。


さて、ゲームのバグ報告の場合、もしそのバグの再現性が高い場合なら、

バグ発生の直前の行動だけでなく、バグ発生に影響のありそうな行動も報告する事になると思います。

なぜなら、RPGやシミュレーションゲームの場合なら、たとえば、「ゲーム中の中盤ストーリー中でしか起きないバグ」とか「東部地方でしか起きないバグ」のように、発生箇所や発生時点が限定されているバグもあるからです。

つまり、単に「Aボタンを押したら、こういうバグが起きました。」なんてのは論外です。

ゲーム中のどこのストーリー時点のどんな場所（マップやエリア、ステージなど）で、どんな操作キャラクターで、キャラクターに何をさせたらバグが起きたのか、といった、5W1H（いつ、どこで、だれが、なにを、どのように、どうした）のような情報を、バグ報告での発生方法では、書きましょう。

たとえば、
:「ゲーム序盤の第1章から行ける街・ハジメガルドの武器屋の親父に、ゲーム中盤の第三章になってからハジメガルドに行き、自軍パーティ構成が戦士・戦士・僧侶の3人パーティの味方平均レベル28くらいの状態で武器屋親父に話しかけると、なぜか親父が話しかけるたびに、バグによって親父のキャラチップの表示位置が1マスぶん右にズレます。」
みたいに、5W1Hで報告するのです。

バグ発生時の瞬間のプレイヤー行動は単に、武器屋で話しかけるですが、しかし、発生に影響を与えてるかもしれないと思った行動など、その他の行動も報告します。

なぜなら、バグ発生の条件は、必ずしも1つとは、限りません。複数の条件が満たされた場合にだけ、バグが発生する場合もあるからです。


これがもし、
:（ダメな例）「武器屋の親父に話しかけると、表示が1マス、ズレます」
だと、報告を聞いた側のプログラマーにとってはバグ発生方法がサッパリ不明です。また、ハジメガルド以外の別の街の武器屋の親父では、バグは発生しないかもしれないので、プログラマー側が再現性を確認プレイしても、
ハジメガルド以外の武器屋でプレイしてしまう可能性もあります。その場合、バグ発生を確認できないので、その結果「間違った報告」としてプログラマーに処理されかねません。


また、ダメな例として
:「武器屋の親父に向かって決定ボタンを押すと、表示が1マス、ズレます」
だと、決定ボタンを押した結果、何が起きる状態なのか、やや不明です。親父に話しかけるために決定ボタンなのか、それとも、たまたま親父の前でメニューコマンドで道具を使おうとして決定ボタンなのか、解釈が分かれてしまいます。

つまり、発生方法の操作の説明は、プレイヤーの動作ではなく、なるべくゲーム中のキャラクターの動作で、バグ報告しましょう。


なお、たといこのバグの発生条件で自軍パーティ構成が結果的に無関係だとしても、報告時に「自軍パーティ構成が戦士・戦士・僧侶の3人パーティの味方平均レベル28くらいの状態で武器屋親父に話しかけると、」のような情報があるのは、構いません。

なぜなら、バグ報告の時点では、まだ自軍パーティ構成がバグ発生に影響しているかどうかは不明だから、です。


バグ発生の条件は、必ずしも1つとは限らず、複数の条件が満たされた場合にだけ、バグ発生する場合もありますので、バグ報告では「影響してそう」と思った情報も提示します。


その他、プレイヤーによって行動が分かれそうなゲーム中での過去イベントでどうしたかとか、そういうのも後に追記しましょう。

たとえば、先のバグ報告バグによって親父のキャラチップの表示位置が1マスぶん右にズレます。」の次の文で、

:「私の今回のテストプレイでは、まだ「伝説の剣」は入手していません。「伝説の盾」は、このバグ発生の時点で入手しています。伝説の盾を守っている中ボス・暗黒大王も撃破してあります。」
などのようにです。

もしかしたら結果的には「伝説の剣」や「伝説の盾」の入手の有無はバグには無関係かもしれないですが、しかしバグ報告の時点ではプログラマーにすら一切、原因は不明なので、よって報告の時点では、関係ありそうだと思った追加情報を手短かに5行～10行くらいで、いくつか選んで情報を報告します。


さて、報告する側は、もし時間に余裕があるなら、次からの検証プレイではバグ発生時の行動を少し変えてみて、それでもバグが起きるかどうかを試してみると、プログラマー側の今後の検証がラクになります。


さて、ゲームに限らずパソコンソフトの場合、

たといデバッガー側で何回もバグを再現できる事を確認できたとしても、

それでも、プログラマー側の環境ではバグが起きない場合がある。


このような場合は、たとえば、ＯＳ（オペレーティングシステム）の違いによって起きる場合がある。

たとえば、Windows の特定のバージョンでしか起きないソフトバグもある。

なので、もしプログラマー側ではバグをテストしても確認できない場合、
自分のＯＳを変更してみる等して、確認する必要がある。


;細かな追試プレイは後回しに
バグ報告は、発見しだい、再現性が3回くらい確認できた時点で、なるべく早めに報告したほうが、最終的に効率的です。（バグ報告は『なるはや』（「なるべく早く」の略）で、と言われます。）

再現性が確認できたら、さっさと報告しましょう。


もちろん、バグ発見箇所の周囲にも類似のバグが潜んでないかとかも、今後はチェックするわけですが（理科でいう『対照実験』みたいに比較検証プレイを、あとでする）、

しかしそんなのは、そのときにチェックすればいいのです。


どうせバグ修正後にも、バグが本当に直ってるかを確認するためのチェックプレイするのですから、

だったら早めにバグ報告して、プログラマー側にとりあえず該当部分のバグを直してもらい、

そのあとに周辺箇所をまとめて通しプレイで調べればいいのです。


仕事術としては、おそらくですが、プログラミングやゲーム産業に限らずなにか仕事で、
:自社や同僚などの設計ミスのようなものが見つかったら、
:再現性が取れた時点で、その後の詳細な調査は後回しにして、ひとまず、
:早めに設計担当の部署に報告をするほうが効率的でしょう。


;その他
会社によっては、社内サーバで、バグ報告シートと、その他のバランス調整報告シートや提案シートなどを共用している場合もあります。

その場合、報告シートに、報告の種類の分類の記入欄があるハズなので、そこに「バグ報告」と記入して、バグ報告であることをきちんと明示しましょう。


なお一般に仕事において提案する場合、その提案の思いついたキッカケになったトラブルなどを一緒に報告すると、伝わりやすいです。

たとえば集団でのゲーム製作での提案の場合なら、「現在の仕様では、テストプレイ中に○○な不都合に遭遇しました。なので提案・要望ですが仕様変更として□□な仕様に変更してほしいです」みたいに伝えると、伝わりやすいです。

=== バグ報告のその後 ===
バグ報告のあとは、次のような流れになります。

# （返事 :）とにかく、担当部署に報告を読ませ、報告を読んだかどうかの返事を書いてもらう。
# （優先度づけ :）修正するのか、または修正の優先度などの評価の決定をして、情報の共有をする。
# （修正 :） コード上でのバグ修正。コード上での修正が終わり、プログラマーの環境で再発しなくなれば、とりあえず「修正」として中間報告。
#  （修正確認 :） 修正版が公開・配布されてから、プログラマー以外のコンピュータ環境でもバグが再発していないか、品質管理チームなどが実際に修正版をテストプレイして確認する。

ゲームに限らず、一般のIT企業でも大抵、似たような流れになります。（というか、ゲーム会社がどうしてるのか、編集した人はあまり知りません。）

オープンソースやフリーソフトの場合などは、返事や修正確認が省略される場合もありますが、しかし有料ソフト開発では返事や修正確認は行ったほうが安全でしょう。

==== 返事 ====
集団作業でのバグ報告の場合、

バグ報告を受け取った側（主にプログラマー）は、

とりあえず返事をする必要があります。


プログラマーがバグ報告にもとづいて実際のプレイしてみて調査した結果として（プログラマー側でも）バグが再現できたのかとか、そういう事を社内のバグ報告用サーバーの専用ページ（あるいはバグ記入用エクセル）に記入するとか、あるいはメールでのバグ報告なら返信するとか、とりあえず、初期対応によって返事をします。

社内で情報共有する必要があるので、社内サーバーを使うのです。


さて、こういった社内サーバー経由のバグ報告では、たとい、すぐにバグが修正できなくても、とりあえず
:「調査中」とか、
:「プログラマー部署でもバグが再現しました」とか、あるいは「プログラマー部署ではバグが再現できませんでした」とか
とにかく、なにか現状が分かるように、バグ報告用サーバーなどにプログラマー側など返事の権限のある側が対応を記入します。


さらに企業などの場合、バグ修正後にも、

バグ記入用紙に、どのようにバグ修正のプログラムを対応したのかを、簡潔に1行～2行ていどで、バグ報告用サーバーの専用ページ（あるいはバグ記入用エクセル）に書いておきます。

したがってゲーム企業などの場合、冒頭の
:・バグの発生方法 :
:・発生の頻度 :
:・バグ発生したソフトのバージョン :
:・バグの症状 :
に加えて、さらに
:・対応:
のような項目が専用ページ（あるいは記入用エクセル）に加わります。


さらに、会社によっては、
:・バグの原因:
などの項目もあるかもしれないです。もちろん、バグの原因を調査するのはプログラマー側です（ソースコードを見れないとバグの原因を特定できないので、ソースコードを扱っているプログラマーなどが原因を記述する場合が多いだろう）。

もちろん、ここでいう原因は、たとえば「テンキーの1と4を押し間違えてしまい、その結果、武器IDが4番の『ハガネの剣』の番号がズレて『青銅の剣』（武器ID:1番）の攻撃力になっていました。」みたいなゲームのコードのミス内容とバグ動作の対応を特定できるような説明のことです。

けっして「寝不足だったんです」とか「風邪気味だったんです」とか、そういう情報は不要です。


ともかく、バグ報告記入シートに「原因」の項目のある場合、2行～4行ていどでバグの原因を記述しましょう。


なお、プログラマー側や管理者は、バグ発生部に関連する他の情報も知っている場合がありますが、なるべく、リリースまでは、最低限のバグに直接・一次的に関係する仕様しか情報の共有しないようにする必要があります。

つまり、デバッガーが報告した事に直接・一次的に関係する事は情報を公開、またはそのデバッガーに連絡する必要があります。

しかし、それ以外の間接的・二次的～三次的にそのバグに影響することは、あまり詳細を教えないようにする必要があります。


なぜそうするかというと、もし、間接的なことまで色々と仕様の裏側を知ってしまうと、デバッガーの次回の通しプレイからは、仕様を知ってしまってるので、自然なプレイが出来なくなってしまいます。


デバッガーによる通しプレイの際には、開発初期には、なるべく一般プレイヤーに近い予備知識の状態でいてもらい、一般プレイヤーの取りそうな行動をデバッガーに再現してもらう必要があります。（一方、開発中期ぐらいからは、デバッグ用テストプレイヤーにも裏仕様などを教えて、確認プレイしてもらう必要がある。）

なので、そのために、開発初期のうちにはデバッガーには余計な知識が無いほうが一般プレイヤーの感覚に近づくので、あえて間接的にバグに影響する仕様については、デバッガーには公開しないでガマンしてもらう必要があります。


具体例を挙げると、たとえばアクションゲームで、全10面あるゲームのうちの4面のボス「暗黒大王」との戦闘アルゴリズムにバグ報告があったとして、その報告をもとにプログラマー側は8面のボス「ゾンビ暗黒大王」にもバグをプログラマー側で別途に発見したとしましょう。

この場合、プログラマー側は、8面の「ゾンビ暗黒大王」にもバグがあることについては、デバッガー・テストプレイヤー達には、開発初期のうちは教えないでおきます。

なぜなら、報告を入れたデバッガー側・テストプレイヤー側はまだ、8面まで進んでおらず、4面ボス「暗黒大王」までしか進んでない人もいるからです。

なお、手前のステージ（この例の場合は1面～3面）のバグについては、報告したプレイヤーだけには個別にメールなどで情報共有しても構わないでしょう（ただし、共有サーバーなどは、他の人も見るので、共有サーバー側では教えないでおく必要があるだろう）。


このような場合の対応策としてオススメなのは、「合計で何個の同種のバグがあるか」という情報を情報共有することです。

たとえば例の「暗黒大王」バグと「ゾンビ暗黒大王」バグの場合なら、合計でボス2体あるいは2ステージぶん、このバグがあるわけですから。

たとえば情報共通では
 4面ボス戦でバグで○○が起きてしまうバグ、およびゲーム後半ステージでの似たようなアルゴリズムのボス敵の類似バグとで、少なくとも合計2件、このバグがありました。
みたいにプログラマー側とデバッガー側とで情報共有すれば、

これはデバッガー側にもネタバレにならずに済みます。

また、万が一、デバッガー側があとから5件や10件も同種のバグを見つけたら、「合計2件」を大幅に超えてることから、プログラマー側の確認モレをデバッガー側が発見したことも分かるようになるという、情報共有の仕方です。

プログラマー側の大幅な確認モレが分かれば、デバッガー側は再度、追加報告する必要があることも、分かるようになります。


==== 優先度づけ ====
この段階で、対応の優先度などのトリアージをします。

最初のバグ報告の時点ですでにとりあえずのトリアージがある場合、返事の際にトリアージの優先度を変更する場合もあるかもしれません。


==== 修正 ====
コードの修正は、プログラマーが実際にキーボードを使って手入力などで行います。こればかりは、自動化は出来ないのです。


==== 修正確認 ====
よくあるミスで、「間違えて修正前バージョンをアップロードしてしまう」、「バージョン番号は修正版になっているのに中身が修正前のまま」（あるいはその逆パターン）、などもミスもあります。

また、修正のコード自体に別のバグが新規に追加されてしまう（「エンバグ」という）場合などもあります。

「デバッグ用の文字などの消し忘れ」、「デバッグモードのオフのし忘れ」などのミスもあります。


そのようなミスが無いかは、実際にバグ報告者や品質管理チームなどがゲームの「修正版」とされるバージョンをテストプレイをして、確認します。


このため、最初のバグ報告を終えても、バグ発生版のセーブデータはなるべく消さずにセーブなどをして保管しておく必要があります。修正確認が終わるまで、バグ報告時点のプレイデータは残しておく必要があります。

=== バグが無かったという報告 ===
==== ver0.01を最初にデバッグプレイする場合 ====
ver0.01やver0.10のような、とても初期のバージョンをプレイする場合、

たとえバグが無い場合でも、ここには「バグが無かった」という報告をします。（ゲームにかぎらず、Linuxなど大手オープンソースソフトのテスト報告なども同様に、「〇〇にはバグが無い」という事を報告します。）

このように現状ではバグの無い、またはバグのきわめて起きづらい部分を見つけ出すことにより、裏を返すと、バグの無いことがまだ確認されていない箇所にバグが潜んでいる確率が高いわけですので、そうやってバグの居場所を突き止めていきます。

実際に商業ゲームでも、たとえば1980～1990年代のセガ（企業名）のアーケードゲーム（ゲームセンターの筐体機用のゲームという意味）では、このような方法で、バグのありかを突き止める方法が行われたらしいです&lt;ref&gt;[https://www.4gamer.net/games/518/G051828/20201111024/index_2.html  『「アストロシティミニ」発売目前！ Hiro師匠＆光吉猛修氏に聞く，FM音源に彩られた1980～1990年代セガ・サウンドの裏側』2020/12/03 00:00 ] 2020年12月4日に閲覧して確認。&lt;/ref&gt;。

例えるなら、プログラムの中に犯人がいて、まだ捜査をしてない場所に犯人が潜んでいる可能性が高いわけです。（参考元のセガ開発者のインタビューで、そういうふうに警察捜査に例えている。）

文献『ゲームクリエイターの仕事 イマドキのゲーム制作現場を大解剖』でも、デバッグを「名探偵のように捜査」と図表で例えています&lt;ref&gt;蛭田健司『ゲームクリエイターの仕事 イマドキのゲーム制作現場を大解剖』、翔泳社、2016年4月14日 初版 第1刷 発行、P103&lt;/ref&gt;。


なお、海外のゲーム開発者の情報ですが、欧米の海外ゲームでもLinux版ユーザーからのバグ報告は良質だと紹介したweb記事もあります（Gigazine『「Linuxゲーマーのバグ報告率は平均の6倍以上」とゲーム開発者が明かす』）&lt;ref&gt;[ https://gigazine.net/news/20211025-linux-gamers-bug-reports/ Gigazine『「Linuxゲーマーのバグ報告率は平均の6倍以上」とゲーム開発者が明かす』 2021年10月25日 21時00分] 2021年10月27日に確認. &lt;/ref&gt;。

このような海外事例もあるので、例外的にもし日本のゲーム市場が海外とよほど異質な品質管理でもしてない限り、オープンソース・コミュニティ一般でのバグ報告の様式は、ゲームのバグ報告でもおおむね通用すると見て、よろしいでしょう。


さて、ゲーム業界ではなくLinuxなどの業界でのテストの場合は、バグが無かった報告のための報告データシートなどの書式が決まっていたり、報告用にテスト操作ごとに入力チェック欄のある専用サイトなどがあったりします。


しかし、ゲームの開発初期バージョンにおける「通しプレイ」には、そんな気の聞いたシステムやサービスは、ありません。（ただし、「壁に体当たり」みたいな、どこのゲームでもチェックするようなデバッグ手法の場合には、個別チェック欄がある可能性もありうる。）

しかし、ゲーム全体の通しプレイでは、そんな個別チェック欄の存在は、まず期待できないでしょう。


なので、デバッガーは、通しプレイの報告スタイルを、自分で考える必要があるかもしれません。

『仕様書』といわれる設計図がデバッグ用のシートを兼ねる場合もありますが、しかし開発初期のほんとに初期バージョンすぎる場合、その『仕様書』そのものが不確定だったり未完成だったりします。このような事情により、IT用語でいう「探索的テスト」という方法で、ゲームの社内デバッガー/テスターはバグ報告せざるを得ない場合も多いかもしれません。ゲームテストの場合、そのゲームの実装にもとづく独自のいろいろな内部プログラムのアルゴリズム/パターンがあるので、そういうのを（開発初期に加わっている）社内デバッガーは察知して、仕様書に無いこと/そもそも仕様書が無い場合もあること、などを意識して探索的テストをする事になる場合も多々あります。

また、同人ゲームには仕様書など存在しません。

:※ アルバイトなどで、デバッグ系テスターを事業としている会社のアルバイト要項などを見ると、あたかもデバッグテストは仕様書やチェックシートにもとづく行為だけかと錯覚しがちです。しかし、そういう外注企業に外注する前に、まず先に発注元のゲーム会社で大まかに通しプレイなどをしてデバッグをしていく必要があります。
:発注元が仕様書そのものを策定するためにも、まず自社でのデバッグによる確認が必要なのです。

::一方、のちの段階で、外注企業としてデバッグ依頼を有料で受ける場合なら、あらかじめ発注元で大まかに通しプレイをして、大まかなデバッグをしてあるハズなので、通しプレイよりも、（選択肢を全パターン確認したり、敗北時の反応を確認するなどの）局所的なチェックを優先する事が望ましい、と考えられます。（ただし、仕様の把握のために外注サイドでもテスターは一度は通しプレイをする必要があるので、程度問題です。）


ともかく、開発初期の時点のデバッガー・テスターは、プランナー（仕様の制定者。いわゆる「作者」）などとヤリトリをしていく仕事を通じて、そのゲームに適したバグ報告スタイルそのものを模索して確立していく必要が生じますので、ある程度はそのゲームを一般プレイヤーの目線でゲーム攻略的にプレイする必要があります。（ただし、短めの日数で攻略プレイを区切る。）


その後、デバッガーは開発のすごく初期の最初のバージョンでは、たといバグが無くても、「自分がプレイした範囲では、どこにバグが無いか」という事を報告する必要があります。

さて、ゲームの場合、単にけっして「どこのシーンでバグが無いか」だけを報告するの'''ではない'''のです。（一般のITソフトとは、ここの仕方が違っているかもしれない。）

なぜならゲームは、そのシーンに到達する前に（重要イベントの選択肢などの選択結果によって）フラグ変数などの影響を受けているからです。だからフラグの状況によっては、他のデバッガーや開発者が追試してもバグが発生しない場合もあります。

なので、「ここにはバグが無かった」という報告をする際には、加えて、そのシーンに至るまでに、途中でどんな感じのプレイをしていたかも加えて報告する必要があります。

たとえばRPGなら、フラグに影響を与えそうな重要イベントの選択肢などでは、自分がどの選択肢を選んだかなどを、加えて報告する必要があるのでしょう。ただし、大まかに報告する必要があります。

なぜなら、ゲーム中のすべての選択を報告するのは、選択肢が膨大すぎるので、まず不可能だからです。（細かい報告をするのは、もう少し完成度の高くなった仕上げの段階からです。）


開発初期のほんと初期バージョンver0.01あたりでは、ゲーム全体に開発チームの労力を回す必要があるため、細かいデバッグは後回しにします。


さらに開発初期では、ゲーム中のどの要素が潜在しているバグに影響を与えやすいかが全く不明であり、重要イベントの選択肢 '''以外'''も潜在バグに影響を与える可能性すらありえるので、とりあえずバランス調整に必要になりそうなプレイ結果も、ついでに報告します。

たとえばRPGの新機能の公開直後なら、いくつかの重要イベントの時点でのレベルとか大まかな装備とか、どこのステージまで攻略したかとか、そういうのも初期テストでは報告します。

レベルが潜在バグに影響を与える可能性だって、開発初期では、ありえるのです。


ただし、この時点（ver0.01あたり）ではバランス調整はしません。なぜなら、ゲーム全体にチームの労力を回す必要があるからです。


なので、デバッガーは今後のバランス調整を見据えて（みすえて）、今後のバランス調整にも使えそうなプレイ結果のデータを、デバッグのテストプレイのついでに報告しとくだけです。


こういったテスト結果をもとに、数人のデバッガーが共通して、「こういうプレイをした結果、ここにはバグが無かった」という事が保証されたなら、

とりあえず、たとい もしそこにバグが潜んでいたとしても、そのバグの発生確率は（「バグが無かった」報告により、発生確率が）低い事が保証されるようになるので、開発チームは他の部分の開発に専念できます。


また、デバッガーどうしでも「〇〇にはバグ無し」情報の共有により、バグ発生確率の低いシーンの検証プレイを後回しにして、まだ未検証の部分の検証プレイに取り掛かることができるようになります。


==== 大幅な更新の直後 ====
ゲームのバージョン更新によって新機能が追加されたばかりの新バージョンには、バグが多く、いろいろな場所にバグが発生する場合があります。

なぜなら、その新機能が、ゲーム中のさまざまな要素に影響を与えるからです。（ゲームに限らず、ITソフトでなにか新機能が追加された場合、バグが多く発生しがちです。）

なので、大幅な機能の追加や、大幅なストーリーの追加などといった、大幅な更新があったら、たといバグが無くても、「ここにはバグ無し」系の報告の必要があります。


 【デバッグ報告】「異常なし」です。
 ソフト「□□□□」のver0.85で大幅にストーリー追加されたバージョンが公開されたので、このver○○で通しプレイおよび、下記の行動をしてみましたが、異常は見られませんでした。今のところ、正常です。
 
 通しプレイ内容
 重要アイテム『ヒスイの首飾り』を本イベントでマップ『隠し洞窟』の魔女から貰いました。
 その後、アサシンギルドのボス『アサシンマスター』を倒したことにより、ダンジョン『アサシンギルド』を攻略しました。
 
 通しプレイでのレベル : Lv40で突入、Lv53で本バージョン追加イベントのクリア 
 
 確認した行為
 ・ △△△
 ・ ～～～
 

みたいな感じでしょうか。


他の利用者が別の利用方法をしてたらバグが見つかる場合もあるので、なので、「自分が何をしている限りは、とりあえず、このソフトにはバグが見つからない」という情報が「異常なし」報告に必要です。

こうすることで、もしバグが今後に他の場所で見つかった場合でも、ソフト作者が「異常なし」報告を受けた部分は後回しにできます。


==== バグが無かったという報告も時には必要 ====
もし仕事でデバッグ依頼を受けている際、開発版ソフトウェアがバージョン更新されてデバッガーなどの協力者に限定公開された場合、デバッガーは検査のためにソフトをテスト使用するワケですが、テストの結果、バグが見つからない場合もあります。

もし仕事のデバッグ依頼を受けている場合、たといバグが見つからなかった場合でも、デバッガーからソフトウェア作者に連絡する必要があります。（ただし、仕事でないソフトの場合、いちいちソフト利用の際に報告の必要は無いし、むしろ作者の手間をかけてしまう。なぜなら、もし作者が利用者全員から報告を受けていたら、人気アプリ作者などは、多くの人から報告されてしまうので返事に手間が掛かってしまうので。）


仕事の場合、IT産業にかぎらず何かの検査では、もし検査の結果として異常が見つからなくても、「今回の何月何日の検査では、ver○○には異常が見つからなかったです」という報告が必要です。日付が必要です。翌日の検査でバグが見つかることも、よくあるので。

なので、最初から、報告レポートに日付欄（ひづけらん）を作っておくのが良いでしょう。

またレポート文中でも、「昨日の報告では」とか書くのではなく、「昨日の5月10日の報告では」みたいに、後日に日付を見ても分かるように、報告書では文中の日付も書きましょう。


ともかく、「異常なし」報告をしないと、そもそも検査の依頼の連絡がテスト者に行き届いてないのかとか、確認のための手間が、製品の作者側に掛かるからです。

さて、ソフトの「異常なし」報告をする場合、「自分はどういった作業をそのソフトウェアで何時間くらい利用していた所、今のところ、ver○○にはバグが見つかりませんでした」というように報告をする必要があります。


たとえば、一例ですが、（※ 未記述）

=== 仕様かバクか不明な場合 ===
ゲーム演出のなかには、一見するとバグっぽい演出もあります。

なのでデバッガーが、ゲームのテストプレイをしているときに見つけた現象が、はたしてバグなのか、それとも意図的な演出なのか、悩むこともよくあります。


このような場合でも、とりあえずはデバッガーは念のためバグかもしれないと報告を挙げておくのが、ゲーム業界での通例だと言われています（要出典）。

たとい結果的にバグではなく意図的な演出だとしても、プログラマー側にとって、ユーザー視点に近い人からの参考意見になります。

もしプログラマー側やクリエイター側は、このような仕様のつもりの部分にバグ報告を受けたら、きちんとデバッガーたちに、「この現象はバグではなく仕様です」ということを説明し、デバッガーたちとプログラマーとで情報共有する必要があります。

=== その他 ===
==== レベル上げやノー・ミスは目的ではない ====
プレイするバージョンについては原則、なるべく最新バージョンをプレイします。

なぜなら、今後のプレイヤーがプレイするバージョンに、もっとも近いバージョンは、現時点での最新バージョンだからです。

なので、RPGやシミュレーションなどのデバッグをしている場合、もし最新バージョンが出たら、とりあえずセーブデータを最新版に移行可能なら、さっさと最新版に移行しましょう（念のため、古いほうのセーブデータもしばらくは残しておく）。


なお、レベル上げのバグの有無の確認については、デバッグ初期の段階で、デバッグモードなどでカンスト（カウンターストップ）チェックを行っているハズです。なので、通しプレイでは、レベル上限チェックの確認の優先順位は、低めでしょう。


とはいえ、一度は誰かが通しプレイでもレベル上げの通しプレイで最高レベル近くなどのレベルをチェックする必要がありますが、しかし時間が掛かりすぎるので、もし誰かが既に1度や2度はレベル上げのカンストのチェックしていれば、あとは他の人がレベル上げをチェックするのは不要でしょう。

このように、一応は通しプレイで誰かが最高レベルや最高スコアなどの上限を確認する必要があるので、なので自分のプレイでの最高レベルなどのセーブデータも一応は保管しておくべきでしょう。

ともかく、このようにデバッガーどうしで役割分担をしましょう（複数のデバッガーがいれば、の場合ですが）。


なお、最新バージョンにセーブデータを移行した際は、攻略の前に、まず『更新履歴』などの情報を読んで、そしてその更新したゲーム内環境の周囲に異常のないことを確認するデバッグ的に色々としてみるプレイをしましょう。

いちおうプログラマー側でも、更新箇所についてはデバッグモードなどで簡易的に確認をしているとは思いますので、この段階ではバグはあまり見つからないのが普通ですが（なので正常な動作が見れるのが普通ですが）、しかしデバッガーにとっても、まず正常な更新結果がどういう結果なのかを知る必要があるのです。


なので、まず正常な更新結果を実際にプレイでさっさと確認してから、そのあとで、通しプレイを始めたり、あるいは移行後のデータを攻略してゲームクリアしたりします。


その後にまだ次のバージョンが出てなければ、今度はニューゲームで最初から通しプレイをしましょう。


また、ノー・ミス（たとえばシューティングゲームなら敵のミサイルを一発も受けないで、全ての敵弾を避けるとか）でクリアするのが目的ではないです。

RPGなどでは、ついつい普通の感覚では、全滅したあとにアプリを保存しないでクローズ（いわゆるリセット）してしまいがちですが、しかし、なるべくデバッグの序盤では、通常のプレイ中にはリセットしないで、そのまま続けて保存してクリアを目指しましょう。なぜなら、デバッグ中にしだいにデバッガーもプレイに上達してしまうので、普通にプレイしてると全滅の回数はしだいに減っていくので、全滅時のデバッグが面倒になっていきます。

なので、ミス時や全滅時などにバグが起きないことも確認する必要があるので、プレイでミスしても、なるべくリセットしないようにしましょう。（ただし、わざと異常なプレイをしている場合には、他のバグ調査と区別するために、保存せずにリセットする場合もあります。）

== バグ報告したあとのデバッガ－ ==
バグが見つかって、報告が終わったら、デバッガー・テスターは空き時間に、類似のバグが無いかを探します。

デバッガーの手元に、バグ再現時に近いデータがありますので（しばらくセーブデータなどを残す必要があります）、ソレを使い、
:報告したバグ内容に近いけど微妙に変えた操作をいろいろとしてみて、バグが起きるか起きないかを調べます。


たとえば、もし報告したバグ内容が下記の例の場合、

:例
 【バグ報告】 ウッキークエスト ver0.87 。ハジメガルド武器屋オヤジの会話時のキャラチップ表示ズレ
 
    ・[バグの症状]   ゲーム中盤でのハジメガルド武器屋の親父の会話時のキャラチップ位置表示ズレです。 
 
    ・[発生の頻度]  当の武器屋オヤジに話しかけるたび、毎回バグ発生です。3回、確認しました。
 
    ・[添付ファイルの内容] メール添付画像は、バグ発生時のオヤジ画像チップが店の壁に乗ってしまってるナゾ画像です。
     
    ・[バグの発生方法]   ゲーム序盤の第1章から行ける街・ハジメガルドの武器屋の親父に、
       ゲーム中盤の第三章になってからハジメガルドに行き、
       自軍パーティ構成が戦士・戦士・僧侶の3人パーティの
       味方平均レベル28くらいの状態で武器屋親父に話しかけると、
       なぜか親父が話しかけるたびに、
       バグによって親父のキャラチップの表示位置が1マスぶん右にズレます。
 
     ・[参考情報]
       私の今回のテストプレイでは、まだ「伝説の剣」は入手していません。
      「伝説の盾」は、このバグ発生の時点で入手しています。
       伝説の盾を守っている中ボス・暗黒大王も撃破してあります。
       
      今回のプレイでは、装備はまだハガネ装備です。ミスリル装備は、していない状態です。
      ミスリル鉱山の街をすでに帝国軍から解放しましたが、プレイヤー所持金を節約するためハガネ装備のままです。
      ハガネ装備のままレベル28まで上げて暗黒大王を倒しています。

上述のような報告を先にしたら、デバッガーは報告後にテストプレイで、たとえば、
:ハジメガルド街の武器屋ではなく、道具屋の主人に話しかけたらどうなるかとか、あるいは宿屋の主人に話しかけた場合はどうなるかとか、
:あるいは自軍パーティ構成を変えたらどうなるかとか、
:あるいは、周囲の他の街の武器屋や道具屋・宿屋の主人に話しかけたらどうなるかとか、

いろいろとテストプレイで試します。（このテストには時間が掛かるので、なので先に報告しておく必要がある。）

== 仕様の矛盾や不具合を見つけた時の報告 ==
=== 概要 ===
デバッガーは、場合によっては、バランス調整チームよりも先に、テストプレイをする場合もあります。

その場合、細かなバランス調整などはデバッガーはしないで、あとのバランス調整チームに任せます。さて、このようなデバッガー先行のテストプレイのとき、仕様（設計）そのものの問題点をデバッガーが見つける場合も、ときどきあります。


プレイヤーにとって「よかれ」と思って作られた設計が、実際にゲームに実装されてみたバージョンをプレイしたとき、その仕様のせいで他の問題点が発生していたりとか、そういう現象にデバッガーが遭遇する場合もあります。

なので、バグ報告のサーバなどは、仕様の改善案などの提出サーバなども兼ねます。


この場合、けっして単に「この仕様のここはオカシイ」とだけ報告を入れるのではなく、できれば大まかに改善案を提案し、つまり、どう直すとイイかを自分なりに考えて数パターンほどの改善案に提案すると、担当者に話が通じやすいです。

こう説明したほうが通じやすい理由は、具体例があったほうが分かりやすいから、です。提案する事自体はあまり目的ではなく、具体例で説明して分かりやすく伝える事が目的です。


=== シナリオなどのデバッグ ===
==== シナリオ系バグの種類 ====
テストプレイヤーは、シナリオ検証も必要です。まず、一口に「シナリオ系のバグ」と言っても、下記のように大まかには幾つかの種類があります。
:* 大元の脚本自体に矛盾があり、ストーリーなどが前半と後半で矛盾しているような場合、
:* 脚本のストーリーには問題なさそうだが、ゲーム作成時のフラグ分岐などの対応用シナリオの作成漏れや内容ミス、
などです。

実際には、上の2種類のバグが融合したような、シナリオバグもあります。もしかしたら、だいたいソレかもしれません。


ともかくゲームの場合、一般の小説やマンガとは違い、プレイの結果によるフラグ分岐によってストーリーが変化するという性質があります。

このため、上記のように、フラグ分岐の数が増えたら、ゲーム内イベントなどの小ストーリーも追加して新たに作成して加える必要があります。


一つのゲーム内には、イベントがいくつもあるので、ときどき、イベント用の小シナリオ作成時にミスとして、そもそものフラグ分岐に対応し忘れたために、そもそもの分岐先シナリオが欠けてしまうバグの場合があります（もちろん、デバッグで直す必要がある。つまりデバッグとして、忘れていた分岐シナリオを作成してゲームに実装する必要がある）。

あるいは、分岐先の対応シナリオそのものは存在しているが、しかし実際のフラグ内容と、分岐シナリオのメッセージ内容がミスって不整合になっている、などのような事例です。

==== 脚本自体のバグの場合 ====
仮に、改善すべきシナリオバグの種類が、脚本自体のバグだとしましょう。もし、キャラクターの会話文などの表現の問題である場合、たとえば、「この性格のキャラクターが、こういう事を言うのはオカシイ」ような問題の場合なら、

改善案の提案では、具体的なセリフは書かないでおくほうが、著作権などの理由で安全な場合もあります。

たとえば、
:「このシーンでなら、このキャラクターは、これこれこういう内容の発言をすべきです。なぜなら～～～」
みたいに、説明文で説明したほうが伝わりやすいです。


あまり、キャラクターの言い回しなどの具体的な表現は、デバッガー側では考えず、表現についてはシナリオライターなどの著作者に任せたほうが、お互いにラクです。

その理由は、法律の著作権などの理由もあります。著作権法では、アイデアは著作権の対象には、ならないのです。（法学の専門用度で「アイデア/表現の二分論」と言います。）

社内の権利関係の管理をラクにさせるため、著作権者はなるべくシナリオライターに統一させます。


そのため、あえてデバッガーなどは、もし表現の不整合に気づいて改善案を出す場合でも、アイデア提案までに留めたほうが良いでしょう。具体的な言いまわしなどはシナリオライターに任せたほうがいいかもしれません。

これは裏を返すと、ゲーム製作では、じつはメインのシナリオライター以外にも、プログラマーやグラフィッカーやデバッガーなどのスタッフも、テストプレイなどを通して、実は少々のシナリオ提案をしている、という事でもあります。（もちろんシナリオ作成の比率はシナリオライターのほうが高いですが）

会話文にかぎらず、ゲーム中の説明文の表示なども、実際にどう表示するかは、なるべく、それぞれの担当者に任せるのが良いでしょう。


テストプレイ中に矛盾点に気づいた場合は、具体的な表現には踏み込まないようにして、しかしアイデアは具体的に「ここでコレを表示すべきです」みたいに具体的に提案する必要があります。


このようにシナリオのデバッグをする際の注意点・留意点として、なるべくシナリオ変更のアイデアの決定権は、シナリオライターに任せます。つまり、けっして多数決には、しないほうが安全です。理由は幾つかありますが、理由のひとつとして、追加シナリオや次回作シナリオなどの今後のシナリオ作成時にも対応する必要があるから、です。

単に現時点で存在しているシナリオ案だけの一時的・一部の矛盾を直すだけなら、単なる（非シナリオライターの）テスター・デバッガーでも出来てしまいますが、しかし変更したシナリオをもとに今後のシナリオを考える事をするのはシナリオライターでないと困難です。

このため、シナリオ変更案の採用の有無の権限は、シナリオライターおよび開発リーダーなどに（採用の権限を）委ねましょう。また、けっしてシナリオライターを飛び越して開発リーダーに直訴・越訴するような事は断じて、やめましょう。

このような直訴・越訴のようなトラブルを防ぐ方法として、たとえば、最初から社内公開のサーバーで仕様変更案を受け付けるとかのように社内公開の場でのみシナリオ変更案を受け付けるなど、そういった工夫などをすると良いかもしれません。


さて、シナリオ改善案の採用の権限は、シナリオライターと開発チームリーダだけが握るのでした。

つまり、けっして小中学校の学級会のような、多数決で何でも決まるような決定方法は、行わないほうが良いでしょう。というかそもそも企業社会は基本的に、学級会のようなシステムは取っていません（たとえば株式会社における株式総会ですら、決して多数決ではありません（株数に応じて票数が割り当てられるので））。

ときどき、高校や大学を卒業したばかりの人は、ここら辺の社会常識を勘違いしている人がいます。自分がそういう勘違い人間にならないように、気をつけましょう。学級会や、現実の政治選挙のような決定システムは、社会全体で見れば、割合と特殊で異例な決定システムです。
:※ マンガ業界でも、既に1990年代に漫画家の小林よしのりが造語の『学級民主主義』という表現で、彼の著書のゴーマニズム宣言の中で、上述のような若者にありがちな、ビジネスを学級会と混同するような勘違いを揶揄しています。


また、こういうことは、テスター視点ではなくゲームデザイナーなど担当者の視点から考えてみれば、デザイナーは、テスターなどからの意見は聞くが、しかし判断は絶対にゆだねず、最終的な判断はデザイナーが自己の責任をもつことを覚悟するということでもあります&lt;ref&gt;塩川洋介『ゲームデザイン プロフェッショナル』、技術評論社、P.211&lt;/ref&gt;。書籍『ゲームデザイン プロフェッショナル』によると、書籍では文脈はやや違ってシナリオ改善案に限ったことではないですが、文献中の大見出しで「意見を聞くが、判断は決して委ねない」とあります&lt;ref&gt;塩川洋介『ゲームデザイン プロフェッショナル』、技術評論社、P.211&lt;/ref&gt;。テスターの話に限らず、ゲーム制作のチームリーダーが『最もやってはいけないコミュニケーションのひとつが、「話を聞きすぎること」』だと著書の塩川氏は述べています」&lt;ref&gt;『ゲームデザイン プロフェッショナル』、P253&lt;/ref&gt;。

マンガ『ナナのリテラシー』第2巻でも、作中の老齢ゲーム作家が商業ゲーム開発を「エゴイスティック」という表現とともに、けっして皆で仲良く作るものではないと自身の体験を説明しています。

また、1995～2005年頃にゲーム評論家の阿部広樹が著書で言うには、彼はもとはゲーム会社出身でその後にゲーム評論家になったのですが、ある作品のゲーム評論にて、そのゲームは学生レベルのゲーム制作をテーマにしたシミュレーション的ゲームだったのですが（つまりゲーム内キャラがゲームを作る）、おおむね阿部は「このゲームでは、能力値の低いキャラは、仲間にしても足手まといだが、著者の経験からするとリアルである」と表現していました。

イマジニア社の1999年の作品『ゲームソフトをつくろう』というのがありますので、おそらく時期的にこれだと思います。

ともかく、多数決でのゲーム制作は、論外のようです。


なお、開発チーム内に複数人のシナリオライターがいるサークル内での場合については、その場合でも上記の開発例と同様に、なるべく、メインのシナリオライターと開発リーダーにだけシナリオ変更の採用の権限を委ねるのが、トラブルを防げて安全だと思います。（ただし、劇中劇などのように、特殊性の高い部分シナリオの場合、その劇中劇だけサブ・シナリオライターなどにも決定権を与えるのも、アリかもしれません。）


たとえば、ゲームに限らずアニメ業界などでも一昔前では、アニメ監督をしている人が、自身の監督している作品が終わった後の時代には、他のアニメ監督の下で下働きをしているような場合もありました（最近はどうか知りませんが）。

マンガ界などでも一昔前では、月刊マイナー漫画誌などで連載終了して手の空いて収入も無くなった漫画家が、別の連載作家（たいてい、終了した側の漫画家が元アシスタントをしていた作家）の連載中マンガ制作を手伝うような事も、ときどきありました。


「船頭多くして、船、山に登る」という戒め（いましめ）のコトワザがあります。

ゲーム開発でも、決して船が山に登らないようにするため、メインのシナリオライター・開発リーダーなどにシナリオ採用の権限を一元化するのが安全でしょう。


そうそう、漫画家は、会社員ではありませんので、連載やアシスタント仕事などの無い期間は、給料はゼロ円です。印税などで稼ぐしかありません。また、単行本の売り上げが少なすぎる場合、単行本化を打ち切られますので、印税の収入源も途絶えます。

世間でよくある勘違いで、「作家を、いったんプロになれば、（公務員のように）定年まで身分（および収入）が保証される」というような勘違いをしている人が多々います。しかし、全く現実に即していない勘違いですので、考えを改めましょう。漫画家の 小林よしのり も、彼は少年ジャンプでのデビュー前まで、てっきり漫画家は定年まで収入が保証されるものだと勘違いしていたと著作『ゴーマニズム宣言』で述べています。


マンガに限らずアニメでも同様です。


これはつまり、元・連載漫画家が、自身の連載終了後に他作家のアシスタントとして生計を立てている場合、当然ですが収入額はアシスタント時代にまでダウンしています。

アニメ監督が、別のアニメ監督の人の下で下働きをしている場合もおそらく同様に、給料は下働きか、せいぜい中間管理職くらいの収入額までダウンしている、という事です。


なのでゲーム会社員でも、他のシナリオライターの下でシナリオのデバッグをしている場合、当然ですが収入は（もしあるとしても）、テスター程度のものだろうという事を覚悟しなければならないかもしれません（このページ書いた人は、あまりよく知りません）。もっとも、そもそもフリーゲーム開発の場合なら、収入自体がゼロですが。

==== どんな矛盾がシナリオ脚本のバグか？ ====
ゲームに限らずマンガやアニメも含めた娯楽フィクションのシナリオの場合、現実とは違って、意図的に矛盾を起こしたシナリオを使う場合があります。たとえばギャグ作品なんか、わざとトークの前後で矛盾をさせる事もよくあります。落語なども同様でしょう。

さらにファンタジー世界やSF世界などで（私たちの）現実世界とはゲーム中の物理法則や時空の法則が違っているので、現実では矛盾していても、ゲーム設定としては矛盾していない場合や、矛盾していても「演出」などとして許される場合もあります。


このため、シナリオの矛盾の報告で、修正すべき矛盾を見つけるのは、なかなか難しいです。

ゲームでは更に、テンポ感などの理由で、小さな矛盾を製作者が意図的に無視する場合すらあります。もし矛盾を修正しようとすると、ゲーム中での説明会話が長くなってしまい、「テンポ感を損ねるだろう」といった判断によって、小さなシナリオ矛盾を残すという高等的なテクニックすらあります。

例外として推理ゲームや推理イベントなどといった、けっして矛盾の許されない例外を除き、ゲームシナリオのデバッグでは必ずしも、杓子定規に全ての矛盾をゼロにするという事は、ゲーム開発では良策とは限らないのです。


アニメ業界でも、ギャグ作品ではないですが、宮崎アニメの主人公パズーの会話シーンで、実はストーリーの冒頭と中盤と後半の会話を見比べると、じつは主人公パズーの性格が微妙に一貫していない、という指摘がアニメ評論家からされた事もあります（「と学会」や「トリビアの泉」で有名な唐沢俊一が８０年代の当時、そういう指摘をしていました）。アニメでもテンポ感のために意図的に矛盾させる技法もあります。

==== 直すべきバグとは作品テーマに反するバグ ====
ですが、それでもあえて、あるシナリオの矛盾を修正しなければならない場合もあります。その例の一つとしては、物語のテーマに反する誤解を与えるような矛盾のある場合です。

たとえば、物語のテーマが、「思春期の男女は、恋愛を通じて人間性も成長する」というようなテーマの場合、もし、たとえば恋愛関係にある男女（仮にボブ（男）とクレア（女）としましょう）が、本来ならボブとクレアは恋愛関係にあるのに、テンポなどの事情でセリフが削られたりして、あたかも「ボブとクレアは嫌いあってる」とか、そもそも「ボブとクレアが恋愛関係にはない、単なる同級生」のような印象をプレイヤーに与えるようなシーンがあるとしたら、おそらくそのシーンはバグと見なして修正されるべきです。

このように、物語テーマに反するシーンなどは、シナリオのバグの可能性があります。


==== 裏テーマという存在 ====
なお、ゲーム開発において必ずしも、いちいち「このゲームのシナリオのテーマは、〇〇です。どういうことかというと（以下略）」みたいな説明は無いことが、よくあります。

「プレイすれば、まともな感覚があれば、物語のテーマくらい分かるでしょ？　大人なんだからさぁ」みたいな感じで、いちいちシナリオテーマはデバッガーなどには説明されないでしょう。

あるいは、表向きのテーマとは別に、名言されていない裏のテーマなどが存在している場合もあります。演出などの都合で、裏テーマはあえて名言されない場合もあります。

たとえば小学生くらいの子供むけのターゲットな明るいゲーム作品などで、「良い大人になるためには、子供はどうあるべきか？」みたいなマジメなテーマは普通、名言はされないで、裏テーマに回るでしょう。

なのでシナリオのデバッグをする場合には、そういった裏テーマも読み取った上で、シナリオをデバッグする必要があります。


上記のノウハウを聞くだけなら簡単そうですが、しかし大変なのは、この「裏テーマの発見」をする事です。シナリオのデバッグ中に、けっしていきなり裏テーマにピンポイントな修正案件が見つかることはありません。

たいてい、最初に見つかるシナリオバグは、単なる設定矛盾などです。

単に仕様書などと照らし合わせれば発見できる一般的なバグとは違い、シナリオのバグの発見には作品への読解や理解が必要です。なので、けっしていきなり最初にピンポイントにシナリオの裏テーマ関連バグは見つかりません。というか、そもそも裏テーマは巧妙に隠されてるからこそ、「裏」のテーマなのです。

テスター・デバッガーたちが細かな設定矛盾などを報告してプログラマーなどが直しているうちに、たまに、ついに裏テーマにピンポイントなシナリオ矛盾をデバッグ関係者の誰かが見つけるって事が、たまにあります。

このように、けっしていきなりは、ピンポイントなシナリオ矛盾は見つかりません。

なのでまず、小さなシナリオ矛盾であっても、よほどテンポ感を下げない限りは、（なるべくテンポ感を下げないまま）とりあえずは矛盾を直していく（矛盾を小さくしていく）のが安全です。

諺（ことわざ）「将を射んと欲せば、まず馬を射よ」のようなものです。


あと、そもそもシナリオライター自身が、自身の脚本に隠れた裏テーマにあまり自覚できていない場合もあります。なのでライターに「この作品のテーマはなんですか？」とか質問しても無駄です。なのでテスターなどが頑張ってシナリオを読解・推察していくしか、裏テーマを見つけだす方法は、ありません。


なお、本wikiでは説明の都合で、あたかも報告当時に「これが裏テーマだ」と気づいたかのように説明しますが、しかし実際には「裏テーマ」として気づくのは数ヵ月後またはリリース後だったりします。

月日が経ってから、ようやく、あとで「あ、あのときシナリオ修正されたアレこそが物語の裏テーマだったんだ」と気づいていきます。

シナリオライター自身の見落としてい第3の物語テーマがテスト中に見つかる場合もありますが、これも「テーマだ」として自覚されるのは数ヵ月後だったりリリース後だったりして、リリース前のデバッグ期間中にはテーマかどうかは分からないものです。


このように、裏テーマか第三テーマかどうかは、リリース前のデバッグ期間中には判定しづらいので、あまり杓子定規には堅苦しくは考えすぎないようにして、とりあえず、ある程度はシナリオライターたちの感性に任せてシナリオ修正していくことになるでしょう。


==== レアケース対応漏れなどのシナリオバグの探し方 ====
レアケース対応漏れなどといったシナリオ作成漏れのバグの探査方法は、仕様書があればそれで見つけるのも良いですが、他にもゲーム実機の実際のテストプレイなどで見つかることも多いです。


なので、テスターはまず、そのゲームの想定するシナリオを通しプレイなどでクリアして、いったんシナリオを把握します。その後、フリープレイ時やテストプレイ時などに、ついでにシナリオ上の矛盾点が見つかる場合もあります。

イベント進行などの状況によって会話などのテキストメッセージ内容が変わりゲーム作品も多くあります。もしゲーム中の説明文や会話文などのメッセージ文の内容と、イベント進行状況が組み合っていなかったりする場合には、バグとなります。

つまり、シナリオ作成時のミスで、分岐先シナリオの作成漏れが出てくる場合もあります。

このようなメッセージ内容のバグは、テスターが実際にゲームのシナリオを把握していないと、そもそも「これはバグである」とは気づかないのです。


さて、このイベント進行状況とメッセージ文の不整合により、ときどき、作品テーマに反する誤解をプレイヤーに与えてしまう場合があるのです。

たとえば、（いくつか前の段落の例での）ボブとクレアの恋人関係の例なら、ストーリー前半でクレアが主人公の仲間になっているのに、もしボブのメッセージ文がストーリー前半でのクレアのパーティ加入に対応してなかったら（もしフラグ管理ミスでストーリー中盤以降からしかクレア加入の場合にしかボブ会話文のフラグ分岐が対応してなかったら）、あたかもボブが恋人クレアをガン無視している（←フラグ上ではクレアが未加入なので. ）かのようにプレイヤーに誤解を与えてしまいかねず、ボブとクレアが不仲になったかのように誤解されかねない・・・、というワケです。

たとえば、クレアが仲間になる条件が、加入条件になっている中盤ボス（レベルはストーリー中盤相当）を倒すことだとして、一般的なプレイヤ－はゲーム中盤にそのボスを倒すので、クレアを仲間にするのも中盤になるプレイヤーが多いとしましょう。

ですが、もし（中盤ではなく）ゲーム前半でもその強ボスを倒すのが原理的に可能なプログラムになっているゲームの場合、プレイヤーの一部はストーリー前半でもそのボスを倒して、クレアを（中盤ではなく）ストーリー前半で仲間にする場合もあるのです。こういったレア目なケースは、理想的にはシナリオ作成の段階でレアケースにも対応できれば理想ですが、しかしライターやプログラマーなどの忙しさなどの関係で、レアケース対応のシナリオの執筆や実装そのものが忘れられて分岐先シナリオ自体の作成漏れというミスをしている場合があります（特にフリーゲームや同人ゲームなど）。

つまり、（「あるイベントのシナリオが仕様と不一致」ではなく）「そもそも、イベントのレアケースの場合だと、その場合のシナリオ自体が作成漏れで無い」という事例もあるのです。

しかしプログラム的に禁止されて無いプレイである限りは、どんなにレアなケースでも、プレイヤーの一部には、そのレアケースのプレイをする人も少数の割合ながら、いるのです。

このようなレアケース漏れや分岐シナリオ作成漏れを見つけるには、テスターは実際に何周もテストプレイをしてみて、様々な攻略パターンでプレイして見つけるしか、ありません。


このような事例があるので、なのでシナリオのバグの有無の確認では、（けっして脚本テキストデータの通読だけでなく、加えて）実際にゲームをプレイしてみて、ゲーム中のメッセージ文をプレイの順序どおりに読んでいくという方法により、テストプレイではバグの有無を確認していく必要があります。


{{コラム|RPGのシナリオは一本道|
岡田斗司夫の1997年『東大オタク学講座』に書かれている事例ですが、
RPGのシナリオは実はほぼ1本道であり、アニメの作り方と似ている部分もあると言われています。

岡田は、そういう RPGの作り方を、ルナ・シルバスターストーリーなどのシリーズを作っていたゲーム会社の人から聞いたと言います。

そして岡田は、大学の講義などで、「確かに市販のRPGのシナリオ構成はそうなっていて、途中で若干の分岐がある場合もあるが、おおむね一本道のストーリーですね」と講義で学生に言っています。

特に大学生から反論が出たとかそういう話は聞かないし文中にも書かれていないので、まあ、大学生もそう思っているのでしょう。


本wikiを読めばわかると思いますが、シナリオ選択肢の自由度に限らず、ゲーム中の自由度の高さはそのままデバッグやバランス調整などの手間を二次関数的に上昇させますので、

よって、ゲーム全体でシナリオのパターンを増やすなどして自由度を高めるのは、調整などの手間が上がります。（また、それとは別理由も考えられ、単純に古いゲームは容量不足の問題もあるので、なんでもかんでも機能を詰め込みできない。）

フリーシナリオで有名なロマサガのシリーズですら、結局は最後に倒す敵は共通ですし、最後のほうに訪れる地域やダンジョンもおおむね共通です。
真・女神転生シリーズなども少なくともスーファミ版の時代は同様です。


実装の手間を無視した企画だけなら、自由度の高い作品の企画や、カスタム性の高い企画は、いくらでも出せます。しかし実際は、人件費などの制約が生じます。

ゲーム評論家の阿部弘樹も、この人はゲーム業界出身であり企画の仕事もしてたのですが、彼はゲーム会社時代の企画で「ファイナルファンタジーのようなファイナルファイト」を思いついたと言いますが、
企画当初は上司に絶賛されたものの、しかし企画を詰めていく段階でシナリオなどの実現性が困難として、仕方なく諦めざるを得なかったという体験談を、阿部の著書では述べています。

もちろん、アクションRPG自体は実現性あるジャンルであり、実際にファルコム社のイースのシリーズのようにファンタジーRPGをアクション化したものは存在します（阿部もイースに言及している）。

しかし、イースは操作キャラクターが1人（主人公アドルだけ）ですし、武器や防具の種類も少な目です（たとえばスーファミ版イース3では、武器は剣の5段階のみ。）

なのにもし、ファイファン（RPG）のようなファイナルファイト（格闘ゲーム）を作るとなると、
まず操作キャラクターの分だけ、
:イース一本（アドル一人分）のシナリオ量　×　キャラクター量
のシナリオが単純計算で必要になります。

その上、ファイナルファンタジーのように多種類の武器（剣のほか槍や斧や弓やハンマーやムチや・・・）や防具の種類を作るとなると、
そのぶんの調整も、膨大に増大します。調整以前の武器の設定などを考えるのも一苦労です。

単純計算で、武器の調整だけでも、　
:武器の種類分　×　イース調整　
の手間になります。

しかも、これがファイナルファイト（格闘ゲーム）のようにコマンド入力の必殺技などを用意するわけですから、
かなり製作がキツイです。

阿部らの会社は、こういう制作作業の膨大さや調整などの手間に気づき、なくなく、「ファイナルファイトのようなファイナルファンタジー」案を諦めました。
}}

==== アイデアの批判をしない ====
ゲーム開発では、予算の問題などで不可能になるアイデアはありますが、しかしだからといって、けっして、アイデア出しの段階で、予算のことばかりを考えてはいけません&lt;ref&gt;川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日 第1版 第1刷、P.385&lt;/ref&gt;。

程度問題ですが、ちょっとぐらい予算が掛かりそうでも、とりあえず色々とアイデアを考えて見ましょう。また、もしかしたら予算をかけないで上手くやる方法がそのうち見つかるかもしれません。リスクを負わなければリターン（報酬）もないのです。

「ブレイン・ストーミング」という集団でアイデアを出すための基本テクニックがあり、それによると、そもそもアイデア出しのための打ち合わせや企画前段階の時点では、批判をしません。
:批判をしない、結論を出さない、
:奇抜なアイデアを歓迎、
:質より量。とにかく量。
:他の議論参加者のアイデアの流用を歓迎、
などが、ブレイン・ストーミングの基本テクニックです。

ブレイン・ストーミングについては高校でも習うので、それを参照してください。

== チェックシートを作成する場合 ==
=== テストシートを作るなら ===
フリーゲームや小規模の同人ゲームでは不要かもしれませんが、大規模なゲームを作る場合は、テストにおいて、確認漏れの無いようチェックシートが普通は必要であり、そのような一覧表のことを「テストシート」または「テスト仕様書」などと言われます。

ここでいう「テストシート」または「テスト仕様書」とは、バグが無いかの検査するためのチェックリストの一覧表のことです。

なお、「デバッグシート」とは意味が違います。デバッグシートとは、バグが実際に発生した際、そのゲームに寄せられたバグの報告を一覧にまとめたものです。


ゲームの場合、テストシートに必要とされる項目はある程度は慣習的に決まっていて、

:【前提条件】　下記の手順のための前提条件（イベントAをクリア済みとか、アイテムBを入手済みとか、）
:【手順】　確認すべき手順の明記。手順が複数の段階に分かれる場合、「1番: 〇〇画面で□□のボタンを押す」「2番: △△画面で××キーを押す」のように、番号も明記しつつ、手順を確実に明記。
:【期待される結果】　上記の手順の実行後に期待される、（もしバグが無い場合の）正常とされる場合の仕様の明記。
:【実際の結果　手順の実行後に実際に起きた結果を、欄内にうまくまとめる。
:【合格、NGの明記】　けっして文章で曖昧に長々と説明するのではなく、「合格」または「NG」などと明言する欄を設けるべきです。（「不合格」だと脱字の際に「合格」と混同の恐れあり）
:【日付、確認日】　仕事の書類を作る際、後日の管理のために、確認日の日付が必要です。
:【確認者】 その確認日に、確認した人物が誰なのかも明記します。順序が逆の場合もあります（先に確認者、あとに確認日の場合も）。

なお、ゲーム以外の一般のIT業界でも、テストシートの要件はおおむね上述のように「前提条件」・「手順」・「期待される結果」の3件を含んでいます。


また、数値などをチェックする際は、実際のゲーム中に表示された数値を【実際の結果】欄に書くと良いでしょう。（ゲームに限らず、製造業などの品質管理チェックシートでも同様です。）

なお、【備考欄】などが、最後の列に付く場合もよくあります。（IT業界に限らず、仕事での一覧表は、たいてい、備考欄がいちばん右にあります。）

エクセル（表計算ソフト）などで、上述のような事を、そのゲームの全ての分岐において、チェック項目として各行に記載して、シートにします。なので前提として、そのゲームの設計仕様書が出来上がっている事が望ましいです。

後日に追記したりするので、紙面ではなくパソコン上にシートを作成する必要があります。


=== デバッグシート（リスト）を作るなら ===
バグ報告とその対応をまとめた一覧表として「デバッグシート」を作成するなら、最低限、下記の3つが必要でしょう。（※　個別のバグの詳細をまとめたものもデバッグシートという場合もありますが、しかしこの節でいう「デバッグシート」とは別物です。このシートでは、いくつものバグ報告の一覧表の事を「デバッグシート」という事にします。）


:【報告時のバグの内容】
:【修正後にあるべき目標の正常仕様の定義】
:【現在の状態】 報告内容がバグのものなら「確認中」、「修正中」、「修正済み」などの対応を明記。また、要望（※ 後述）などに対しては、採用したのか現状維持なのか等も。他、「仕様確認」などがテスターから送られてくる場合も。

後日に追記したりするので、紙面ではなくパソコン上にシートを作成する必要があります。


この他、バグの詳細説明などを書く場合もありますが、しかし、スペースの都合などもあり、なかなか記載すべきか難しいです。

とりあえず、最低でも、上記の3点（「バグ内容」「正常仕様の定義」「現在の状態」）は必要かと思われます。


また、ゲーム制作の場合、バグ発見テスターから、操作方法の改善提案などの提案や要望などが入る場合があります。

デバッグシートが、この要望リストを兼務する場合もあります。


なので、「要望」なのか「バグ報告」なのかと言った、テストチームなどからの報告の【種類】も一覧に書く必要があるかもしれません。


本来、「バグ探し」と「バランス調整」または（操作システムなどの）「開発」とは別の業務なのですが、しかしテスターが実際に発売前の開発中ゲームの制作にテスターとして参加してみると、色々とバランスや操作性などの問題点にも気がつくものらしいのです（ページ編集者はあまりよく知りません）。


テスターにどの程度の権限を与えるかは会社によって違うでしょうが、一応デバッグシート側では念のため、要望などにも対応できるように【種類】の項目を作っておくと良いでしょう。


この他、仕様書に無い実装、仕様書では不明瞭な実装について、確認の要請の報告がテスター等から送られてくる事もありますので、【種類】の項目に『仕様確認』なども入れられるようにしましょう・


その他、
:【確認日】
:【確認者】
なども必要かもしれません。

== 参考文献 ==</text>
      <sha1>djngpn6r6s3cyj93ubfqaietkqwn2kh</sha1>
    </revision>
  </page>
  <page>
    <title>Minecraft/クリーパー</title>
    <ns>0</ns>
    <id>32127</id>
    <revision>
      <id>205751</id>
      <parentid>181061</parentid>
      <timestamp>2022-07-24T05:04:09Z</timestamp>
      <contributor>
        <ip>153.125.238.20</ip>
      </contributor>
      <comment>ページの白紙化</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="0" />
      <sha1>phoiac9h4m842xq45sp7s6u21eteeq1</sha1>
    </revision>
    <revision>
      <id>205752</id>
      <parentid>205751</parentid>
      <timestamp>2022-07-24T05:04:35Z</timestamp>
      <contributor>
        <username>Mtarch11</username>
        <id>59188</id>
      </contributor>
      <minor />
      <comment>Reverted edits by [[Special:Contribs/153.125.238.20|153.125.238.20]] ([[User talk:153.125.238.20|talk]]) to last version by CommonsDelinker: unexplained content removal</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="1186" xml:space="preserve">クリーパーは、マインクラフトのオーバーワールドにスポーンする、敵対モブです。[[Category:Minecraft]]


==この敵対モブについて==
クリーパーは、オーバーワールドの明るさレベル7以下の場所にスポーンする、足が4本あり、緑色の体をした敵対モブです。クリーパーは、近くにいるプレイヤーに近づき、プレイヤーとの距離が3ブロックになると、カウントダウンを始め、2秒後に爆発します。爆発する前にプレイヤーが離れた場合、クリーパーはカウントダウンをやめて再び追跡します。プレイヤーがクリーパーに向かって火打石と打ち金を使用すると、クリーパーはその場で爆発します。クリーパーは、他のモブとは異なり声を発しません。

クリーパーを倒すと、火薬が手に入ります。

近くに[[Minecraft/ヤマネコ|ヤマネコ]]がいる場合、クリーパーはヤマネコから逃げようとします。

クリーパーに雷が当たると、青く光った帯電クリーパーに変化して、爆発力がアップします。</text>
      <sha1>6kcf1q3otk0n6k4qalhbgyucre2ka8d</sha1>
    </revision>
  </page>
  <page>
    <title>Zig</title>
    <ns>0</ns>
    <id>35197</id>
    <revision>
      <id>205753</id>
      <parentid>205495</parentid>
      <timestamp>2022-07-24T05:12:11Z</timestamp>
      <contributor>
        <username>すじにくシチュー</username>
        <id>12058</id>
      </contributor>
      <comment>/* 基礎篇 */ 「分量」とはスプーンとかで測る量のこと。「文章量」に修正。</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="13973" xml:space="preserve">{{Pathnav|メインページ|工学|情報技術|プログラミング|frame=1}}
{{Wikipedia|Zig (プログラミング言語)}}
本書は、[[w:Zig|Zig]]のチュートリアルです。
Zigは、堅牢で最適かつ再利用可能なソフトウェアを維持するための汎用プログラミング言語およびツールチェインです&lt;ref&gt;{{Cite web
|url=https://ziglang.org/
|title=Home ⚡ Zig Programming Language
|website=ziglang.org
|accessdate=2022-07-17
|cite=Zig is a general-purpose programming language and toolchain for maintaining '''robust''', '''optimal''' and '''reusable''' software.
}}&lt;/ref&gt;。
Zigは、アンドリュー・ケリー( ''[https://andrewkelley.me/ Andrew Kelley]'' )によって設計され、汎用システムプログラミング言語で、静的で強い型付けで型推論とジェネリックプログラミングをサポートします。

== 概要 ==
Zigは、2016年2月に発表された比較的若いプログラミング言語で&lt;ref&gt;{{Cite web
|last1=Kelley
|first1=Andrew
|title=Introduction to the Zig Programming Language
|url=https://andrewkelley.me/post/intro-to-zig.html
|website=andrewkelley.me
|accessdate=2022-07-17
}}&lt;/ref&gt;、2022年7月現在のバージョンは 0.9.1 で、'''''pre-release''''' と位置づけられています&lt;ref&gt;{{Cite web
|url=https://github.com/ziglang/zig/releases
|title=Releases · ziglang/zig
|website=github.com
|accessdate=2022-07-17
}}&lt;/ref&gt;。このため [[W:Hello world|Hello world]] ですら、バージョン間で互換性がなくなることもあり、リリースバージョンまでは言語仕様やライブラリーおよびツールチェインの仕様が変更される可能性があります。

=== Hello world の変遷 ===
[https://ziglang.org/documentation/master/ Zig Language Reference]の、[[W:Hello world|Hello world]]の変遷（新しい順）。

;master@2022-07-17&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/master/#Hello-World
|title=Zig Documentation(master@2022-07-17)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.8.1に同じ
;0.9.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.9.1/#Hello-World
|title=Zig Documentation(0.9.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.8.1に同じ
;0.8.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.8.1/#Hello-World
|title=Zig Documentation(0.8.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=4&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().writer();
    try stdout.print(&quot;Hello, {s}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: &lt;code&gt;{}&lt;/code&gt; ⇒ &lt;code&gt;{s}&lt;/code&gt;&lt;ref&gt;{{Cite web
|url=https://ziglang.org/download/0.8.0/release-notes.html#Formatted-Printing
|title=0.8.0 Release Notes
|website=ziglang.org
|accessdate=2022-07-17
|quote=Disable the special casing of {} for u8 slices/arrays. Unless {s} is specified the contents won't be treated as a string.
}}&lt;/ref&gt;
;0.7.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.7.1/#Hello-World
|title=Zig Documentation(0.7.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=3&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().writer();
    try stdout.print(&quot;Hello, {}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: s/outStream/writer/
;0.6.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.6.0/#Hello-World
|title=Zig Documentation(0.6.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=3&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().outStream();
    try stdout.print(&quot;Hello, {}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: 初期化の初期値から &lt;code&gt;try&lt;/code&gt; がなくなった。
;0.4.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.4.0/#Hello-World
|title=Zig Documentation(0.4.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.2.0に同じ
;0.5.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.5.0/#Hello-World
|title=Zig Documentation(0.5.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=4&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    // If this program is run without stdout attached, exit with an error.
    const stdout_file = try std.io.getStdOut();
    // If this program encounters pipe failure when printing to stdout, exit
    // with an error.
    try stdout_file.write(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;
: &lt;var&gt;stdout_file&lt;/var&gt; が &lt;code&gt;var&lt;/code&gt; から &lt;code&gt;const&lt;/code&gt; に変更された。

;0.3.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.3.0/#Hello-World
|title=Zig Documentation(0.3.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.2.0に同じ
;0.2.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.2.0/#Hello-World
|title=Zig Documentation(0.2.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    // If this program is run without stdout attached, exit with an error.
    var stdout_file = try std.io.getStdOut();
    // If this program encounters pipe failure when printing to stdout, exit
    // with an error.
    try stdout_file.write(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;
;0.1.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.1.1/#hello-world
|title=Zig Documentation
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig&gt;
const io = @import(&quot;std&quot;).io;
pub fn main() -&gt; %void {
    %%io.stdout.printf(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;

== 基礎篇 ==
[TODO:書くべき項目を並べてみましたが、例えば「値と型」を網羅的に書いていくと文章量が爆発するのが目に見えているので、過剰になったらリファレンス篇に移動するなどの方法で、各節はコンパクトさを心がけたいです。]

=== コメント ===
Zigでは、&lt;code&gt;//&lt;/code&gt; から行末までがコメントです。
C言語の &lt;code&gt;/* … */&lt;/code&gt; のスタイルの複数行に渡るコメントは'''ありません'''。
これは、コードの各行を文脈に関係なくトークン化できるようにするためです。
:&lt;syntaxhighlight lang=zig&gt;
// @import は組込み関数です。
const std = @import(&quot;std&quot;); // 先頭に @ が付く関数は組込み関数です
pub fn main() !void {
   try std.io.getStdOut().writeAll(&quot;Hello, World!\n&quot;);
}
&lt;/syntaxhighlight&gt;

==== Docコメント ====
Zigでは、&lt;code&gt;///&lt;/code&gt; から始まるコメントは特別なコメントで、Docコメント( ''Doc comments'' )と呼ばれます。
Docコメントは特定の場所にしか許されません。式の途中や非Docコメントの直前など、予想外の場所にdocコメントがあると、コンパイルエラーになります。

[TODO:サンプルコードと整形結果]

==== トップレベルDocコメント ====
Zigでは、&lt;code&gt;//!&lt;/code&gt; から始まるコメントは特別なコメントで、トップレベルDocコメント( ''Top-Level Doc Comments '' )と呼ばれます。
コンテナレベルのドキュメントのように、直後のドキュメントに属さないユーザードキュメントに、トップレベルDocコメントを使います。

[TODO:サンプルコードと整形結果]

DocコメントおよびトップレベルDocコメントは、コンパイル時に zig build-exe -femit-docs ソースファイル.zig の様に、-femit-docs をあたえると、 docs/ 以下にドキュメントが生成されます。

=== 値と型 ===
[TOD0:整数・浮動小数・論理値・文字列・共用体・構造体・列挙・配列・ベクトル・スライス・ポインター・ゼロビットな型]

:&lt;syntaxhighlight lang=zig&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot; (1) = {}\n&quot;, .{42});
    try print(&quot; (2) = {}\n&quot;, .{0x17});
    try print(&quot; (3) = {}\n&quot;, .{0o17});
    try print(&quot; (4) = {}\n&quot;, .{0b0100101});
    try print(&quot; (5) = {}\n&quot;, .{1e222});
    try print(&quot; (6) = {}\n&quot;, .{3.1415926536});
    try print(&quot; (7) = {}\n&quot;, .{'c'});
    try print(&quot; (8) = {c}\n&quot;, .{'c'});
    try print(&quot; (9) = {s}\n&quot;, .{&quot;abcdef&quot;});
    try print(&quot;(10) = {}, {}\n&quot;, .{ 111, 999 });
    try print(&quot;(11) = {1}, {0}\n&quot;, .{ 111, 999 });
    try print(&quot;(12) = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; });
    try print(&quot;(13) = {0d}, {0b}, {0o}, {0x}, {0X}\n&quot;, .{ 123 });
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
 (1) = 42
 (2) = 23
 (3) = 15
 (4) = 37
 (5) = 1.0e+222
 (6) = 3.1415926536e+00
 (7) = 99
 (8) = c
 (9) = abcdef
(10) = 111, 999
(11) = 999, 111
(12) = abc, 111
(13) = 123, 1111011, 173, 7b, 7B
&lt;/syntaxhighlight&gt;
&lt;!-- リテラルの例、というか、@import(&quot;std&quot;).io.getStdOut().writer().print の例になっていますね。--&gt;
ご覧のように、数値（整数と浮動小数点数）や文字・文字列のリテラルがあり、整数は基数を、浮動小数点数は指数表現と少数表現があります。

@import(&quot;std&quot;).io.getStdOut().writer().printの、第一引数は書式化文字列、第二引数は値リストです。
書式化文字列は、通常の文字列ですが &lt;code&gt;{&lt;/code&gt; と &lt;code&gt;}&lt;/code&gt; で囲まれたプレスホルダーが、引数リストの値（を書式化した文字列）に置換わります。
一番素朴なプレスホルダーは {} で、引数の値の一般的な文字列表記に置換ります（整数なら十進数表記、浮動小数点数なら指数表記）。
ところが、’c’ のような文字型を {} に適用すると文字コード化され整数と同じ十進数表記になってしまいます。そこで、文字型の場合は {c} と文字であることを明記すると文字表現となります。
また、文字列の間合いは {s} を明記しないと（バージョン0.8.0からは）エラーになります。
2つ以上の値を渡す場合は、第二引数を　.{ 1, 2, 3 } の様にカンマ区切りのリストにします（ {} の前の . （点）を忘れがち）。
基本的に、左から順にプレスホルダーにリストの値が左から与えられますが、{0} {1} の書式で参照する引数の順位を明示できます。
書式指定と併用する時は、 &lt;code&gt; print(&quot;? = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; })&lt;/code&gt; の様に順位が先、書式指定文字が後になります。

[TODO:[https://github.com/ziglang/zig/blob/master/lib/std/fmt.zig master/lib/std/fmt.zig]を観て書いています。参照すべき標準ライブラリのドキュメントを発見出来たら、見直し]
[TODO:表組み]

==== comptime ====
Zigでは、コンパイル時に式が既知かどうかという概念を重要視しています。

&lt;!--
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const i = 0;
    const string = [_]i32{ 1, 2, 3, 4 };
    for (string) |character, index| {
        std.debug.print(&quot;character: {}, index: {}, :{s} \n&quot;, .{ character, index, @typeName(@TypeOf(character)) });
    }
    _ = i;
}
--&gt;

=== テスト ===
=== 変数 ===
=== 制御構造 ===
[TODO:Zig の制御構造は文ではなく式]
==== 分岐 ====
[TODO:ifとswitch]
==== 反復 ====
[TODO:whileとfor]
=== 関数 ===
=== エラー ===
=== 演算子 ===
==== 優先順位 ====
高
&lt;syntaxhighlight lang=text line&gt;
 x() x[] x.y x.* x.?
 a!b
 x{}
 !x -x -%x ~x &amp;x ?x
 * / % ** *% *| ||
 + - ++ +% -% +| -|
 &lt;&lt; &gt;&gt; &lt;&lt;|
 &amp; ^ | orelse catch
 == != &lt; &gt; &lt;= &gt;=
 and
 or
 = *= *%= *|= /= %= += +%= +|= -= -%= -|= &lt;&lt;= &lt;&lt;|= &gt;&gt;= &amp;= ^= |=
&lt;/syntaxhighlight&gt;
低

===  optional type ===
===  opaque ===
訳語未定
=== ブロック ===
[TODO:スコープとシャドーイング；deferはここ？]
=== キャスト ===
[TODO:Zig は強い型付け()； 型強制 (Type coercion) について]
=== アセンブリ言語との連携 ===
[TODO:所謂インラインアセンラ]
=== atomic ===
=== 非同期関数 ===
=== 組込み関数 ===
[TODO:組込み関数は、@で始まり、@TypeOfや@alignOfの他@sinや@memcpyも組込み関数]
=== メモリ管理 ===
=== キーワード一覧 ===
&lt;code&gt;align&lt;/code&gt;
&lt;code&gt;allowzero&lt;/code&gt;
&lt;code&gt;and&lt;/code&gt;
&lt;code&gt;anyframe&lt;/code&gt;
&lt;code&gt;anytype&lt;/code&gt;
&lt;code&gt;asm&lt;/code&gt;
&lt;code&gt;async&lt;/code&gt;
&lt;code&gt;await&lt;/code&gt;
&lt;code&gt;break&lt;/code&gt;
&lt;code&gt;catch&lt;/code&gt;
&lt;code&gt;comptime&lt;/code&gt;
&lt;code&gt;const&lt;/code&gt;
&lt;code&gt;continue&lt;/code&gt;
&lt;code&gt;defer&lt;/code&gt;
&lt;code&gt;else&lt;/code&gt;
&lt;code&gt;enum&lt;/code&gt;
&lt;code&gt;errdefer&lt;/code&gt;
&lt;code&gt;error&lt;/code&gt;
&lt;code&gt;export&lt;/code&gt;
&lt;code&gt;extern&lt;/code&gt;
&lt;code&gt;fn&lt;/code&gt;
&lt;code&gt;for&lt;/code&gt;
&lt;code&gt;if&lt;/code&gt;
&lt;code&gt;inline&lt;/code&gt;
&lt;code&gt;noalias&lt;/code&gt;
&lt;code&gt;nosuspend&lt;/code&gt;
&lt;code&gt;or&lt;/code&gt;
&lt;code&gt;orelse&lt;/code&gt;
&lt;code&gt;packed&lt;/code&gt;
&lt;code&gt;pub&lt;/code&gt;
&lt;code&gt;resume&lt;/code&gt;
&lt;code&gt;return&lt;/code&gt;
&lt;code&gt;linksection&lt;/code&gt;
&lt;code&gt;struct&lt;/code&gt;
&lt;code&gt;suspend&lt;/code&gt;
&lt;code&gt;switch&lt;/code&gt;
&lt;code&gt;test&lt;/code&gt;
&lt;code&gt;threadlocal&lt;/code&gt;
&lt;code&gt;try&lt;/code&gt;
&lt;code&gt;union&lt;/code&gt;
&lt;code&gt;unreachable&lt;/code&gt;
&lt;code&gt;usingnamespace&lt;/code&gt;
&lt;code&gt;var&lt;/code&gt;
&lt;code&gt;volatile&lt;/code&gt;
&lt;code&gt;while&lt;/code&gt;

== チートシート ==
[TODO:文法と型と頻用する標準ライブラリの関数と型のアンチョコ]

== リファレンス篇 ==

== 脚註 ==
&lt;references /&gt;

== 外部リンク ==
* [https://ziglang.org/ Home ⚡ Zig Programming Language] {{---}} 公式サイト
** [[https://ziglang.org/documentation/master/ Zig Language Reference]] {{---}} リファレンスマニュアル
* [https://github.com/ziglang/zig ziglang/zig: General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.] {{---}} 公式リポジトリ
* [https://zig-play.dev/ Zig Playground] {{---}} オンライン実行環境
** [https://github.com/gsquire/zig-play About An online Zig compiler inspired by Go and Rust] {{---}} リポジトリ

[[Category:zig|*]]
[[Category:プログラミング言語]]</text>
      <sha1>hbkrog6i36cvjs371t8dnxx8uhdt2nd</sha1>
    </revision>
    <revision>
      <id>205754</id>
      <parentid>205753</parentid>
      <timestamp>2022-07-24T05:30:26Z</timestamp>
      <contributor>
        <username>すじにくシチュー</username>
        <id>12058</id>
      </contributor>
      <comment>インストール方法など。Fedora Linux の場合。Ubuntu など他の環境が手元に無いのでそっちは知らない。mac持ってないので放置。macerが自分で書け。</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="16445" xml:space="preserve">{{Pathnav|メインページ|工学|情報技術|プログラミング|frame=1}}
{{Wikipedia|Zig (プログラミング言語)}}
本書は、[[w:Zig|Zig]]のチュートリアルです。
Zigは、堅牢で最適かつ再利用可能なソフトウェアを維持するための汎用プログラミング言語およびツールチェインです&lt;ref&gt;{{Cite web
|url=https://ziglang.org/
|title=Home ⚡ Zig Programming Language
|website=ziglang.org
|accessdate=2022-07-17
|cite=Zig is a general-purpose programming language and toolchain for maintaining '''robust''', '''optimal''' and '''reusable''' software.
}}&lt;/ref&gt;。
Zigは、アンドリュー・ケリー( ''[https://andrewkelley.me/ Andrew Kelley]'' )によって設計され、汎用システムプログラミング言語で、静的で強い型付けで型推論とジェネリックプログラミングをサポートします。

== 概要 ==
Zigは、2016年2月に発表された比較的若いプログラミング言語で&lt;ref&gt;{{Cite web
|last1=Kelley
|first1=Andrew
|title=Introduction to the Zig Programming Language
|url=https://andrewkelley.me/post/intro-to-zig.html
|website=andrewkelley.me
|accessdate=2022-07-17
}}&lt;/ref&gt;、2022年7月現在のバージョンは 0.9.1 で、'''''pre-release''''' と位置づけられています&lt;ref&gt;{{Cite web
|url=https://github.com/ziglang/zig/releases
|title=Releases · ziglang/zig
|website=github.com
|accessdate=2022-07-17
}}&lt;/ref&gt;。このため [[W:Hello world|Hello world]] ですら、バージョン間で互換性がなくなることもあり、リリースバージョンまでは言語仕様やライブラリーおよびツールチェインの仕様が変更される可能性があります。

=== Hello world の変遷 ===
[https://ziglang.org/documentation/master/ Zig Language Reference]の、[[W:Hello world|Hello world]]の変遷（新しい順）。

;master@2022-07-17&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/master/#Hello-World
|title=Zig Documentation(master@2022-07-17)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.8.1に同じ
;0.9.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.9.1/#Hello-World
|title=Zig Documentation(0.9.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.8.1に同じ
;0.8.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.8.1/#Hello-World
|title=Zig Documentation(0.8.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=4&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().writer();
    try stdout.print(&quot;Hello, {s}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: &lt;code&gt;{}&lt;/code&gt; ⇒ &lt;code&gt;{s}&lt;/code&gt;&lt;ref&gt;{{Cite web
|url=https://ziglang.org/download/0.8.0/release-notes.html#Formatted-Printing
|title=0.8.0 Release Notes
|website=ziglang.org
|accessdate=2022-07-17
|quote=Disable the special casing of {} for u8 slices/arrays. Unless {s} is specified the contents won't be treated as a string.
}}&lt;/ref&gt;
;0.7.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.7.1/#Hello-World
|title=Zig Documentation(0.7.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=3&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().writer();
    try stdout.print(&quot;Hello, {}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: s/outStream/writer/
;0.6.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.6.0/#Hello-World
|title=Zig Documentation(0.6.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=3&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().outStream();
    try stdout.print(&quot;Hello, {}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: 初期化の初期値から &lt;code&gt;try&lt;/code&gt; がなくなった。
;0.4.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.4.0/#Hello-World
|title=Zig Documentation(0.4.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.2.0に同じ
;0.5.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.5.0/#Hello-World
|title=Zig Documentation(0.5.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=4&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    // If this program is run without stdout attached, exit with an error.
    const stdout_file = try std.io.getStdOut();
    // If this program encounters pipe failure when printing to stdout, exit
    // with an error.
    try stdout_file.write(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;
: &lt;var&gt;stdout_file&lt;/var&gt; が &lt;code&gt;var&lt;/code&gt; から &lt;code&gt;const&lt;/code&gt; に変更された。

;0.3.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.3.0/#Hello-World
|title=Zig Documentation(0.3.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.2.0に同じ
;0.2.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.2.0/#Hello-World
|title=Zig Documentation(0.2.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    // If this program is run without stdout attached, exit with an error.
    var stdout_file = try std.io.getStdOut();
    // If this program encounters pipe failure when printing to stdout, exit
    // with an error.
    try stdout_file.write(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;
;0.1.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.1.1/#hello-world
|title=Zig Documentation
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig&gt;
const io = @import(&quot;std&quot;).io;
pub fn main() -&gt; %void {
    %%io.stdout.printf(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;

== 環境準備 ==
=== Linuxの場合 ===
==== インストール方法 ====
Fedora 36 の場合、2022年の時点で、コマンド
 sudo dnf install zig
だけでインストールできる事を確認。

インストールできたと思ったら、バージョン確認コマンドなどで、インストールの成否を確認しよう。コマンド
 zig version
で確認できる。

なお、2022年7月現在、まだバージョンは1未満であり、同7月に実験したところ
 0.9.1
であった。上記のセクションでも掛かれているように2022年の段階ではまだプレリリースであるので、1未満でもインストール成功なので安心していい。

==== コードの実行方法 ====
===== 直接コンパイルする場合 =====
インストールにつづけてプロジェクト関連のフォルダ一式を用意する別コマンドもあるが、プロジェクトを作成しなくても gcc などと同様の方法でコマンド一発でコンパイルを作成することも可能。

たとえば、ファイル名「hello.zig」のソースコードをコンパイルしたいなら、コマンド
 zig build-exe hello.zig
である。

これを実行するには、
 ./hello
である。

===== インタプリタ的に実行する場合 =====
コンパイル済みファイルの作成を飛ばして、インタプリタ的に直接に実行する方法もあり、たとえばファイル名「hello.zig」なら下記のようなコマンドある。
 zig run hello.zig


===== プロジェクト作成する場合 =====
まず、プロジェクト関連のコマンドを実行すると、自動で数個のフォルダが作成されるので、それをまとめるためのフォルダを別に作っておき（たとえば proj とする）、べつにマウス右クリックでも mldir コマンドでもなんでもいいので proj ディレクトリを作成しておく。

そして、さらにカレント・ディレクトリを proj に移動するために、ターミナルでコマンド
 cd proj
で、そこに移動する。（そうしないと、今後の動作でホームフォルダにいくつものフォルダやファイルが作成され、管理しづらくなる）

その上で、プロジェクト作成のために
 zig init-exe
を行う。このコマンドにより、初期設定ファイルなどがいくつか自動的に作成される。


== 基礎篇 ==
[TODO:書くべき項目を並べてみましたが、例えば「値と型」を網羅的に書いていくと文章量が爆発するのが目に見えているので、過剰になったらリファレンス篇に移動するなどの方法で、各節はコンパクトさを心がけたいです。]

=== コメント ===
Zigでは、&lt;code&gt;//&lt;/code&gt; から行末までがコメントです。
C言語の &lt;code&gt;/* … */&lt;/code&gt; のスタイルの複数行に渡るコメントは'''ありません'''。
これは、コードの各行を文脈に関係なくトークン化できるようにするためです。
:&lt;syntaxhighlight lang=zig&gt;
// @import は組込み関数です。
const std = @import(&quot;std&quot;); // 先頭に @ が付く関数は組込み関数です
pub fn main() !void {
   try std.io.getStdOut().writeAll(&quot;Hello, World!\n&quot;);
}
&lt;/syntaxhighlight&gt;

==== Docコメント ====
Zigでは、&lt;code&gt;///&lt;/code&gt; から始まるコメントは特別なコメントで、Docコメント( ''Doc comments'' )と呼ばれます。
Docコメントは特定の場所にしか許されません。式の途中や非Docコメントの直前など、予想外の場所にdocコメントがあると、コンパイルエラーになります。

[TODO:サンプルコードと整形結果]

==== トップレベルDocコメント ====
Zigでは、&lt;code&gt;//!&lt;/code&gt; から始まるコメントは特別なコメントで、トップレベルDocコメント( ''Top-Level Doc Comments '' )と呼ばれます。
コンテナレベルのドキュメントのように、直後のドキュメントに属さないユーザードキュメントに、トップレベルDocコメントを使います。

[TODO:サンプルコードと整形結果]

DocコメントおよびトップレベルDocコメントは、コンパイル時に zig build-exe -femit-docs ソースファイル.zig の様に、-femit-docs をあたえると、 docs/ 以下にドキュメントが生成されます。

=== 値と型 ===
[TOD0:整数・浮動小数・論理値・文字列・共用体・構造体・列挙・配列・ベクトル・スライス・ポインター・ゼロビットな型]

:&lt;syntaxhighlight lang=zig&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot; (1) = {}\n&quot;, .{42});
    try print(&quot; (2) = {}\n&quot;, .{0x17});
    try print(&quot; (3) = {}\n&quot;, .{0o17});
    try print(&quot; (4) = {}\n&quot;, .{0b0100101});
    try print(&quot; (5) = {}\n&quot;, .{1e222});
    try print(&quot; (6) = {}\n&quot;, .{3.1415926536});
    try print(&quot; (7) = {}\n&quot;, .{'c'});
    try print(&quot; (8) = {c}\n&quot;, .{'c'});
    try print(&quot; (9) = {s}\n&quot;, .{&quot;abcdef&quot;});
    try print(&quot;(10) = {}, {}\n&quot;, .{ 111, 999 });
    try print(&quot;(11) = {1}, {0}\n&quot;, .{ 111, 999 });
    try print(&quot;(12) = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; });
    try print(&quot;(13) = {0d}, {0b}, {0o}, {0x}, {0X}\n&quot;, .{ 123 });
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
 (1) = 42
 (2) = 23
 (3) = 15
 (4) = 37
 (5) = 1.0e+222
 (6) = 3.1415926536e+00
 (7) = 99
 (8) = c
 (9) = abcdef
(10) = 111, 999
(11) = 999, 111
(12) = abc, 111
(13) = 123, 1111011, 173, 7b, 7B
&lt;/syntaxhighlight&gt;
&lt;!-- リテラルの例、というか、@import(&quot;std&quot;).io.getStdOut().writer().print の例になっていますね。--&gt;
ご覧のように、数値（整数と浮動小数点数）や文字・文字列のリテラルがあり、整数は基数を、浮動小数点数は指数表現と少数表現があります。

@import(&quot;std&quot;).io.getStdOut().writer().printの、第一引数は書式化文字列、第二引数は値リストです。
書式化文字列は、通常の文字列ですが &lt;code&gt;{&lt;/code&gt; と &lt;code&gt;}&lt;/code&gt; で囲まれたプレスホルダーが、引数リストの値（を書式化した文字列）に置換わります。
一番素朴なプレスホルダーは {} で、引数の値の一般的な文字列表記に置換ります（整数なら十進数表記、浮動小数点数なら指数表記）。
ところが、’c’ のような文字型を {} に適用すると文字コード化され整数と同じ十進数表記になってしまいます。そこで、文字型の場合は {c} と文字であることを明記すると文字表現となります。
また、文字列の間合いは {s} を明記しないと（バージョン0.8.0からは）エラーになります。
2つ以上の値を渡す場合は、第二引数を　.{ 1, 2, 3 } の様にカンマ区切りのリストにします（ {} の前の . （点）を忘れがち）。
基本的に、左から順にプレスホルダーにリストの値が左から与えられますが、{0} {1} の書式で参照する引数の順位を明示できます。
書式指定と併用する時は、 &lt;code&gt; print(&quot;? = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; })&lt;/code&gt; の様に順位が先、書式指定文字が後になります。

[TODO:[https://github.com/ziglang/zig/blob/master/lib/std/fmt.zig master/lib/std/fmt.zig]を観て書いています。参照すべき標準ライブラリのドキュメントを発見出来たら、見直し]
[TODO:表組み]

==== comptime ====
Zigでは、コンパイル時に式が既知かどうかという概念を重要視しています。

&lt;!--
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const i = 0;
    const string = [_]i32{ 1, 2, 3, 4 };
    for (string) |character, index| {
        std.debug.print(&quot;character: {}, index: {}, :{s} \n&quot;, .{ character, index, @typeName(@TypeOf(character)) });
    }
    _ = i;
}
--&gt;

=== テスト ===
=== 変数 ===
=== 制御構造 ===
[TODO:Zig の制御構造は文ではなく式]
==== 分岐 ====
[TODO:ifとswitch]
==== 反復 ====
[TODO:whileとfor]
=== 関数 ===
=== エラー ===
=== 演算子 ===
==== 優先順位 ====
高
&lt;syntaxhighlight lang=text line&gt;
 x() x[] x.y x.* x.?
 a!b
 x{}
 !x -x -%x ~x &amp;x ?x
 * / % ** *% *| ||
 + - ++ +% -% +| -|
 &lt;&lt; &gt;&gt; &lt;&lt;|
 &amp; ^ | orelse catch
 == != &lt; &gt; &lt;= &gt;=
 and
 or
 = *= *%= *|= /= %= += +%= +|= -= -%= -|= &lt;&lt;= &lt;&lt;|= &gt;&gt;= &amp;= ^= |=
&lt;/syntaxhighlight&gt;
低

===  optional type ===
===  opaque ===
訳語未定
=== ブロック ===
[TODO:スコープとシャドーイング；deferはここ？]
=== キャスト ===
[TODO:Zig は強い型付け()； 型強制 (Type coercion) について]
=== アセンブリ言語との連携 ===
[TODO:所謂インラインアセンラ]
=== atomic ===
=== 非同期関数 ===
=== 組込み関数 ===
[TODO:組込み関数は、@で始まり、@TypeOfや@alignOfの他@sinや@memcpyも組込み関数]
=== メモリ管理 ===
=== キーワード一覧 ===
&lt;code&gt;align&lt;/code&gt;
&lt;code&gt;allowzero&lt;/code&gt;
&lt;code&gt;and&lt;/code&gt;
&lt;code&gt;anyframe&lt;/code&gt;
&lt;code&gt;anytype&lt;/code&gt;
&lt;code&gt;asm&lt;/code&gt;
&lt;code&gt;async&lt;/code&gt;
&lt;code&gt;await&lt;/code&gt;
&lt;code&gt;break&lt;/code&gt;
&lt;code&gt;catch&lt;/code&gt;
&lt;code&gt;comptime&lt;/code&gt;
&lt;code&gt;const&lt;/code&gt;
&lt;code&gt;continue&lt;/code&gt;
&lt;code&gt;defer&lt;/code&gt;
&lt;code&gt;else&lt;/code&gt;
&lt;code&gt;enum&lt;/code&gt;
&lt;code&gt;errdefer&lt;/code&gt;
&lt;code&gt;error&lt;/code&gt;
&lt;code&gt;export&lt;/code&gt;
&lt;code&gt;extern&lt;/code&gt;
&lt;code&gt;fn&lt;/code&gt;
&lt;code&gt;for&lt;/code&gt;
&lt;code&gt;if&lt;/code&gt;
&lt;code&gt;inline&lt;/code&gt;
&lt;code&gt;noalias&lt;/code&gt;
&lt;code&gt;nosuspend&lt;/code&gt;
&lt;code&gt;or&lt;/code&gt;
&lt;code&gt;orelse&lt;/code&gt;
&lt;code&gt;packed&lt;/code&gt;
&lt;code&gt;pub&lt;/code&gt;
&lt;code&gt;resume&lt;/code&gt;
&lt;code&gt;return&lt;/code&gt;
&lt;code&gt;linksection&lt;/code&gt;
&lt;code&gt;struct&lt;/code&gt;
&lt;code&gt;suspend&lt;/code&gt;
&lt;code&gt;switch&lt;/code&gt;
&lt;code&gt;test&lt;/code&gt;
&lt;code&gt;threadlocal&lt;/code&gt;
&lt;code&gt;try&lt;/code&gt;
&lt;code&gt;union&lt;/code&gt;
&lt;code&gt;unreachable&lt;/code&gt;
&lt;code&gt;usingnamespace&lt;/code&gt;
&lt;code&gt;var&lt;/code&gt;
&lt;code&gt;volatile&lt;/code&gt;
&lt;code&gt;while&lt;/code&gt;

== チートシート ==
[TODO:文法と型と頻用する標準ライブラリの関数と型のアンチョコ]

== リファレンス篇 ==

== 脚註 ==
&lt;references /&gt;

== 外部リンク ==
* [https://ziglang.org/ Home ⚡ Zig Programming Language] {{---}} 公式サイト
** [[https://ziglang.org/documentation/master/ Zig Language Reference]] {{---}} リファレンスマニュアル
* [https://github.com/ziglang/zig ziglang/zig: General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.] {{---}} 公式リポジトリ
* [https://zig-play.dev/ Zig Playground] {{---}} オンライン実行環境
** [https://github.com/gsquire/zig-play About An online Zig compiler inspired by Go and Rust] {{---}} リポジトリ

[[Category:zig|*]]
[[Category:プログラミング言語]]</text>
      <sha1>oi57bcqditjz3utg6c6rt7r1a9qpjlj</sha1>
    </revision>
    <revision>
      <id>205756</id>
      <parentid>205754</parentid>
      <timestamp>2022-07-24T05:56:06Z</timestamp>
      <contributor>
        <username>Ef3</username>
        <id>694</id>
      </contributor>
      <comment>/* comptime */  Zigでは、コンパイル時に式が既知かどうかという概念を重要視しています。</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="20840" xml:space="preserve">{{Pathnav|メインページ|工学|情報技術|プログラミング|frame=1}}
{{Wikipedia|Zig (プログラミング言語)}}
本書は、[[w:Zig|Zig]]のチュートリアルです。
Zigは、堅牢で最適かつ再利用可能なソフトウェアを維持するための汎用プログラミング言語およびツールチェインです&lt;ref&gt;{{Cite web
|url=https://ziglang.org/
|title=Home ⚡ Zig Programming Language
|website=ziglang.org
|accessdate=2022-07-17
|cite=Zig is a general-purpose programming language and toolchain for maintaining '''robust''', '''optimal''' and '''reusable''' software.
}}&lt;/ref&gt;。
Zigは、アンドリュー・ケリー( ''[https://andrewkelley.me/ Andrew Kelley]'' )によって設計され、汎用システムプログラミング言語で、静的で強い型付けで型推論とジェネリックプログラミングをサポートします。

== 概要 ==
Zigは、2016年2月に発表された比較的若いプログラミング言語で&lt;ref&gt;{{Cite web
|last1=Kelley
|first1=Andrew
|title=Introduction to the Zig Programming Language
|url=https://andrewkelley.me/post/intro-to-zig.html
|website=andrewkelley.me
|accessdate=2022-07-17
}}&lt;/ref&gt;、2022年7月現在のバージョンは 0.9.1 で、'''''pre-release''''' と位置づけられています&lt;ref&gt;{{Cite web
|url=https://github.com/ziglang/zig/releases
|title=Releases · ziglang/zig
|website=github.com
|accessdate=2022-07-17
}}&lt;/ref&gt;。このため [[W:Hello world|Hello world]] ですら、バージョン間で互換性がなくなることもあり、リリースバージョンまでは言語仕様やライブラリーおよびツールチェインの仕様が変更される可能性があります。

=== Hello world の変遷 ===
[https://ziglang.org/documentation/master/ Zig Language Reference]の、[[W:Hello world|Hello world]]の変遷（新しい順）。

;master@2022-07-17&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/master/#Hello-World
|title=Zig Documentation(master@2022-07-17)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.8.1に同じ
;0.9.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.9.1/#Hello-World
|title=Zig Documentation(0.9.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.8.1に同じ
;0.8.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.8.1/#Hello-World
|title=Zig Documentation(0.8.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=4&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().writer();
    try stdout.print(&quot;Hello, {s}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: &lt;code&gt;{}&lt;/code&gt; ⇒ &lt;code&gt;{s}&lt;/code&gt;&lt;ref&gt;{{Cite web
|url=https://ziglang.org/download/0.8.0/release-notes.html#Formatted-Printing
|title=0.8.0 Release Notes
|website=ziglang.org
|accessdate=2022-07-17
|quote=Disable the special casing of {} for u8 slices/arrays. Unless {s} is specified the contents won't be treated as a string.
}}&lt;/ref&gt;
;0.7.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.7.1/#Hello-World
|title=Zig Documentation(0.7.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=3&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().writer();
    try stdout.print(&quot;Hello, {}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: s/outStream/writer/
;0.6.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.6.0/#Hello-World
|title=Zig Documentation(0.6.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=3&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().outStream();
    try stdout.print(&quot;Hello, {}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: 初期化の初期値から &lt;code&gt;try&lt;/code&gt; がなくなった。
;0.4.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.4.0/#Hello-World
|title=Zig Documentation(0.4.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.2.0に同じ
;0.5.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.5.0/#Hello-World
|title=Zig Documentation(0.5.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=4&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    // If this program is run without stdout attached, exit with an error.
    const stdout_file = try std.io.getStdOut();
    // If this program encounters pipe failure when printing to stdout, exit
    // with an error.
    try stdout_file.write(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;
: &lt;var&gt;stdout_file&lt;/var&gt; が &lt;code&gt;var&lt;/code&gt; から &lt;code&gt;const&lt;/code&gt; に変更された。

;0.3.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.3.0/#Hello-World
|title=Zig Documentation(0.3.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.2.0に同じ
;0.2.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.2.0/#Hello-World
|title=Zig Documentation(0.2.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    // If this program is run without stdout attached, exit with an error.
    var stdout_file = try std.io.getStdOut();
    // If this program encounters pipe failure when printing to stdout, exit
    // with an error.
    try stdout_file.write(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;
;0.1.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.1.1/#hello-world
|title=Zig Documentation
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig&gt;
const io = @import(&quot;std&quot;).io;
pub fn main() -&gt; %void {
    %%io.stdout.printf(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;

== 環境準備 ==
=== Linuxの場合 ===
==== インストール方法 ====
Fedora 36 の場合、2022年の時点で、コマンド
 sudo dnf install zig
だけでインストールできる事を確認。

インストールできたと思ったら、バージョン確認コマンドなどで、インストールの成否を確認しよう。コマンド
 zig version
で確認できる。

なお、2022年7月現在、まだバージョンは1未満であり、同7月に実験したところ
 0.9.1
であった。上記のセクションでも掛かれているように2022年の段階ではまだプレリリースであるので、1未満でもインストール成功なので安心していい。

==== コードの実行方法 ====
=== 値と型 ===
[TOD0:整数・浮動小数・論理値・文字列・共用体・構造体・列挙・配列・ベクトル・スライス・ポインター・ゼロビットな型]

:&lt;syntaxhighlight lang=zig&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot; (1) = {}\n&quot;, .{42});
    try print(&quot; (2) = {}\n&quot;, .{0x17});
    try print(&quot; (3) = {}\n&quot;, .{0o17});
    try print(&quot; (4) = {}\n&quot;, .{0b0100101});
    try print(&quot; (5) = {}\n&quot;, .{1e222});
    try print(&quot; (6) = {}\n&quot;, .{3.1415926536});
    try print(&quot; (7) = {}\n&quot;, .{'c'});
    try print(&quot; (8) = {c}\n&quot;, .{'c'});
    try print(&quot; (9) = {s}\n&quot;, .{&quot;abcdef&quot;});
    try print(&quot;(10) = {}, {}\n&quot;, .{ 111, 999 });
    try print(&quot;(11) = {1}, {0}\n&quot;, .{ 111, 999 });
    try print(&quot;(12) = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; });
    try print(&quot;(13) = {0d}, {0b}, {0o}, {0x}, {0X}\n&quot;, .{ 123 });
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
 (1) = 42
 (2) = 23
 (3) = 15
 (4) = 37
 (5) = 1.0e+222
 (6) = 3.1415926536e+00
 (7) = 99
 (8) = c
 (9) = abcdef
(10) = 111, 999
(11) = 999, 111
(12) = abc, 111
(13) = 123, 1111011, 173, 7b, 7B
&lt;/syntaxhighlight&gt;
&lt;!-- リテラルの例、というか、@import(&quot;std&quot;).io.getStdOut().writer().print の例になっていますね。--&gt;
ご覧のように、数値（整数と浮動小数点数）や文字・文字列のリテラルがあり、整数は基数を、浮動小数点数は指数表現と少数表現があります。

@import(&quot;std&quot;).io.getStdOut().writer().printの、第一引数は書式化文字列、第二引数は値リストです。
書式化文字列は、通常の文字列ですが &lt;code&gt;{&lt;/code&gt; と &lt;code&gt;}&lt;/code&gt; で囲まれたプレスホルダーが、引数リストの値（を書式化した文字列）に置換わります。
一番素朴なプレスホルダーは {} で、引数の値の一般的な文字列表記に置換ります（整数なら十進数表記、浮動小数点数なら指数表記）。
ところが、’c’ のような文字型を {} に適用すると文字コード化され整数と同じ十進数表記になってしまいます。そこで、文字型の場合は {c} と文字であることを明記すると文字表現となります。
また、文字列の間合いは {s} を明記しないと（バージョン0.8.0からは）エラーになります。
2つ以上の値を渡す場合は、第二引数を　.{ 1, 2, 3 } の様にカンマ区切りのリストにします（ {} の前の . （点）を忘れがち）。
基本的に、左から順にプレスホルダーにリストの値が左から与えられますが、{0} {1} の書式で参照する引数の順位を明示できます。
書式指定と併用する時は、 &lt;code&gt; print(&quot;? = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; })&lt;/code&gt; の様に順位が先、書式指定文字が後になります。

[TODO:[https://github.com/ziglang/zig/blob/master/lib/std/fmt.zig master/lib/std/fmt.zig]を観て書いています。参照すべき標準ライブラリのドキュメントを発見出来たら、見直し]
[TODO:表組み]

==== comptime ====
Zigでは、コンパイル時に式が既知かどうかという概念を重要視しています。

次のコードを観てみましょう。
:&lt;syntaxhighlight lang=zig line highlight=7&gt;
fn mul(x: usize, y: usize) usize {
    return x * y;
}

pub fn main() void {
    const len : usize = mul(3, 4);
    const ary: [len]i32 = undefined;
    _ = ary;
}
&lt;/syntaxhighlight&gt;
;コンパイル結果:&lt;syntaxhighlight lang=text&gt;
An error occurred: 
/tmp/playground130713503/play.zig:7:17: error: unable to evaluate constant expression 
    const ary: [len]i32 = undefined;
&lt;/syntaxhighlight&gt;
: 「定数式が評価できない 」と宣っています。
: [[C++]]であれば、constexprが適用なケースですが、Zigでは次のような解決方法を取ります。

:&lt;syntaxhighlight lang=zig line highlight=6&gt;
fn mul(x: usize, y: usize) usize {
    return x * y;
}

pub fn main() void {
    const len : usize = comptime mul(3, 4);
    const ary: [len]i32 = undefined;
    _ = ary;
}
&lt;/syntaxhighlight&gt;
: mul() の呼出しを comptime で修飾しました。comptime は、修飾子式を'''コンパイル時に実行する'''修飾子で、式の中でコンパイル時に未定な値が参照されると、エラーとなります。ここでは、数リテラル同士の商を求めているので、コンパイル時値が確定できます。
: _ = ary は、「定義済だが参照のない変数宣言」をサプレッスするときのイディオムです。

&lt;!--
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const i = 0;
    const string = [_]i32{ 1, 2, 3, 4 };
    for (string) |character, index| {
        std.debug.print(&quot;character: {}, index: {}, :{s} \n&quot;, .{ character, index, @typeName(@TypeOf(character)) });
    }
    _ = i;
}
--&gt;

===== インタプリタ的に実行する場合 =====
コンパイル済みファイルの作成を飛ばして、インタプリタ的に直接に実行する方法もあり、たとえばファイル名「hello.zig」なら下記のようなコマンドある。
 zig run hello.zig


===== プロジェクト作成する場合 =====
まず、プロジェクト関連のコマンドを実行すると、自動で数個のフォルダが作成されるので、それをまとめるためのフォルダを別に作っておき（たとえば proj とする）、べつにマウス右クリックでも mldir コマンドでもなんでもいいので proj ディレクトリを作成しておく。

そして、さらにカレント・ディレクトリを proj に移動するために、ターミナルでコマンド
 cd proj
で、そこに移動する。（そうしないと、今後の動作でホームフォルダにいくつものフォルダやファイルが作成され、管理しづらくなる）

その上で、プロジェクト作成のために
 zig init-exe
を行う。このコマンドにより、初期設定ファイルなどがいくつか自動的に作成される。


== 基礎篇 ==
[TODO:書くべき項目を並べてみましたが、例えば「値と型」を網羅的に書いていくと文章量が爆発するのが目に見えているので、過剰になったらリファレンス篇に移動するなどの方法で、各節はコンパクトさを心がけたいです。]

=== コメント ===
Zigでは、&lt;code&gt;//&lt;/code&gt; から行末までがコメントです。
C言語の &lt;code&gt;/* … */&lt;/code&gt; のスタイルの複数行に渡るコメントは'''ありません'''。
これは、コードの各行を文脈に関係なくトークン化できるようにするためです。
:&lt;syntaxhighlight lang=zig&gt;
// @import は組込み関数です。
const std = @import(&quot;std&quot;); // 先頭に @ が付く関数は組込み関数です
pub fn main() !void {
   try std.io.getStdOut().writeAll(&quot;Hello, World!\n&quot;);
}
&lt;/syntaxhighlight&gt;

==== Docコメント ====
Zigでは、&lt;code&gt;///&lt;/code&gt; から始まるコメントは特別なコメントで、Docコメント( ''Doc comments'' )と呼ばれます。
Docコメントは特定の場所にしか許されません。式の途中や非Docコメントの直前など、予想外の場所にdocコメントがあると、コンパイルエラーになります。

[TODO:サンプルコードと整形結果]

==== トップレベルDocコメント ====
Zigでは、&lt;code&gt;//!&lt;/code&gt; から始まるコメントは特別なコメントで、トップレベルDocコメント( ''Top-Level Doc Comments '' )と呼ばれます。
コンテナレベルのドキュメントのように、直後のドキュメントに属さないユーザードキュメントに、トップレベルDocコメントを使います。

[TODO:サンプルコードと整形結果]

DocコメントおよびトップレベルDocコメントは、コンパイル時に zig build-exe -femit-docs ソースファイル.zig の様に、-femit-docs をあたえると、 docs/ 以下にドキュメントが生成されます。

=== 値と型 ===
[TOD0:整数・浮動小数・論理値・文字列・共用体・構造体・列挙・配列・ベクトル・スライス・ポインター・ゼロビットな型]

:&lt;syntaxhighlight lang=zig&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot; (1) = {}\n&quot;, .{42});
    try print(&quot; (2) = {}\n&quot;, .{0x17});
    try print(&quot; (3) = {}\n&quot;, .{0o17});
    try print(&quot; (4) = {}\n&quot;, .{0b0100101});
    try print(&quot; (5) = {}\n&quot;, .{1e222});
    try print(&quot; (6) = {}\n&quot;, .{3.1415926536});
    try print(&quot; (7) = {}\n&quot;, .{'c'});
    try print(&quot; (8) = {c}\n&quot;, .{'c'});
    try print(&quot; (9) = {s}\n&quot;, .{&quot;abcdef&quot;});
    try print(&quot;(10) = {}, {}\n&quot;, .{ 111, 999 });
    try print(&quot;(11) = {1}, {0}\n&quot;, .{ 111, 999 });
    try print(&quot;(12) = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; });
    try print(&quot;(13) = {0d}, {0b}, {0o}, {0x}, {0X}\n&quot;, .{ 123 });
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
 (1) = 42
 (2) = 23
 (3) = 15
 (4) = 37
 (5) = 1.0e+222
 (6) = 3.1415926536e+00
 (7) = 99
 (8) = c
 (9) = abcdef
(10) = 111, 999
(11) = 999, 111
(12) = abc, 111
(13) = 123, 1111011, 173, 7b, 7B
&lt;/syntaxhighlight&gt;
&lt;!-- リテラルの例、というか、@import(&quot;std&quot;).io.getStdOut().writer().print の例になっていますね。--&gt;
ご覧のように、数値（整数と浮動小数点数）や文字・文字列のリテラルがあり、整数は基数を、浮動小数点数は指数表現と少数表現があります。

@import(&quot;std&quot;).io.getStdOut().writer().printの、第一引数は書式化文字列、第二引数は値リストです。
書式化文字列は、通常の文字列ですが &lt;code&gt;{&lt;/code&gt; と &lt;code&gt;}&lt;/code&gt; で囲まれたプレスホルダーが、引数リストの値（を書式化した文字列）に置換わります。
一番素朴なプレスホルダーは {} で、引数の値の一般的な文字列表記に置換ります（整数なら十進数表記、浮動小数点数なら指数表記）。
ところが、’c’ のような文字型を {} に適用すると文字コード化され整数と同じ十進数表記になってしまいます。そこで、文字型の場合は {c} と文字であることを明記すると文字表現となります。
また、文字列の間合いは {s} を明記しないと（バージョン0.8.0からは）エラーになります。
2つ以上の値を渡す場合は、第二引数を　.{ 1, 2, 3 } の様にカンマ区切りのリストにします（ {} の前の . （点）を忘れがち）。
基本的に、左から順にプレスホルダーにリストの値が左から与えられますが、{0} {1} の書式で参照する引数の順位を明示できます。
書式指定と併用する時は、 &lt;code&gt; print(&quot;? = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; })&lt;/code&gt; の様に順位が先、書式指定文字が後になります。

[TODO:[https://github.com/ziglang/zig/blob/master/lib/std/fmt.zig master/lib/std/fmt.zig]を観て書いています。参照すべき標準ライブラリのドキュメントを発見出来たら、見直し]
[TODO:表組み]

==== comptime ====
Zigでは、コンパイル時に式が既知かどうかという概念を重要視しています。

&lt;!--
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const i = 0;
    const string = [_]i32{ 1, 2, 3, 4 };
    for (string) |character, index| {
        std.debug.print(&quot;character: {}, index: {}, :{s} \n&quot;, .{ character, index, @typeName(@TypeOf(character)) });
    }
    _ = i;
}
--&gt;

=== テスト ===
=== 変数 ===
=== 制御構造 ===
[TODO:Zig の制御構造は文ではなく式]
==== 分岐 ====
[TODO:ifとswitch]
==== 反復 ====
[TODO:whileとfor]
=== 関数 ===
=== エラー ===
=== 演算子 ===
==== 優先順位 ====
高
&lt;syntaxhighlight lang=text line&gt;
 x() x[] x.y x.* x.?
 a!b
 x{}
 !x -x -%x ~x &amp;x ?x
 * / % ** *% *| ||
 + - ++ +% -% +| -|
 &lt;&lt; &gt;&gt; &lt;&lt;|
 &amp; ^ | orelse catch
 == != &lt; &gt; &lt;= &gt;=
 and
 or
 = *= *%= *|= /= %= += +%= +|= -= -%= -|= &lt;&lt;= &lt;&lt;|= &gt;&gt;= &amp;= ^= |=
&lt;/syntaxhighlight&gt;
低

===  optional type ===
===  opaque ===
訳語未定
=== ブロック ===
[TODO:スコープとシャドーイング；deferはここ？]
=== キャスト ===
[TODO:Zig は強い型付け()； 型強制 (Type coercion) について]
=== アセンブリ言語との連携 ===
[TODO:所謂インラインアセンラ]
=== atomic ===
=== 非同期関数 ===
=== 組込み関数 ===
[TODO:組込み関数は、@で始まり、@TypeOfや@alignOfの他@sinや@memcpyも組込み関数]
=== メモリ管理 ===
=== キーワード一覧 ===
&lt;code&gt;align&lt;/code&gt;
&lt;code&gt;allowzero&lt;/code&gt;
&lt;code&gt;and&lt;/code&gt;
&lt;code&gt;anyframe&lt;/code&gt;
&lt;code&gt;anytype&lt;/code&gt;
&lt;code&gt;asm&lt;/code&gt;
&lt;code&gt;async&lt;/code&gt;
&lt;code&gt;await&lt;/code&gt;
&lt;code&gt;break&lt;/code&gt;
&lt;code&gt;catch&lt;/code&gt;
&lt;code&gt;comptime&lt;/code&gt;
&lt;code&gt;const&lt;/code&gt;
&lt;code&gt;continue&lt;/code&gt;
&lt;code&gt;defer&lt;/code&gt;
&lt;code&gt;else&lt;/code&gt;
&lt;code&gt;enum&lt;/code&gt;
&lt;code&gt;errdefer&lt;/code&gt;
&lt;code&gt;error&lt;/code&gt;
&lt;code&gt;export&lt;/code&gt;
&lt;code&gt;extern&lt;/code&gt;
&lt;code&gt;fn&lt;/code&gt;
&lt;code&gt;for&lt;/code&gt;
&lt;code&gt;if&lt;/code&gt;
&lt;code&gt;inline&lt;/code&gt;
&lt;code&gt;noalias&lt;/code&gt;
&lt;code&gt;nosuspend&lt;/code&gt;
&lt;code&gt;or&lt;/code&gt;
&lt;code&gt;orelse&lt;/code&gt;
&lt;code&gt;packed&lt;/code&gt;
&lt;code&gt;pub&lt;/code&gt;
&lt;code&gt;resume&lt;/code&gt;
&lt;code&gt;return&lt;/code&gt;
&lt;code&gt;linksection&lt;/code&gt;
&lt;code&gt;struct&lt;/code&gt;
&lt;code&gt;suspend&lt;/code&gt;
&lt;code&gt;switch&lt;/code&gt;
&lt;code&gt;test&lt;/code&gt;
&lt;code&gt;threadlocal&lt;/code&gt;
&lt;code&gt;try&lt;/code&gt;
&lt;code&gt;union&lt;/code&gt;
&lt;code&gt;unreachable&lt;/code&gt;
&lt;code&gt;usingnamespace&lt;/code&gt;
&lt;code&gt;var&lt;/code&gt;
&lt;code&gt;volatile&lt;/code&gt;
&lt;code&gt;while&lt;/code&gt;

== チートシート ==
[TODO:文法と型と頻用する標準ライブラリの関数と型のアンチョコ]

== リファレンス篇 ==

== 脚註 ==
&lt;references /&gt;

== 外部リンク ==
* [https://ziglang.org/ Home ⚡ Zig Programming Language] {{---}} 公式サイト
** [[https://ziglang.org/documentation/master/ Zig Language Reference]] {{---}} リファレンスマニュアル
* [https://github.com/ziglang/zig ziglang/zig: General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.] {{---}} 公式リポジトリ
* [https://zig-play.dev/ Zig Playground] {{---}} オンライン実行環境
** [https://github.com/gsquire/zig-play About An online Zig compiler inspired by Go and Rust] {{---}} リポジトリ

[[Category:zig|*]]
[[Category:プログラミング言語]]</text>
      <sha1>3lokm1h2jksqdb3ftdt84ml1jbozfwg</sha1>
    </revision>
    <revision>
      <id>205758</id>
      <parentid>205756</parentid>
      <timestamp>2022-07-24T06:12:52Z</timestamp>
      <contributor>
        <username>すじにくシチュー</username>
        <id>12058</id>
      </contributor>
      <comment>/* 環境準備 */ Git Hub へのリンク。その他のOS環境でのインストールについては、GitHub &quot;ziglang /zig&quot; を参照せよ。</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="21019" xml:space="preserve">{{Pathnav|メインページ|工学|情報技術|プログラミング|frame=1}}
{{Wikipedia|Zig (プログラミング言語)}}
本書は、[[w:Zig|Zig]]のチュートリアルです。
Zigは、堅牢で最適かつ再利用可能なソフトウェアを維持するための汎用プログラミング言語およびツールチェインです&lt;ref&gt;{{Cite web
|url=https://ziglang.org/
|title=Home ⚡ Zig Programming Language
|website=ziglang.org
|accessdate=2022-07-17
|cite=Zig is a general-purpose programming language and toolchain for maintaining '''robust''', '''optimal''' and '''reusable''' software.
}}&lt;/ref&gt;。
Zigは、アンドリュー・ケリー( ''[https://andrewkelley.me/ Andrew Kelley]'' )によって設計され、汎用システムプログラミング言語で、静的で強い型付けで型推論とジェネリックプログラミングをサポートします。

== 概要 ==
Zigは、2016年2月に発表された比較的若いプログラミング言語で&lt;ref&gt;{{Cite web
|last1=Kelley
|first1=Andrew
|title=Introduction to the Zig Programming Language
|url=https://andrewkelley.me/post/intro-to-zig.html
|website=andrewkelley.me
|accessdate=2022-07-17
}}&lt;/ref&gt;、2022年7月現在のバージョンは 0.9.1 で、'''''pre-release''''' と位置づけられています&lt;ref&gt;{{Cite web
|url=https://github.com/ziglang/zig/releases
|title=Releases · ziglang/zig
|website=github.com
|accessdate=2022-07-17
}}&lt;/ref&gt;。このため [[W:Hello world|Hello world]] ですら、バージョン間で互換性がなくなることもあり、リリースバージョンまでは言語仕様やライブラリーおよびツールチェインの仕様が変更される可能性があります。

=== Hello world の変遷 ===
[https://ziglang.org/documentation/master/ Zig Language Reference]の、[[W:Hello world|Hello world]]の変遷（新しい順）。

;master@2022-07-17&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/master/#Hello-World
|title=Zig Documentation(master@2022-07-17)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.8.1に同じ
;0.9.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.9.1/#Hello-World
|title=Zig Documentation(0.9.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.8.1に同じ
;0.8.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.8.1/#Hello-World
|title=Zig Documentation(0.8.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=4&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().writer();
    try stdout.print(&quot;Hello, {s}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: &lt;code&gt;{}&lt;/code&gt; ⇒ &lt;code&gt;{s}&lt;/code&gt;&lt;ref&gt;{{Cite web
|url=https://ziglang.org/download/0.8.0/release-notes.html#Formatted-Printing
|title=0.8.0 Release Notes
|website=ziglang.org
|accessdate=2022-07-17
|quote=Disable the special casing of {} for u8 slices/arrays. Unless {s} is specified the contents won't be treated as a string.
}}&lt;/ref&gt;
;0.7.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.7.1/#Hello-World
|title=Zig Documentation(0.7.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=3&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().writer();
    try stdout.print(&quot;Hello, {}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: s/outStream/writer/
;0.6.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.6.0/#Hello-World
|title=Zig Documentation(0.6.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=3&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().outStream();
    try stdout.print(&quot;Hello, {}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: 初期化の初期値から &lt;code&gt;try&lt;/code&gt; がなくなった。
;0.4.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.4.0/#Hello-World
|title=Zig Documentation(0.4.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.2.0に同じ
;0.5.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.5.0/#Hello-World
|title=Zig Documentation(0.5.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=4&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    // If this program is run without stdout attached, exit with an error.
    const stdout_file = try std.io.getStdOut();
    // If this program encounters pipe failure when printing to stdout, exit
    // with an error.
    try stdout_file.write(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;
: &lt;var&gt;stdout_file&lt;/var&gt; が &lt;code&gt;var&lt;/code&gt; から &lt;code&gt;const&lt;/code&gt; に変更された。

;0.3.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.3.0/#Hello-World
|title=Zig Documentation(0.3.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.2.0に同じ
;0.2.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.2.0/#Hello-World
|title=Zig Documentation(0.2.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    // If this program is run without stdout attached, exit with an error.
    var stdout_file = try std.io.getStdOut();
    // If this program encounters pipe failure when printing to stdout, exit
    // with an error.
    try stdout_file.write(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;
;0.1.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.1.1/#hello-world
|title=Zig Documentation
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig&gt;
const io = @import(&quot;std&quot;).io;
pub fn main() -&gt; %void {
    %%io.stdout.printf(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;

== 環境準備 ==
=== Linuxの場合 ===
==== インストール方法 ====
Fedora 36 の場合、2022年の時点で、コマンド
 sudo dnf install zig
だけでインストールできる事を確認。

その他のOS環境でのインストールについては、[https://github.com/ziglang/zig/wiki/Install-Zig-from-a-Package-Manager  GitHub  &quot;ziglang /zig&quot; ] を参照せよ。

インストールできたと思ったら、バージョン確認コマンドなどで、インストールの成否を確認しよう。コマンド
 zig version
で確認できる。

なお、2022年7月現在、まだバージョンは1未満であり、同7月に実験したところ
 0.9.1
であった。上記のセクションでも掛かれているように2022年の段階ではまだプレリリースであるので、1未満でもインストール成功なので安心していい。

==== コードの実行方法 ====
=== 値と型 ===
[TOD0:整数・浮動小数・論理値・文字列・共用体・構造体・列挙・配列・ベクトル・スライス・ポインター・ゼロビットな型]

:&lt;syntaxhighlight lang=zig&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot; (1) = {}\n&quot;, .{42});
    try print(&quot; (2) = {}\n&quot;, .{0x17});
    try print(&quot; (3) = {}\n&quot;, .{0o17});
    try print(&quot; (4) = {}\n&quot;, .{0b0100101});
    try print(&quot; (5) = {}\n&quot;, .{1e222});
    try print(&quot; (6) = {}\n&quot;, .{3.1415926536});
    try print(&quot; (7) = {}\n&quot;, .{'c'});
    try print(&quot; (8) = {c}\n&quot;, .{'c'});
    try print(&quot; (9) = {s}\n&quot;, .{&quot;abcdef&quot;});
    try print(&quot;(10) = {}, {}\n&quot;, .{ 111, 999 });
    try print(&quot;(11) = {1}, {0}\n&quot;, .{ 111, 999 });
    try print(&quot;(12) = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; });
    try print(&quot;(13) = {0d}, {0b}, {0o}, {0x}, {0X}\n&quot;, .{ 123 });
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
 (1) = 42
 (2) = 23
 (3) = 15
 (4) = 37
 (5) = 1.0e+222
 (6) = 3.1415926536e+00
 (7) = 99
 (8) = c
 (9) = abcdef
(10) = 111, 999
(11) = 999, 111
(12) = abc, 111
(13) = 123, 1111011, 173, 7b, 7B
&lt;/syntaxhighlight&gt;
&lt;!-- リテラルの例、というか、@import(&quot;std&quot;).io.getStdOut().writer().print の例になっていますね。--&gt;
ご覧のように、数値（整数と浮動小数点数）や文字・文字列のリテラルがあり、整数は基数を、浮動小数点数は指数表現と少数表現があります。

@import(&quot;std&quot;).io.getStdOut().writer().printの、第一引数は書式化文字列、第二引数は値リストです。
書式化文字列は、通常の文字列ですが &lt;code&gt;{&lt;/code&gt; と &lt;code&gt;}&lt;/code&gt; で囲まれたプレスホルダーが、引数リストの値（を書式化した文字列）に置換わります。
一番素朴なプレスホルダーは {} で、引数の値の一般的な文字列表記に置換ります（整数なら十進数表記、浮動小数点数なら指数表記）。
ところが、’c’ のような文字型を {} に適用すると文字コード化され整数と同じ十進数表記になってしまいます。そこで、文字型の場合は {c} と文字であることを明記すると文字表現となります。
また、文字列の間合いは {s} を明記しないと（バージョン0.8.0からは）エラーになります。
2つ以上の値を渡す場合は、第二引数を　.{ 1, 2, 3 } の様にカンマ区切りのリストにします（ {} の前の . （点）を忘れがち）。
基本的に、左から順にプレスホルダーにリストの値が左から与えられますが、{0} {1} の書式で参照する引数の順位を明示できます。
書式指定と併用する時は、 &lt;code&gt; print(&quot;? = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; })&lt;/code&gt; の様に順位が先、書式指定文字が後になります。

[TODO:[https://github.com/ziglang/zig/blob/master/lib/std/fmt.zig master/lib/std/fmt.zig]を観て書いています。参照すべき標準ライブラリのドキュメントを発見出来たら、見直し]
[TODO:表組み]

==== comptime ====
Zigでは、コンパイル時に式が既知かどうかという概念を重要視しています。

次のコードを観てみましょう。
:&lt;syntaxhighlight lang=zig line highlight=7&gt;
fn mul(x: usize, y: usize) usize {
    return x * y;
}

pub fn main() void {
    const len : usize = mul(3, 4);
    const ary: [len]i32 = undefined;
    _ = ary;
}
&lt;/syntaxhighlight&gt;
;コンパイル結果:&lt;syntaxhighlight lang=text&gt;
An error occurred: 
/tmp/playground130713503/play.zig:7:17: error: unable to evaluate constant expression 
    const ary: [len]i32 = undefined;
&lt;/syntaxhighlight&gt;
: 「定数式が評価できない 」と宣っています。
: [[C++]]であれば、constexprが適用なケースですが、Zigでは次のような解決方法を取ります。

:&lt;syntaxhighlight lang=zig line highlight=6&gt;
fn mul(x: usize, y: usize) usize {
    return x * y;
}

pub fn main() void {
    const len : usize = comptime mul(3, 4);
    const ary: [len]i32 = undefined;
    _ = ary;
}
&lt;/syntaxhighlight&gt;
: mul() の呼出しを comptime で修飾しました。comptime は、修飾子式を'''コンパイル時に実行する'''修飾子で、式の中でコンパイル時に未定な値が参照されると、エラーとなります。ここでは、数リテラル同士の商を求めているので、コンパイル時値が確定できます。
: _ = ary は、「定義済だが参照のない変数宣言」をサプレッスするときのイディオムです。

&lt;!--
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const i = 0;
    const string = [_]i32{ 1, 2, 3, 4 };
    for (string) |character, index| {
        std.debug.print(&quot;character: {}, index: {}, :{s} \n&quot;, .{ character, index, @typeName(@TypeOf(character)) });
    }
    _ = i;
}
--&gt;

===== インタプリタ的に実行する場合 =====
コンパイル済みファイルの作成を飛ばして、インタプリタ的に直接に実行する方法もあり、たとえばファイル名「hello.zig」なら下記のようなコマンドある。
 zig run hello.zig


===== プロジェクト作成する場合 =====
まず、プロジェクト関連のコマンドを実行すると、自動で数個のフォルダが作成されるので、それをまとめるためのフォルダを別に作っておき（たとえば proj とする）、べつにマウス右クリックでも mldir コマンドでもなんでもいいので proj ディレクトリを作成しておく。

そして、さらにカレント・ディレクトリを proj に移動するために、ターミナルでコマンド
 cd proj
で、そこに移動する。（そうしないと、今後の動作でホームフォルダにいくつものフォルダやファイルが作成され、管理しづらくなる）

その上で、プロジェクト作成のために
 zig init-exe
を行う。このコマンドにより、初期設定ファイルなどがいくつか自動的に作成される。

== 基礎篇 ==
[TODO:書くべき項目を並べてみましたが、例えば「値と型」を網羅的に書いていくと文章量が爆発するのが目に見えているので、過剰になったらリファレンス篇に移動するなどの方法で、各節はコンパクトさを心がけたいです。]

=== コメント ===
Zigでは、&lt;code&gt;//&lt;/code&gt; から行末までがコメントです。
C言語の &lt;code&gt;/* … */&lt;/code&gt; のスタイルの複数行に渡るコメントは'''ありません'''。
これは、コードの各行を文脈に関係なくトークン化できるようにするためです。
:&lt;syntaxhighlight lang=zig&gt;
// @import は組込み関数です。
const std = @import(&quot;std&quot;); // 先頭に @ が付く関数は組込み関数です
pub fn main() !void {
   try std.io.getStdOut().writeAll(&quot;Hello, World!\n&quot;);
}
&lt;/syntaxhighlight&gt;

==== Docコメント ====
Zigでは、&lt;code&gt;///&lt;/code&gt; から始まるコメントは特別なコメントで、Docコメント( ''Doc comments'' )と呼ばれます。
Docコメントは特定の場所にしか許されません。式の途中や非Docコメントの直前など、予想外の場所にdocコメントがあると、コンパイルエラーになります。

[TODO:サンプルコードと整形結果]

==== トップレベルDocコメント ====
Zigでは、&lt;code&gt;//!&lt;/code&gt; から始まるコメントは特別なコメントで、トップレベルDocコメント( ''Top-Level Doc Comments '' )と呼ばれます。
コンテナレベルのドキュメントのように、直後のドキュメントに属さないユーザードキュメントに、トップレベルDocコメントを使います。

[TODO:サンプルコードと整形結果]

DocコメントおよびトップレベルDocコメントは、コンパイル時に zig build-exe -femit-docs ソースファイル.zig の様に、-femit-docs をあたえると、 docs/ 以下にドキュメントが生成されます。

=== 値と型 ===
[TOD0:整数・浮動小数・論理値・文字列・共用体・構造体・列挙・配列・ベクトル・スライス・ポインター・ゼロビットな型]

:&lt;syntaxhighlight lang=zig&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot; (1) = {}\n&quot;, .{42});
    try print(&quot; (2) = {}\n&quot;, .{0x17});
    try print(&quot; (3) = {}\n&quot;, .{0o17});
    try print(&quot; (4) = {}\n&quot;, .{0b0100101});
    try print(&quot; (5) = {}\n&quot;, .{1e222});
    try print(&quot; (6) = {}\n&quot;, .{3.1415926536});
    try print(&quot; (7) = {}\n&quot;, .{'c'});
    try print(&quot; (8) = {c}\n&quot;, .{'c'});
    try print(&quot; (9) = {s}\n&quot;, .{&quot;abcdef&quot;});
    try print(&quot;(10) = {}, {}\n&quot;, .{ 111, 999 });
    try print(&quot;(11) = {1}, {0}\n&quot;, .{ 111, 999 });
    try print(&quot;(12) = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; });
    try print(&quot;(13) = {0d}, {0b}, {0o}, {0x}, {0X}\n&quot;, .{ 123 });
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
 (1) = 42
 (2) = 23
 (3) = 15
 (4) = 37
 (5) = 1.0e+222
 (6) = 3.1415926536e+00
 (7) = 99
 (8) = c
 (9) = abcdef
(10) = 111, 999
(11) = 999, 111
(12) = abc, 111
(13) = 123, 1111011, 173, 7b, 7B
&lt;/syntaxhighlight&gt;
&lt;!-- リテラルの例、というか、@import(&quot;std&quot;).io.getStdOut().writer().print の例になっていますね。--&gt;
ご覧のように、数値（整数と浮動小数点数）や文字・文字列のリテラルがあり、整数は基数を、浮動小数点数は指数表現と少数表現があります。

@import(&quot;std&quot;).io.getStdOut().writer().printの、第一引数は書式化文字列、第二引数は値リストです。
書式化文字列は、通常の文字列ですが &lt;code&gt;{&lt;/code&gt; と &lt;code&gt;}&lt;/code&gt; で囲まれたプレスホルダーが、引数リストの値（を書式化した文字列）に置換わります。
一番素朴なプレスホルダーは {} で、引数の値の一般的な文字列表記に置換ります（整数なら十進数表記、浮動小数点数なら指数表記）。
ところが、’c’ のような文字型を {} に適用すると文字コード化され整数と同じ十進数表記になってしまいます。そこで、文字型の場合は {c} と文字であることを明記すると文字表現となります。
また、文字列の間合いは {s} を明記しないと（バージョン0.8.0からは）エラーになります。
2つ以上の値を渡す場合は、第二引数を　.{ 1, 2, 3 } の様にカンマ区切りのリストにします（ {} の前の . （点）を忘れがち）。
基本的に、左から順にプレスホルダーにリストの値が左から与えられますが、{0} {1} の書式で参照する引数の順位を明示できます。
書式指定と併用する時は、 &lt;code&gt; print(&quot;? = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; })&lt;/code&gt; の様に順位が先、書式指定文字が後になります。

[TODO:[https://github.com/ziglang/zig/blob/master/lib/std/fmt.zig master/lib/std/fmt.zig]を観て書いています。参照すべき標準ライブラリのドキュメントを発見出来たら、見直し]
[TODO:表組み]

==== comptime ====
Zigでは、コンパイル時に式が既知かどうかという概念を重要視しています。

&lt;!--
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const i = 0;
    const string = [_]i32{ 1, 2, 3, 4 };
    for (string) |character, index| {
        std.debug.print(&quot;character: {}, index: {}, :{s} \n&quot;, .{ character, index, @typeName(@TypeOf(character)) });
    }
    _ = i;
}
--&gt;

=== テスト ===
=== 変数 ===
=== 制御構造 ===
[TODO:Zig の制御構造は文ではなく式]
==== 分岐 ====
[TODO:ifとswitch]
==== 反復 ====
[TODO:whileとfor]
=== 関数 ===
=== エラー ===
=== 演算子 ===
==== 優先順位 ====
高
&lt;syntaxhighlight lang=text line&gt;
 x() x[] x.y x.* x.?
 a!b
 x{}
 !x -x -%x ~x &amp;x ?x
 * / % ** *% *| ||
 + - ++ +% -% +| -|
 &lt;&lt; &gt;&gt; &lt;&lt;|
 &amp; ^ | orelse catch
 == != &lt; &gt; &lt;= &gt;=
 and
 or
 = *= *%= *|= /= %= += +%= +|= -= -%= -|= &lt;&lt;= &lt;&lt;|= &gt;&gt;= &amp;= ^= |=
&lt;/syntaxhighlight&gt;
低

===  optional type ===
===  opaque ===
訳語未定
=== ブロック ===
[TODO:スコープとシャドーイング；deferはここ？]
=== キャスト ===
[TODO:Zig は強い型付け()； 型強制 (Type coercion) について]
=== アセンブリ言語との連携 ===
[TODO:所謂インラインアセンラ]
=== atomic ===
=== 非同期関数 ===
=== 組込み関数 ===
[TODO:組込み関数は、@で始まり、@TypeOfや@alignOfの他@sinや@memcpyも組込み関数]
=== メモリ管理 ===
=== キーワード一覧 ===
&lt;code&gt;align&lt;/code&gt;
&lt;code&gt;allowzero&lt;/code&gt;
&lt;code&gt;and&lt;/code&gt;
&lt;code&gt;anyframe&lt;/code&gt;
&lt;code&gt;anytype&lt;/code&gt;
&lt;code&gt;asm&lt;/code&gt;
&lt;code&gt;async&lt;/code&gt;
&lt;code&gt;await&lt;/code&gt;
&lt;code&gt;break&lt;/code&gt;
&lt;code&gt;catch&lt;/code&gt;
&lt;code&gt;comptime&lt;/code&gt;
&lt;code&gt;const&lt;/code&gt;
&lt;code&gt;continue&lt;/code&gt;
&lt;code&gt;defer&lt;/code&gt;
&lt;code&gt;else&lt;/code&gt;
&lt;code&gt;enum&lt;/code&gt;
&lt;code&gt;errdefer&lt;/code&gt;
&lt;code&gt;error&lt;/code&gt;
&lt;code&gt;export&lt;/code&gt;
&lt;code&gt;extern&lt;/code&gt;
&lt;code&gt;fn&lt;/code&gt;
&lt;code&gt;for&lt;/code&gt;
&lt;code&gt;if&lt;/code&gt;
&lt;code&gt;inline&lt;/code&gt;
&lt;code&gt;noalias&lt;/code&gt;
&lt;code&gt;nosuspend&lt;/code&gt;
&lt;code&gt;or&lt;/code&gt;
&lt;code&gt;orelse&lt;/code&gt;
&lt;code&gt;packed&lt;/code&gt;
&lt;code&gt;pub&lt;/code&gt;
&lt;code&gt;resume&lt;/code&gt;
&lt;code&gt;return&lt;/code&gt;
&lt;code&gt;linksection&lt;/code&gt;
&lt;code&gt;struct&lt;/code&gt;
&lt;code&gt;suspend&lt;/code&gt;
&lt;code&gt;switch&lt;/code&gt;
&lt;code&gt;test&lt;/code&gt;
&lt;code&gt;threadlocal&lt;/code&gt;
&lt;code&gt;try&lt;/code&gt;
&lt;code&gt;union&lt;/code&gt;
&lt;code&gt;unreachable&lt;/code&gt;
&lt;code&gt;usingnamespace&lt;/code&gt;
&lt;code&gt;var&lt;/code&gt;
&lt;code&gt;volatile&lt;/code&gt;
&lt;code&gt;while&lt;/code&gt;

== チートシート ==
[TODO:文法と型と頻用する標準ライブラリの関数と型のアンチョコ]

== リファレンス篇 ==

== 脚註 ==
&lt;references /&gt;

== 外部リンク ==
* [https://ziglang.org/ Home ⚡ Zig Programming Language] {{---}} 公式サイト
** [[https://ziglang.org/documentation/master/ Zig Language Reference]] {{---}} リファレンスマニュアル
* [https://github.com/ziglang/zig ziglang/zig: General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.] {{---}} 公式リポジトリ
* [https://zig-play.dev/ Zig Playground] {{---}} オンライン実行環境
** [https://github.com/gsquire/zig-play About An online Zig compiler inspired by Go and Rust] {{---}} リポジトリ

[[Category:zig|*]]
[[Category:プログラミング言語]]</text>
      <sha1>aaitkwo98z6xgz92wml8v2rn57g745l</sha1>
    </revision>
    <revision>
      <id>205761</id>
      <parentid>205758</parentid>
      <timestamp>2022-07-24T06:29:56Z</timestamp>
      <contributor>
        <username>Ef3</username>
        <id>694</id>
      </contributor>
      <comment>/* 値と型 */ .{ 1, 2, 3 } の様にカンマ区切りのリストにします（ これが、Zig の配列リテラルの表現で、{} の前の . （点）を忘れがち）。</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="21071" xml:space="preserve">{{Pathnav|メインページ|工学|情報技術|プログラミング|frame=1}}
{{Wikipedia|Zig (プログラミング言語)}}
本書は、[[w:Zig|Zig]]のチュートリアルです。
Zigは、堅牢で最適かつ再利用可能なソフトウェアを維持するための汎用プログラミング言語およびツールチェインです&lt;ref&gt;{{Cite web
|url=https://ziglang.org/
|title=Home ⚡ Zig Programming Language
|website=ziglang.org
|accessdate=2022-07-17
|cite=Zig is a general-purpose programming language and toolchain for maintaining '''robust''', '''optimal''' and '''reusable''' software.
}}&lt;/ref&gt;。
Zigは、アンドリュー・ケリー( ''[https://andrewkelley.me/ Andrew Kelley]'' )によって設計され、汎用システムプログラミング言語で、静的で強い型付けで型推論とジェネリックプログラミングをサポートします。

== 概要 ==
Zigは、2016年2月に発表された比較的若いプログラミング言語で&lt;ref&gt;{{Cite web
|last1=Kelley
|first1=Andrew
|title=Introduction to the Zig Programming Language
|url=https://andrewkelley.me/post/intro-to-zig.html
|website=andrewkelley.me
|accessdate=2022-07-17
}}&lt;/ref&gt;、2022年7月現在のバージョンは 0.9.1 で、'''''pre-release''''' と位置づけられています&lt;ref&gt;{{Cite web
|url=https://github.com/ziglang/zig/releases
|title=Releases · ziglang/zig
|website=github.com
|accessdate=2022-07-17
}}&lt;/ref&gt;。このため [[W:Hello world|Hello world]] ですら、バージョン間で互換性がなくなることもあり、リリースバージョンまでは言語仕様やライブラリーおよびツールチェインの仕様が変更される可能性があります。

=== Hello world の変遷 ===
[https://ziglang.org/documentation/master/ Zig Language Reference]の、[[W:Hello world|Hello world]]の変遷（新しい順）。

;master@2022-07-17&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/master/#Hello-World
|title=Zig Documentation(master@2022-07-17)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.8.1に同じ
;0.9.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.9.1/#Hello-World
|title=Zig Documentation(0.9.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.8.1に同じ
;0.8.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.8.1/#Hello-World
|title=Zig Documentation(0.8.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=4&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().writer();
    try stdout.print(&quot;Hello, {s}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: &lt;code&gt;{}&lt;/code&gt; ⇒ &lt;code&gt;{s}&lt;/code&gt;&lt;ref&gt;{{Cite web
|url=https://ziglang.org/download/0.8.0/release-notes.html#Formatted-Printing
|title=0.8.0 Release Notes
|website=ziglang.org
|accessdate=2022-07-17
|quote=Disable the special casing of {} for u8 slices/arrays. Unless {s} is specified the contents won't be treated as a string.
}}&lt;/ref&gt;
;0.7.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.7.1/#Hello-World
|title=Zig Documentation(0.7.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=3&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().writer();
    try stdout.print(&quot;Hello, {}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: s/outStream/writer/
;0.6.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.6.0/#Hello-World
|title=Zig Documentation(0.6.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=3&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().outStream();
    try stdout.print(&quot;Hello, {}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: 初期化の初期値から &lt;code&gt;try&lt;/code&gt; がなくなった。
;0.4.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.4.0/#Hello-World
|title=Zig Documentation(0.4.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.2.0に同じ
;0.5.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.5.0/#Hello-World
|title=Zig Documentation(0.5.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=4&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    // If this program is run without stdout attached, exit with an error.
    const stdout_file = try std.io.getStdOut();
    // If this program encounters pipe failure when printing to stdout, exit
    // with an error.
    try stdout_file.write(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;
: &lt;var&gt;stdout_file&lt;/var&gt; が &lt;code&gt;var&lt;/code&gt; から &lt;code&gt;const&lt;/code&gt; に変更された。

;0.3.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.3.0/#Hello-World
|title=Zig Documentation(0.3.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.2.0に同じ
;0.2.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.2.0/#Hello-World
|title=Zig Documentation(0.2.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    // If this program is run without stdout attached, exit with an error.
    var stdout_file = try std.io.getStdOut();
    // If this program encounters pipe failure when printing to stdout, exit
    // with an error.
    try stdout_file.write(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;
;0.1.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.1.1/#hello-world
|title=Zig Documentation
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig&gt;
const io = @import(&quot;std&quot;).io;
pub fn main() -&gt; %void {
    %%io.stdout.printf(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;

== 環境準備 ==
=== Linuxの場合 ===
==== インストール方法 ====
Fedora 36 の場合、2022年の時点で、コマンド
 sudo dnf install zig
だけでインストールできる事を確認。

その他のOS環境でのインストールについては、[https://github.com/ziglang/zig/wiki/Install-Zig-from-a-Package-Manager  GitHub  &quot;ziglang /zig&quot; ] を参照せよ。

インストールできたと思ったら、バージョン確認コマンドなどで、インストールの成否を確認しよう。コマンド
 zig version
で確認できる。

なお、2022年7月現在、まだバージョンは1未満であり、同7月に実験したところ
 0.9.1
であった。上記のセクションでも掛かれているように2022年の段階ではまだプレリリースであるので、1未満でもインストール成功なので安心していい。

==== コードの実行方法 ====
=== 値と型 ===
[TOD0:整数・浮動小数・論理値・文字列・共用体・構造体・列挙・配列・ベクトル・スライス・ポインター・ゼロビットな型]

:&lt;syntaxhighlight lang=zig&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot; (1) = {}\n&quot;, .{42});
    try print(&quot; (2) = {}\n&quot;, .{0x17});
    try print(&quot; (3) = {}\n&quot;, .{0o17});
    try print(&quot; (4) = {}\n&quot;, .{0b0100101});
    try print(&quot; (5) = {}\n&quot;, .{1e222});
    try print(&quot; (6) = {}\n&quot;, .{3.1415926536});
    try print(&quot; (7) = {}\n&quot;, .{'c'});
    try print(&quot; (8) = {c}\n&quot;, .{'c'});
    try print(&quot; (9) = {s}\n&quot;, .{&quot;abcdef&quot;});
    try print(&quot;(10) = {}, {}\n&quot;, .{ 111, 999 });
    try print(&quot;(11) = {1}, {0}\n&quot;, .{ 111, 999 });
    try print(&quot;(12) = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; });
    try print(&quot;(13) = {0d}, {0b}, {0o}, {0x}, {0X}\n&quot;, .{ 123 });
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
 (1) = 42
 (2) = 23
 (3) = 15
 (4) = 37
 (5) = 1.0e+222
 (6) = 3.1415926536e+00
 (7) = 99
 (8) = c
 (9) = abcdef
(10) = 111, 999
(11) = 999, 111
(12) = abc, 111
(13) = 123, 1111011, 173, 7b, 7B
&lt;/syntaxhighlight&gt;
&lt;!-- リテラルの例、というか、@import(&quot;std&quot;).io.getStdOut().writer().print の例になっていますね。--&gt;
ご覧のように、数値（整数と浮動小数点数）や文字・文字列のリテラルがあり、整数は基数を、浮動小数点数は指数表現と少数表現があります。

@import(&quot;std&quot;).io.getStdOut().writer().printの、第一引数は書式化文字列、第二引数は値リストです。
書式化文字列は、通常の文字列ですが &lt;code&gt;{&lt;/code&gt; と &lt;code&gt;}&lt;/code&gt; で囲まれたプレスホルダーが、引数リストの値（を書式化した文字列）に置換わります。
一番素朴なプレスホルダーは {} で、引数の値の一般的な文字列表記に置換ります（整数なら十進数表記、浮動小数点数なら指数表記）。
ところが、’c’ のような文字型を {} に適用すると文字コード化され整数と同じ十進数表記になってしまいます。そこで、文字型の場合は {c} と文字であることを明記すると文字表現となります。
また、文字列の間合いは {s} を明記しないと（バージョン0.8.0からは）エラーになります。
2つ以上の値を渡す場合は、第二引数を　.{ 1, 2, 3 } の様にカンマ区切りのリストにします（ {} の前の . （点）を忘れがち）。
基本的に、左から順にプレスホルダーにリストの値が左から与えられますが、{0} {1} の書式で参照する引数の順位を明示できます。
書式指定と併用する時は、 &lt;code&gt; print(&quot;? = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; })&lt;/code&gt; の様に順位が先、書式指定文字が後になります。

[TODO:[https://github.com/ziglang/zig/blob/master/lib/std/fmt.zig master/lib/std/fmt.zig]を観て書いています。参照すべき標準ライブラリのドキュメントを発見出来たら、見直し]
[TODO:表組み]

==== comptime ====
Zigでは、コンパイル時に式が既知かどうかという概念を重要視しています。

次のコードを観てみましょう。
:&lt;syntaxhighlight lang=zig line highlight=7&gt;
fn mul(x: usize, y: usize) usize {
    return x * y;
}

pub fn main() void {
    const len : usize = mul(3, 4);
    const ary: [len]i32 = undefined;
    _ = ary;
}
&lt;/syntaxhighlight&gt;
;コンパイル結果:&lt;syntaxhighlight lang=text&gt;
An error occurred: 
/tmp/playground130713503/play.zig:7:17: error: unable to evaluate constant expression 
    const ary: [len]i32 = undefined;
&lt;/syntaxhighlight&gt;
: 「定数式が評価できない 」と宣っています。
: [[C++]]であれば、constexprが適用なケースですが、Zigでは次のような解決方法を取ります。

:&lt;syntaxhighlight lang=zig line highlight=6&gt;
fn mul(x: usize, y: usize) usize {
    return x * y;
}

pub fn main() void {
    const len : usize = comptime mul(3, 4);
    const ary: [len]i32 = undefined;
    _ = ary;
}
&lt;/syntaxhighlight&gt;
: mul() の呼出しを comptime で修飾しました。comptime は、修飾子式を'''コンパイル時に実行する'''修飾子で、式の中でコンパイル時に未定な値が参照されると、エラーとなります。ここでは、数リテラル同士の商を求めているので、コンパイル時値が確定できます。
: _ = ary は、「定義済だが参照のない変数宣言」をサプレッスするときのイディオムです。

&lt;!--
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const i = 0;
    const string = [_]i32{ 1, 2, 3, 4 };
    for (string) |character, index| {
        std.debug.print(&quot;character: {}, index: {}, :{s} \n&quot;, .{ character, index, @typeName(@TypeOf(character)) });
    }
    _ = i;
}
--&gt;

===== インタプリタ的に実行する場合 =====
コンパイル済みファイルの作成を飛ばして、インタプリタ的に直接に実行する方法もあり、たとえばファイル名「hello.zig」なら下記のようなコマンドある。
 zig run hello.zig


===== プロジェクト作成する場合 =====
まず、プロジェクト関連のコマンドを実行すると、自動で数個のフォルダが作成されるので、それをまとめるためのフォルダを別に作っておき（たとえば proj とする）、べつにマウス右クリックでも mldir コマンドでもなんでもいいので proj ディレクトリを作成しておく。

そして、さらにカレント・ディレクトリを proj に移動するために、ターミナルでコマンド
 cd proj
で、そこに移動する。（そうしないと、今後の動作でホームフォルダにいくつものフォルダやファイルが作成され、管理しづらくなる）

その上で、プロジェクト作成のために
 zig init-exe
を行う。このコマンドにより、初期設定ファイルなどがいくつか自動的に作成される。

== 基礎篇 ==
[TODO:書くべき項目を並べてみましたが、例えば「値と型」を網羅的に書いていくと文章量が爆発するのが目に見えているので、過剰になったらリファレンス篇に移動するなどの方法で、各節はコンパクトさを心がけたいです。]

=== コメント ===
Zigでは、&lt;code&gt;//&lt;/code&gt; から行末までがコメントです。
C言語の &lt;code&gt;/* … */&lt;/code&gt; のスタイルの複数行に渡るコメントは'''ありません'''。
これは、コードの各行を文脈に関係なくトークン化できるようにするためです。
:&lt;syntaxhighlight lang=zig&gt;
// @import は組込み関数です。
const std = @import(&quot;std&quot;); // 先頭に @ が付く関数は組込み関数です
pub fn main() !void {
   try std.io.getStdOut().writeAll(&quot;Hello, World!\n&quot;);
}
&lt;/syntaxhighlight&gt;

==== Docコメント ====
Zigでは、&lt;code&gt;///&lt;/code&gt; から始まるコメントは特別なコメントで、Docコメント( ''Doc comments'' )と呼ばれます。
Docコメントは特定の場所にしか許されません。式の途中や非Docコメントの直前など、予想外の場所にdocコメントがあると、コンパイルエラーになります。

[TODO:サンプルコードと整形結果]

==== トップレベルDocコメント ====
Zigでは、&lt;code&gt;//!&lt;/code&gt; から始まるコメントは特別なコメントで、トップレベルDocコメント( ''Top-Level Doc Comments '' )と呼ばれます。
コンテナレベルのドキュメントのように、直後のドキュメントに属さないユーザードキュメントに、トップレベルDocコメントを使います。

[TODO:サンプルコードと整形結果]

DocコメントおよびトップレベルDocコメントは、コンパイル時に zig build-exe -femit-docs ソースファイル.zig の様に、-femit-docs をあたえると、 docs/ 以下にドキュメントが生成されます。

=== 値と型 ===
[TOD0:整数・浮動小数・論理値・文字列・共用体・構造体・列挙・配列・ベクトル・スライス・ポインター・ゼロビットな型]

:&lt;syntaxhighlight lang=zig&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot; (1) = {}\n&quot;, .{42});
    try print(&quot; (2) = {}\n&quot;, .{0x17});
    try print(&quot; (3) = {}\n&quot;, .{0o17});
    try print(&quot; (4) = {}\n&quot;, .{0b0100101});
    try print(&quot; (5) = {}\n&quot;, .{1e222});
    try print(&quot; (6) = {}\n&quot;, .{3.1415926536});
    try print(&quot; (7) = {}\n&quot;, .{'c'});
    try print(&quot; (8) = {c}\n&quot;, .{'c'});
    try print(&quot; (9) = {s}\n&quot;, .{&quot;abcdef&quot;});
    try print(&quot;(10) = {}, {}\n&quot;, .{ 111, 999 });
    try print(&quot;(11) = {1}, {0}\n&quot;, .{ 111, 999 });
    try print(&quot;(12) = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; });
    try print(&quot;(13) = {0d}, {0b}, {0o}, {0x}, {0X}\n&quot;, .{ 123 });
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
 (1) = 42
 (2) = 23
 (3) = 15
 (4) = 37
 (5) = 1.0e+222
 (6) = 3.1415926536e+00
 (7) = 99
 (8) = c
 (9) = abcdef
(10) = 111, 999
(11) = 999, 111
(12) = abc, 111
(13) = 123, 1111011, 173, 7b, 7B
&lt;/syntaxhighlight&gt;
&lt;!-- リテラルの例、というか、@import(&quot;std&quot;).io.getStdOut().writer().print の例になっていますね。--&gt;
ご覧のように、数値（整数と浮動小数点数）や文字・文字列のリテラルがあり、整数は基数を、浮動小数点数は指数表現と少数表現があります。

@import(&quot;std&quot;).io.getStdOut().writer().printの、第一引数は書式化文字列、第二引数は値リストです。
書式化文字列は、通常の文字列ですが &lt;code&gt;{&lt;/code&gt; と &lt;code&gt;}&lt;/code&gt; で囲まれたプレスホルダーが、引数リストの値（を書式化した文字列）に置換わります。
一番素朴なプレスホルダーは {} で、引数の値の一般的な文字列表記に置換ります（整数なら十進数表記、浮動小数点数なら指数表記）。
ところが、’c’ のような文字型を {} に適用すると文字コード化され整数と同じ十進数表記になってしまいます。そこで、文字型の場合は {c} と文字であることを明記すると文字表現となります。
また、文字列の間合いは {s} を明記しないと（バージョン0.8.0からは）エラーになります。
2つ以上の値を渡す場合は、第二引数を　.{ 1, 2, 3 } の様にカンマ区切りのリストにします（ これが、Zig の配列リテラルの表現で、{} の前の . （点）を忘れがち）。
基本的に、左から順にプレスホルダーにリストの値が左から与えられますが、{0} {1} の書式で参照する引数の順位を明示できます。
書式指定と併用する時は、 &lt;code&gt; print(&quot;? = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; })&lt;/code&gt; の様に順位が先、書式指定文字が後になります。

[TODO:[https://github.com/ziglang/zig/blob/master/lib/std/fmt.zig master/lib/std/fmt.zig]を観て書いています。参照すべき標準ライブラリのドキュメントを発見出来たら、見直し]
[TODO:表組み]

==== comptime ====
Zigでは、コンパイル時に式が既知かどうかという概念を重要視しています。

&lt;!--
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const i = 0;
    const string = [_]i32{ 1, 2, 3, 4 };
    for (string) |character, index| {
        std.debug.print(&quot;character: {}, index: {}, :{s} \n&quot;, .{ character, index, @typeName(@TypeOf(character)) });
    }
    _ = i;
}
--&gt;

=== テスト ===
=== 変数 ===
=== 制御構造 ===
[TODO:Zig の制御構造は文ではなく式]
==== 分岐 ====
[TODO:ifとswitch]
==== 反復 ====
[TODO:whileとfor]
=== 関数 ===
=== エラー ===
=== 演算子 ===
==== 優先順位 ====
高
&lt;syntaxhighlight lang=text line&gt;
 x() x[] x.y x.* x.?
 a!b
 x{}
 !x -x -%x ~x &amp;x ?x
 * / % ** *% *| ||
 + - ++ +% -% +| -|
 &lt;&lt; &gt;&gt; &lt;&lt;|
 &amp; ^ | orelse catch
 == != &lt; &gt; &lt;= &gt;=
 and
 or
 = *= *%= *|= /= %= += +%= +|= -= -%= -|= &lt;&lt;= &lt;&lt;|= &gt;&gt;= &amp;= ^= |=
&lt;/syntaxhighlight&gt;
低

===  optional type ===
===  opaque ===
訳語未定
=== ブロック ===
[TODO:スコープとシャドーイング；deferはここ？]
=== キャスト ===
[TODO:Zig は強い型付け()； 型強制 (Type coercion) について]
=== アセンブリ言語との連携 ===
[TODO:所謂インラインアセンラ]
=== atomic ===
=== 非同期関数 ===
=== 組込み関数 ===
[TODO:組込み関数は、@で始まり、@TypeOfや@alignOfの他@sinや@memcpyも組込み関数]
=== メモリ管理 ===
=== キーワード一覧 ===
&lt;code&gt;align&lt;/code&gt;
&lt;code&gt;allowzero&lt;/code&gt;
&lt;code&gt;and&lt;/code&gt;
&lt;code&gt;anyframe&lt;/code&gt;
&lt;code&gt;anytype&lt;/code&gt;
&lt;code&gt;asm&lt;/code&gt;
&lt;code&gt;async&lt;/code&gt;
&lt;code&gt;await&lt;/code&gt;
&lt;code&gt;break&lt;/code&gt;
&lt;code&gt;catch&lt;/code&gt;
&lt;code&gt;comptime&lt;/code&gt;
&lt;code&gt;const&lt;/code&gt;
&lt;code&gt;continue&lt;/code&gt;
&lt;code&gt;defer&lt;/code&gt;
&lt;code&gt;else&lt;/code&gt;
&lt;code&gt;enum&lt;/code&gt;
&lt;code&gt;errdefer&lt;/code&gt;
&lt;code&gt;error&lt;/code&gt;
&lt;code&gt;export&lt;/code&gt;
&lt;code&gt;extern&lt;/code&gt;
&lt;code&gt;fn&lt;/code&gt;
&lt;code&gt;for&lt;/code&gt;
&lt;code&gt;if&lt;/code&gt;
&lt;code&gt;inline&lt;/code&gt;
&lt;code&gt;noalias&lt;/code&gt;
&lt;code&gt;nosuspend&lt;/code&gt;
&lt;code&gt;or&lt;/code&gt;
&lt;code&gt;orelse&lt;/code&gt;
&lt;code&gt;packed&lt;/code&gt;
&lt;code&gt;pub&lt;/code&gt;
&lt;code&gt;resume&lt;/code&gt;
&lt;code&gt;return&lt;/code&gt;
&lt;code&gt;linksection&lt;/code&gt;
&lt;code&gt;struct&lt;/code&gt;
&lt;code&gt;suspend&lt;/code&gt;
&lt;code&gt;switch&lt;/code&gt;
&lt;code&gt;test&lt;/code&gt;
&lt;code&gt;threadlocal&lt;/code&gt;
&lt;code&gt;try&lt;/code&gt;
&lt;code&gt;union&lt;/code&gt;
&lt;code&gt;unreachable&lt;/code&gt;
&lt;code&gt;usingnamespace&lt;/code&gt;
&lt;code&gt;var&lt;/code&gt;
&lt;code&gt;volatile&lt;/code&gt;
&lt;code&gt;while&lt;/code&gt;

== チートシート ==
[TODO:文法と型と頻用する標準ライブラリの関数と型のアンチョコ]

== リファレンス篇 ==

== 脚註 ==
&lt;references /&gt;

== 外部リンク ==
* [https://ziglang.org/ Home ⚡ Zig Programming Language] {{---}} 公式サイト
** [[https://ziglang.org/documentation/master/ Zig Language Reference]] {{---}} リファレンスマニュアル
* [https://github.com/ziglang/zig ziglang/zig: General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.] {{---}} 公式リポジトリ
* [https://zig-play.dev/ Zig Playground] {{---}} オンライン実行環境
** [https://github.com/gsquire/zig-play About An online Zig compiler inspired by Go and Rust] {{---}} リポジトリ

[[Category:zig|*]]
[[Category:プログラミング言語]]</text>
      <sha1>cqa11682txkhjjgdrmbsbq8zyzwvs0x</sha1>
    </revision>
    <revision>
      <id>205763</id>
      <parentid>205761</parentid>
      <timestamp>2022-07-24T06:37:44Z</timestamp>
      <contributor>
        <username>すじにくシチュー</username>
        <id>12058</id>
      </contributor>
      <comment>/* 値と型 */ typo 少数 -&gt; 小数</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="21550" xml:space="preserve">{{Pathnav|メインページ|工学|情報技術|プログラミング|frame=1}}
{{Wikipedia|Zig (プログラミング言語)}}
本書は、[[w:Zig|Zig]]のチュートリアルです。
Zigは、堅牢で最適かつ再利用可能なソフトウェアを維持するための汎用プログラミング言語およびツールチェインです&lt;ref&gt;{{Cite web
|url=https://ziglang.org/
|title=Home ⚡ Zig Programming Language
|website=ziglang.org
|accessdate=2022-07-17
|cite=Zig is a general-purpose programming language and toolchain for maintaining '''robust''', '''optimal''' and '''reusable''' software.
}}&lt;/ref&gt;。
Zigは、アンドリュー・ケリー( ''[https://andrewkelley.me/ Andrew Kelley]'' )によって設計され、汎用システムプログラミング言語で、静的で強い型付けで型推論とジェネリックプログラミングをサポートします。

== 概要 ==
Zigは、2016年2月に発表された比較的若いプログラミング言語で&lt;ref&gt;{{Cite web
|last1=Kelley
|first1=Andrew
|title=Introduction to the Zig Programming Language
|url=https://andrewkelley.me/post/intro-to-zig.html
|website=andrewkelley.me
|accessdate=2022-07-17
}}&lt;/ref&gt;、2022年7月現在のバージョンは 0.9.1 で、'''''pre-release''''' と位置づけられています&lt;ref&gt;{{Cite web
|url=https://github.com/ziglang/zig/releases
|title=Releases · ziglang/zig
|website=github.com
|accessdate=2022-07-17
}}&lt;/ref&gt;。このため [[W:Hello world|Hello world]] ですら、バージョン間で互換性がなくなることもあり、リリースバージョンまでは言語仕様やライブラリーおよびツールチェインの仕様が変更される可能性があります。

=== Hello world の変遷 ===
[https://ziglang.org/documentation/master/ Zig Language Reference]の、[[W:Hello world|Hello world]]の変遷（新しい順）。

;master@2022-07-17&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/master/#Hello-World
|title=Zig Documentation(master@2022-07-17)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.8.1に同じ
;0.9.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.9.1/#Hello-World
|title=Zig Documentation(0.9.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.8.1に同じ
;0.8.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.8.1/#Hello-World
|title=Zig Documentation(0.8.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=4&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().writer();
    try stdout.print(&quot;Hello, {s}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: &lt;code&gt;{}&lt;/code&gt; ⇒ &lt;code&gt;{s}&lt;/code&gt;&lt;ref&gt;{{Cite web
|url=https://ziglang.org/download/0.8.0/release-notes.html#Formatted-Printing
|title=0.8.0 Release Notes
|website=ziglang.org
|accessdate=2022-07-17
|quote=Disable the special casing of {} for u8 slices/arrays. Unless {s} is specified the contents won't be treated as a string.
}}&lt;/ref&gt;
;0.7.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.7.1/#Hello-World
|title=Zig Documentation(0.7.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=3&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().writer();
    try stdout.print(&quot;Hello, {}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: s/outStream/writer/
;0.6.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.6.0/#Hello-World
|title=Zig Documentation(0.6.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=3&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().outStream();
    try stdout.print(&quot;Hello, {}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: 初期化の初期値から &lt;code&gt;try&lt;/code&gt; がなくなった。
;0.4.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.4.0/#Hello-World
|title=Zig Documentation(0.4.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.2.0に同じ
;0.5.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.5.0/#Hello-World
|title=Zig Documentation(0.5.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=4&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    // If this program is run without stdout attached, exit with an error.
    const stdout_file = try std.io.getStdOut();
    // If this program encounters pipe failure when printing to stdout, exit
    // with an error.
    try stdout_file.write(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;
: &lt;var&gt;stdout_file&lt;/var&gt; が &lt;code&gt;var&lt;/code&gt; から &lt;code&gt;const&lt;/code&gt; に変更された。

;0.3.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.3.0/#Hello-World
|title=Zig Documentation(0.3.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.2.0に同じ
;0.2.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.2.0/#Hello-World
|title=Zig Documentation(0.2.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    // If this program is run without stdout attached, exit with an error.
    var stdout_file = try std.io.getStdOut();
    // If this program encounters pipe failure when printing to stdout, exit
    // with an error.
    try stdout_file.write(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;
;0.1.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.1.1/#hello-world
|title=Zig Documentation
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig&gt;
const io = @import(&quot;std&quot;).io;
pub fn main() -&gt; %void {
    %%io.stdout.printf(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;

== 環境準備 ==
=== Linuxの場合 ===
==== インストール方法 ====
Fedora 36 の場合、2022年の時点で、コマンド
 sudo dnf install zig
だけでインストールできる事を確認。

その他のOS環境でのインストールについては、[https://github.com/ziglang/zig/wiki/Install-Zig-from-a-Package-Manager  GitHub  &quot;ziglang /zig&quot; ] を参照せよ。

インストールできたと思ったら、バージョン確認コマンドなどで、インストールの成否を確認しよう。コマンド
 zig version
で確認できる。

なお、2022年7月現在、まだバージョンは1未満であり、同7月に実験したところ
 0.9.1
であった。上記のセクションでも掛かれているように2022年の段階ではまだプレリリースであるので、1未満でもインストール成功なので安心していい。

==== コードの実行方法 ====
=== 値と型 ===
[TOD0:整数・浮動小数・論理値・文字列・共用体・構造体・列挙・配列・ベクトル・スライス・ポインター・ゼロビットな型]

:&lt;syntaxhighlight lang=&quot;zig&quot;&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot;abcd \n&quot;, .{} );
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
abcd 
&lt;/syntaxhighlight&gt;

2022年7月現在、引用符中に変数をなにも使っていなくても、&lt;code&gt;.{}&lt;/code&gt;が必要である。ほか&lt;code&gt;try print&lt;/code&gt; の &lt;code&gt;try&lt;/code&gt; については、&lt;code&gt;try&lt;/code&gt;がないとエラーになる。

:&lt;syntaxhighlight lang=&quot;zig&quot;&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot; (1) = {}\n&quot;, .{42});
    try print(&quot; (2) = {}\n&quot;, .{0x17});
    try print(&quot; (3) = {}\n&quot;, .{0o17});
    try print(&quot; (4) = {}\n&quot;, .{0b0100101});
    try print(&quot; (5) = {}\n&quot;, .{1e222});
    try print(&quot; (6) = {}\n&quot;, .{3.1415926536});
    try print(&quot; (7) = {}\n&quot;, .{'c'});
    try print(&quot; (8) = {c}\n&quot;, .{'c'});
    try print(&quot; (9) = {s}\n&quot;, .{&quot;abcdef&quot;});
    try print(&quot;(10) = {}, {}\n&quot;, .{ 111, 999 });
    try print(&quot;(11) = {1}, {0}\n&quot;, .{ 111, 999 });
    try print(&quot;(12) = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; });
    try print(&quot;(13) = {0d}, {0b}, {0o}, {0x}, {0X}\n&quot;, .{ 123 });
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
 (1) = 42
 (2) = 23
 (3) = 15
 (4) = 37
 (5) = 1.0e+222
 (6) = 3.1415926536e+00
 (7) = 99
 (8) = c
 (9) = abcdef
(10) = 111, 999
(11) = 999, 111
(12) = abc, 111
(13) = 123, 1111011, 173, 7b, 7B
&lt;/syntaxhighlight&gt;
&lt;!-- リテラルの例、というか、@import(&quot;std&quot;).io.getStdOut().writer().print の例になっていますね。--&gt;
ご覧のように、数値（整数と浮動小数点数）や文字・文字列のリテラルがあり、整数は基数を、浮動小数点数は指数表現と小数表現があります。

@import(&quot;std&quot;).io.getStdOut().writer().printの、第一引数は書式化文字列、第二引数は値リストです。
書式化文字列は、通常の文字列ですが &lt;code&gt;{&lt;/code&gt; と &lt;code&gt;}&lt;/code&gt; で囲まれたプレスホルダーが、引数リストの値（を書式化した文字列）に置換わります。
一番素朴なプレスホルダーは {} で、引数の値の一般的な文字列表記に置換ります（整数なら十進数表記、浮動小数点数なら指数表記）。
ところが、’c’ のような文字型を {} に適用すると文字コード化され整数と同じ十進数表記になってしまいます。そこで、文字型の場合は {c} と文字であることを明記すると文字表現となります。
また、文字列の間合いは {s} を明記しないと（バージョン0.8.0からは）エラーになります。
2つ以上の値を渡す場合は、第二引数を　.{ 1, 2, 3 } の様にカンマ区切りのリストにします（ {} の前の . （点）を忘れがち）。
基本的に、左から順にプレスホルダーにリストの値が左から与えられますが、{0} {1} の書式で参照する引数の順位を明示できます。
書式指定と併用する時は、 &lt;code&gt; print(&quot;? = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; })&lt;/code&gt; の様に順位が先、書式指定文字が後になります。

[TODO:[https://github.com/ziglang/zig/blob/master/lib/std/fmt.zig master/lib/std/fmt.zig]を観て書いています。参照すべき標準ライブラリのドキュメントを発見出来たら、見直し]
[TODO:表組み]

==== comptime ====
Zigでは、コンパイル時に式が既知かどうかという概念を重要視しています。

次のコードを観てみましょう。
:&lt;syntaxhighlight lang=&quot;zig&quot; line highlight=7&gt;
fn mul(x: usize, y: usize) usize {
    return x * y;
}

pub fn main() void {
    const len : usize = mul(3, 4);
    const ary: [len]i32 = undefined;
    _ = ary;
}
&lt;/syntaxhighlight&gt;
;コンパイル結果:&lt;syntaxhighlight lang=text&gt;
An error occurred: 
/tmp/playground130713503/play.zig:7:17: error: unable to evaluate constant expression 
    const ary: [len]i32 = undefined;
&lt;/syntaxhighlight&gt;
: 「定数式が評価できない 」と宣っています。
: [[C++]]であれば、constexprが適用なケースですが、Zigでは次のような解決方法を取ります。

:&lt;syntaxhighlight lang=&quot;zig&quot; line highlight=6&gt;
fn mul(x: usize, y: usize) usize {
    return x * y;
}

pub fn main() void {
    const len : usize = comptime mul(3, 4);
    const ary: [len]i32 = undefined;
    _ = ary;
}
&lt;/syntaxhighlight&gt;
: mul() の呼出しを comptime で修飾しました。comptime は、修飾子式を'''コンパイル時に実行する'''修飾子で、式の中でコンパイル時に未定な値が参照されると、エラーとなります。ここでは、数リテラル同士の商を求めているので、コンパイル時値が確定できます。
: _ = ary は、「定義済だが参照のない変数宣言」をサプレッスするときのイディオムです。

&lt;!--
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const i = 0;
    const string = [_]i32{ 1, 2, 3, 4 };
    for (string) |character, index| {
        std.debug.print(&quot;character: {}, index: {}, :{s} \n&quot;, .{ character, index, @typeName(@TypeOf(character)) });
    }
    _ = i;
}
--&gt;

===== インタプリタ的に実行する場合 =====
コンパイル済みファイルの作成を飛ばして、インタプリタ的に直接に実行する方法もあり、たとえばファイル名「hello.zig」なら下記のようなコマンドある。
 zig run hello.zig


===== プロジェクト作成する場合 =====
まず、プロジェクト関連のコマンドを実行すると、自動で数個のフォルダが作成されるので、それをまとめるためのフォルダを別に作っておき（たとえば proj とする）、べつにマウス右クリックでも mldir コマンドでもなんでもいいので proj ディレクトリを作成しておく。

そして、さらにカレント・ディレクトリを proj に移動するために、ターミナルでコマンド
 cd proj
で、そこに移動する。（そうしないと、今後の動作でホームフォルダにいくつものフォルダやファイルが作成され、管理しづらくなる）

その上で、プロジェクト作成のために
 zig init-exe
を行う。このコマンドにより、初期設定ファイルなどがいくつか自動的に作成される。

== 基礎篇 ==
[TODO:書くべき項目を並べてみましたが、例えば「値と型」を網羅的に書いていくと文章量が爆発するのが目に見えているので、過剰になったらリファレンス篇に移動するなどの方法で、各節はコンパクトさを心がけたいです。]

=== コメント ===
Zigでは、&lt;code&gt;//&lt;/code&gt; から行末までがコメントです。
C言語の &lt;code&gt;/* … */&lt;/code&gt; のスタイルの複数行に渡るコメントは'''ありません'''。
これは、コードの各行を文脈に関係なくトークン化できるようにするためです。
:&lt;syntaxhighlight lang=zig&gt;
// @import は組込み関数です。
const std = @import(&quot;std&quot;); // 先頭に @ が付く関数は組込み関数です
pub fn main() !void {
   try std.io.getStdOut().writeAll(&quot;Hello, World!\n&quot;);
}
&lt;/syntaxhighlight&gt;

==== Docコメント ====
Zigでは、&lt;code&gt;///&lt;/code&gt; から始まるコメントは特別なコメントで、Docコメント( ''Doc comments'' )と呼ばれます。
Docコメントは特定の場所にしか許されません。式の途中や非Docコメントの直前など、予想外の場所にdocコメントがあると、コンパイルエラーになります。

[TODO:サンプルコードと整形結果]

==== トップレベルDocコメント ====
Zigでは、&lt;code&gt;//!&lt;/code&gt; から始まるコメントは特別なコメントで、トップレベルDocコメント( ''Top-Level Doc Comments '' )と呼ばれます。
コンテナレベルのドキュメントのように、直後のドキュメントに属さないユーザードキュメントに、トップレベルDocコメントを使います。

[TODO:サンプルコードと整形結果]

DocコメントおよびトップレベルDocコメントは、コンパイル時に zig build-exe -femit-docs ソースファイル.zig の様に、-femit-docs をあたえると、 docs/ 以下にドキュメントが生成されます。

=== 値と型 ===
[TOD0:整数・浮動小数・論理値・文字列・共用体・構造体・列挙・配列・ベクトル・スライス・ポインター・ゼロビットな型]

:&lt;syntaxhighlight lang=zig&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot; (1) = {}\n&quot;, .{42});
    try print(&quot; (2) = {}\n&quot;, .{0x17});
    try print(&quot; (3) = {}\n&quot;, .{0o17});
    try print(&quot; (4) = {}\n&quot;, .{0b0100101});
    try print(&quot; (5) = {}\n&quot;, .{1e222});
    try print(&quot; (6) = {}\n&quot;, .{3.1415926536});
    try print(&quot; (7) = {}\n&quot;, .{'c'});
    try print(&quot; (8) = {c}\n&quot;, .{'c'});
    try print(&quot; (9) = {s}\n&quot;, .{&quot;abcdef&quot;});
    try print(&quot;(10) = {}, {}\n&quot;, .{ 111, 999 });
    try print(&quot;(11) = {1}, {0}\n&quot;, .{ 111, 999 });
    try print(&quot;(12) = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; });
    try print(&quot;(13) = {0d}, {0b}, {0o}, {0x}, {0X}\n&quot;, .{ 123 });
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
 (1) = 42
 (2) = 23
 (3) = 15
 (4) = 37
 (5) = 1.0e+222
 (6) = 3.1415926536e+00
 (7) = 99
 (8) = c
 (9) = abcdef
(10) = 111, 999
(11) = 999, 111
(12) = abc, 111
(13) = 123, 1111011, 173, 7b, 7B
&lt;/syntaxhighlight&gt;
&lt;!-- リテラルの例、というか、@import(&quot;std&quot;).io.getStdOut().writer().print の例になっていますね。--&gt;
ご覧のように、数値（整数と浮動小数点数）や文字・文字列のリテラルがあり、整数は基数を、浮動小数点数は指数表現と少数表現があります。

@import(&quot;std&quot;).io.getStdOut().writer().printの、第一引数は書式化文字列、第二引数は値リストです。
書式化文字列は、通常の文字列ですが &lt;code&gt;{&lt;/code&gt; と &lt;code&gt;}&lt;/code&gt; で囲まれたプレスホルダーが、引数リストの値（を書式化した文字列）に置換わります。
一番素朴なプレスホルダーは {} で、引数の値の一般的な文字列表記に置換ります（整数なら十進数表記、浮動小数点数なら指数表記）。
ところが、’c’ のような文字型を {} に適用すると文字コード化され整数と同じ十進数表記になってしまいます。そこで、文字型の場合は {c} と文字であることを明記すると文字表現となります。
また、文字列の間合いは {s} を明記しないと（バージョン0.8.0からは）エラーになります。
2つ以上の値を渡す場合は、第二引数を　.{ 1, 2, 3 } の様にカンマ区切りのリストにします（ これが、Zig の配列リテラルの表現で、{} の前の . （点）を忘れがち）。
基本的に、左から順にプレスホルダーにリストの値が左から与えられますが、{0} {1} の書式で参照する引数の順位を明示できます。
書式指定と併用する時は、 &lt;code&gt; print(&quot;? = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; })&lt;/code&gt; の様に順位が先、書式指定文字が後になります。

[TODO:[https://github.com/ziglang/zig/blob/master/lib/std/fmt.zig master/lib/std/fmt.zig]を観て書いています。参照すべき標準ライブラリのドキュメントを発見出来たら、見直し]
[TODO:表組み]

==== comptime ====
Zigでは、コンパイル時に式が既知かどうかという概念を重要視しています。

&lt;!--
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const i = 0;
    const string = [_]i32{ 1, 2, 3, 4 };
    for (string) |character, index| {
        std.debug.print(&quot;character: {}, index: {}, :{s} \n&quot;, .{ character, index, @typeName(@TypeOf(character)) });
    }
    _ = i;
}
--&gt;

=== テスト ===
=== 変数 ===
=== 制御構造 ===
[TODO:Zig の制御構造は文ではなく式]
==== 分岐 ====
[TODO:ifとswitch]
==== 反復 ====
[TODO:whileとfor]
=== 関数 ===
=== エラー ===
=== 演算子 ===
==== 優先順位 ====
高
&lt;syntaxhighlight lang=text line&gt;
 x() x[] x.y x.* x.?
 a!b
 x{}
 !x -x -%x ~x &amp;x ?x
 * / % ** *% *| ||
 + - ++ +% -% +| -|
 &lt;&lt; &gt;&gt; &lt;&lt;|
 &amp; ^ | orelse catch
 == != &lt; &gt; &lt;= &gt;=
 and
 or
 = *= *%= *|= /= %= += +%= +|= -= -%= -|= &lt;&lt;= &lt;&lt;|= &gt;&gt;= &amp;= ^= |=
&lt;/syntaxhighlight&gt;
低

===  optional type ===
===  opaque ===
訳語未定
=== ブロック ===
[TODO:スコープとシャドーイング；deferはここ？]
=== キャスト ===
[TODO:Zig は強い型付け()； 型強制 (Type coercion) について]
=== アセンブリ言語との連携 ===
[TODO:所謂インラインアセンラ]
=== atomic ===
=== 非同期関数 ===
=== 組込み関数 ===
[TODO:組込み関数は、@で始まり、@TypeOfや@alignOfの他@sinや@memcpyも組込み関数]
=== メモリ管理 ===
=== キーワード一覧 ===
&lt;code&gt;align&lt;/code&gt;
&lt;code&gt;allowzero&lt;/code&gt;
&lt;code&gt;and&lt;/code&gt;
&lt;code&gt;anyframe&lt;/code&gt;
&lt;code&gt;anytype&lt;/code&gt;
&lt;code&gt;asm&lt;/code&gt;
&lt;code&gt;async&lt;/code&gt;
&lt;code&gt;await&lt;/code&gt;
&lt;code&gt;break&lt;/code&gt;
&lt;code&gt;catch&lt;/code&gt;
&lt;code&gt;comptime&lt;/code&gt;
&lt;code&gt;const&lt;/code&gt;
&lt;code&gt;continue&lt;/code&gt;
&lt;code&gt;defer&lt;/code&gt;
&lt;code&gt;else&lt;/code&gt;
&lt;code&gt;enum&lt;/code&gt;
&lt;code&gt;errdefer&lt;/code&gt;
&lt;code&gt;error&lt;/code&gt;
&lt;code&gt;export&lt;/code&gt;
&lt;code&gt;extern&lt;/code&gt;
&lt;code&gt;fn&lt;/code&gt;
&lt;code&gt;for&lt;/code&gt;
&lt;code&gt;if&lt;/code&gt;
&lt;code&gt;inline&lt;/code&gt;
&lt;code&gt;noalias&lt;/code&gt;
&lt;code&gt;nosuspend&lt;/code&gt;
&lt;code&gt;or&lt;/code&gt;
&lt;code&gt;orelse&lt;/code&gt;
&lt;code&gt;packed&lt;/code&gt;
&lt;code&gt;pub&lt;/code&gt;
&lt;code&gt;resume&lt;/code&gt;
&lt;code&gt;return&lt;/code&gt;
&lt;code&gt;linksection&lt;/code&gt;
&lt;code&gt;struct&lt;/code&gt;
&lt;code&gt;suspend&lt;/code&gt;
&lt;code&gt;switch&lt;/code&gt;
&lt;code&gt;test&lt;/code&gt;
&lt;code&gt;threadlocal&lt;/code&gt;
&lt;code&gt;try&lt;/code&gt;
&lt;code&gt;union&lt;/code&gt;
&lt;code&gt;unreachable&lt;/code&gt;
&lt;code&gt;usingnamespace&lt;/code&gt;
&lt;code&gt;var&lt;/code&gt;
&lt;code&gt;volatile&lt;/code&gt;
&lt;code&gt;while&lt;/code&gt;

== チートシート ==
[TODO:文法と型と頻用する標準ライブラリの関数と型のアンチョコ]

== リファレンス篇 ==

== 脚註 ==
&lt;references /&gt;

== 外部リンク ==
* [https://ziglang.org/ Home ⚡ Zig Programming Language] {{---}} 公式サイト
** [[https://ziglang.org/documentation/master/ Zig Language Reference]] {{---}} リファレンスマニュアル
* [https://github.com/ziglang/zig ziglang/zig: General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.] {{---}} 公式リポジトリ
* [https://zig-play.dev/ Zig Playground] {{---}} オンライン実行環境
** [https://github.com/gsquire/zig-play About An online Zig compiler inspired by Go and Rust] {{---}} リポジトリ

[[Category:zig|*]]
[[Category:プログラミング言語]]</text>
      <sha1>t0739tgz9x9nrnovwqw8q7u97tzpdj9</sha1>
    </revision>
    <revision>
      <id>205764</id>
      <parentid>205763</parentid>
      <timestamp>2022-07-24T06:41:10Z</timestamp>
      <contributor>
        <username>すじにくシチュー</username>
        <id>12058</id>
      </contributor>
      <comment>/* comptime */</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="21622" xml:space="preserve">{{Pathnav|メインページ|工学|情報技術|プログラミング|frame=1}}
{{Wikipedia|Zig (プログラミング言語)}}
本書は、[[w:Zig|Zig]]のチュートリアルです。
Zigは、堅牢で最適かつ再利用可能なソフトウェアを維持するための汎用プログラミング言語およびツールチェインです&lt;ref&gt;{{Cite web
|url=https://ziglang.org/
|title=Home ⚡ Zig Programming Language
|website=ziglang.org
|accessdate=2022-07-17
|cite=Zig is a general-purpose programming language and toolchain for maintaining '''robust''', '''optimal''' and '''reusable''' software.
}}&lt;/ref&gt;。
Zigは、アンドリュー・ケリー( ''[https://andrewkelley.me/ Andrew Kelley]'' )によって設計され、汎用システムプログラミング言語で、静的で強い型付けで型推論とジェネリックプログラミングをサポートします。

== 概要 ==
Zigは、2016年2月に発表された比較的若いプログラミング言語で&lt;ref&gt;{{Cite web
|last1=Kelley
|first1=Andrew
|title=Introduction to the Zig Programming Language
|url=https://andrewkelley.me/post/intro-to-zig.html
|website=andrewkelley.me
|accessdate=2022-07-17
}}&lt;/ref&gt;、2022年7月現在のバージョンは 0.9.1 で、'''''pre-release''''' と位置づけられています&lt;ref&gt;{{Cite web
|url=https://github.com/ziglang/zig/releases
|title=Releases · ziglang/zig
|website=github.com
|accessdate=2022-07-17
}}&lt;/ref&gt;。このため [[W:Hello world|Hello world]] ですら、バージョン間で互換性がなくなることもあり、リリースバージョンまでは言語仕様やライブラリーおよびツールチェインの仕様が変更される可能性があります。

=== Hello world の変遷 ===
[https://ziglang.org/documentation/master/ Zig Language Reference]の、[[W:Hello world|Hello world]]の変遷（新しい順）。

;master@2022-07-17&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/master/#Hello-World
|title=Zig Documentation(master@2022-07-17)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.8.1に同じ
;0.9.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.9.1/#Hello-World
|title=Zig Documentation(0.9.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.8.1に同じ
;0.8.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.8.1/#Hello-World
|title=Zig Documentation(0.8.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=4&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().writer();
    try stdout.print(&quot;Hello, {s}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: &lt;code&gt;{}&lt;/code&gt; ⇒ &lt;code&gt;{s}&lt;/code&gt;&lt;ref&gt;{{Cite web
|url=https://ziglang.org/download/0.8.0/release-notes.html#Formatted-Printing
|title=0.8.0 Release Notes
|website=ziglang.org
|accessdate=2022-07-17
|quote=Disable the special casing of {} for u8 slices/arrays. Unless {s} is specified the contents won't be treated as a string.
}}&lt;/ref&gt;
;0.7.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.7.1/#Hello-World
|title=Zig Documentation(0.7.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=3&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().writer();
    try stdout.print(&quot;Hello, {}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: s/outStream/writer/
;0.6.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.6.0/#Hello-World
|title=Zig Documentation(0.6.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=3&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().outStream();
    try stdout.print(&quot;Hello, {}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: 初期化の初期値から &lt;code&gt;try&lt;/code&gt; がなくなった。
;0.4.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.4.0/#Hello-World
|title=Zig Documentation(0.4.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.2.0に同じ
;0.5.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.5.0/#Hello-World
|title=Zig Documentation(0.5.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=4&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    // If this program is run without stdout attached, exit with an error.
    const stdout_file = try std.io.getStdOut();
    // If this program encounters pipe failure when printing to stdout, exit
    // with an error.
    try stdout_file.write(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;
: &lt;var&gt;stdout_file&lt;/var&gt; が &lt;code&gt;var&lt;/code&gt; から &lt;code&gt;const&lt;/code&gt; に変更された。

;0.3.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.3.0/#Hello-World
|title=Zig Documentation(0.3.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.2.0に同じ
;0.2.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.2.0/#Hello-World
|title=Zig Documentation(0.2.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    // If this program is run without stdout attached, exit with an error.
    var stdout_file = try std.io.getStdOut();
    // If this program encounters pipe failure when printing to stdout, exit
    // with an error.
    try stdout_file.write(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;
;0.1.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.1.1/#hello-world
|title=Zig Documentation
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig&gt;
const io = @import(&quot;std&quot;).io;
pub fn main() -&gt; %void {
    %%io.stdout.printf(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;

== 環境準備 ==
=== Linuxの場合 ===
==== インストール方法 ====
Fedora 36 の場合、2022年の時点で、コマンド
 sudo dnf install zig
だけでインストールできる事を確認。

その他のOS環境でのインストールについては、[https://github.com/ziglang/zig/wiki/Install-Zig-from-a-Package-Manager  GitHub  &quot;ziglang /zig&quot; ] を参照せよ。

インストールできたと思ったら、バージョン確認コマンドなどで、インストールの成否を確認しよう。コマンド
 zig version
で確認できる。

なお、2022年7月現在、まだバージョンは1未満であり、同7月に実験したところ
 0.9.1
であった。上記のセクションでも掛かれているように2022年の段階ではまだプレリリースであるので、1未満でもインストール成功なので安心していい。

==== コードの実行方法 ====
=== 値と型 ===
[TOD0:整数・浮動小数・論理値・文字列・共用体・構造体・列挙・配列・ベクトル・スライス・ポインター・ゼロビットな型]

:&lt;syntaxhighlight lang=&quot;zig&quot;&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot;abcd \n&quot;, .{} );
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
abcd 
&lt;/syntaxhighlight&gt;

2022年7月現在、引用符中に変数をなにも使っていなくても、&lt;code&gt;.{}&lt;/code&gt;が必要である。ほか&lt;code&gt;try print&lt;/code&gt; の &lt;code&gt;try&lt;/code&gt; については、&lt;code&gt;try&lt;/code&gt;がないとエラーになる。

:&lt;syntaxhighlight lang=&quot;zig&quot;&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot; (1) = {}\n&quot;, .{42});
    try print(&quot; (2) = {}\n&quot;, .{0x17});
    try print(&quot; (3) = {}\n&quot;, .{0o17});
    try print(&quot; (4) = {}\n&quot;, .{0b0100101});
    try print(&quot; (5) = {}\n&quot;, .{1e222});
    try print(&quot; (6) = {}\n&quot;, .{3.1415926536});
    try print(&quot; (7) = {}\n&quot;, .{'c'});
    try print(&quot; (8) = {c}\n&quot;, .{'c'});
    try print(&quot; (9) = {s}\n&quot;, .{&quot;abcdef&quot;});
    try print(&quot;(10) = {}, {}\n&quot;, .{ 111, 999 });
    try print(&quot;(11) = {1}, {0}\n&quot;, .{ 111, 999 });
    try print(&quot;(12) = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; });
    try print(&quot;(13) = {0d}, {0b}, {0o}, {0x}, {0X}\n&quot;, .{ 123 });
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
 (1) = 42
 (2) = 23
 (3) = 15
 (4) = 37
 (5) = 1.0e+222
 (6) = 3.1415926536e+00
 (7) = 99
 (8) = c
 (9) = abcdef
(10) = 111, 999
(11) = 999, 111
(12) = abc, 111
(13) = 123, 1111011, 173, 7b, 7B
&lt;/syntaxhighlight&gt;
&lt;!-- リテラルの例、というか、@import(&quot;std&quot;).io.getStdOut().writer().print の例になっていますね。--&gt;
ご覧のように、数値（整数と浮動小数点数）や文字・文字列のリテラルがあり、整数は基数を、浮動小数点数は指数表現と小数表現があります。

@import(&quot;std&quot;).io.getStdOut().writer().printの、第一引数は書式化文字列、第二引数は値リストです。
書式化文字列は、通常の文字列ですが &lt;code&gt;{&lt;/code&gt; と &lt;code&gt;}&lt;/code&gt; で囲まれたプレスホルダーが、引数リストの値（を書式化した文字列）に置換わります。
一番素朴なプレスホルダーは {} で、引数の値の一般的な文字列表記に置換ります（整数なら十進数表記、浮動小数点数なら指数表記）。
ところが、’c’ のような文字型を {} に適用すると文字コード化され整数と同じ十進数表記になってしまいます。そこで、文字型の場合は {c} と文字であることを明記すると文字表現となります。
また、文字列の間合いは {s} を明記しないと（バージョン0.8.0からは）エラーになります。
2つ以上の値を渡す場合は、第二引数を　.{ 1, 2, 3 } の様にカンマ区切りのリストにします（ {} の前の . （点）を忘れがち）。
基本的に、左から順にプレスホルダーにリストの値が左から与えられますが、{0} {1} の書式で参照する引数の順位を明示できます。
書式指定と併用する時は、 &lt;code&gt; print(&quot;? = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; })&lt;/code&gt; の様に順位が先、書式指定文字が後になります。

[TODO:[https://github.com/ziglang/zig/blob/master/lib/std/fmt.zig master/lib/std/fmt.zig]を観て書いています。参照すべき標準ライブラリのドキュメントを発見出来たら、見直し]
[TODO:表組み]

==== comptime ====
Zigでは、コンパイル時に式が既知かどうかという概念を重要視しています。

下記コードはコンパイル等がエラーになります。
:&lt;syntaxhighlight lang=&quot;zig&quot; line highlight=7&gt;
fn mul(x: usize, y: usize) usize {
    return x * y;
}

pub fn main() void {
    const len : usize = mul(3, 4);
    const ary: [len]i32 = undefined;
    _ = ary;
}
&lt;/syntaxhighlight&gt;
;コンパイル結果:&lt;syntaxhighlight lang=text&gt;
An error occurred: 
/tmp/playground130713503/play.zig:7:17: error: unable to evaluate constant expression 
    const ary: [len]i32 = undefined;
&lt;/syntaxhighlight&gt;
: 「定数式が評価できない 」と宣っています。
: [[C++]]であれば、constexprが適用なケースですが、Zigでは次のような解決方法を取ります。下記コードはエラーになりません。

:&lt;syntaxhighlight lang=&quot;zig&quot; line highlight=6&gt;
fn mul(x: usize, y: usize) usize {
    return x * y;
}

pub fn main() void {
    const len : usize = comptime mul(3, 4);
    const ary: [len]i32 = undefined;
    _ = ary;
}
&lt;/syntaxhighlight&gt;
: mul() の呼出しを comptime で修飾しました。comptime は、修飾子式を'''コンパイル時に実行する'''修飾子で、式の中でコンパイル時に未定な値が参照されると、エラーとなります。ここでは、数リテラル同士の商を求めているので、コンパイル時値が確定できます。
: _ = ary は、「定義済だが参照のない変数宣言」をサプレッスするときのイディオムです。

&lt;!--
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const i = 0;
    const string = [_]i32{ 1, 2, 3, 4 };
    for (string) |character, index| {
        std.debug.print(&quot;character: {}, index: {}, :{s} \n&quot;, .{ character, index, @typeName(@TypeOf(character)) });
    }
    _ = i;
}
--&gt;

===== インタプリタ的に実行する場合 =====
コンパイル済みファイルの作成を飛ばして、インタプリタ的に直接に実行する方法もあり、たとえばファイル名「hello.zig」なら下記のようなコマンドある。
 zig run hello.zig


===== プロジェクト作成する場合 =====
まず、プロジェクト関連のコマンドを実行すると、自動で数個のフォルダが作成されるので、それをまとめるためのフォルダを別に作っておき（たとえば proj とする）、べつにマウス右クリックでも mldir コマンドでもなんでもいいので proj ディレクトリを作成しておく。

そして、さらにカレント・ディレクトリを proj に移動するために、ターミナルでコマンド
 cd proj
で、そこに移動する。（そうしないと、今後の動作でホームフォルダにいくつものフォルダやファイルが作成され、管理しづらくなる）

その上で、プロジェクト作成のために
 zig init-exe
を行う。このコマンドにより、初期設定ファイルなどがいくつか自動的に作成される。

== 基礎篇 ==
[TODO:書くべき項目を並べてみましたが、例えば「値と型」を網羅的に書いていくと文章量が爆発するのが目に見えているので、過剰になったらリファレンス篇に移動するなどの方法で、各節はコンパクトさを心がけたいです。]

=== コメント ===
Zigでは、&lt;code&gt;//&lt;/code&gt; から行末までがコメントです。
C言語の &lt;code&gt;/* … */&lt;/code&gt; のスタイルの複数行に渡るコメントは'''ありません'''。
これは、コードの各行を文脈に関係なくトークン化できるようにするためです。
:&lt;syntaxhighlight lang=zig&gt;
// @import は組込み関数です。
const std = @import(&quot;std&quot;); // 先頭に @ が付く関数は組込み関数です
pub fn main() !void {
   try std.io.getStdOut().writeAll(&quot;Hello, World!\n&quot;);
}
&lt;/syntaxhighlight&gt;

==== Docコメント ====
Zigでは、&lt;code&gt;///&lt;/code&gt; から始まるコメントは特別なコメントで、Docコメント( ''Doc comments'' )と呼ばれます。
Docコメントは特定の場所にしか許されません。式の途中や非Docコメントの直前など、予想外の場所にdocコメントがあると、コンパイルエラーになります。

[TODO:サンプルコードと整形結果]

==== トップレベルDocコメント ====
Zigでは、&lt;code&gt;//!&lt;/code&gt; から始まるコメントは特別なコメントで、トップレベルDocコメント( ''Top-Level Doc Comments '' )と呼ばれます。
コンテナレベルのドキュメントのように、直後のドキュメントに属さないユーザードキュメントに、トップレベルDocコメントを使います。

[TODO:サンプルコードと整形結果]

DocコメントおよびトップレベルDocコメントは、コンパイル時に zig build-exe -femit-docs ソースファイル.zig の様に、-femit-docs をあたえると、 docs/ 以下にドキュメントが生成されます。

=== 値と型 ===
[TOD0:整数・浮動小数・論理値・文字列・共用体・構造体・列挙・配列・ベクトル・スライス・ポインター・ゼロビットな型]

:&lt;syntaxhighlight lang=zig&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot; (1) = {}\n&quot;, .{42});
    try print(&quot; (2) = {}\n&quot;, .{0x17});
    try print(&quot; (3) = {}\n&quot;, .{0o17});
    try print(&quot; (4) = {}\n&quot;, .{0b0100101});
    try print(&quot; (5) = {}\n&quot;, .{1e222});
    try print(&quot; (6) = {}\n&quot;, .{3.1415926536});
    try print(&quot; (7) = {}\n&quot;, .{'c'});
    try print(&quot; (8) = {c}\n&quot;, .{'c'});
    try print(&quot; (9) = {s}\n&quot;, .{&quot;abcdef&quot;});
    try print(&quot;(10) = {}, {}\n&quot;, .{ 111, 999 });
    try print(&quot;(11) = {1}, {0}\n&quot;, .{ 111, 999 });
    try print(&quot;(12) = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; });
    try print(&quot;(13) = {0d}, {0b}, {0o}, {0x}, {0X}\n&quot;, .{ 123 });
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
 (1) = 42
 (2) = 23
 (3) = 15
 (4) = 37
 (5) = 1.0e+222
 (6) = 3.1415926536e+00
 (7) = 99
 (8) = c
 (9) = abcdef
(10) = 111, 999
(11) = 999, 111
(12) = abc, 111
(13) = 123, 1111011, 173, 7b, 7B
&lt;/syntaxhighlight&gt;
&lt;!-- リテラルの例、というか、@import(&quot;std&quot;).io.getStdOut().writer().print の例になっていますね。--&gt;
ご覧のように、数値（整数と浮動小数点数）や文字・文字列のリテラルがあり、整数は基数を、浮動小数点数は指数表現と少数表現があります。

@import(&quot;std&quot;).io.getStdOut().writer().printの、第一引数は書式化文字列、第二引数は値リストです。
書式化文字列は、通常の文字列ですが &lt;code&gt;{&lt;/code&gt; と &lt;code&gt;}&lt;/code&gt; で囲まれたプレスホルダーが、引数リストの値（を書式化した文字列）に置換わります。
一番素朴なプレスホルダーは {} で、引数の値の一般的な文字列表記に置換ります（整数なら十進数表記、浮動小数点数なら指数表記）。
ところが、’c’ のような文字型を {} に適用すると文字コード化され整数と同じ十進数表記になってしまいます。そこで、文字型の場合は {c} と文字であることを明記すると文字表現となります。
また、文字列の間合いは {s} を明記しないと（バージョン0.8.0からは）エラーになります。
2つ以上の値を渡す場合は、第二引数を　.{ 1, 2, 3 } の様にカンマ区切りのリストにします（ これが、Zig の配列リテラルの表現で、{} の前の . （点）を忘れがち）。
基本的に、左から順にプレスホルダーにリストの値が左から与えられますが、{0} {1} の書式で参照する引数の順位を明示できます。
書式指定と併用する時は、 &lt;code&gt; print(&quot;? = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; })&lt;/code&gt; の様に順位が先、書式指定文字が後になります。

[TODO:[https://github.com/ziglang/zig/blob/master/lib/std/fmt.zig master/lib/std/fmt.zig]を観て書いています。参照すべき標準ライブラリのドキュメントを発見出来たら、見直し]
[TODO:表組み]

==== comptime ====
Zigでは、コンパイル時に式が既知かどうかという概念を重要視しています。

&lt;!--
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const i = 0;
    const string = [_]i32{ 1, 2, 3, 4 };
    for (string) |character, index| {
        std.debug.print(&quot;character: {}, index: {}, :{s} \n&quot;, .{ character, index, @typeName(@TypeOf(character)) });
    }
    _ = i;
}
--&gt;

=== テスト ===
=== 変数 ===
=== 制御構造 ===
[TODO:Zig の制御構造は文ではなく式]
==== 分岐 ====
[TODO:ifとswitch]
==== 反復 ====
[TODO:whileとfor]
=== 関数 ===
=== エラー ===
=== 演算子 ===
==== 優先順位 ====
高
&lt;syntaxhighlight lang=text line&gt;
 x() x[] x.y x.* x.?
 a!b
 x{}
 !x -x -%x ~x &amp;x ?x
 * / % ** *% *| ||
 + - ++ +% -% +| -|
 &lt;&lt; &gt;&gt; &lt;&lt;|
 &amp; ^ | orelse catch
 == != &lt; &gt; &lt;= &gt;=
 and
 or
 = *= *%= *|= /= %= += +%= +|= -= -%= -|= &lt;&lt;= &lt;&lt;|= &gt;&gt;= &amp;= ^= |=
&lt;/syntaxhighlight&gt;
低

===  optional type ===
===  opaque ===
訳語未定
=== ブロック ===
[TODO:スコープとシャドーイング；deferはここ？]
=== キャスト ===
[TODO:Zig は強い型付け()； 型強制 (Type coercion) について]
=== アセンブリ言語との連携 ===
[TODO:所謂インラインアセンラ]
=== atomic ===
=== 非同期関数 ===
=== 組込み関数 ===
[TODO:組込み関数は、@で始まり、@TypeOfや@alignOfの他@sinや@memcpyも組込み関数]
=== メモリ管理 ===
=== キーワード一覧 ===
&lt;code&gt;align&lt;/code&gt;
&lt;code&gt;allowzero&lt;/code&gt;
&lt;code&gt;and&lt;/code&gt;
&lt;code&gt;anyframe&lt;/code&gt;
&lt;code&gt;anytype&lt;/code&gt;
&lt;code&gt;asm&lt;/code&gt;
&lt;code&gt;async&lt;/code&gt;
&lt;code&gt;await&lt;/code&gt;
&lt;code&gt;break&lt;/code&gt;
&lt;code&gt;catch&lt;/code&gt;
&lt;code&gt;comptime&lt;/code&gt;
&lt;code&gt;const&lt;/code&gt;
&lt;code&gt;continue&lt;/code&gt;
&lt;code&gt;defer&lt;/code&gt;
&lt;code&gt;else&lt;/code&gt;
&lt;code&gt;enum&lt;/code&gt;
&lt;code&gt;errdefer&lt;/code&gt;
&lt;code&gt;error&lt;/code&gt;
&lt;code&gt;export&lt;/code&gt;
&lt;code&gt;extern&lt;/code&gt;
&lt;code&gt;fn&lt;/code&gt;
&lt;code&gt;for&lt;/code&gt;
&lt;code&gt;if&lt;/code&gt;
&lt;code&gt;inline&lt;/code&gt;
&lt;code&gt;noalias&lt;/code&gt;
&lt;code&gt;nosuspend&lt;/code&gt;
&lt;code&gt;or&lt;/code&gt;
&lt;code&gt;orelse&lt;/code&gt;
&lt;code&gt;packed&lt;/code&gt;
&lt;code&gt;pub&lt;/code&gt;
&lt;code&gt;resume&lt;/code&gt;
&lt;code&gt;return&lt;/code&gt;
&lt;code&gt;linksection&lt;/code&gt;
&lt;code&gt;struct&lt;/code&gt;
&lt;code&gt;suspend&lt;/code&gt;
&lt;code&gt;switch&lt;/code&gt;
&lt;code&gt;test&lt;/code&gt;
&lt;code&gt;threadlocal&lt;/code&gt;
&lt;code&gt;try&lt;/code&gt;
&lt;code&gt;union&lt;/code&gt;
&lt;code&gt;unreachable&lt;/code&gt;
&lt;code&gt;usingnamespace&lt;/code&gt;
&lt;code&gt;var&lt;/code&gt;
&lt;code&gt;volatile&lt;/code&gt;
&lt;code&gt;while&lt;/code&gt;

== チートシート ==
[TODO:文法と型と頻用する標準ライブラリの関数と型のアンチョコ]

== リファレンス篇 ==

== 脚註 ==
&lt;references /&gt;

== 外部リンク ==
* [https://ziglang.org/ Home ⚡ Zig Programming Language] {{---}} 公式サイト
** [[https://ziglang.org/documentation/master/ Zig Language Reference]] {{---}} リファレンスマニュアル
* [https://github.com/ziglang/zig ziglang/zig: General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.] {{---}} 公式リポジトリ
* [https://zig-play.dev/ Zig Playground] {{---}} オンライン実行環境
** [https://github.com/gsquire/zig-play About An online Zig compiler inspired by Go and Rust] {{---}} リポジトリ

[[Category:zig|*]]
[[Category:プログラミング言語]]</text>
      <sha1>ja59rkh2gtfcdq7lhyvv9omuu89933d</sha1>
    </revision>
    <revision>
      <id>205765</id>
      <parentid>205764</parentid>
      <timestamp>2022-07-24T06:44:02Z</timestamp>
      <contributor>
        <username>すじにくシチュー</username>
        <id>12058</id>
      </contributor>
      <comment>/* comptime */ // mul の前に comptime を追加</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="21659" xml:space="preserve">{{Pathnav|メインページ|工学|情報技術|プログラミング|frame=1}}
{{Wikipedia|Zig (プログラミング言語)}}
本書は、[[w:Zig|Zig]]のチュートリアルです。
Zigは、堅牢で最適かつ再利用可能なソフトウェアを維持するための汎用プログラミング言語およびツールチェインです&lt;ref&gt;{{Cite web
|url=https://ziglang.org/
|title=Home ⚡ Zig Programming Language
|website=ziglang.org
|accessdate=2022-07-17
|cite=Zig is a general-purpose programming language and toolchain for maintaining '''robust''', '''optimal''' and '''reusable''' software.
}}&lt;/ref&gt;。
Zigは、アンドリュー・ケリー( ''[https://andrewkelley.me/ Andrew Kelley]'' )によって設計され、汎用システムプログラミング言語で、静的で強い型付けで型推論とジェネリックプログラミングをサポートします。

== 概要 ==
Zigは、2016年2月に発表された比較的若いプログラミング言語で&lt;ref&gt;{{Cite web
|last1=Kelley
|first1=Andrew
|title=Introduction to the Zig Programming Language
|url=https://andrewkelley.me/post/intro-to-zig.html
|website=andrewkelley.me
|accessdate=2022-07-17
}}&lt;/ref&gt;、2022年7月現在のバージョンは 0.9.1 で、'''''pre-release''''' と位置づけられています&lt;ref&gt;{{Cite web
|url=https://github.com/ziglang/zig/releases
|title=Releases · ziglang/zig
|website=github.com
|accessdate=2022-07-17
}}&lt;/ref&gt;。このため [[W:Hello world|Hello world]] ですら、バージョン間で互換性がなくなることもあり、リリースバージョンまでは言語仕様やライブラリーおよびツールチェインの仕様が変更される可能性があります。

=== Hello world の変遷 ===
[https://ziglang.org/documentation/master/ Zig Language Reference]の、[[W:Hello world|Hello world]]の変遷（新しい順）。

;master@2022-07-17&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/master/#Hello-World
|title=Zig Documentation(master@2022-07-17)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.8.1に同じ
;0.9.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.9.1/#Hello-World
|title=Zig Documentation(0.9.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.8.1に同じ
;0.8.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.8.1/#Hello-World
|title=Zig Documentation(0.8.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=4&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().writer();
    try stdout.print(&quot;Hello, {s}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: &lt;code&gt;{}&lt;/code&gt; ⇒ &lt;code&gt;{s}&lt;/code&gt;&lt;ref&gt;{{Cite web
|url=https://ziglang.org/download/0.8.0/release-notes.html#Formatted-Printing
|title=0.8.0 Release Notes
|website=ziglang.org
|accessdate=2022-07-17
|quote=Disable the special casing of {} for u8 slices/arrays. Unless {s} is specified the contents won't be treated as a string.
}}&lt;/ref&gt;
;0.7.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.7.1/#Hello-World
|title=Zig Documentation(0.7.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=3&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().writer();
    try stdout.print(&quot;Hello, {}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: s/outStream/writer/
;0.6.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.6.0/#Hello-World
|title=Zig Documentation(0.6.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=3&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().outStream();
    try stdout.print(&quot;Hello, {}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: 初期化の初期値から &lt;code&gt;try&lt;/code&gt; がなくなった。
;0.4.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.4.0/#Hello-World
|title=Zig Documentation(0.4.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.2.0に同じ
;0.5.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.5.0/#Hello-World
|title=Zig Documentation(0.5.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=4&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    // If this program is run without stdout attached, exit with an error.
    const stdout_file = try std.io.getStdOut();
    // If this program encounters pipe failure when printing to stdout, exit
    // with an error.
    try stdout_file.write(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;
: &lt;var&gt;stdout_file&lt;/var&gt; が &lt;code&gt;var&lt;/code&gt; から &lt;code&gt;const&lt;/code&gt; に変更された。

;0.3.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.3.0/#Hello-World
|title=Zig Documentation(0.3.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.2.0に同じ
;0.2.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.2.0/#Hello-World
|title=Zig Documentation(0.2.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    // If this program is run without stdout attached, exit with an error.
    var stdout_file = try std.io.getStdOut();
    // If this program encounters pipe failure when printing to stdout, exit
    // with an error.
    try stdout_file.write(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;
;0.1.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.1.1/#hello-world
|title=Zig Documentation
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig&gt;
const io = @import(&quot;std&quot;).io;
pub fn main() -&gt; %void {
    %%io.stdout.printf(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;

== 環境準備 ==
=== Linuxの場合 ===
==== インストール方法 ====
Fedora 36 の場合、2022年の時点で、コマンド
 sudo dnf install zig
だけでインストールできる事を確認。

その他のOS環境でのインストールについては、[https://github.com/ziglang/zig/wiki/Install-Zig-from-a-Package-Manager  GitHub  &quot;ziglang /zig&quot; ] を参照せよ。

インストールできたと思ったら、バージョン確認コマンドなどで、インストールの成否を確認しよう。コマンド
 zig version
で確認できる。

なお、2022年7月現在、まだバージョンは1未満であり、同7月に実験したところ
 0.9.1
であった。上記のセクションでも掛かれているように2022年の段階ではまだプレリリースであるので、1未満でもインストール成功なので安心していい。

==== コードの実行方法 ====
=== 値と型 ===
[TOD0:整数・浮動小数・論理値・文字列・共用体・構造体・列挙・配列・ベクトル・スライス・ポインター・ゼロビットな型]

:&lt;syntaxhighlight lang=&quot;zig&quot;&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot;abcd \n&quot;, .{} );
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
abcd 
&lt;/syntaxhighlight&gt;

2022年7月現在、引用符中に変数をなにも使っていなくても、&lt;code&gt;.{}&lt;/code&gt;が必要である。ほか&lt;code&gt;try print&lt;/code&gt; の &lt;code&gt;try&lt;/code&gt; については、&lt;code&gt;try&lt;/code&gt;がないとエラーになる。

:&lt;syntaxhighlight lang=&quot;zig&quot;&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot; (1) = {}\n&quot;, .{42});
    try print(&quot; (2) = {}\n&quot;, .{0x17});
    try print(&quot; (3) = {}\n&quot;, .{0o17});
    try print(&quot; (4) = {}\n&quot;, .{0b0100101});
    try print(&quot; (5) = {}\n&quot;, .{1e222});
    try print(&quot; (6) = {}\n&quot;, .{3.1415926536});
    try print(&quot; (7) = {}\n&quot;, .{'c'});
    try print(&quot; (8) = {c}\n&quot;, .{'c'});
    try print(&quot; (9) = {s}\n&quot;, .{&quot;abcdef&quot;});
    try print(&quot;(10) = {}, {}\n&quot;, .{ 111, 999 });
    try print(&quot;(11) = {1}, {0}\n&quot;, .{ 111, 999 });
    try print(&quot;(12) = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; });
    try print(&quot;(13) = {0d}, {0b}, {0o}, {0x}, {0X}\n&quot;, .{ 123 });
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
 (1) = 42
 (2) = 23
 (3) = 15
 (4) = 37
 (5) = 1.0e+222
 (6) = 3.1415926536e+00
 (7) = 99
 (8) = c
 (9) = abcdef
(10) = 111, 999
(11) = 999, 111
(12) = abc, 111
(13) = 123, 1111011, 173, 7b, 7B
&lt;/syntaxhighlight&gt;
&lt;!-- リテラルの例、というか、@import(&quot;std&quot;).io.getStdOut().writer().print の例になっていますね。--&gt;
ご覧のように、数値（整数と浮動小数点数）や文字・文字列のリテラルがあり、整数は基数を、浮動小数点数は指数表現と小数表現があります。

@import(&quot;std&quot;).io.getStdOut().writer().printの、第一引数は書式化文字列、第二引数は値リストです。
書式化文字列は、通常の文字列ですが &lt;code&gt;{&lt;/code&gt; と &lt;code&gt;}&lt;/code&gt; で囲まれたプレスホルダーが、引数リストの値（を書式化した文字列）に置換わります。
一番素朴なプレスホルダーは {} で、引数の値の一般的な文字列表記に置換ります（整数なら十進数表記、浮動小数点数なら指数表記）。
ところが、’c’ のような文字型を {} に適用すると文字コード化され整数と同じ十進数表記になってしまいます。そこで、文字型の場合は {c} と文字であることを明記すると文字表現となります。
また、文字列の間合いは {s} を明記しないと（バージョン0.8.0からは）エラーになります。
2つ以上の値を渡す場合は、第二引数を　.{ 1, 2, 3 } の様にカンマ区切りのリストにします（ {} の前の . （点）を忘れがち）。
基本的に、左から順にプレスホルダーにリストの値が左から与えられますが、{0} {1} の書式で参照する引数の順位を明示できます。
書式指定と併用する時は、 &lt;code&gt; print(&quot;? = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; })&lt;/code&gt; の様に順位が先、書式指定文字が後になります。

[TODO:[https://github.com/ziglang/zig/blob/master/lib/std/fmt.zig master/lib/std/fmt.zig]を観て書いています。参照すべき標準ライブラリのドキュメントを発見出来たら、見直し]
[TODO:表組み]

==== comptime ====
Zigでは、コンパイル時に式が既知かどうかという概念を重要視しています。

下記コードはコンパイル等がエラーになります。
:&lt;syntaxhighlight lang=&quot;zig&quot; line highlight=7&gt;
fn mul(x: usize, y: usize) usize {
    return x * y;
}

pub fn main() void {
    const len : usize = mul(3, 4);
    const ary: [len]i32 = undefined;
    _ = ary;
}
&lt;/syntaxhighlight&gt;
;コンパイル結果:&lt;syntaxhighlight lang=text&gt;
An error occurred: 
/tmp/playground130713503/play.zig:7:17: error: unable to evaluate constant expression 
    const ary: [len]i32 = undefined;
&lt;/syntaxhighlight&gt;
: 「定数式が評価できない 」と宣っています。
: [[C++]]であれば、constexprが適用なケースですが、Zigでは次のような解決方法を取ります。下記コードはエラーになりません。

:&lt;syntaxhighlight lang=&quot;zig&quot; line highlight=6&gt;
fn mul(x: usize, y: usize) usize {
    return x * y;
}

pub fn main() void {
    const len : usize = comptime mul(3, 4); // mul の前に comptime を追加 
    const ary: [len]i32 = undefined;
    _ = ary;
}
&lt;/syntaxhighlight&gt;
: mul() の呼出しを comptime で修飾しました。comptime は、修飾子式を'''コンパイル時に実行する'''修飾子で、式の中でコンパイル時に未定な値が参照されると、エラーとなります。ここでは、数リテラル同士の商を求めているので、コンパイル時値が確定できます。
: _ = ary は、「定義済だが参照のない変数宣言」をサプレッスするときのイディオムです。

&lt;!--
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const i = 0;
    const string = [_]i32{ 1, 2, 3, 4 };
    for (string) |character, index| {
        std.debug.print(&quot;character: {}, index: {}, :{s} \n&quot;, .{ character, index, @typeName(@TypeOf(character)) });
    }
    _ = i;
}
--&gt;

===== インタプリタ的に実行する場合 =====
コンパイル済みファイルの作成を飛ばして、インタプリタ的に直接に実行する方法もあり、たとえばファイル名「hello.zig」なら下記のようなコマンドある。
 zig run hello.zig


===== プロジェクト作成する場合 =====
まず、プロジェクト関連のコマンドを実行すると、自動で数個のフォルダが作成されるので、それをまとめるためのフォルダを別に作っておき（たとえば proj とする）、べつにマウス右クリックでも mldir コマンドでもなんでもいいので proj ディレクトリを作成しておく。

そして、さらにカレント・ディレクトリを proj に移動するために、ターミナルでコマンド
 cd proj
で、そこに移動する。（そうしないと、今後の動作でホームフォルダにいくつものフォルダやファイルが作成され、管理しづらくなる）

その上で、プロジェクト作成のために
 zig init-exe
を行う。このコマンドにより、初期設定ファイルなどがいくつか自動的に作成される。

== 基礎篇 ==
[TODO:書くべき項目を並べてみましたが、例えば「値と型」を網羅的に書いていくと文章量が爆発するのが目に見えているので、過剰になったらリファレンス篇に移動するなどの方法で、各節はコンパクトさを心がけたいです。]

=== コメント ===
Zigでは、&lt;code&gt;//&lt;/code&gt; から行末までがコメントです。
C言語の &lt;code&gt;/* … */&lt;/code&gt; のスタイルの複数行に渡るコメントは'''ありません'''。
これは、コードの各行を文脈に関係なくトークン化できるようにするためです。
:&lt;syntaxhighlight lang=zig&gt;
// @import は組込み関数です。
const std = @import(&quot;std&quot;); // 先頭に @ が付く関数は組込み関数です
pub fn main() !void {
   try std.io.getStdOut().writeAll(&quot;Hello, World!\n&quot;);
}
&lt;/syntaxhighlight&gt;

==== Docコメント ====
Zigでは、&lt;code&gt;///&lt;/code&gt; から始まるコメントは特別なコメントで、Docコメント( ''Doc comments'' )と呼ばれます。
Docコメントは特定の場所にしか許されません。式の途中や非Docコメントの直前など、予想外の場所にdocコメントがあると、コンパイルエラーになります。

[TODO:サンプルコードと整形結果]

==== トップレベルDocコメント ====
Zigでは、&lt;code&gt;//!&lt;/code&gt; から始まるコメントは特別なコメントで、トップレベルDocコメント( ''Top-Level Doc Comments '' )と呼ばれます。
コンテナレベルのドキュメントのように、直後のドキュメントに属さないユーザードキュメントに、トップレベルDocコメントを使います。

[TODO:サンプルコードと整形結果]

DocコメントおよびトップレベルDocコメントは、コンパイル時に zig build-exe -femit-docs ソースファイル.zig の様に、-femit-docs をあたえると、 docs/ 以下にドキュメントが生成されます。

=== 値と型 ===
[TOD0:整数・浮動小数・論理値・文字列・共用体・構造体・列挙・配列・ベクトル・スライス・ポインター・ゼロビットな型]

:&lt;syntaxhighlight lang=zig&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot; (1) = {}\n&quot;, .{42});
    try print(&quot; (2) = {}\n&quot;, .{0x17});
    try print(&quot; (3) = {}\n&quot;, .{0o17});
    try print(&quot; (4) = {}\n&quot;, .{0b0100101});
    try print(&quot; (5) = {}\n&quot;, .{1e222});
    try print(&quot; (6) = {}\n&quot;, .{3.1415926536});
    try print(&quot; (7) = {}\n&quot;, .{'c'});
    try print(&quot; (8) = {c}\n&quot;, .{'c'});
    try print(&quot; (9) = {s}\n&quot;, .{&quot;abcdef&quot;});
    try print(&quot;(10) = {}, {}\n&quot;, .{ 111, 999 });
    try print(&quot;(11) = {1}, {0}\n&quot;, .{ 111, 999 });
    try print(&quot;(12) = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; });
    try print(&quot;(13) = {0d}, {0b}, {0o}, {0x}, {0X}\n&quot;, .{ 123 });
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
 (1) = 42
 (2) = 23
 (3) = 15
 (4) = 37
 (5) = 1.0e+222
 (6) = 3.1415926536e+00
 (7) = 99
 (8) = c
 (9) = abcdef
(10) = 111, 999
(11) = 999, 111
(12) = abc, 111
(13) = 123, 1111011, 173, 7b, 7B
&lt;/syntaxhighlight&gt;
&lt;!-- リテラルの例、というか、@import(&quot;std&quot;).io.getStdOut().writer().print の例になっていますね。--&gt;
ご覧のように、数値（整数と浮動小数点数）や文字・文字列のリテラルがあり、整数は基数を、浮動小数点数は指数表現と少数表現があります。

@import(&quot;std&quot;).io.getStdOut().writer().printの、第一引数は書式化文字列、第二引数は値リストです。
書式化文字列は、通常の文字列ですが &lt;code&gt;{&lt;/code&gt; と &lt;code&gt;}&lt;/code&gt; で囲まれたプレスホルダーが、引数リストの値（を書式化した文字列）に置換わります。
一番素朴なプレスホルダーは {} で、引数の値の一般的な文字列表記に置換ります（整数なら十進数表記、浮動小数点数なら指数表記）。
ところが、’c’ のような文字型を {} に適用すると文字コード化され整数と同じ十進数表記になってしまいます。そこで、文字型の場合は {c} と文字であることを明記すると文字表現となります。
また、文字列の間合いは {s} を明記しないと（バージョン0.8.0からは）エラーになります。
2つ以上の値を渡す場合は、第二引数を　.{ 1, 2, 3 } の様にカンマ区切りのリストにします（ これが、Zig の配列リテラルの表現で、{} の前の . （点）を忘れがち）。
基本的に、左から順にプレスホルダーにリストの値が左から与えられますが、{0} {1} の書式で参照する引数の順位を明示できます。
書式指定と併用する時は、 &lt;code&gt; print(&quot;? = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; })&lt;/code&gt; の様に順位が先、書式指定文字が後になります。

[TODO:[https://github.com/ziglang/zig/blob/master/lib/std/fmt.zig master/lib/std/fmt.zig]を観て書いています。参照すべき標準ライブラリのドキュメントを発見出来たら、見直し]
[TODO:表組み]

==== comptime ====
Zigでは、コンパイル時に式が既知かどうかという概念を重要視しています。

&lt;!--
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const i = 0;
    const string = [_]i32{ 1, 2, 3, 4 };
    for (string) |character, index| {
        std.debug.print(&quot;character: {}, index: {}, :{s} \n&quot;, .{ character, index, @typeName(@TypeOf(character)) });
    }
    _ = i;
}
--&gt;

=== テスト ===
=== 変数 ===
=== 制御構造 ===
[TODO:Zig の制御構造は文ではなく式]
==== 分岐 ====
[TODO:ifとswitch]
==== 反復 ====
[TODO:whileとfor]
=== 関数 ===
=== エラー ===
=== 演算子 ===
==== 優先順位 ====
高
&lt;syntaxhighlight lang=text line&gt;
 x() x[] x.y x.* x.?
 a!b
 x{}
 !x -x -%x ~x &amp;x ?x
 * / % ** *% *| ||
 + - ++ +% -% +| -|
 &lt;&lt; &gt;&gt; &lt;&lt;|
 &amp; ^ | orelse catch
 == != &lt; &gt; &lt;= &gt;=
 and
 or
 = *= *%= *|= /= %= += +%= +|= -= -%= -|= &lt;&lt;= &lt;&lt;|= &gt;&gt;= &amp;= ^= |=
&lt;/syntaxhighlight&gt;
低

===  optional type ===
===  opaque ===
訳語未定
=== ブロック ===
[TODO:スコープとシャドーイング；deferはここ？]
=== キャスト ===
[TODO:Zig は強い型付け()； 型強制 (Type coercion) について]
=== アセンブリ言語との連携 ===
[TODO:所謂インラインアセンラ]
=== atomic ===
=== 非同期関数 ===
=== 組込み関数 ===
[TODO:組込み関数は、@で始まり、@TypeOfや@alignOfの他@sinや@memcpyも組込み関数]
=== メモリ管理 ===
=== キーワード一覧 ===
&lt;code&gt;align&lt;/code&gt;
&lt;code&gt;allowzero&lt;/code&gt;
&lt;code&gt;and&lt;/code&gt;
&lt;code&gt;anyframe&lt;/code&gt;
&lt;code&gt;anytype&lt;/code&gt;
&lt;code&gt;asm&lt;/code&gt;
&lt;code&gt;async&lt;/code&gt;
&lt;code&gt;await&lt;/code&gt;
&lt;code&gt;break&lt;/code&gt;
&lt;code&gt;catch&lt;/code&gt;
&lt;code&gt;comptime&lt;/code&gt;
&lt;code&gt;const&lt;/code&gt;
&lt;code&gt;continue&lt;/code&gt;
&lt;code&gt;defer&lt;/code&gt;
&lt;code&gt;else&lt;/code&gt;
&lt;code&gt;enum&lt;/code&gt;
&lt;code&gt;errdefer&lt;/code&gt;
&lt;code&gt;error&lt;/code&gt;
&lt;code&gt;export&lt;/code&gt;
&lt;code&gt;extern&lt;/code&gt;
&lt;code&gt;fn&lt;/code&gt;
&lt;code&gt;for&lt;/code&gt;
&lt;code&gt;if&lt;/code&gt;
&lt;code&gt;inline&lt;/code&gt;
&lt;code&gt;noalias&lt;/code&gt;
&lt;code&gt;nosuspend&lt;/code&gt;
&lt;code&gt;or&lt;/code&gt;
&lt;code&gt;orelse&lt;/code&gt;
&lt;code&gt;packed&lt;/code&gt;
&lt;code&gt;pub&lt;/code&gt;
&lt;code&gt;resume&lt;/code&gt;
&lt;code&gt;return&lt;/code&gt;
&lt;code&gt;linksection&lt;/code&gt;
&lt;code&gt;struct&lt;/code&gt;
&lt;code&gt;suspend&lt;/code&gt;
&lt;code&gt;switch&lt;/code&gt;
&lt;code&gt;test&lt;/code&gt;
&lt;code&gt;threadlocal&lt;/code&gt;
&lt;code&gt;try&lt;/code&gt;
&lt;code&gt;union&lt;/code&gt;
&lt;code&gt;unreachable&lt;/code&gt;
&lt;code&gt;usingnamespace&lt;/code&gt;
&lt;code&gt;var&lt;/code&gt;
&lt;code&gt;volatile&lt;/code&gt;
&lt;code&gt;while&lt;/code&gt;

== チートシート ==
[TODO:文法と型と頻用する標準ライブラリの関数と型のアンチョコ]

== リファレンス篇 ==

== 脚註 ==
&lt;references /&gt;

== 外部リンク ==
* [https://ziglang.org/ Home ⚡ Zig Programming Language] {{---}} 公式サイト
** [[https://ziglang.org/documentation/master/ Zig Language Reference]] {{---}} リファレンスマニュアル
* [https://github.com/ziglang/zig ziglang/zig: General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.] {{---}} 公式リポジトリ
* [https://zig-play.dev/ Zig Playground] {{---}} オンライン実行環境
** [https://github.com/gsquire/zig-play About An online Zig compiler inspired by Go and Rust] {{---}} リポジトリ

[[Category:zig|*]]
[[Category:プログラミング言語]]</text>
      <sha1>82wiblh8nw8j6xtsiwwi1eszp9w9fvw</sha1>
    </revision>
    <revision>
      <id>205766</id>
      <parentid>205765</parentid>
      <timestamp>2022-07-24T06:45:12Z</timestamp>
      <contributor>
        <username>すじにくシチュー</username>
        <id>12058</id>
      </contributor>
      <comment>/* comptime */ 「変更点は mul() の呼出しを comptime で修飾しただけです。」に言い換え。他に変更点があるかどうか、読み手による確認の手間を減らすため。</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="21677" xml:space="preserve">{{Pathnav|メインページ|工学|情報技術|プログラミング|frame=1}}
{{Wikipedia|Zig (プログラミング言語)}}
本書は、[[w:Zig|Zig]]のチュートリアルです。
Zigは、堅牢で最適かつ再利用可能なソフトウェアを維持するための汎用プログラミング言語およびツールチェインです&lt;ref&gt;{{Cite web
|url=https://ziglang.org/
|title=Home ⚡ Zig Programming Language
|website=ziglang.org
|accessdate=2022-07-17
|cite=Zig is a general-purpose programming language and toolchain for maintaining '''robust''', '''optimal''' and '''reusable''' software.
}}&lt;/ref&gt;。
Zigは、アンドリュー・ケリー( ''[https://andrewkelley.me/ Andrew Kelley]'' )によって設計され、汎用システムプログラミング言語で、静的で強い型付けで型推論とジェネリックプログラミングをサポートします。

== 概要 ==
Zigは、2016年2月に発表された比較的若いプログラミング言語で&lt;ref&gt;{{Cite web
|last1=Kelley
|first1=Andrew
|title=Introduction to the Zig Programming Language
|url=https://andrewkelley.me/post/intro-to-zig.html
|website=andrewkelley.me
|accessdate=2022-07-17
}}&lt;/ref&gt;、2022年7月現在のバージョンは 0.9.1 で、'''''pre-release''''' と位置づけられています&lt;ref&gt;{{Cite web
|url=https://github.com/ziglang/zig/releases
|title=Releases · ziglang/zig
|website=github.com
|accessdate=2022-07-17
}}&lt;/ref&gt;。このため [[W:Hello world|Hello world]] ですら、バージョン間で互換性がなくなることもあり、リリースバージョンまでは言語仕様やライブラリーおよびツールチェインの仕様が変更される可能性があります。

=== Hello world の変遷 ===
[https://ziglang.org/documentation/master/ Zig Language Reference]の、[[W:Hello world|Hello world]]の変遷（新しい順）。

;master@2022-07-17&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/master/#Hello-World
|title=Zig Documentation(master@2022-07-17)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.8.1に同じ
;0.9.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.9.1/#Hello-World
|title=Zig Documentation(0.9.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.8.1に同じ
;0.8.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.8.1/#Hello-World
|title=Zig Documentation(0.8.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=4&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().writer();
    try stdout.print(&quot;Hello, {s}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: &lt;code&gt;{}&lt;/code&gt; ⇒ &lt;code&gt;{s}&lt;/code&gt;&lt;ref&gt;{{Cite web
|url=https://ziglang.org/download/0.8.0/release-notes.html#Formatted-Printing
|title=0.8.0 Release Notes
|website=ziglang.org
|accessdate=2022-07-17
|quote=Disable the special casing of {} for u8 slices/arrays. Unless {s} is specified the contents won't be treated as a string.
}}&lt;/ref&gt;
;0.7.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.7.1/#Hello-World
|title=Zig Documentation(0.7.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=3&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().writer();
    try stdout.print(&quot;Hello, {}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: s/outStream/writer/
;0.6.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.6.0/#Hello-World
|title=Zig Documentation(0.6.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=3&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().outStream();
    try stdout.print(&quot;Hello, {}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: 初期化の初期値から &lt;code&gt;try&lt;/code&gt; がなくなった。
;0.4.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.4.0/#Hello-World
|title=Zig Documentation(0.4.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.2.0に同じ
;0.5.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.5.0/#Hello-World
|title=Zig Documentation(0.5.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=4&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    // If this program is run without stdout attached, exit with an error.
    const stdout_file = try std.io.getStdOut();
    // If this program encounters pipe failure when printing to stdout, exit
    // with an error.
    try stdout_file.write(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;
: &lt;var&gt;stdout_file&lt;/var&gt; が &lt;code&gt;var&lt;/code&gt; から &lt;code&gt;const&lt;/code&gt; に変更された。

;0.3.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.3.0/#Hello-World
|title=Zig Documentation(0.3.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.2.0に同じ
;0.2.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.2.0/#Hello-World
|title=Zig Documentation(0.2.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    // If this program is run without stdout attached, exit with an error.
    var stdout_file = try std.io.getStdOut();
    // If this program encounters pipe failure when printing to stdout, exit
    // with an error.
    try stdout_file.write(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;
;0.1.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.1.1/#hello-world
|title=Zig Documentation
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig&gt;
const io = @import(&quot;std&quot;).io;
pub fn main() -&gt; %void {
    %%io.stdout.printf(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;

== 環境準備 ==
=== Linuxの場合 ===
==== インストール方法 ====
Fedora 36 の場合、2022年の時点で、コマンド
 sudo dnf install zig
だけでインストールできる事を確認。

その他のOS環境でのインストールについては、[https://github.com/ziglang/zig/wiki/Install-Zig-from-a-Package-Manager  GitHub  &quot;ziglang /zig&quot; ] を参照せよ。

インストールできたと思ったら、バージョン確認コマンドなどで、インストールの成否を確認しよう。コマンド
 zig version
で確認できる。

なお、2022年7月現在、まだバージョンは1未満であり、同7月に実験したところ
 0.9.1
であった。上記のセクションでも掛かれているように2022年の段階ではまだプレリリースであるので、1未満でもインストール成功なので安心していい。

==== コードの実行方法 ====
=== 値と型 ===
[TOD0:整数・浮動小数・論理値・文字列・共用体・構造体・列挙・配列・ベクトル・スライス・ポインター・ゼロビットな型]

:&lt;syntaxhighlight lang=&quot;zig&quot;&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot;abcd \n&quot;, .{} );
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
abcd 
&lt;/syntaxhighlight&gt;

2022年7月現在、引用符中に変数をなにも使っていなくても、&lt;code&gt;.{}&lt;/code&gt;が必要である。ほか&lt;code&gt;try print&lt;/code&gt; の &lt;code&gt;try&lt;/code&gt; については、&lt;code&gt;try&lt;/code&gt;がないとエラーになる。

:&lt;syntaxhighlight lang=&quot;zig&quot;&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot; (1) = {}\n&quot;, .{42});
    try print(&quot; (2) = {}\n&quot;, .{0x17});
    try print(&quot; (3) = {}\n&quot;, .{0o17});
    try print(&quot; (4) = {}\n&quot;, .{0b0100101});
    try print(&quot; (5) = {}\n&quot;, .{1e222});
    try print(&quot; (6) = {}\n&quot;, .{3.1415926536});
    try print(&quot; (7) = {}\n&quot;, .{'c'});
    try print(&quot; (8) = {c}\n&quot;, .{'c'});
    try print(&quot; (9) = {s}\n&quot;, .{&quot;abcdef&quot;});
    try print(&quot;(10) = {}, {}\n&quot;, .{ 111, 999 });
    try print(&quot;(11) = {1}, {0}\n&quot;, .{ 111, 999 });
    try print(&quot;(12) = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; });
    try print(&quot;(13) = {0d}, {0b}, {0o}, {0x}, {0X}\n&quot;, .{ 123 });
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
 (1) = 42
 (2) = 23
 (3) = 15
 (4) = 37
 (5) = 1.0e+222
 (6) = 3.1415926536e+00
 (7) = 99
 (8) = c
 (9) = abcdef
(10) = 111, 999
(11) = 999, 111
(12) = abc, 111
(13) = 123, 1111011, 173, 7b, 7B
&lt;/syntaxhighlight&gt;
&lt;!-- リテラルの例、というか、@import(&quot;std&quot;).io.getStdOut().writer().print の例になっていますね。--&gt;
ご覧のように、数値（整数と浮動小数点数）や文字・文字列のリテラルがあり、整数は基数を、浮動小数点数は指数表現と小数表現があります。

@import(&quot;std&quot;).io.getStdOut().writer().printの、第一引数は書式化文字列、第二引数は値リストです。
書式化文字列は、通常の文字列ですが &lt;code&gt;{&lt;/code&gt; と &lt;code&gt;}&lt;/code&gt; で囲まれたプレスホルダーが、引数リストの値（を書式化した文字列）に置換わります。
一番素朴なプレスホルダーは {} で、引数の値の一般的な文字列表記に置換ります（整数なら十進数表記、浮動小数点数なら指数表記）。
ところが、’c’ のような文字型を {} に適用すると文字コード化され整数と同じ十進数表記になってしまいます。そこで、文字型の場合は {c} と文字であることを明記すると文字表現となります。
また、文字列の間合いは {s} を明記しないと（バージョン0.8.0からは）エラーになります。
2つ以上の値を渡す場合は、第二引数を　.{ 1, 2, 3 } の様にカンマ区切りのリストにします（ {} の前の . （点）を忘れがち）。
基本的に、左から順にプレスホルダーにリストの値が左から与えられますが、{0} {1} の書式で参照する引数の順位を明示できます。
書式指定と併用する時は、 &lt;code&gt; print(&quot;? = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; })&lt;/code&gt; の様に順位が先、書式指定文字が後になります。

[TODO:[https://github.com/ziglang/zig/blob/master/lib/std/fmt.zig master/lib/std/fmt.zig]を観て書いています。参照すべき標準ライブラリのドキュメントを発見出来たら、見直し]
[TODO:表組み]

==== comptime ====
Zigでは、コンパイル時に式が既知かどうかという概念を重要視しています。

下記コードはコンパイル等がエラーになります。
:&lt;syntaxhighlight lang=&quot;zig&quot; line highlight=7&gt;
fn mul(x: usize, y: usize) usize {
    return x * y;
}

pub fn main() void {
    const len : usize = mul(3, 4);
    const ary: [len]i32 = undefined;
    _ = ary;
}
&lt;/syntaxhighlight&gt;
;コンパイル結果:&lt;syntaxhighlight lang=text&gt;
An error occurred: 
/tmp/playground130713503/play.zig:7:17: error: unable to evaluate constant expression 
    const ary: [len]i32 = undefined;
&lt;/syntaxhighlight&gt;
: 「定数式が評価できない 」と宣っています。
: [[C++]]であれば、constexprが適用なケースですが、Zigでは次のような解決方法を取ります。下記コードはエラーになりません。

:&lt;syntaxhighlight lang=&quot;zig&quot; line highlight=6&gt;
fn mul(x: usize, y: usize) usize {
    return x * y;
}

pub fn main() void {
    const len : usize = comptime mul(3, 4); // mul の前に comptime を追加 
    const ary: [len]i32 = undefined;
    _ = ary;
}
&lt;/syntaxhighlight&gt;
:変更点は mul() の呼出しを comptime で修飾しただけです。comptime は、修飾子式を'''コンパイル時に実行する'''修飾子で、式の中でコンパイル時に未定な値が参照されると、エラーとなります。ここでは、数リテラル同士の商を求めているので、コンパイル時値が確定できます。
: _ = ary は、「定義済だが参照のない変数宣言」をサプレッスするときのイディオムです。

&lt;!--
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const i = 0;
    const string = [_]i32{ 1, 2, 3, 4 };
    for (string) |character, index| {
        std.debug.print(&quot;character: {}, index: {}, :{s} \n&quot;, .{ character, index, @typeName(@TypeOf(character)) });
    }
    _ = i;
}
--&gt;

===== インタプリタ的に実行する場合 =====
コンパイル済みファイルの作成を飛ばして、インタプリタ的に直接に実行する方法もあり、たとえばファイル名「hello.zig」なら下記のようなコマンドある。
 zig run hello.zig


===== プロジェクト作成する場合 =====
まず、プロジェクト関連のコマンドを実行すると、自動で数個のフォルダが作成されるので、それをまとめるためのフォルダを別に作っておき（たとえば proj とする）、べつにマウス右クリックでも mldir コマンドでもなんでもいいので proj ディレクトリを作成しておく。

そして、さらにカレント・ディレクトリを proj に移動するために、ターミナルでコマンド
 cd proj
で、そこに移動する。（そうしないと、今後の動作でホームフォルダにいくつものフォルダやファイルが作成され、管理しづらくなる）

その上で、プロジェクト作成のために
 zig init-exe
を行う。このコマンドにより、初期設定ファイルなどがいくつか自動的に作成される。

== 基礎篇 ==
[TODO:書くべき項目を並べてみましたが、例えば「値と型」を網羅的に書いていくと文章量が爆発するのが目に見えているので、過剰になったらリファレンス篇に移動するなどの方法で、各節はコンパクトさを心がけたいです。]

=== コメント ===
Zigでは、&lt;code&gt;//&lt;/code&gt; から行末までがコメントです。
C言語の &lt;code&gt;/* … */&lt;/code&gt; のスタイルの複数行に渡るコメントは'''ありません'''。
これは、コードの各行を文脈に関係なくトークン化できるようにするためです。
:&lt;syntaxhighlight lang=zig&gt;
// @import は組込み関数です。
const std = @import(&quot;std&quot;); // 先頭に @ が付く関数は組込み関数です
pub fn main() !void {
   try std.io.getStdOut().writeAll(&quot;Hello, World!\n&quot;);
}
&lt;/syntaxhighlight&gt;

==== Docコメント ====
Zigでは、&lt;code&gt;///&lt;/code&gt; から始まるコメントは特別なコメントで、Docコメント( ''Doc comments'' )と呼ばれます。
Docコメントは特定の場所にしか許されません。式の途中や非Docコメントの直前など、予想外の場所にdocコメントがあると、コンパイルエラーになります。

[TODO:サンプルコードと整形結果]

==== トップレベルDocコメント ====
Zigでは、&lt;code&gt;//!&lt;/code&gt; から始まるコメントは特別なコメントで、トップレベルDocコメント( ''Top-Level Doc Comments '' )と呼ばれます。
コンテナレベルのドキュメントのように、直後のドキュメントに属さないユーザードキュメントに、トップレベルDocコメントを使います。

[TODO:サンプルコードと整形結果]

DocコメントおよびトップレベルDocコメントは、コンパイル時に zig build-exe -femit-docs ソースファイル.zig の様に、-femit-docs をあたえると、 docs/ 以下にドキュメントが生成されます。

=== 値と型 ===
[TOD0:整数・浮動小数・論理値・文字列・共用体・構造体・列挙・配列・ベクトル・スライス・ポインター・ゼロビットな型]

:&lt;syntaxhighlight lang=zig&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot; (1) = {}\n&quot;, .{42});
    try print(&quot; (2) = {}\n&quot;, .{0x17});
    try print(&quot; (3) = {}\n&quot;, .{0o17});
    try print(&quot; (4) = {}\n&quot;, .{0b0100101});
    try print(&quot; (5) = {}\n&quot;, .{1e222});
    try print(&quot; (6) = {}\n&quot;, .{3.1415926536});
    try print(&quot; (7) = {}\n&quot;, .{'c'});
    try print(&quot; (8) = {c}\n&quot;, .{'c'});
    try print(&quot; (9) = {s}\n&quot;, .{&quot;abcdef&quot;});
    try print(&quot;(10) = {}, {}\n&quot;, .{ 111, 999 });
    try print(&quot;(11) = {1}, {0}\n&quot;, .{ 111, 999 });
    try print(&quot;(12) = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; });
    try print(&quot;(13) = {0d}, {0b}, {0o}, {0x}, {0X}\n&quot;, .{ 123 });
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
 (1) = 42
 (2) = 23
 (3) = 15
 (4) = 37
 (5) = 1.0e+222
 (6) = 3.1415926536e+00
 (7) = 99
 (8) = c
 (9) = abcdef
(10) = 111, 999
(11) = 999, 111
(12) = abc, 111
(13) = 123, 1111011, 173, 7b, 7B
&lt;/syntaxhighlight&gt;
&lt;!-- リテラルの例、というか、@import(&quot;std&quot;).io.getStdOut().writer().print の例になっていますね。--&gt;
ご覧のように、数値（整数と浮動小数点数）や文字・文字列のリテラルがあり、整数は基数を、浮動小数点数は指数表現と少数表現があります。

@import(&quot;std&quot;).io.getStdOut().writer().printの、第一引数は書式化文字列、第二引数は値リストです。
書式化文字列は、通常の文字列ですが &lt;code&gt;{&lt;/code&gt; と &lt;code&gt;}&lt;/code&gt; で囲まれたプレスホルダーが、引数リストの値（を書式化した文字列）に置換わります。
一番素朴なプレスホルダーは {} で、引数の値の一般的な文字列表記に置換ります（整数なら十進数表記、浮動小数点数なら指数表記）。
ところが、’c’ のような文字型を {} に適用すると文字コード化され整数と同じ十進数表記になってしまいます。そこで、文字型の場合は {c} と文字であることを明記すると文字表現となります。
また、文字列の間合いは {s} を明記しないと（バージョン0.8.0からは）エラーになります。
2つ以上の値を渡す場合は、第二引数を　.{ 1, 2, 3 } の様にカンマ区切りのリストにします（ これが、Zig の配列リテラルの表現で、{} の前の . （点）を忘れがち）。
基本的に、左から順にプレスホルダーにリストの値が左から与えられますが、{0} {1} の書式で参照する引数の順位を明示できます。
書式指定と併用する時は、 &lt;code&gt; print(&quot;? = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; })&lt;/code&gt; の様に順位が先、書式指定文字が後になります。

[TODO:[https://github.com/ziglang/zig/blob/master/lib/std/fmt.zig master/lib/std/fmt.zig]を観て書いています。参照すべき標準ライブラリのドキュメントを発見出来たら、見直し]
[TODO:表組み]

==== comptime ====
Zigでは、コンパイル時に式が既知かどうかという概念を重要視しています。

&lt;!--
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const i = 0;
    const string = [_]i32{ 1, 2, 3, 4 };
    for (string) |character, index| {
        std.debug.print(&quot;character: {}, index: {}, :{s} \n&quot;, .{ character, index, @typeName(@TypeOf(character)) });
    }
    _ = i;
}
--&gt;

=== テスト ===
=== 変数 ===
=== 制御構造 ===
[TODO:Zig の制御構造は文ではなく式]
==== 分岐 ====
[TODO:ifとswitch]
==== 反復 ====
[TODO:whileとfor]
=== 関数 ===
=== エラー ===
=== 演算子 ===
==== 優先順位 ====
高
&lt;syntaxhighlight lang=text line&gt;
 x() x[] x.y x.* x.?
 a!b
 x{}
 !x -x -%x ~x &amp;x ?x
 * / % ** *% *| ||
 + - ++ +% -% +| -|
 &lt;&lt; &gt;&gt; &lt;&lt;|
 &amp; ^ | orelse catch
 == != &lt; &gt; &lt;= &gt;=
 and
 or
 = *= *%= *|= /= %= += +%= +|= -= -%= -|= &lt;&lt;= &lt;&lt;|= &gt;&gt;= &amp;= ^= |=
&lt;/syntaxhighlight&gt;
低

===  optional type ===
===  opaque ===
訳語未定
=== ブロック ===
[TODO:スコープとシャドーイング；deferはここ？]
=== キャスト ===
[TODO:Zig は強い型付け()； 型強制 (Type coercion) について]
=== アセンブリ言語との連携 ===
[TODO:所謂インラインアセンラ]
=== atomic ===
=== 非同期関数 ===
=== 組込み関数 ===
[TODO:組込み関数は、@で始まり、@TypeOfや@alignOfの他@sinや@memcpyも組込み関数]
=== メモリ管理 ===
=== キーワード一覧 ===
&lt;code&gt;align&lt;/code&gt;
&lt;code&gt;allowzero&lt;/code&gt;
&lt;code&gt;and&lt;/code&gt;
&lt;code&gt;anyframe&lt;/code&gt;
&lt;code&gt;anytype&lt;/code&gt;
&lt;code&gt;asm&lt;/code&gt;
&lt;code&gt;async&lt;/code&gt;
&lt;code&gt;await&lt;/code&gt;
&lt;code&gt;break&lt;/code&gt;
&lt;code&gt;catch&lt;/code&gt;
&lt;code&gt;comptime&lt;/code&gt;
&lt;code&gt;const&lt;/code&gt;
&lt;code&gt;continue&lt;/code&gt;
&lt;code&gt;defer&lt;/code&gt;
&lt;code&gt;else&lt;/code&gt;
&lt;code&gt;enum&lt;/code&gt;
&lt;code&gt;errdefer&lt;/code&gt;
&lt;code&gt;error&lt;/code&gt;
&lt;code&gt;export&lt;/code&gt;
&lt;code&gt;extern&lt;/code&gt;
&lt;code&gt;fn&lt;/code&gt;
&lt;code&gt;for&lt;/code&gt;
&lt;code&gt;if&lt;/code&gt;
&lt;code&gt;inline&lt;/code&gt;
&lt;code&gt;noalias&lt;/code&gt;
&lt;code&gt;nosuspend&lt;/code&gt;
&lt;code&gt;or&lt;/code&gt;
&lt;code&gt;orelse&lt;/code&gt;
&lt;code&gt;packed&lt;/code&gt;
&lt;code&gt;pub&lt;/code&gt;
&lt;code&gt;resume&lt;/code&gt;
&lt;code&gt;return&lt;/code&gt;
&lt;code&gt;linksection&lt;/code&gt;
&lt;code&gt;struct&lt;/code&gt;
&lt;code&gt;suspend&lt;/code&gt;
&lt;code&gt;switch&lt;/code&gt;
&lt;code&gt;test&lt;/code&gt;
&lt;code&gt;threadlocal&lt;/code&gt;
&lt;code&gt;try&lt;/code&gt;
&lt;code&gt;union&lt;/code&gt;
&lt;code&gt;unreachable&lt;/code&gt;
&lt;code&gt;usingnamespace&lt;/code&gt;
&lt;code&gt;var&lt;/code&gt;
&lt;code&gt;volatile&lt;/code&gt;
&lt;code&gt;while&lt;/code&gt;

== チートシート ==
[TODO:文法と型と頻用する標準ライブラリの関数と型のアンチョコ]

== リファレンス篇 ==

== 脚註 ==
&lt;references /&gt;

== 外部リンク ==
* [https://ziglang.org/ Home ⚡ Zig Programming Language] {{---}} 公式サイト
** [[https://ziglang.org/documentation/master/ Zig Language Reference]] {{---}} リファレンスマニュアル
* [https://github.com/ziglang/zig ziglang/zig: General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.] {{---}} 公式リポジトリ
* [https://zig-play.dev/ Zig Playground] {{---}} オンライン実行環境
** [https://github.com/gsquire/zig-play About An online Zig compiler inspired by Go and Rust] {{---}} リポジトリ

[[Category:zig|*]]
[[Category:プログラミング言語]]</text>
      <sha1>3cyuw4182ekpce9nkpj02m8874yehgw</sha1>
    </revision>
    <revision>
      <id>205767</id>
      <parentid>205766</parentid>
      <timestamp>2022-07-24T06:49:18Z</timestamp>
      <contributor>
        <username>すじにくシチュー</username>
        <id>12058</id>
      </contributor>
      <comment>「置換ります」-&gt;「置き換わります」に。てっきり、「チカン（置換）ります」かと思った</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="21680" xml:space="preserve">{{Pathnav|メインページ|工学|情報技術|プログラミング|frame=1}}
{{Wikipedia|Zig (プログラミング言語)}}
本書は、[[w:Zig|Zig]]のチュートリアルです。
Zigは、堅牢で最適かつ再利用可能なソフトウェアを維持するための汎用プログラミング言語およびツールチェインです&lt;ref&gt;{{Cite web
|url=https://ziglang.org/
|title=Home ⚡ Zig Programming Language
|website=ziglang.org
|accessdate=2022-07-17
|cite=Zig is a general-purpose programming language and toolchain for maintaining '''robust''', '''optimal''' and '''reusable''' software.
}}&lt;/ref&gt;。
Zigは、アンドリュー・ケリー( ''[https://andrewkelley.me/ Andrew Kelley]'' )によって設計され、汎用システムプログラミング言語で、静的で強い型付けで型推論とジェネリックプログラミングをサポートします。

== 概要 ==
Zigは、2016年2月に発表された比較的若いプログラミング言語で&lt;ref&gt;{{Cite web
|last1=Kelley
|first1=Andrew
|title=Introduction to the Zig Programming Language
|url=https://andrewkelley.me/post/intro-to-zig.html
|website=andrewkelley.me
|accessdate=2022-07-17
}}&lt;/ref&gt;、2022年7月現在のバージョンは 0.9.1 で、'''''pre-release''''' と位置づけられています&lt;ref&gt;{{Cite web
|url=https://github.com/ziglang/zig/releases
|title=Releases · ziglang/zig
|website=github.com
|accessdate=2022-07-17
}}&lt;/ref&gt;。このため [[W:Hello world|Hello world]] ですら、バージョン間で互換性がなくなることもあり、リリースバージョンまでは言語仕様やライブラリーおよびツールチェインの仕様が変更される可能性があります。

=== Hello world の変遷 ===
[https://ziglang.org/documentation/master/ Zig Language Reference]の、[[W:Hello world|Hello world]]の変遷（新しい順）。

;master@2022-07-17&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/master/#Hello-World
|title=Zig Documentation(master@2022-07-17)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.8.1に同じ
;0.9.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.9.1/#Hello-World
|title=Zig Documentation(0.9.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.8.1に同じ
;0.8.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.8.1/#Hello-World
|title=Zig Documentation(0.8.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=4&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().writer();
    try stdout.print(&quot;Hello, {s}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: &lt;code&gt;{}&lt;/code&gt; ⇒ &lt;code&gt;{s}&lt;/code&gt;&lt;ref&gt;{{Cite web
|url=https://ziglang.org/download/0.8.0/release-notes.html#Formatted-Printing
|title=0.8.0 Release Notes
|website=ziglang.org
|accessdate=2022-07-17
|quote=Disable the special casing of {} for u8 slices/arrays. Unless {s} is specified the contents won't be treated as a string.
}}&lt;/ref&gt;
;0.7.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.7.1/#Hello-World
|title=Zig Documentation(0.7.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=3&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().writer();
    try stdout.print(&quot;Hello, {}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: s/outStream/writer/
;0.6.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.6.0/#Hello-World
|title=Zig Documentation(0.6.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=3&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().outStream();
    try stdout.print(&quot;Hello, {}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: 初期化の初期値から &lt;code&gt;try&lt;/code&gt; がなくなった。
;0.4.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.4.0/#Hello-World
|title=Zig Documentation(0.4.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.2.0に同じ
;0.5.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.5.0/#Hello-World
|title=Zig Documentation(0.5.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=4&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    // If this program is run without stdout attached, exit with an error.
    const stdout_file = try std.io.getStdOut();
    // If this program encounters pipe failure when printing to stdout, exit
    // with an error.
    try stdout_file.write(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;
: &lt;var&gt;stdout_file&lt;/var&gt; が &lt;code&gt;var&lt;/code&gt; から &lt;code&gt;const&lt;/code&gt; に変更された。

;0.3.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.3.0/#Hello-World
|title=Zig Documentation(0.3.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.2.0に同じ
;0.2.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.2.0/#Hello-World
|title=Zig Documentation(0.2.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    // If this program is run without stdout attached, exit with an error.
    var stdout_file = try std.io.getStdOut();
    // If this program encounters pipe failure when printing to stdout, exit
    // with an error.
    try stdout_file.write(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;
;0.1.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.1.1/#hello-world
|title=Zig Documentation
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig&gt;
const io = @import(&quot;std&quot;).io;
pub fn main() -&gt; %void {
    %%io.stdout.printf(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;

== 環境準備 ==
=== Linuxの場合 ===
==== インストール方法 ====
Fedora 36 の場合、2022年の時点で、コマンド
 sudo dnf install zig
だけでインストールできる事を確認。

その他のOS環境でのインストールについては、[https://github.com/ziglang/zig/wiki/Install-Zig-from-a-Package-Manager  GitHub  &quot;ziglang /zig&quot; ] を参照せよ。

インストールできたと思ったら、バージョン確認コマンドなどで、インストールの成否を確認しよう。コマンド
 zig version
で確認できる。

なお、2022年7月現在、まだバージョンは1未満であり、同7月に実験したところ
 0.9.1
であった。上記のセクションでも掛かれているように2022年の段階ではまだプレリリースであるので、1未満でもインストール成功なので安心していい。

==== コードの実行方法 ====
=== 値と型 ===
[TOD0:整数・浮動小数・論理値・文字列・共用体・構造体・列挙・配列・ベクトル・スライス・ポインター・ゼロビットな型]

:&lt;syntaxhighlight lang=&quot;zig&quot;&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot;abcd \n&quot;, .{} );
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
abcd 
&lt;/syntaxhighlight&gt;

2022年7月現在、引用符中に変数をなにも使っていなくても、&lt;code&gt;.{}&lt;/code&gt;が必要である。ほか&lt;code&gt;try print&lt;/code&gt; の &lt;code&gt;try&lt;/code&gt; については、&lt;code&gt;try&lt;/code&gt;がないとエラーになる。

:&lt;syntaxhighlight lang=&quot;zig&quot;&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot; (1) = {}\n&quot;, .{42});
    try print(&quot; (2) = {}\n&quot;, .{0x17});
    try print(&quot; (3) = {}\n&quot;, .{0o17});
    try print(&quot; (4) = {}\n&quot;, .{0b0100101});
    try print(&quot; (5) = {}\n&quot;, .{1e222});
    try print(&quot; (6) = {}\n&quot;, .{3.1415926536});
    try print(&quot; (7) = {}\n&quot;, .{'c'});
    try print(&quot; (8) = {c}\n&quot;, .{'c'});
    try print(&quot; (9) = {s}\n&quot;, .{&quot;abcdef&quot;});
    try print(&quot;(10) = {}, {}\n&quot;, .{ 111, 999 });
    try print(&quot;(11) = {1}, {0}\n&quot;, .{ 111, 999 });
    try print(&quot;(12) = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; });
    try print(&quot;(13) = {0d}, {0b}, {0o}, {0x}, {0X}\n&quot;, .{ 123 });
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
 (1) = 42
 (2) = 23
 (3) = 15
 (4) = 37
 (5) = 1.0e+222
 (6) = 3.1415926536e+00
 (7) = 99
 (8) = c
 (9) = abcdef
(10) = 111, 999
(11) = 999, 111
(12) = abc, 111
(13) = 123, 1111011, 173, 7b, 7B
&lt;/syntaxhighlight&gt;
&lt;!-- リテラルの例、というか、@import(&quot;std&quot;).io.getStdOut().writer().print の例になっていますね。--&gt;
ご覧のように、数値（整数と浮動小数点数）や文字・文字列のリテラルがあり、整数は基数を、浮動小数点数は指数表現と小数表現があります。

@import(&quot;std&quot;).io.getStdOut().writer().printの、第一引数は書式化文字列、第二引数は値リストです。
書式化文字列は、通常の文字列ですが &lt;code&gt;{&lt;/code&gt; と &lt;code&gt;}&lt;/code&gt; で囲まれたプレスホルダーが、引数リストの値（を書式化した文字列）に置換わります。
一番素朴なプレスホルダーは {} で、引数の値の一般的な文字列表記に置き換ります（整数なら十進数表記、浮動小数点数なら指数表記）。
ところが、’c’ のような文字型を {} に適用すると文字コード化され整数と同じ十進数表記になってしまいます。そこで、文字型の場合は {c} と文字であることを明記すると文字表現となります。
また、文字列の間合いは {s} を明記しないと（バージョン0.8.0からは）エラーになります。
2つ以上の値を渡す場合は、第二引数を　.{ 1, 2, 3 } の様にカンマ区切りのリストにします（ {} の前の . （点）を忘れがち）。
基本的に、左から順にプレスホルダーにリストの値が左から与えられますが、{0} {1} の書式で参照する引数の順位を明示できます。
書式指定と併用する時は、 &lt;code&gt; print(&quot;? = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; })&lt;/code&gt; の様に順位が先、書式指定文字が後になります。

[TODO:[https://github.com/ziglang/zig/blob/master/lib/std/fmt.zig master/lib/std/fmt.zig]を観て書いています。参照すべき標準ライブラリのドキュメントを発見出来たら、見直し]
[TODO:表組み]

==== comptime ====
Zigでは、コンパイル時に式が既知かどうかという概念を重要視しています。

下記コードはコンパイル等がエラーになります。
:&lt;syntaxhighlight lang=&quot;zig&quot; line highlight=7&gt;
fn mul(x: usize, y: usize) usize {
    return x * y;
}

pub fn main() void {
    const len : usize = mul(3, 4);
    const ary: [len]i32 = undefined;
    _ = ary;
}
&lt;/syntaxhighlight&gt;
;コンパイル結果:&lt;syntaxhighlight lang=text&gt;
An error occurred: 
/tmp/playground130713503/play.zig:7:17: error: unable to evaluate constant expression 
    const ary: [len]i32 = undefined;
&lt;/syntaxhighlight&gt;
: 「定数式が評価できない 」と宣っています。
: [[C++]]であれば、constexprが適用なケースですが、Zigでは次のような解決方法を取ります。下記コードはエラーになりません。

:&lt;syntaxhighlight lang=&quot;zig&quot; line highlight=6&gt;
fn mul(x: usize, y: usize) usize {
    return x * y;
}

pub fn main() void {
    const len : usize = comptime mul(3, 4); // mul の前に comptime を追加 
    const ary: [len]i32 = undefined;
    _ = ary;
}
&lt;/syntaxhighlight&gt;
:変更点は mul() の呼出しを comptime で修飾しただけです。comptime は、修飾子式を'''コンパイル時に実行する'''修飾子で、式の中でコンパイル時に未定な値が参照されると、エラーとなります。ここでは、数リテラル同士の商を求めているので、コンパイル時値が確定できます。
: _ = ary は、「定義済だが参照のない変数宣言」をサプレッスするときのイディオムです。

&lt;!--
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const i = 0;
    const string = [_]i32{ 1, 2, 3, 4 };
    for (string) |character, index| {
        std.debug.print(&quot;character: {}, index: {}, :{s} \n&quot;, .{ character, index, @typeName(@TypeOf(character)) });
    }
    _ = i;
}
--&gt;

===== インタプリタ的に実行する場合 =====
コンパイル済みファイルの作成を飛ばして、インタプリタ的に直接に実行する方法もあり、たとえばファイル名「hello.zig」なら下記のようなコマンドある。
 zig run hello.zig


===== プロジェクト作成する場合 =====
まず、プロジェクト関連のコマンドを実行すると、自動で数個のフォルダが作成されるので、それをまとめるためのフォルダを別に作っておき（たとえば proj とする）、べつにマウス右クリックでも mldir コマンドでもなんでもいいので proj ディレクトリを作成しておく。

そして、さらにカレント・ディレクトリを proj に移動するために、ターミナルでコマンド
 cd proj
で、そこに移動する。（そうしないと、今後の動作でホームフォルダにいくつものフォルダやファイルが作成され、管理しづらくなる）

その上で、プロジェクト作成のために
 zig init-exe
を行う。このコマンドにより、初期設定ファイルなどがいくつか自動的に作成される。

== 基礎篇 ==
[TODO:書くべき項目を並べてみましたが、例えば「値と型」を網羅的に書いていくと文章量が爆発するのが目に見えているので、過剰になったらリファレンス篇に移動するなどの方法で、各節はコンパクトさを心がけたいです。]

=== コメント ===
Zigでは、&lt;code&gt;//&lt;/code&gt; から行末までがコメントです。
C言語の &lt;code&gt;/* … */&lt;/code&gt; のスタイルの複数行に渡るコメントは'''ありません'''。
これは、コードの各行を文脈に関係なくトークン化できるようにするためです。
:&lt;syntaxhighlight lang=zig&gt;
// @import は組込み関数です。
const std = @import(&quot;std&quot;); // 先頭に @ が付く関数は組込み関数です
pub fn main() !void {
   try std.io.getStdOut().writeAll(&quot;Hello, World!\n&quot;);
}
&lt;/syntaxhighlight&gt;

==== Docコメント ====
Zigでは、&lt;code&gt;///&lt;/code&gt; から始まるコメントは特別なコメントで、Docコメント( ''Doc comments'' )と呼ばれます。
Docコメントは特定の場所にしか許されません。式の途中や非Docコメントの直前など、予想外の場所にdocコメントがあると、コンパイルエラーになります。

[TODO:サンプルコードと整形結果]

==== トップレベルDocコメント ====
Zigでは、&lt;code&gt;//!&lt;/code&gt; から始まるコメントは特別なコメントで、トップレベルDocコメント( ''Top-Level Doc Comments '' )と呼ばれます。
コンテナレベルのドキュメントのように、直後のドキュメントに属さないユーザードキュメントに、トップレベルDocコメントを使います。

[TODO:サンプルコードと整形結果]

DocコメントおよびトップレベルDocコメントは、コンパイル時に zig build-exe -femit-docs ソースファイル.zig の様に、-femit-docs をあたえると、 docs/ 以下にドキュメントが生成されます。

=== 値と型 ===
[TOD0:整数・浮動小数・論理値・文字列・共用体・構造体・列挙・配列・ベクトル・スライス・ポインター・ゼロビットな型]

:&lt;syntaxhighlight lang=zig&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot; (1) = {}\n&quot;, .{42});
    try print(&quot; (2) = {}\n&quot;, .{0x17});
    try print(&quot; (3) = {}\n&quot;, .{0o17});
    try print(&quot; (4) = {}\n&quot;, .{0b0100101});
    try print(&quot; (5) = {}\n&quot;, .{1e222});
    try print(&quot; (6) = {}\n&quot;, .{3.1415926536});
    try print(&quot; (7) = {}\n&quot;, .{'c'});
    try print(&quot; (8) = {c}\n&quot;, .{'c'});
    try print(&quot; (9) = {s}\n&quot;, .{&quot;abcdef&quot;});
    try print(&quot;(10) = {}, {}\n&quot;, .{ 111, 999 });
    try print(&quot;(11) = {1}, {0}\n&quot;, .{ 111, 999 });
    try print(&quot;(12) = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; });
    try print(&quot;(13) = {0d}, {0b}, {0o}, {0x}, {0X}\n&quot;, .{ 123 });
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
 (1) = 42
 (2) = 23
 (3) = 15
 (4) = 37
 (5) = 1.0e+222
 (6) = 3.1415926536e+00
 (7) = 99
 (8) = c
 (9) = abcdef
(10) = 111, 999
(11) = 999, 111
(12) = abc, 111
(13) = 123, 1111011, 173, 7b, 7B
&lt;/syntaxhighlight&gt;
&lt;!-- リテラルの例、というか、@import(&quot;std&quot;).io.getStdOut().writer().print の例になっていますね。--&gt;
ご覧のように、数値（整数と浮動小数点数）や文字・文字列のリテラルがあり、整数は基数を、浮動小数点数は指数表現と少数表現があります。

@import(&quot;std&quot;).io.getStdOut().writer().printの、第一引数は書式化文字列、第二引数は値リストです。
書式化文字列は、通常の文字列ですが &lt;code&gt;{&lt;/code&gt; と &lt;code&gt;}&lt;/code&gt; で囲まれたプレスホルダーが、引数リストの値（を書式化した文字列）に置換わります。
一番素朴なプレスホルダーは {} で、引数の値の一般的な文字列表記に置換ります（整数なら十進数表記、浮動小数点数なら指数表記）。
ところが、’c’ のような文字型を {} に適用すると文字コード化され整数と同じ十進数表記になってしまいます。そこで、文字型の場合は {c} と文字であることを明記すると文字表現となります。
また、文字列の間合いは {s} を明記しないと（バージョン0.8.0からは）エラーになります。
2つ以上の値を渡す場合は、第二引数を　.{ 1, 2, 3 } の様にカンマ区切りのリストにします（ これが、Zig の配列リテラルの表現で、{} の前の . （点）を忘れがち）。
基本的に、左から順にプレスホルダーにリストの値が左から与えられますが、{0} {1} の書式で参照する引数の順位を明示できます。
書式指定と併用する時は、 &lt;code&gt; print(&quot;? = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; })&lt;/code&gt; の様に順位が先、書式指定文字が後になります。

[TODO:[https://github.com/ziglang/zig/blob/master/lib/std/fmt.zig master/lib/std/fmt.zig]を観て書いています。参照すべき標準ライブラリのドキュメントを発見出来たら、見直し]
[TODO:表組み]

==== comptime ====
Zigでは、コンパイル時に式が既知かどうかという概念を重要視しています。

&lt;!--
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const i = 0;
    const string = [_]i32{ 1, 2, 3, 4 };
    for (string) |character, index| {
        std.debug.print(&quot;character: {}, index: {}, :{s} \n&quot;, .{ character, index, @typeName(@TypeOf(character)) });
    }
    _ = i;
}
--&gt;

=== テスト ===
=== 変数 ===
=== 制御構造 ===
[TODO:Zig の制御構造は文ではなく式]
==== 分岐 ====
[TODO:ifとswitch]
==== 反復 ====
[TODO:whileとfor]
=== 関数 ===
=== エラー ===
=== 演算子 ===
==== 優先順位 ====
高
&lt;syntaxhighlight lang=text line&gt;
 x() x[] x.y x.* x.?
 a!b
 x{}
 !x -x -%x ~x &amp;x ?x
 * / % ** *% *| ||
 + - ++ +% -% +| -|
 &lt;&lt; &gt;&gt; &lt;&lt;|
 &amp; ^ | orelse catch
 == != &lt; &gt; &lt;= &gt;=
 and
 or
 = *= *%= *|= /= %= += +%= +|= -= -%= -|= &lt;&lt;= &lt;&lt;|= &gt;&gt;= &amp;= ^= |=
&lt;/syntaxhighlight&gt;
低

===  optional type ===
===  opaque ===
訳語未定
=== ブロック ===
[TODO:スコープとシャドーイング；deferはここ？]
=== キャスト ===
[TODO:Zig は強い型付け()； 型強制 (Type coercion) について]
=== アセンブリ言語との連携 ===
[TODO:所謂インラインアセンラ]
=== atomic ===
=== 非同期関数 ===
=== 組込み関数 ===
[TODO:組込み関数は、@で始まり、@TypeOfや@alignOfの他@sinや@memcpyも組込み関数]
=== メモリ管理 ===
=== キーワード一覧 ===
&lt;code&gt;align&lt;/code&gt;
&lt;code&gt;allowzero&lt;/code&gt;
&lt;code&gt;and&lt;/code&gt;
&lt;code&gt;anyframe&lt;/code&gt;
&lt;code&gt;anytype&lt;/code&gt;
&lt;code&gt;asm&lt;/code&gt;
&lt;code&gt;async&lt;/code&gt;
&lt;code&gt;await&lt;/code&gt;
&lt;code&gt;break&lt;/code&gt;
&lt;code&gt;catch&lt;/code&gt;
&lt;code&gt;comptime&lt;/code&gt;
&lt;code&gt;const&lt;/code&gt;
&lt;code&gt;continue&lt;/code&gt;
&lt;code&gt;defer&lt;/code&gt;
&lt;code&gt;else&lt;/code&gt;
&lt;code&gt;enum&lt;/code&gt;
&lt;code&gt;errdefer&lt;/code&gt;
&lt;code&gt;error&lt;/code&gt;
&lt;code&gt;export&lt;/code&gt;
&lt;code&gt;extern&lt;/code&gt;
&lt;code&gt;fn&lt;/code&gt;
&lt;code&gt;for&lt;/code&gt;
&lt;code&gt;if&lt;/code&gt;
&lt;code&gt;inline&lt;/code&gt;
&lt;code&gt;noalias&lt;/code&gt;
&lt;code&gt;nosuspend&lt;/code&gt;
&lt;code&gt;or&lt;/code&gt;
&lt;code&gt;orelse&lt;/code&gt;
&lt;code&gt;packed&lt;/code&gt;
&lt;code&gt;pub&lt;/code&gt;
&lt;code&gt;resume&lt;/code&gt;
&lt;code&gt;return&lt;/code&gt;
&lt;code&gt;linksection&lt;/code&gt;
&lt;code&gt;struct&lt;/code&gt;
&lt;code&gt;suspend&lt;/code&gt;
&lt;code&gt;switch&lt;/code&gt;
&lt;code&gt;test&lt;/code&gt;
&lt;code&gt;threadlocal&lt;/code&gt;
&lt;code&gt;try&lt;/code&gt;
&lt;code&gt;union&lt;/code&gt;
&lt;code&gt;unreachable&lt;/code&gt;
&lt;code&gt;usingnamespace&lt;/code&gt;
&lt;code&gt;var&lt;/code&gt;
&lt;code&gt;volatile&lt;/code&gt;
&lt;code&gt;while&lt;/code&gt;

== チートシート ==
[TODO:文法と型と頻用する標準ライブラリの関数と型のアンチョコ]

== リファレンス篇 ==

== 脚註 ==
&lt;references /&gt;

== 外部リンク ==
* [https://ziglang.org/ Home ⚡ Zig Programming Language] {{---}} 公式サイト
** [[https://ziglang.org/documentation/master/ Zig Language Reference]] {{---}} リファレンスマニュアル
* [https://github.com/ziglang/zig ziglang/zig: General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.] {{---}} 公式リポジトリ
* [https://zig-play.dev/ Zig Playground] {{---}} オンライン実行環境
** [https://github.com/gsquire/zig-play About An online Zig compiler inspired by Go and Rust] {{---}} リポジトリ

[[Category:zig|*]]
[[Category:プログラミング言語]]</text>
      <sha1>id1w3kkmrmlw7n1b6hnre33uvohimlg</sha1>
    </revision>
    <revision>
      <id>205768</id>
      <parentid>205767</parentid>
      <timestamp>2022-07-24T06:50:17Z</timestamp>
      <contributor>
        <username>すじにくシチュー</username>
        <id>12058</id>
      </contributor>
      <minor />
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="21683" xml:space="preserve">{{Pathnav|メインページ|工学|情報技術|プログラミング|frame=1}}
{{Wikipedia|Zig (プログラミング言語)}}
本書は、[[w:Zig|Zig]]のチュートリアルです。
Zigは、堅牢で最適かつ再利用可能なソフトウェアを維持するための汎用プログラミング言語およびツールチェインです&lt;ref&gt;{{Cite web
|url=https://ziglang.org/
|title=Home ⚡ Zig Programming Language
|website=ziglang.org
|accessdate=2022-07-17
|cite=Zig is a general-purpose programming language and toolchain for maintaining '''robust''', '''optimal''' and '''reusable''' software.
}}&lt;/ref&gt;。
Zigは、アンドリュー・ケリー( ''[https://andrewkelley.me/ Andrew Kelley]'' )によって設計され、汎用システムプログラミング言語で、静的で強い型付けで型推論とジェネリックプログラミングをサポートします。

== 概要 ==
Zigは、2016年2月に発表された比較的若いプログラミング言語で&lt;ref&gt;{{Cite web
|last1=Kelley
|first1=Andrew
|title=Introduction to the Zig Programming Language
|url=https://andrewkelley.me/post/intro-to-zig.html
|website=andrewkelley.me
|accessdate=2022-07-17
}}&lt;/ref&gt;、2022年7月現在のバージョンは 0.9.1 で、'''''pre-release''''' と位置づけられています&lt;ref&gt;{{Cite web
|url=https://github.com/ziglang/zig/releases
|title=Releases · ziglang/zig
|website=github.com
|accessdate=2022-07-17
}}&lt;/ref&gt;。このため [[W:Hello world|Hello world]] ですら、バージョン間で互換性がなくなることもあり、リリースバージョンまでは言語仕様やライブラリーおよびツールチェインの仕様が変更される可能性があります。

=== Hello world の変遷 ===
[https://ziglang.org/documentation/master/ Zig Language Reference]の、[[W:Hello world|Hello world]]の変遷（新しい順）。

;master@2022-07-17&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/master/#Hello-World
|title=Zig Documentation(master@2022-07-17)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.8.1に同じ
;0.9.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.9.1/#Hello-World
|title=Zig Documentation(0.9.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.8.1に同じ
;0.8.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.8.1/#Hello-World
|title=Zig Documentation(0.8.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=4&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().writer();
    try stdout.print(&quot;Hello, {s}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: &lt;code&gt;{}&lt;/code&gt; ⇒ &lt;code&gt;{s}&lt;/code&gt;&lt;ref&gt;{{Cite web
|url=https://ziglang.org/download/0.8.0/release-notes.html#Formatted-Printing
|title=0.8.0 Release Notes
|website=ziglang.org
|accessdate=2022-07-17
|quote=Disable the special casing of {} for u8 slices/arrays. Unless {s} is specified the contents won't be treated as a string.
}}&lt;/ref&gt;
;0.7.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.7.1/#Hello-World
|title=Zig Documentation(0.7.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=3&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().writer();
    try stdout.print(&quot;Hello, {}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: s/outStream/writer/
;0.6.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.6.0/#Hello-World
|title=Zig Documentation(0.6.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=3&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().outStream();
    try stdout.print(&quot;Hello, {}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: 初期化の初期値から &lt;code&gt;try&lt;/code&gt; がなくなった。
;0.4.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.4.0/#Hello-World
|title=Zig Documentation(0.4.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.2.0に同じ
;0.5.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.5.0/#Hello-World
|title=Zig Documentation(0.5.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=4&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    // If this program is run without stdout attached, exit with an error.
    const stdout_file = try std.io.getStdOut();
    // If this program encounters pipe failure when printing to stdout, exit
    // with an error.
    try stdout_file.write(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;
: &lt;var&gt;stdout_file&lt;/var&gt; が &lt;code&gt;var&lt;/code&gt; から &lt;code&gt;const&lt;/code&gt; に変更された。

;0.3.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.3.0/#Hello-World
|title=Zig Documentation(0.3.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.2.0に同じ
;0.2.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.2.0/#Hello-World
|title=Zig Documentation(0.2.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    // If this program is run without stdout attached, exit with an error.
    var stdout_file = try std.io.getStdOut();
    // If this program encounters pipe failure when printing to stdout, exit
    // with an error.
    try stdout_file.write(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;
;0.1.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.1.1/#hello-world
|title=Zig Documentation
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig&gt;
const io = @import(&quot;std&quot;).io;
pub fn main() -&gt; %void {
    %%io.stdout.printf(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;

== 環境準備 ==
=== Linuxの場合 ===
==== インストール方法 ====
Fedora 36 の場合、2022年の時点で、コマンド
 sudo dnf install zig
だけでインストールできる事を確認。

その他のOS環境でのインストールについては、[https://github.com/ziglang/zig/wiki/Install-Zig-from-a-Package-Manager  GitHub  &quot;ziglang /zig&quot; ] を参照せよ。

インストールできたと思ったら、バージョン確認コマンドなどで、インストールの成否を確認しよう。コマンド
 zig version
で確認できる。

なお、2022年7月現在、まだバージョンは1未満であり、同7月に実験したところ
 0.9.1
であった。上記のセクションでも掛かれているように2022年の段階ではまだプレリリースであるので、1未満でもインストール成功なので安心していい。

==== コードの実行方法 ====
=== 値と型 ===
[TOD0:整数・浮動小数・論理値・文字列・共用体・構造体・列挙・配列・ベクトル・スライス・ポインター・ゼロビットな型]

:&lt;syntaxhighlight lang=&quot;zig&quot;&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot;abcd \n&quot;, .{} );
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
abcd 
&lt;/syntaxhighlight&gt;

2022年7月現在、引用符中に変数をなにも使っていなくても、&lt;code&gt;.{}&lt;/code&gt;が必要である。ほか&lt;code&gt;try print&lt;/code&gt; の &lt;code&gt;try&lt;/code&gt; については、&lt;code&gt;try&lt;/code&gt;がないとエラーになる。

:&lt;syntaxhighlight lang=&quot;zig&quot;&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot; (1) = {}\n&quot;, .{42});
    try print(&quot; (2) = {}\n&quot;, .{0x17});
    try print(&quot; (3) = {}\n&quot;, .{0o17});
    try print(&quot; (4) = {}\n&quot;, .{0b0100101});
    try print(&quot; (5) = {}\n&quot;, .{1e222});
    try print(&quot; (6) = {}\n&quot;, .{3.1415926536});
    try print(&quot; (7) = {}\n&quot;, .{'c'});
    try print(&quot; (8) = {c}\n&quot;, .{'c'});
    try print(&quot; (9) = {s}\n&quot;, .{&quot;abcdef&quot;});
    try print(&quot;(10) = {}, {}\n&quot;, .{ 111, 999 });
    try print(&quot;(11) = {1}, {0}\n&quot;, .{ 111, 999 });
    try print(&quot;(12) = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; });
    try print(&quot;(13) = {0d}, {0b}, {0o}, {0x}, {0X}\n&quot;, .{ 123 });
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
 (1) = 42
 (2) = 23
 (3) = 15
 (4) = 37
 (5) = 1.0e+222
 (6) = 3.1415926536e+00
 (7) = 99
 (8) = c
 (9) = abcdef
(10) = 111, 999
(11) = 999, 111
(12) = abc, 111
(13) = 123, 1111011, 173, 7b, 7B
&lt;/syntaxhighlight&gt;
&lt;!-- リテラルの例、というか、@import(&quot;std&quot;).io.getStdOut().writer().print の例になっていますね。--&gt;
ご覧のように、数値（整数と浮動小数点数）や文字・文字列のリテラルがあり、整数は基数を、浮動小数点数は指数表現と小数表現があります。

@import(&quot;std&quot;).io.getStdOut().writer().printの、第一引数は書式化文字列、第二引数は値リストです。
書式化文字列は、通常の文字列ですが &lt;code&gt;{&lt;/code&gt; と &lt;code&gt;}&lt;/code&gt; で囲まれたプレスホルダーが、引数リストの値（を書式化した文字列）に置換わります。
一番素朴なプレスホルダーは {} で、引数の値の一般的な文字列表記に置き換ります（整数なら十進数表記、浮動小数点数なら指数表記）。
ところが、’c’ のような文字型を {} に適用すると文字コード化され整数と同じ十進数表記になってしまいます。そこで、文字型の場合は {c} と文字であることを明記すると文字表現となります。
また、文字列の間合いは {s} を明記しないと（バージョン0.8.0からは）エラーになります。
2つ以上の値を渡す場合は、第二引数を　.{ 1, 2, 3 } の様にカンマ区切りのリストにします（ {} の前の . （点）を忘れがち）。
基本的に、左から順にプレスホルダーにリストの値が左から与えられますが、{0} {1} の書式で参照する引数の順位を明示できます。
書式指定と併用する時は、 &lt;code&gt; print(&quot;? = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; })&lt;/code&gt; の様に順位が先、書式指定文字が後になります。

[TODO:[https://github.com/ziglang/zig/blob/master/lib/std/fmt.zig master/lib/std/fmt.zig]を観て書いています。参照すべき標準ライブラリのドキュメントを発見出来たら、見直し]
[TODO:表組み]

==== comptime ====
Zigでは、コンパイル時に式が既知かどうかという概念を重要視しています。

下記コードはコンパイル等がエラーになります。
:&lt;syntaxhighlight lang=&quot;zig&quot; line highlight=7&gt;
fn mul(x: usize, y: usize) usize {
    return x * y;
}

pub fn main() void {
    const len : usize = mul(3, 4);
    const ary: [len]i32 = undefined;
    _ = ary;
}
&lt;/syntaxhighlight&gt;
;コンパイル結果:&lt;syntaxhighlight lang=text&gt;
An error occurred: 
/tmp/playground130713503/play.zig:7:17: error: unable to evaluate constant expression 
    const ary: [len]i32 = undefined;
&lt;/syntaxhighlight&gt;
: 「定数式が評価できない 」と宣っています。
: [[C++]]であれば、constexprが適用なケースですが、Zigでは次のような解決方法を取ります。下記コードはエラーになりません。

:&lt;syntaxhighlight lang=&quot;zig&quot; line highlight=6&gt;
fn mul(x: usize, y: usize) usize {
    return x * y;
}

pub fn main() void {
    const len : usize = comptime mul(3, 4); // mul の前に comptime を追加 
    const ary: [len]i32 = undefined;
    _ = ary;
}
&lt;/syntaxhighlight&gt;
:変更点は mul() の呼出しを comptime で修飾しただけです。comptime は、修飾子式を'''コンパイル時に実行する'''修飾子で、式の中でコンパイル時に未定な値が参照されると、エラーとなります。ここでは、数リテラル同士の商を求めているので、コンパイル時値が確定できます。
: _ = ary は、「定義済だが参照のない変数宣言」をサプレッスするときのイディオムです。

&lt;!--
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const i = 0;
    const string = [_]i32{ 1, 2, 3, 4 };
    for (string) |character, index| {
        std.debug.print(&quot;character: {}, index: {}, :{s} \n&quot;, .{ character, index, @typeName(@TypeOf(character)) });
    }
    _ = i;
}
--&gt;

===== インタプリタ的に実行する場合 =====
コンパイル済みファイルの作成を飛ばして、インタプリタ的に直接に実行する方法もあり、たとえばファイル名「hello.zig」なら下記のようなコマンドある。
 zig run hello.zig


===== プロジェクト作成する場合 =====
まず、プロジェクト関連のコマンドを実行すると、自動で数個のフォルダが作成されるので、それをまとめるためのフォルダを別に作っておき（たとえば proj とする）、べつにマウス右クリックでも mldir コマンドでもなんでもいいので proj ディレクトリを作成しておく。

そして、さらにカレント・ディレクトリを proj に移動するために、ターミナルでコマンド
 cd proj
で、そこに移動する。（そうしないと、今後の動作でホームフォルダにいくつものフォルダやファイルが作成され、管理しづらくなる）

その上で、プロジェクト作成のために
 zig init-exe
を行う。このコマンドにより、初期設定ファイルなどがいくつか自動的に作成される。

== 基礎篇 ==
[TODO:書くべき項目を並べてみましたが、例えば「値と型」を網羅的に書いていくと文章量が爆発するのが目に見えているので、過剰になったらリファレンス篇に移動するなどの方法で、各節はコンパクトさを心がけたいです。]

=== コメント ===
Zigでは、&lt;code&gt;//&lt;/code&gt; から行末までがコメントです。
C言語の &lt;code&gt;/* … */&lt;/code&gt; のスタイルの複数行に渡るコメントは'''ありません'''。
これは、コードの各行を文脈に関係なくトークン化できるようにするためです。
:&lt;syntaxhighlight lang=zig&gt;
// @import は組込み関数です。
const std = @import(&quot;std&quot;); // 先頭に @ が付く関数は組込み関数です
pub fn main() !void {
   try std.io.getStdOut().writeAll(&quot;Hello, World!\n&quot;);
}
&lt;/syntaxhighlight&gt;

==== Docコメント ====
Zigでは、&lt;code&gt;///&lt;/code&gt; から始まるコメントは特別なコメントで、Docコメント( ''Doc comments'' )と呼ばれます。
Docコメントは特定の場所にしか許されません。式の途中や非Docコメントの直前など、予想外の場所にdocコメントがあると、コンパイルエラーになります。

[TODO:サンプルコードと整形結果]

==== トップレベルDocコメント ====
Zigでは、&lt;code&gt;//!&lt;/code&gt; から始まるコメントは特別なコメントで、トップレベルDocコメント( ''Top-Level Doc Comments '' )と呼ばれます。
コンテナレベルのドキュメントのように、直後のドキュメントに属さないユーザードキュメントに、トップレベルDocコメントを使います。

[TODO:サンプルコードと整形結果]

DocコメントおよびトップレベルDocコメントは、コンパイル時に zig build-exe -femit-docs ソースファイル.zig の様に、-femit-docs をあたえると、 docs/ 以下にドキュメントが生成されます。

=== 値と型 ===
[TOD0:整数・浮動小数・論理値・文字列・共用体・構造体・列挙・配列・ベクトル・スライス・ポインター・ゼロビットな型]

:&lt;syntaxhighlight lang=zig&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot; (1) = {}\n&quot;, .{42});
    try print(&quot; (2) = {}\n&quot;, .{0x17});
    try print(&quot; (3) = {}\n&quot;, .{0o17});
    try print(&quot; (4) = {}\n&quot;, .{0b0100101});
    try print(&quot; (5) = {}\n&quot;, .{1e222});
    try print(&quot; (6) = {}\n&quot;, .{3.1415926536});
    try print(&quot; (7) = {}\n&quot;, .{'c'});
    try print(&quot; (8) = {c}\n&quot;, .{'c'});
    try print(&quot; (9) = {s}\n&quot;, .{&quot;abcdef&quot;});
    try print(&quot;(10) = {}, {}\n&quot;, .{ 111, 999 });
    try print(&quot;(11) = {1}, {0}\n&quot;, .{ 111, 999 });
    try print(&quot;(12) = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; });
    try print(&quot;(13) = {0d}, {0b}, {0o}, {0x}, {0X}\n&quot;, .{ 123 });
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
 (1) = 42
 (2) = 23
 (3) = 15
 (4) = 37
 (5) = 1.0e+222
 (6) = 3.1415926536e+00
 (7) = 99
 (8) = c
 (9) = abcdef
(10) = 111, 999
(11) = 999, 111
(12) = abc, 111
(13) = 123, 1111011, 173, 7b, 7B
&lt;/syntaxhighlight&gt;
&lt;!-- リテラルの例、というか、@import(&quot;std&quot;).io.getStdOut().writer().print の例になっていますね。--&gt;
ご覧のように、数値（整数と浮動小数点数）や文字・文字列のリテラルがあり、整数は基数を、浮動小数点数は指数表現と少数表現があります。

@import(&quot;std&quot;).io.getStdOut().writer().printの、第一引数は書式化文字列、第二引数は値リストです。
書式化文字列は、通常の文字列ですが &lt;code&gt;{&lt;/code&gt; と &lt;code&gt;}&lt;/code&gt; で囲まれたプレスホルダーが、引数リストの値（を書式化した文字列）に置換わります。
一番素朴なプレスホルダーは {} で、引数の値の一般的な文字列表記に置き換ります（整数なら十進数表記、浮動小数点数なら指数表記）。
ところが、’c’ のような文字型を {} に適用すると文字コード化され整数と同じ十進数表記になってしまいます。そこで、文字型の場合は {c} と文字であることを明記すると文字表現となります。
また、文字列の間合いは {s} を明記しないと（バージョン0.8.0からは）エラーになります。
2つ以上の値を渡す場合は、第二引数を　.{ 1, 2, 3 } の様にカンマ区切りのリストにします（ これが、Zig の配列リテラルの表現で、{} の前の . （点）を忘れがち）。
基本的に、左から順にプレスホルダーにリストの値が左から与えられますが、{0} {1} の書式で参照する引数の順位を明示できます。
書式指定と併用する時は、 &lt;code&gt; print(&quot;? = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; })&lt;/code&gt; の様に順位が先、書式指定文字が後になります。

[TODO:[https://github.com/ziglang/zig/blob/master/lib/std/fmt.zig master/lib/std/fmt.zig]を観て書いています。参照すべき標準ライブラリのドキュメントを発見出来たら、見直し]
[TODO:表組み]

==== comptime ====
Zigでは、コンパイル時に式が既知かどうかという概念を重要視しています。

&lt;!--
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const i = 0;
    const string = [_]i32{ 1, 2, 3, 4 };
    for (string) |character, index| {
        std.debug.print(&quot;character: {}, index: {}, :{s} \n&quot;, .{ character, index, @typeName(@TypeOf(character)) });
    }
    _ = i;
}
--&gt;

=== テスト ===
=== 変数 ===
=== 制御構造 ===
[TODO:Zig の制御構造は文ではなく式]
==== 分岐 ====
[TODO:ifとswitch]
==== 反復 ====
[TODO:whileとfor]
=== 関数 ===
=== エラー ===
=== 演算子 ===
==== 優先順位 ====
高
&lt;syntaxhighlight lang=text line&gt;
 x() x[] x.y x.* x.?
 a!b
 x{}
 !x -x -%x ~x &amp;x ?x
 * / % ** *% *| ||
 + - ++ +% -% +| -|
 &lt;&lt; &gt;&gt; &lt;&lt;|
 &amp; ^ | orelse catch
 == != &lt; &gt; &lt;= &gt;=
 and
 or
 = *= *%= *|= /= %= += +%= +|= -= -%= -|= &lt;&lt;= &lt;&lt;|= &gt;&gt;= &amp;= ^= |=
&lt;/syntaxhighlight&gt;
低

===  optional type ===
===  opaque ===
訳語未定
=== ブロック ===
[TODO:スコープとシャドーイング；deferはここ？]
=== キャスト ===
[TODO:Zig は強い型付け()； 型強制 (Type coercion) について]
=== アセンブリ言語との連携 ===
[TODO:所謂インラインアセンラ]
=== atomic ===
=== 非同期関数 ===
=== 組込み関数 ===
[TODO:組込み関数は、@で始まり、@TypeOfや@alignOfの他@sinや@memcpyも組込み関数]
=== メモリ管理 ===
=== キーワード一覧 ===
&lt;code&gt;align&lt;/code&gt;
&lt;code&gt;allowzero&lt;/code&gt;
&lt;code&gt;and&lt;/code&gt;
&lt;code&gt;anyframe&lt;/code&gt;
&lt;code&gt;anytype&lt;/code&gt;
&lt;code&gt;asm&lt;/code&gt;
&lt;code&gt;async&lt;/code&gt;
&lt;code&gt;await&lt;/code&gt;
&lt;code&gt;break&lt;/code&gt;
&lt;code&gt;catch&lt;/code&gt;
&lt;code&gt;comptime&lt;/code&gt;
&lt;code&gt;const&lt;/code&gt;
&lt;code&gt;continue&lt;/code&gt;
&lt;code&gt;defer&lt;/code&gt;
&lt;code&gt;else&lt;/code&gt;
&lt;code&gt;enum&lt;/code&gt;
&lt;code&gt;errdefer&lt;/code&gt;
&lt;code&gt;error&lt;/code&gt;
&lt;code&gt;export&lt;/code&gt;
&lt;code&gt;extern&lt;/code&gt;
&lt;code&gt;fn&lt;/code&gt;
&lt;code&gt;for&lt;/code&gt;
&lt;code&gt;if&lt;/code&gt;
&lt;code&gt;inline&lt;/code&gt;
&lt;code&gt;noalias&lt;/code&gt;
&lt;code&gt;nosuspend&lt;/code&gt;
&lt;code&gt;or&lt;/code&gt;
&lt;code&gt;orelse&lt;/code&gt;
&lt;code&gt;packed&lt;/code&gt;
&lt;code&gt;pub&lt;/code&gt;
&lt;code&gt;resume&lt;/code&gt;
&lt;code&gt;return&lt;/code&gt;
&lt;code&gt;linksection&lt;/code&gt;
&lt;code&gt;struct&lt;/code&gt;
&lt;code&gt;suspend&lt;/code&gt;
&lt;code&gt;switch&lt;/code&gt;
&lt;code&gt;test&lt;/code&gt;
&lt;code&gt;threadlocal&lt;/code&gt;
&lt;code&gt;try&lt;/code&gt;
&lt;code&gt;union&lt;/code&gt;
&lt;code&gt;unreachable&lt;/code&gt;
&lt;code&gt;usingnamespace&lt;/code&gt;
&lt;code&gt;var&lt;/code&gt;
&lt;code&gt;volatile&lt;/code&gt;
&lt;code&gt;while&lt;/code&gt;

== チートシート ==
[TODO:文法と型と頻用する標準ライブラリの関数と型のアンチョコ]

== リファレンス篇 ==

== 脚註 ==
&lt;references /&gt;

== 外部リンク ==
* [https://ziglang.org/ Home ⚡ Zig Programming Language] {{---}} 公式サイト
** [[https://ziglang.org/documentation/master/ Zig Language Reference]] {{---}} リファレンスマニュアル
* [https://github.com/ziglang/zig ziglang/zig: General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.] {{---}} 公式リポジトリ
* [https://zig-play.dev/ Zig Playground] {{---}} オンライン実行環境
** [https://github.com/gsquire/zig-play About An online Zig compiler inspired by Go and Rust] {{---}} リポジトリ

[[Category:zig|*]]
[[Category:プログラミング言語]]</text>
      <sha1>4yie9xj92loommunr5kbroq4yt35mou</sha1>
    </revision>
    <revision>
      <id>205769</id>
      <parentid>205768</parentid>
      <timestamp>2022-07-24T06:56:08Z</timestamp>
      <contributor>
        <username>すじにくシチュー</username>
        <id>12058</id>
      </contributor>
      <comment>/* 値と型 */ 13個もあるリストの中から話題の内容を見つけるのは面倒なので、文章中で何番の話かを追記。</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="22001" xml:space="preserve">{{Pathnav|メインページ|工学|情報技術|プログラミング|frame=1}}
{{Wikipedia|Zig (プログラミング言語)}}
本書は、[[w:Zig|Zig]]のチュートリアルです。
Zigは、堅牢で最適かつ再利用可能なソフトウェアを維持するための汎用プログラミング言語およびツールチェインです&lt;ref&gt;{{Cite web
|url=https://ziglang.org/
|title=Home ⚡ Zig Programming Language
|website=ziglang.org
|accessdate=2022-07-17
|cite=Zig is a general-purpose programming language and toolchain for maintaining '''robust''', '''optimal''' and '''reusable''' software.
}}&lt;/ref&gt;。
Zigは、アンドリュー・ケリー( ''[https://andrewkelley.me/ Andrew Kelley]'' )によって設計され、汎用システムプログラミング言語で、静的で強い型付けで型推論とジェネリックプログラミングをサポートします。

== 概要 ==
Zigは、2016年2月に発表された比較的若いプログラミング言語で&lt;ref&gt;{{Cite web
|last1=Kelley
|first1=Andrew
|title=Introduction to the Zig Programming Language
|url=https://andrewkelley.me/post/intro-to-zig.html
|website=andrewkelley.me
|accessdate=2022-07-17
}}&lt;/ref&gt;、2022年7月現在のバージョンは 0.9.1 で、'''''pre-release''''' と位置づけられています&lt;ref&gt;{{Cite web
|url=https://github.com/ziglang/zig/releases
|title=Releases · ziglang/zig
|website=github.com
|accessdate=2022-07-17
}}&lt;/ref&gt;。このため [[W:Hello world|Hello world]] ですら、バージョン間で互換性がなくなることもあり、リリースバージョンまでは言語仕様やライブラリーおよびツールチェインの仕様が変更される可能性があります。

=== Hello world の変遷 ===
[https://ziglang.org/documentation/master/ Zig Language Reference]の、[[W:Hello world|Hello world]]の変遷（新しい順）。

;master@2022-07-17&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/master/#Hello-World
|title=Zig Documentation(master@2022-07-17)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.8.1に同じ
;0.9.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.9.1/#Hello-World
|title=Zig Documentation(0.9.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.8.1に同じ
;0.8.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.8.1/#Hello-World
|title=Zig Documentation(0.8.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=4&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().writer();
    try stdout.print(&quot;Hello, {s}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: &lt;code&gt;{}&lt;/code&gt; ⇒ &lt;code&gt;{s}&lt;/code&gt;&lt;ref&gt;{{Cite web
|url=https://ziglang.org/download/0.8.0/release-notes.html#Formatted-Printing
|title=0.8.0 Release Notes
|website=ziglang.org
|accessdate=2022-07-17
|quote=Disable the special casing of {} for u8 slices/arrays. Unless {s} is specified the contents won't be treated as a string.
}}&lt;/ref&gt;
;0.7.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.7.1/#Hello-World
|title=Zig Documentation(0.7.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=3&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().writer();
    try stdout.print(&quot;Hello, {}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: s/outStream/writer/
;0.6.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.6.0/#Hello-World
|title=Zig Documentation(0.6.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=3&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().outStream();
    try stdout.print(&quot;Hello, {}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: 初期化の初期値から &lt;code&gt;try&lt;/code&gt; がなくなった。
;0.4.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.4.0/#Hello-World
|title=Zig Documentation(0.4.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.2.0に同じ
;0.5.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.5.0/#Hello-World
|title=Zig Documentation(0.5.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=4&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    // If this program is run without stdout attached, exit with an error.
    const stdout_file = try std.io.getStdOut();
    // If this program encounters pipe failure when printing to stdout, exit
    // with an error.
    try stdout_file.write(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;
: &lt;var&gt;stdout_file&lt;/var&gt; が &lt;code&gt;var&lt;/code&gt; から &lt;code&gt;const&lt;/code&gt; に変更された。

;0.3.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.3.0/#Hello-World
|title=Zig Documentation(0.3.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.2.0に同じ
;0.2.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.2.0/#Hello-World
|title=Zig Documentation(0.2.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    // If this program is run without stdout attached, exit with an error.
    var stdout_file = try std.io.getStdOut();
    // If this program encounters pipe failure when printing to stdout, exit
    // with an error.
    try stdout_file.write(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;
;0.1.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.1.1/#hello-world
|title=Zig Documentation
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig&gt;
const io = @import(&quot;std&quot;).io;
pub fn main() -&gt; %void {
    %%io.stdout.printf(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;

== 環境準備 ==
=== Linuxの場合 ===
==== インストール方法 ====
Fedora 36 の場合、2022年の時点で、コマンド
 sudo dnf install zig
だけでインストールできる事を確認。

その他のOS環境でのインストールについては、[https://github.com/ziglang/zig/wiki/Install-Zig-from-a-Package-Manager  GitHub  &quot;ziglang /zig&quot; ] を参照せよ。

インストールできたと思ったら、バージョン確認コマンドなどで、インストールの成否を確認しよう。コマンド
 zig version
で確認できる。

なお、2022年7月現在、まだバージョンは1未満であり、同7月に実験したところ
 0.9.1
であった。上記のセクションでも掛かれているように2022年の段階ではまだプレリリースであるので、1未満でもインストール成功なので安心していい。

==== コードの実行方法 ====
=== 値と型 ===
[TOD0:整数・浮動小数・論理値・文字列・共用体・構造体・列挙・配列・ベクトル・スライス・ポインター・ゼロビットな型]

:&lt;syntaxhighlight lang=&quot;zig&quot;&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot;abcd \n&quot;, .{} );
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
abcd 
&lt;/syntaxhighlight&gt;

2022年7月現在、引用符中に変数をなにも使っていなくても、&lt;code&gt;.{}&lt;/code&gt;が必要である。ほか&lt;code&gt;try print&lt;/code&gt; の &lt;code&gt;try&lt;/code&gt; については、&lt;code&gt;try&lt;/code&gt;がないとエラーになる。

:&lt;syntaxhighlight lang=&quot;zig&quot;&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot; (1) = {}\n&quot;, .{42});
    try print(&quot; (2) = {}\n&quot;, .{0x17});
    try print(&quot; (3) = {}\n&quot;, .{0o17});
    try print(&quot; (4) = {}\n&quot;, .{0b0100101});
    try print(&quot; (5) = {}\n&quot;, .{1e222});
    try print(&quot; (6) = {}\n&quot;, .{3.1415926536});
    try print(&quot; (7) = {}\n&quot;, .{'c'});
    try print(&quot; (8) = {c}\n&quot;, .{'c'});
    try print(&quot; (9) = {s}\n&quot;, .{&quot;abcdef&quot;});
    try print(&quot;(10) = {}, {}\n&quot;, .{ 111, 999 });
    try print(&quot;(11) = {1}, {0}\n&quot;, .{ 111, 999 });
    try print(&quot;(12) = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; });
    try print(&quot;(13) = {0d}, {0b}, {0o}, {0x}, {0X}\n&quot;, .{ 123 });
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
 (1) = 42
 (2) = 23
 (3) = 15
 (4) = 37
 (5) = 1.0e+222
 (6) = 3.1415926536e+00
 (7) = 99
 (8) = c
 (9) = abcdef
(10) = 111, 999
(11) = 999, 111
(12) = abc, 111
(13) = 123, 1111011, 173, 7b, 7B
&lt;/syntaxhighlight&gt;
&lt;!-- リテラルの例、というか、@import(&quot;std&quot;).io.getStdOut().writer().print の例になっていますね。--&gt;
ご覧のように、数値（整数と浮動小数点数）や文字・文字列のリテラルがあり、整数は基数を、浮動小数点数は指数表現と小数表現があります。

@import(&quot;std&quot;).io.getStdOut().writer().printの、第一引数は書式化文字列、第二引数は値リストです。書式化文字列は、通常の文字列ですが &lt;code&gt;{&lt;/code&gt; と &lt;code&gt;}&lt;/code&gt; で囲まれたプレスホルダーが、引数リストの値（を書式化した文字列）に置き換わります。

一番素朴なプレスホルダーは {} で、引数の値の一般的な文字列表記に置き換ります（整数なら十進数表記、浮動小数点数なら指数表記）。ところが、’c’ のような文字型を &lt;code&gt;{}&lt;/code&gt; そのままに適用すると下記のように文字コード化され整数と同じ十進数表記になってしまいます。そこで、文字型の場合は {c} と文字であることを明記すると文字表現となります。

上記コードでは、次のような部分のことです。
:&lt;syntaxhighlight lang=&quot;zig&quot;&gt;
    try print(&quot; (7) = {}\n&quot;, .{'c'});
    try print(&quot; (8) = {c}\n&quot;, .{'c'});
&lt;/syntaxhighlight&gt;

;対応部分:&lt;syntaxhighlight lang=text&gt;
 (7) = 99
 (8) = c
&lt;/syntaxhighlight&gt;

また、文字列の間合いは {s} を明記しないと（バージョン0.8.0からは）エラーになります。
2つ以上の値を渡す場合は、第二引数を　.{ 1, 2, 3 } の様にカンマ区切りのリストにします（ {} の前の . （点）を忘れがち）。
基本的に、左から順にプレスホルダーにリストの値が左から与えられますが、{0} {1} の書式で参照する引数の順位を明示できます。
書式指定と併用する時は、 &lt;code&gt; print(&quot;? = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; })&lt;/code&gt; の様に順位が先、書式指定文字が後になります。

[TODO:[https://github.com/ziglang/zig/blob/master/lib/std/fmt.zig master/lib/std/fmt.zig]を観て書いています。参照すべき標準ライブラリのドキュメントを発見出来たら、見直し]
[TODO:表組み]

==== comptime ====
Zigでは、コンパイル時に式が既知かどうかという概念を重要視しています。

下記コードはコンパイル等がエラーになります。
:&lt;syntaxhighlight lang=&quot;zig&quot; line highlight=7&gt;
fn mul(x: usize, y: usize) usize {
    return x * y;
}

pub fn main() void {
    const len : usize = mul(3, 4);
    const ary: [len]i32 = undefined;
    _ = ary;
}
&lt;/syntaxhighlight&gt;
;コンパイル結果:&lt;syntaxhighlight lang=text&gt;
An error occurred: 
/tmp/playground130713503/play.zig:7:17: error: unable to evaluate constant expression 
    const ary: [len]i32 = undefined;
&lt;/syntaxhighlight&gt;
: 「定数式が評価できない 」と宣っています。
: [[C++]]であれば、constexprが適用なケースですが、Zigでは次のような解決方法を取ります。下記コードはエラーになりません。

:&lt;syntaxhighlight lang=&quot;zig&quot; line highlight=6&gt;
fn mul(x: usize, y: usize) usize {
    return x * y;
}

pub fn main() void {
    const len : usize = comptime mul(3, 4); // mul の前に comptime を追加 
    const ary: [len]i32 = undefined;
    _ = ary;
}
&lt;/syntaxhighlight&gt;
:変更点は mul() の呼出しを comptime で修飾しただけです。comptime は、修飾子式を'''コンパイル時に実行する'''修飾子で、式の中でコンパイル時に未定な値が参照されると、エラーとなります。ここでは、数リテラル同士の商を求めているので、コンパイル時値が確定できます。
: _ = ary は、「定義済だが参照のない変数宣言」をサプレッスするときのイディオムです。

&lt;!--
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const i = 0;
    const string = [_]i32{ 1, 2, 3, 4 };
    for (string) |character, index| {
        std.debug.print(&quot;character: {}, index: {}, :{s} \n&quot;, .{ character, index, @typeName(@TypeOf(character)) });
    }
    _ = i;
}
--&gt;

===== インタプリタ的に実行する場合 =====
コンパイル済みファイルの作成を飛ばして、インタプリタ的に直接に実行する方法もあり、たとえばファイル名「hello.zig」なら下記のようなコマンドある。
 zig run hello.zig


===== プロジェクト作成する場合 =====
まず、プロジェクト関連のコマンドを実行すると、自動で数個のフォルダが作成されるので、それをまとめるためのフォルダを別に作っておき（たとえば proj とする）、べつにマウス右クリックでも mldir コマンドでもなんでもいいので proj ディレクトリを作成しておく。

そして、さらにカレント・ディレクトリを proj に移動するために、ターミナルでコマンド
 cd proj
で、そこに移動する。（そうしないと、今後の動作でホームフォルダにいくつものフォルダやファイルが作成され、管理しづらくなる）

その上で、プロジェクト作成のために
 zig init-exe
を行う。このコマンドにより、初期設定ファイルなどがいくつか自動的に作成される。

== 基礎篇 ==
[TODO:書くべき項目を並べてみましたが、例えば「値と型」を網羅的に書いていくと文章量が爆発するのが目に見えているので、過剰になったらリファレンス篇に移動するなどの方法で、各節はコンパクトさを心がけたいです。]

=== コメント ===
Zigでは、&lt;code&gt;//&lt;/code&gt; から行末までがコメントです。
C言語の &lt;code&gt;/* … */&lt;/code&gt; のスタイルの複数行に渡るコメントは'''ありません'''。
これは、コードの各行を文脈に関係なくトークン化できるようにするためです。
:&lt;syntaxhighlight lang=zig&gt;
// @import は組込み関数です。
const std = @import(&quot;std&quot;); // 先頭に @ が付く関数は組込み関数です
pub fn main() !void {
   try std.io.getStdOut().writeAll(&quot;Hello, World!\n&quot;);
}
&lt;/syntaxhighlight&gt;

==== Docコメント ====
Zigでは、&lt;code&gt;///&lt;/code&gt; から始まるコメントは特別なコメントで、Docコメント( ''Doc comments'' )と呼ばれます。
Docコメントは特定の場所にしか許されません。式の途中や非Docコメントの直前など、予想外の場所にdocコメントがあると、コンパイルエラーになります。

[TODO:サンプルコードと整形結果]

==== トップレベルDocコメント ====
Zigでは、&lt;code&gt;//!&lt;/code&gt; から始まるコメントは特別なコメントで、トップレベルDocコメント( ''Top-Level Doc Comments '' )と呼ばれます。
コンテナレベルのドキュメントのように、直後のドキュメントに属さないユーザードキュメントに、トップレベルDocコメントを使います。

[TODO:サンプルコードと整形結果]

DocコメントおよびトップレベルDocコメントは、コンパイル時に zig build-exe -femit-docs ソースファイル.zig の様に、-femit-docs をあたえると、 docs/ 以下にドキュメントが生成されます。

=== 値と型 ===
[TOD0:整数・浮動小数・論理値・文字列・共用体・構造体・列挙・配列・ベクトル・スライス・ポインター・ゼロビットな型]

:&lt;syntaxhighlight lang=zig&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot; (1) = {}\n&quot;, .{42});
    try print(&quot; (2) = {}\n&quot;, .{0x17});
    try print(&quot; (3) = {}\n&quot;, .{0o17});
    try print(&quot; (4) = {}\n&quot;, .{0b0100101});
    try print(&quot; (5) = {}\n&quot;, .{1e222});
    try print(&quot; (6) = {}\n&quot;, .{3.1415926536});
    try print(&quot; (7) = {}\n&quot;, .{'c'});
    try print(&quot; (8) = {c}\n&quot;, .{'c'});
    try print(&quot; (9) = {s}\n&quot;, .{&quot;abcdef&quot;});
    try print(&quot;(10) = {}, {}\n&quot;, .{ 111, 999 });
    try print(&quot;(11) = {1}, {0}\n&quot;, .{ 111, 999 });
    try print(&quot;(12) = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; });
    try print(&quot;(13) = {0d}, {0b}, {0o}, {0x}, {0X}\n&quot;, .{ 123 });
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
 (1) = 42
 (2) = 23
 (3) = 15
 (4) = 37
 (5) = 1.0e+222
 (6) = 3.1415926536e+00
 (7) = 99
 (8) = c
 (9) = abcdef
(10) = 111, 999
(11) = 999, 111
(12) = abc, 111
(13) = 123, 1111011, 173, 7b, 7B
&lt;/syntaxhighlight&gt;
&lt;!-- リテラルの例、というか、@import(&quot;std&quot;).io.getStdOut().writer().print の例になっていますね。--&gt;
ご覧のように、数値（整数と浮動小数点数）や文字・文字列のリテラルがあり、整数は基数を、浮動小数点数は指数表現と少数表現があります。

@import(&quot;std&quot;).io.getStdOut().writer().printの、第一引数は書式化文字列、第二引数は値リストです。
書式化文字列は、通常の文字列ですが &lt;code&gt;{&lt;/code&gt; と &lt;code&gt;}&lt;/code&gt; で囲まれたプレスホルダーが、引数リストの値（を書式化した文字列）に置換わります。
一番素朴なプレスホルダーは {} で、引数の値の一般的な文字列表記に置き換ります（整数なら十進数表記、浮動小数点数なら指数表記）。
ところが、’c’ のような文字型を {} に適用すると文字コード化され整数と同じ十進数表記になってしまいます。そこで、文字型の場合は {c} と文字であることを明記すると文字表現となります。
また、文字列の間合いは {s} を明記しないと（バージョン0.8.0からは）エラーになります。
2つ以上の値を渡す場合は、第二引数を　.{ 1, 2, 3 } の様にカンマ区切りのリストにします（ これが、Zig の配列リテラルの表現で、{} の前の . （点）を忘れがち）。
基本的に、左から順にプレスホルダーにリストの値が左から与えられますが、{0} {1} の書式で参照する引数の順位を明示できます。
書式指定と併用する時は、 &lt;code&gt; print(&quot;? = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; })&lt;/code&gt; の様に順位が先、書式指定文字が後になります。

[TODO:[https://github.com/ziglang/zig/blob/master/lib/std/fmt.zig master/lib/std/fmt.zig]を観て書いています。参照すべき標準ライブラリのドキュメントを発見出来たら、見直し]
[TODO:表組み]

==== comptime ====
Zigでは、コンパイル時に式が既知かどうかという概念を重要視しています。

&lt;!--
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const i = 0;
    const string = [_]i32{ 1, 2, 3, 4 };
    for (string) |character, index| {
        std.debug.print(&quot;character: {}, index: {}, :{s} \n&quot;, .{ character, index, @typeName(@TypeOf(character)) });
    }
    _ = i;
}
--&gt;

=== テスト ===
=== 変数 ===
=== 制御構造 ===
[TODO:Zig の制御構造は文ではなく式]
==== 分岐 ====
[TODO:ifとswitch]
==== 反復 ====
[TODO:whileとfor]
=== 関数 ===
=== エラー ===
=== 演算子 ===
==== 優先順位 ====
高
&lt;syntaxhighlight lang=text line&gt;
 x() x[] x.y x.* x.?
 a!b
 x{}
 !x -x -%x ~x &amp;x ?x
 * / % ** *% *| ||
 + - ++ +% -% +| -|
 &lt;&lt; &gt;&gt; &lt;&lt;|
 &amp; ^ | orelse catch
 == != &lt; &gt; &lt;= &gt;=
 and
 or
 = *= *%= *|= /= %= += +%= +|= -= -%= -|= &lt;&lt;= &lt;&lt;|= &gt;&gt;= &amp;= ^= |=
&lt;/syntaxhighlight&gt;
低

===  optional type ===
===  opaque ===
訳語未定
=== ブロック ===
[TODO:スコープとシャドーイング；deferはここ？]
=== キャスト ===
[TODO:Zig は強い型付け()； 型強制 (Type coercion) について]
=== アセンブリ言語との連携 ===
[TODO:所謂インラインアセンラ]
=== atomic ===
=== 非同期関数 ===
=== 組込み関数 ===
[TODO:組込み関数は、@で始まり、@TypeOfや@alignOfの他@sinや@memcpyも組込み関数]
=== メモリ管理 ===
=== キーワード一覧 ===
&lt;code&gt;align&lt;/code&gt;
&lt;code&gt;allowzero&lt;/code&gt;
&lt;code&gt;and&lt;/code&gt;
&lt;code&gt;anyframe&lt;/code&gt;
&lt;code&gt;anytype&lt;/code&gt;
&lt;code&gt;asm&lt;/code&gt;
&lt;code&gt;async&lt;/code&gt;
&lt;code&gt;await&lt;/code&gt;
&lt;code&gt;break&lt;/code&gt;
&lt;code&gt;catch&lt;/code&gt;
&lt;code&gt;comptime&lt;/code&gt;
&lt;code&gt;const&lt;/code&gt;
&lt;code&gt;continue&lt;/code&gt;
&lt;code&gt;defer&lt;/code&gt;
&lt;code&gt;else&lt;/code&gt;
&lt;code&gt;enum&lt;/code&gt;
&lt;code&gt;errdefer&lt;/code&gt;
&lt;code&gt;error&lt;/code&gt;
&lt;code&gt;export&lt;/code&gt;
&lt;code&gt;extern&lt;/code&gt;
&lt;code&gt;fn&lt;/code&gt;
&lt;code&gt;for&lt;/code&gt;
&lt;code&gt;if&lt;/code&gt;
&lt;code&gt;inline&lt;/code&gt;
&lt;code&gt;noalias&lt;/code&gt;
&lt;code&gt;nosuspend&lt;/code&gt;
&lt;code&gt;or&lt;/code&gt;
&lt;code&gt;orelse&lt;/code&gt;
&lt;code&gt;packed&lt;/code&gt;
&lt;code&gt;pub&lt;/code&gt;
&lt;code&gt;resume&lt;/code&gt;
&lt;code&gt;return&lt;/code&gt;
&lt;code&gt;linksection&lt;/code&gt;
&lt;code&gt;struct&lt;/code&gt;
&lt;code&gt;suspend&lt;/code&gt;
&lt;code&gt;switch&lt;/code&gt;
&lt;code&gt;test&lt;/code&gt;
&lt;code&gt;threadlocal&lt;/code&gt;
&lt;code&gt;try&lt;/code&gt;
&lt;code&gt;union&lt;/code&gt;
&lt;code&gt;unreachable&lt;/code&gt;
&lt;code&gt;usingnamespace&lt;/code&gt;
&lt;code&gt;var&lt;/code&gt;
&lt;code&gt;volatile&lt;/code&gt;
&lt;code&gt;while&lt;/code&gt;

== チートシート ==
[TODO:文法と型と頻用する標準ライブラリの関数と型のアンチョコ]

== リファレンス篇 ==

== 脚註 ==
&lt;references /&gt;

== 外部リンク ==
* [https://ziglang.org/ Home ⚡ Zig Programming Language] {{---}} 公式サイト
** [[https://ziglang.org/documentation/master/ Zig Language Reference]] {{---}} リファレンスマニュアル
* [https://github.com/ziglang/zig ziglang/zig: General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.] {{---}} 公式リポジトリ
* [https://zig-play.dev/ Zig Playground] {{---}} オンライン実行環境
** [https://github.com/gsquire/zig-play About An online Zig compiler inspired by Go and Rust] {{---}} リポジトリ

[[Category:zig|*]]
[[Category:プログラミング言語]]</text>
      <sha1>8vd7qar7v0llhvtck9bvkxwqz5dzou5</sha1>
    </revision>
    <revision>
      <id>205770</id>
      <parentid>205769</parentid>
      <timestamp>2022-07-24T06:56:27Z</timestamp>
      <contributor>
        <username>すじにくシチュー</username>
        <id>12058</id>
      </contributor>
      <minor />
      <comment>/* 値と型 */</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="22000" xml:space="preserve">{{Pathnav|メインページ|工学|情報技術|プログラミング|frame=1}}
{{Wikipedia|Zig (プログラミング言語)}}
本書は、[[w:Zig|Zig]]のチュートリアルです。
Zigは、堅牢で最適かつ再利用可能なソフトウェアを維持するための汎用プログラミング言語およびツールチェインです&lt;ref&gt;{{Cite web
|url=https://ziglang.org/
|title=Home ⚡ Zig Programming Language
|website=ziglang.org
|accessdate=2022-07-17
|cite=Zig is a general-purpose programming language and toolchain for maintaining '''robust''', '''optimal''' and '''reusable''' software.
}}&lt;/ref&gt;。
Zigは、アンドリュー・ケリー( ''[https://andrewkelley.me/ Andrew Kelley]'' )によって設計され、汎用システムプログラミング言語で、静的で強い型付けで型推論とジェネリックプログラミングをサポートします。

== 概要 ==
Zigは、2016年2月に発表された比較的若いプログラミング言語で&lt;ref&gt;{{Cite web
|last1=Kelley
|first1=Andrew
|title=Introduction to the Zig Programming Language
|url=https://andrewkelley.me/post/intro-to-zig.html
|website=andrewkelley.me
|accessdate=2022-07-17
}}&lt;/ref&gt;、2022年7月現在のバージョンは 0.9.1 で、'''''pre-release''''' と位置づけられています&lt;ref&gt;{{Cite web
|url=https://github.com/ziglang/zig/releases
|title=Releases · ziglang/zig
|website=github.com
|accessdate=2022-07-17
}}&lt;/ref&gt;。このため [[W:Hello world|Hello world]] ですら、バージョン間で互換性がなくなることもあり、リリースバージョンまでは言語仕様やライブラリーおよびツールチェインの仕様が変更される可能性があります。

=== Hello world の変遷 ===
[https://ziglang.org/documentation/master/ Zig Language Reference]の、[[W:Hello world|Hello world]]の変遷（新しい順）。

;master@2022-07-17&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/master/#Hello-World
|title=Zig Documentation(master@2022-07-17)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.8.1に同じ
;0.9.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.9.1/#Hello-World
|title=Zig Documentation(0.9.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.8.1に同じ
;0.8.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.8.1/#Hello-World
|title=Zig Documentation(0.8.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=4&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().writer();
    try stdout.print(&quot;Hello, {s}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: &lt;code&gt;{}&lt;/code&gt; ⇒ &lt;code&gt;{s}&lt;/code&gt;&lt;ref&gt;{{Cite web
|url=https://ziglang.org/download/0.8.0/release-notes.html#Formatted-Printing
|title=0.8.0 Release Notes
|website=ziglang.org
|accessdate=2022-07-17
|quote=Disable the special casing of {} for u8 slices/arrays. Unless {s} is specified the contents won't be treated as a string.
}}&lt;/ref&gt;
;0.7.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.7.1/#Hello-World
|title=Zig Documentation(0.7.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=3&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().writer();
    try stdout.print(&quot;Hello, {}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: s/outStream/writer/
;0.6.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.6.0/#Hello-World
|title=Zig Documentation(0.6.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=3&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().outStream();
    try stdout.print(&quot;Hello, {}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: 初期化の初期値から &lt;code&gt;try&lt;/code&gt; がなくなった。
;0.4.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.4.0/#Hello-World
|title=Zig Documentation(0.4.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.2.0に同じ
;0.5.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.5.0/#Hello-World
|title=Zig Documentation(0.5.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=4&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    // If this program is run without stdout attached, exit with an error.
    const stdout_file = try std.io.getStdOut();
    // If this program encounters pipe failure when printing to stdout, exit
    // with an error.
    try stdout_file.write(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;
: &lt;var&gt;stdout_file&lt;/var&gt; が &lt;code&gt;var&lt;/code&gt; から &lt;code&gt;const&lt;/code&gt; に変更された。

;0.3.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.3.0/#Hello-World
|title=Zig Documentation(0.3.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.2.0に同じ
;0.2.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.2.0/#Hello-World
|title=Zig Documentation(0.2.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    // If this program is run without stdout attached, exit with an error.
    var stdout_file = try std.io.getStdOut();
    // If this program encounters pipe failure when printing to stdout, exit
    // with an error.
    try stdout_file.write(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;
;0.1.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.1.1/#hello-world
|title=Zig Documentation
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig&gt;
const io = @import(&quot;std&quot;).io;
pub fn main() -&gt; %void {
    %%io.stdout.printf(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;

== 環境準備 ==
=== Linuxの場合 ===
==== インストール方法 ====
Fedora 36 の場合、2022年の時点で、コマンド
 sudo dnf install zig
だけでインストールできる事を確認。

その他のOS環境でのインストールについては、[https://github.com/ziglang/zig/wiki/Install-Zig-from-a-Package-Manager  GitHub  &quot;ziglang /zig&quot; ] を参照せよ。

インストールできたと思ったら、バージョン確認コマンドなどで、インストールの成否を確認しよう。コマンド
 zig version
で確認できる。

なお、2022年7月現在、まだバージョンは1未満であり、同7月に実験したところ
 0.9.1
であった。上記のセクションでも掛かれているように2022年の段階ではまだプレリリースであるので、1未満でもインストール成功なので安心していい。

==== コードの実行方法 ====
=== 値と型 ===
[TOD0:整数・浮動小数・論理値・文字列・共用体・構造体・列挙・配列・ベクトル・スライス・ポインター・ゼロビットな型]

:&lt;syntaxhighlight lang=&quot;zig&quot;&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot;abcd \n&quot;, .{} );
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
abcd 
&lt;/syntaxhighlight&gt;

2022年7月現在、引用符中に変数をなにも使っていなくても、&lt;code&gt;.{}&lt;/code&gt;が必要である。ほか&lt;code&gt;try print&lt;/code&gt; の &lt;code&gt;try&lt;/code&gt; については、&lt;code&gt;try&lt;/code&gt;がないとエラーになる。

:&lt;syntaxhighlight lang=&quot;zig&quot;&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot; (1) = {}\n&quot;, .{42});
    try print(&quot; (2) = {}\n&quot;, .{0x17});
    try print(&quot; (3) = {}\n&quot;, .{0o17});
    try print(&quot; (4) = {}\n&quot;, .{0b0100101});
    try print(&quot; (5) = {}\n&quot;, .{1e222});
    try print(&quot; (6) = {}\n&quot;, .{3.1415926536});
    try print(&quot; (7) = {}\n&quot;, .{'c'});
    try print(&quot; (8) = {c}\n&quot;, .{'c'});
    try print(&quot; (9) = {s}\n&quot;, .{&quot;abcdef&quot;});
    try print(&quot;(10) = {}, {}\n&quot;, .{ 111, 999 });
    try print(&quot;(11) = {1}, {0}\n&quot;, .{ 111, 999 });
    try print(&quot;(12) = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; });
    try print(&quot;(13) = {0d}, {0b}, {0o}, {0x}, {0X}\n&quot;, .{ 123 });
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
 (1) = 42
 (2) = 23
 (3) = 15
 (4) = 37
 (5) = 1.0e+222
 (6) = 3.1415926536e+00
 (7) = 99
 (8) = c
 (9) = abcdef
(10) = 111, 999
(11) = 999, 111
(12) = abc, 111
(13) = 123, 1111011, 173, 7b, 7B
&lt;/syntaxhighlight&gt;
&lt;!-- リテラルの例、というか、@import(&quot;std&quot;).io.getStdOut().writer().print の例になっていますね。--&gt;
ご覧のように、数値（整数と浮動小数点数）や文字・文字列のリテラルがあり、整数は基数を、浮動小数点数は指数表現と小数表現があります。

@import(&quot;std&quot;).io.getStdOut().writer().printの、第一引数は書式化文字列、第二引数は値リストです。書式化文字列は、通常の文字列ですが &lt;code&gt;{&lt;/code&gt; と &lt;code&gt;}&lt;/code&gt; で囲まれたプレスホルダーが、引数リストの値（を書式化した文字列）に置き換わります。

一番素朴なプレスホルダーは {} で、引数の値の一般的な文字列表記に置き換ります（整数なら十進数表記、浮動小数点数なら指数表記）。ところが、’c’ のような文字型を &lt;code&gt;{}&lt;/code&gt; そのままに適用すると下記のように文字コード化され整数と同じ十進数表記になってしまいます。そこで、文字型の場合は {c} と文字であることを明記すると文字表現となります。

上記コードでは、次のような部分のことです。
:&lt;syntaxhighlight lang=&quot;zig&quot;&gt;
    try print(&quot; (7) = {}\n&quot;, .{'c'});
    try print(&quot; (8) = {c}\n&quot;, .{'c'});
&lt;/syntaxhighlight&gt;

対応部分:&lt;syntaxhighlight lang=text&gt;
 (7) = 99
 (8) = c
&lt;/syntaxhighlight&gt;

また、文字列の間合いは {s} を明記しないと（バージョン0.8.0からは）エラーになります。
2つ以上の値を渡す場合は、第二引数を　.{ 1, 2, 3 } の様にカンマ区切りのリストにします（ {} の前の . （点）を忘れがち）。
基本的に、左から順にプレスホルダーにリストの値が左から与えられますが、{0} {1} の書式で参照する引数の順位を明示できます。
書式指定と併用する時は、 &lt;code&gt; print(&quot;? = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; })&lt;/code&gt; の様に順位が先、書式指定文字が後になります。

[TODO:[https://github.com/ziglang/zig/blob/master/lib/std/fmt.zig master/lib/std/fmt.zig]を観て書いています。参照すべき標準ライブラリのドキュメントを発見出来たら、見直し]
[TODO:表組み]

==== comptime ====
Zigでは、コンパイル時に式が既知かどうかという概念を重要視しています。

下記コードはコンパイル等がエラーになります。
:&lt;syntaxhighlight lang=&quot;zig&quot; line highlight=7&gt;
fn mul(x: usize, y: usize) usize {
    return x * y;
}

pub fn main() void {
    const len : usize = mul(3, 4);
    const ary: [len]i32 = undefined;
    _ = ary;
}
&lt;/syntaxhighlight&gt;
;コンパイル結果:&lt;syntaxhighlight lang=text&gt;
An error occurred: 
/tmp/playground130713503/play.zig:7:17: error: unable to evaluate constant expression 
    const ary: [len]i32 = undefined;
&lt;/syntaxhighlight&gt;
: 「定数式が評価できない 」と宣っています。
: [[C++]]であれば、constexprが適用なケースですが、Zigでは次のような解決方法を取ります。下記コードはエラーになりません。

:&lt;syntaxhighlight lang=&quot;zig&quot; line highlight=6&gt;
fn mul(x: usize, y: usize) usize {
    return x * y;
}

pub fn main() void {
    const len : usize = comptime mul(3, 4); // mul の前に comptime を追加 
    const ary: [len]i32 = undefined;
    _ = ary;
}
&lt;/syntaxhighlight&gt;
:変更点は mul() の呼出しを comptime で修飾しただけです。comptime は、修飾子式を'''コンパイル時に実行する'''修飾子で、式の中でコンパイル時に未定な値が参照されると、エラーとなります。ここでは、数リテラル同士の商を求めているので、コンパイル時値が確定できます。
: _ = ary は、「定義済だが参照のない変数宣言」をサプレッスするときのイディオムです。

&lt;!--
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const i = 0;
    const string = [_]i32{ 1, 2, 3, 4 };
    for (string) |character, index| {
        std.debug.print(&quot;character: {}, index: {}, :{s} \n&quot;, .{ character, index, @typeName(@TypeOf(character)) });
    }
    _ = i;
}
--&gt;

===== インタプリタ的に実行する場合 =====
コンパイル済みファイルの作成を飛ばして、インタプリタ的に直接に実行する方法もあり、たとえばファイル名「hello.zig」なら下記のようなコマンドある。
 zig run hello.zig


===== プロジェクト作成する場合 =====
まず、プロジェクト関連のコマンドを実行すると、自動で数個のフォルダが作成されるので、それをまとめるためのフォルダを別に作っておき（たとえば proj とする）、べつにマウス右クリックでも mldir コマンドでもなんでもいいので proj ディレクトリを作成しておく。

そして、さらにカレント・ディレクトリを proj に移動するために、ターミナルでコマンド
 cd proj
で、そこに移動する。（そうしないと、今後の動作でホームフォルダにいくつものフォルダやファイルが作成され、管理しづらくなる）

その上で、プロジェクト作成のために
 zig init-exe
を行う。このコマンドにより、初期設定ファイルなどがいくつか自動的に作成される。

== 基礎篇 ==
[TODO:書くべき項目を並べてみましたが、例えば「値と型」を網羅的に書いていくと文章量が爆発するのが目に見えているので、過剰になったらリファレンス篇に移動するなどの方法で、各節はコンパクトさを心がけたいです。]

=== コメント ===
Zigでは、&lt;code&gt;//&lt;/code&gt; から行末までがコメントです。
C言語の &lt;code&gt;/* … */&lt;/code&gt; のスタイルの複数行に渡るコメントは'''ありません'''。
これは、コードの各行を文脈に関係なくトークン化できるようにするためです。
:&lt;syntaxhighlight lang=zig&gt;
// @import は組込み関数です。
const std = @import(&quot;std&quot;); // 先頭に @ が付く関数は組込み関数です
pub fn main() !void {
   try std.io.getStdOut().writeAll(&quot;Hello, World!\n&quot;);
}
&lt;/syntaxhighlight&gt;

==== Docコメント ====
Zigでは、&lt;code&gt;///&lt;/code&gt; から始まるコメントは特別なコメントで、Docコメント( ''Doc comments'' )と呼ばれます。
Docコメントは特定の場所にしか許されません。式の途中や非Docコメントの直前など、予想外の場所にdocコメントがあると、コンパイルエラーになります。

[TODO:サンプルコードと整形結果]

==== トップレベルDocコメント ====
Zigでは、&lt;code&gt;//!&lt;/code&gt; から始まるコメントは特別なコメントで、トップレベルDocコメント( ''Top-Level Doc Comments '' )と呼ばれます。
コンテナレベルのドキュメントのように、直後のドキュメントに属さないユーザードキュメントに、トップレベルDocコメントを使います。

[TODO:サンプルコードと整形結果]

DocコメントおよびトップレベルDocコメントは、コンパイル時に zig build-exe -femit-docs ソースファイル.zig の様に、-femit-docs をあたえると、 docs/ 以下にドキュメントが生成されます。

=== 値と型 ===
[TOD0:整数・浮動小数・論理値・文字列・共用体・構造体・列挙・配列・ベクトル・スライス・ポインター・ゼロビットな型]

:&lt;syntaxhighlight lang=zig&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot; (1) = {}\n&quot;, .{42});
    try print(&quot; (2) = {}\n&quot;, .{0x17});
    try print(&quot; (3) = {}\n&quot;, .{0o17});
    try print(&quot; (4) = {}\n&quot;, .{0b0100101});
    try print(&quot; (5) = {}\n&quot;, .{1e222});
    try print(&quot; (6) = {}\n&quot;, .{3.1415926536});
    try print(&quot; (7) = {}\n&quot;, .{'c'});
    try print(&quot; (8) = {c}\n&quot;, .{'c'});
    try print(&quot; (9) = {s}\n&quot;, .{&quot;abcdef&quot;});
    try print(&quot;(10) = {}, {}\n&quot;, .{ 111, 999 });
    try print(&quot;(11) = {1}, {0}\n&quot;, .{ 111, 999 });
    try print(&quot;(12) = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; });
    try print(&quot;(13) = {0d}, {0b}, {0o}, {0x}, {0X}\n&quot;, .{ 123 });
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
 (1) = 42
 (2) = 23
 (3) = 15
 (4) = 37
 (5) = 1.0e+222
 (6) = 3.1415926536e+00
 (7) = 99
 (8) = c
 (9) = abcdef
(10) = 111, 999
(11) = 999, 111
(12) = abc, 111
(13) = 123, 1111011, 173, 7b, 7B
&lt;/syntaxhighlight&gt;
&lt;!-- リテラルの例、というか、@import(&quot;std&quot;).io.getStdOut().writer().print の例になっていますね。--&gt;
ご覧のように、数値（整数と浮動小数点数）や文字・文字列のリテラルがあり、整数は基数を、浮動小数点数は指数表現と少数表現があります。

@import(&quot;std&quot;).io.getStdOut().writer().printの、第一引数は書式化文字列、第二引数は値リストです。
書式化文字列は、通常の文字列ですが &lt;code&gt;{&lt;/code&gt; と &lt;code&gt;}&lt;/code&gt; で囲まれたプレスホルダーが、引数リストの値（を書式化した文字列）に置換わります。
一番素朴なプレスホルダーは {} で、引数の値の一般的な文字列表記に置き換ります（整数なら十進数表記、浮動小数点数なら指数表記）。
ところが、’c’ のような文字型を {} に適用すると文字コード化され整数と同じ十進数表記になってしまいます。そこで、文字型の場合は {c} と文字であることを明記すると文字表現となります。
また、文字列の間合いは {s} を明記しないと（バージョン0.8.0からは）エラーになります。
2つ以上の値を渡す場合は、第二引数を　.{ 1, 2, 3 } の様にカンマ区切りのリストにします（ これが、Zig の配列リテラルの表現で、{} の前の . （点）を忘れがち）。
基本的に、左から順にプレスホルダーにリストの値が左から与えられますが、{0} {1} の書式で参照する引数の順位を明示できます。
書式指定と併用する時は、 &lt;code&gt; print(&quot;? = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; })&lt;/code&gt; の様に順位が先、書式指定文字が後になります。

[TODO:[https://github.com/ziglang/zig/blob/master/lib/std/fmt.zig master/lib/std/fmt.zig]を観て書いています。参照すべき標準ライブラリのドキュメントを発見出来たら、見直し]
[TODO:表組み]

==== comptime ====
Zigでは、コンパイル時に式が既知かどうかという概念を重要視しています。

&lt;!--
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const i = 0;
    const string = [_]i32{ 1, 2, 3, 4 };
    for (string) |character, index| {
        std.debug.print(&quot;character: {}, index: {}, :{s} \n&quot;, .{ character, index, @typeName(@TypeOf(character)) });
    }
    _ = i;
}
--&gt;

=== テスト ===
=== 変数 ===
=== 制御構造 ===
[TODO:Zig の制御構造は文ではなく式]
==== 分岐 ====
[TODO:ifとswitch]
==== 反復 ====
[TODO:whileとfor]
=== 関数 ===
=== エラー ===
=== 演算子 ===
==== 優先順位 ====
高
&lt;syntaxhighlight lang=text line&gt;
 x() x[] x.y x.* x.?
 a!b
 x{}
 !x -x -%x ~x &amp;x ?x
 * / % ** *% *| ||
 + - ++ +% -% +| -|
 &lt;&lt; &gt;&gt; &lt;&lt;|
 &amp; ^ | orelse catch
 == != &lt; &gt; &lt;= &gt;=
 and
 or
 = *= *%= *|= /= %= += +%= +|= -= -%= -|= &lt;&lt;= &lt;&lt;|= &gt;&gt;= &amp;= ^= |=
&lt;/syntaxhighlight&gt;
低

===  optional type ===
===  opaque ===
訳語未定
=== ブロック ===
[TODO:スコープとシャドーイング；deferはここ？]
=== キャスト ===
[TODO:Zig は強い型付け()； 型強制 (Type coercion) について]
=== アセンブリ言語との連携 ===
[TODO:所謂インラインアセンラ]
=== atomic ===
=== 非同期関数 ===
=== 組込み関数 ===
[TODO:組込み関数は、@で始まり、@TypeOfや@alignOfの他@sinや@memcpyも組込み関数]
=== メモリ管理 ===
=== キーワード一覧 ===
&lt;code&gt;align&lt;/code&gt;
&lt;code&gt;allowzero&lt;/code&gt;
&lt;code&gt;and&lt;/code&gt;
&lt;code&gt;anyframe&lt;/code&gt;
&lt;code&gt;anytype&lt;/code&gt;
&lt;code&gt;asm&lt;/code&gt;
&lt;code&gt;async&lt;/code&gt;
&lt;code&gt;await&lt;/code&gt;
&lt;code&gt;break&lt;/code&gt;
&lt;code&gt;catch&lt;/code&gt;
&lt;code&gt;comptime&lt;/code&gt;
&lt;code&gt;const&lt;/code&gt;
&lt;code&gt;continue&lt;/code&gt;
&lt;code&gt;defer&lt;/code&gt;
&lt;code&gt;else&lt;/code&gt;
&lt;code&gt;enum&lt;/code&gt;
&lt;code&gt;errdefer&lt;/code&gt;
&lt;code&gt;error&lt;/code&gt;
&lt;code&gt;export&lt;/code&gt;
&lt;code&gt;extern&lt;/code&gt;
&lt;code&gt;fn&lt;/code&gt;
&lt;code&gt;for&lt;/code&gt;
&lt;code&gt;if&lt;/code&gt;
&lt;code&gt;inline&lt;/code&gt;
&lt;code&gt;noalias&lt;/code&gt;
&lt;code&gt;nosuspend&lt;/code&gt;
&lt;code&gt;or&lt;/code&gt;
&lt;code&gt;orelse&lt;/code&gt;
&lt;code&gt;packed&lt;/code&gt;
&lt;code&gt;pub&lt;/code&gt;
&lt;code&gt;resume&lt;/code&gt;
&lt;code&gt;return&lt;/code&gt;
&lt;code&gt;linksection&lt;/code&gt;
&lt;code&gt;struct&lt;/code&gt;
&lt;code&gt;suspend&lt;/code&gt;
&lt;code&gt;switch&lt;/code&gt;
&lt;code&gt;test&lt;/code&gt;
&lt;code&gt;threadlocal&lt;/code&gt;
&lt;code&gt;try&lt;/code&gt;
&lt;code&gt;union&lt;/code&gt;
&lt;code&gt;unreachable&lt;/code&gt;
&lt;code&gt;usingnamespace&lt;/code&gt;
&lt;code&gt;var&lt;/code&gt;
&lt;code&gt;volatile&lt;/code&gt;
&lt;code&gt;while&lt;/code&gt;

== チートシート ==
[TODO:文法と型と頻用する標準ライブラリの関数と型のアンチョコ]

== リファレンス篇 ==

== 脚註 ==
&lt;references /&gt;

== 外部リンク ==
* [https://ziglang.org/ Home ⚡ Zig Programming Language] {{---}} 公式サイト
** [[https://ziglang.org/documentation/master/ Zig Language Reference]] {{---}} リファレンスマニュアル
* [https://github.com/ziglang/zig ziglang/zig: General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.] {{---}} 公式リポジトリ
* [https://zig-play.dev/ Zig Playground] {{---}} オンライン実行環境
** [https://github.com/gsquire/zig-play About An online Zig compiler inspired by Go and Rust] {{---}} リポジトリ

[[Category:zig|*]]
[[Category:プログラミング言語]]</text>
      <sha1>khejlaxtnowpqn2b3qiso9ju8kfxbxx</sha1>
    </revision>
    <revision>
      <id>205771</id>
      <parentid>205770</parentid>
      <timestamp>2022-07-24T06:58:11Z</timestamp>
      <contributor>
        <username>すじにくシチュー</username>
        <id>12058</id>
      </contributor>
      <comment>/* 値と型 */ たぶん「間合い」ではなく「場合」かと。とりあえず変更して様子見。</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="22027" xml:space="preserve">{{Pathnav|メインページ|工学|情報技術|プログラミング|frame=1}}
{{Wikipedia|Zig (プログラミング言語)}}
本書は、[[w:Zig|Zig]]のチュートリアルです。
Zigは、堅牢で最適かつ再利用可能なソフトウェアを維持するための汎用プログラミング言語およびツールチェインです&lt;ref&gt;{{Cite web
|url=https://ziglang.org/
|title=Home ⚡ Zig Programming Language
|website=ziglang.org
|accessdate=2022-07-17
|cite=Zig is a general-purpose programming language and toolchain for maintaining '''robust''', '''optimal''' and '''reusable''' software.
}}&lt;/ref&gt;。
Zigは、アンドリュー・ケリー( ''[https://andrewkelley.me/ Andrew Kelley]'' )によって設計され、汎用システムプログラミング言語で、静的で強い型付けで型推論とジェネリックプログラミングをサポートします。

== 概要 ==
Zigは、2016年2月に発表された比較的若いプログラミング言語で&lt;ref&gt;{{Cite web
|last1=Kelley
|first1=Andrew
|title=Introduction to the Zig Programming Language
|url=https://andrewkelley.me/post/intro-to-zig.html
|website=andrewkelley.me
|accessdate=2022-07-17
}}&lt;/ref&gt;、2022年7月現在のバージョンは 0.9.1 で、'''''pre-release''''' と位置づけられています&lt;ref&gt;{{Cite web
|url=https://github.com/ziglang/zig/releases
|title=Releases · ziglang/zig
|website=github.com
|accessdate=2022-07-17
}}&lt;/ref&gt;。このため [[W:Hello world|Hello world]] ですら、バージョン間で互換性がなくなることもあり、リリースバージョンまでは言語仕様やライブラリーおよびツールチェインの仕様が変更される可能性があります。

=== Hello world の変遷 ===
[https://ziglang.org/documentation/master/ Zig Language Reference]の、[[W:Hello world|Hello world]]の変遷（新しい順）。

;master@2022-07-17&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/master/#Hello-World
|title=Zig Documentation(master@2022-07-17)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.8.1に同じ
;0.9.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.9.1/#Hello-World
|title=Zig Documentation(0.9.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.8.1に同じ
;0.8.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.8.1/#Hello-World
|title=Zig Documentation(0.8.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=4&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().writer();
    try stdout.print(&quot;Hello, {s}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: &lt;code&gt;{}&lt;/code&gt; ⇒ &lt;code&gt;{s}&lt;/code&gt;&lt;ref&gt;{{Cite web
|url=https://ziglang.org/download/0.8.0/release-notes.html#Formatted-Printing
|title=0.8.0 Release Notes
|website=ziglang.org
|accessdate=2022-07-17
|quote=Disable the special casing of {} for u8 slices/arrays. Unless {s} is specified the contents won't be treated as a string.
}}&lt;/ref&gt;
;0.7.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.7.1/#Hello-World
|title=Zig Documentation(0.7.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=3&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().writer();
    try stdout.print(&quot;Hello, {}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: s/outStream/writer/
;0.6.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.6.0/#Hello-World
|title=Zig Documentation(0.6.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=3&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().outStream();
    try stdout.print(&quot;Hello, {}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: 初期化の初期値から &lt;code&gt;try&lt;/code&gt; がなくなった。
;0.4.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.4.0/#Hello-World
|title=Zig Documentation(0.4.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.2.0に同じ
;0.5.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.5.0/#Hello-World
|title=Zig Documentation(0.5.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=4&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    // If this program is run without stdout attached, exit with an error.
    const stdout_file = try std.io.getStdOut();
    // If this program encounters pipe failure when printing to stdout, exit
    // with an error.
    try stdout_file.write(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;
: &lt;var&gt;stdout_file&lt;/var&gt; が &lt;code&gt;var&lt;/code&gt; から &lt;code&gt;const&lt;/code&gt; に変更された。

;0.3.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.3.0/#Hello-World
|title=Zig Documentation(0.3.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.2.0に同じ
;0.2.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.2.0/#Hello-World
|title=Zig Documentation(0.2.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    // If this program is run without stdout attached, exit with an error.
    var stdout_file = try std.io.getStdOut();
    // If this program encounters pipe failure when printing to stdout, exit
    // with an error.
    try stdout_file.write(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;
;0.1.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.1.1/#hello-world
|title=Zig Documentation
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig&gt;
const io = @import(&quot;std&quot;).io;
pub fn main() -&gt; %void {
    %%io.stdout.printf(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;

== 環境準備 ==
=== Linuxの場合 ===
==== インストール方法 ====
Fedora 36 の場合、2022年の時点で、コマンド
 sudo dnf install zig
だけでインストールできる事を確認。

その他のOS環境でのインストールについては、[https://github.com/ziglang/zig/wiki/Install-Zig-from-a-Package-Manager  GitHub  &quot;ziglang /zig&quot; ] を参照せよ。

インストールできたと思ったら、バージョン確認コマンドなどで、インストールの成否を確認しよう。コマンド
 zig version
で確認できる。

なお、2022年7月現在、まだバージョンは1未満であり、同7月に実験したところ
 0.9.1
であった。上記のセクションでも掛かれているように2022年の段階ではまだプレリリースであるので、1未満でもインストール成功なので安心していい。

==== コードの実行方法 ====
=== 値と型 ===
[TOD0:整数・浮動小数・論理値・文字列・共用体・構造体・列挙・配列・ベクトル・スライス・ポインター・ゼロビットな型]

:&lt;syntaxhighlight lang=&quot;zig&quot;&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot;abcd \n&quot;, .{} );
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
abcd 
&lt;/syntaxhighlight&gt;

2022年7月現在、引用符中に変数をなにも使っていなくても、&lt;code&gt;.{}&lt;/code&gt;が必要である。ほか&lt;code&gt;try print&lt;/code&gt; の &lt;code&gt;try&lt;/code&gt; については、&lt;code&gt;try&lt;/code&gt;がないとエラーになる。

:&lt;syntaxhighlight lang=&quot;zig&quot;&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot; (1) = {}\n&quot;, .{42});
    try print(&quot; (2) = {}\n&quot;, .{0x17});
    try print(&quot; (3) = {}\n&quot;, .{0o17});
    try print(&quot; (4) = {}\n&quot;, .{0b0100101});
    try print(&quot; (5) = {}\n&quot;, .{1e222});
    try print(&quot; (6) = {}\n&quot;, .{3.1415926536});
    try print(&quot; (7) = {}\n&quot;, .{'c'});
    try print(&quot; (8) = {c}\n&quot;, .{'c'});
    try print(&quot; (9) = {s}\n&quot;, .{&quot;abcdef&quot;});
    try print(&quot;(10) = {}, {}\n&quot;, .{ 111, 999 });
    try print(&quot;(11) = {1}, {0}\n&quot;, .{ 111, 999 });
    try print(&quot;(12) = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; });
    try print(&quot;(13) = {0d}, {0b}, {0o}, {0x}, {0X}\n&quot;, .{ 123 });
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
 (1) = 42
 (2) = 23
 (3) = 15
 (4) = 37
 (5) = 1.0e+222
 (6) = 3.1415926536e+00
 (7) = 99
 (8) = c
 (9) = abcdef
(10) = 111, 999
(11) = 999, 111
(12) = abc, 111
(13) = 123, 1111011, 173, 7b, 7B
&lt;/syntaxhighlight&gt;
&lt;!-- リテラルの例、というか、@import(&quot;std&quot;).io.getStdOut().writer().print の例になっていますね。--&gt;
ご覧のように、数値（整数と浮動小数点数）や文字・文字列のリテラルがあり、整数は基数を、浮動小数点数は指数表現と小数表現があります。

@import(&quot;std&quot;).io.getStdOut().writer().printの、第一引数は書式化文字列、第二引数は値リストです。書式化文字列は、通常の文字列ですが &lt;code&gt;{&lt;/code&gt; と &lt;code&gt;}&lt;/code&gt; で囲まれたプレスホルダーが、引数リストの値（を書式化した文字列）に置き換わります。

一番素朴なプレスホルダーは {} で、引数の値の一般的な文字列表記に置き換ります（整数なら十進数表記、浮動小数点数なら指数表記）。ところが、’c’ のような文字型を &lt;code&gt;{}&lt;/code&gt; そのままに適用すると下記のように文字コード化され整数と同じ十進数表記になってしまいます。そこで、文字型の場合は {c} と文字であることを明記すると文字表現となります。

上記コードでは、次のような部分のことです。
:&lt;syntaxhighlight lang=&quot;zig&quot;&gt;
    try print(&quot; (7) = {}\n&quot;, .{'c'});
    try print(&quot; (8) = {c}\n&quot;, .{'c'});
&lt;/syntaxhighlight&gt;

対応部分:&lt;syntaxhighlight lang=text&gt;
 (7) = 99
 (8) = c
&lt;/syntaxhighlight&gt;

また、（文字ではなく）文字'''列'''の場合は {s} を明記しないと（バージョン0.8.0からは）エラーになります。
2つ以上の値を渡す場合は、第二引数を　.{ 1, 2, 3 } の様にカンマ区切りのリストにします（ {} の前の . （点）を忘れがち）。
基本的に、左から順にプレスホルダーにリストの値が左から与えられますが、{0} {1} の書式で参照する引数の順位を明示できます。
書式指定と併用する時は、 &lt;code&gt; print(&quot;? = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; })&lt;/code&gt; の様に順位が先、書式指定文字が後になります。

[TODO:[https://github.com/ziglang/zig/blob/master/lib/std/fmt.zig master/lib/std/fmt.zig]を観て書いています。参照すべき標準ライブラリのドキュメントを発見出来たら、見直し]
[TODO:表組み]

==== comptime ====
Zigでは、コンパイル時に式が既知かどうかという概念を重要視しています。

下記コードはコンパイル等がエラーになります。
:&lt;syntaxhighlight lang=&quot;zig&quot; line highlight=7&gt;
fn mul(x: usize, y: usize) usize {
    return x * y;
}

pub fn main() void {
    const len : usize = mul(3, 4);
    const ary: [len]i32 = undefined;
    _ = ary;
}
&lt;/syntaxhighlight&gt;
;コンパイル結果:&lt;syntaxhighlight lang=text&gt;
An error occurred: 
/tmp/playground130713503/play.zig:7:17: error: unable to evaluate constant expression 
    const ary: [len]i32 = undefined;
&lt;/syntaxhighlight&gt;
: 「定数式が評価できない 」と宣っています。
: [[C++]]であれば、constexprが適用なケースですが、Zigでは次のような解決方法を取ります。下記コードはエラーになりません。

:&lt;syntaxhighlight lang=&quot;zig&quot; line highlight=6&gt;
fn mul(x: usize, y: usize) usize {
    return x * y;
}

pub fn main() void {
    const len : usize = comptime mul(3, 4); // mul の前に comptime を追加 
    const ary: [len]i32 = undefined;
    _ = ary;
}
&lt;/syntaxhighlight&gt;
:変更点は mul() の呼出しを comptime で修飾しただけです。comptime は、修飾子式を'''コンパイル時に実行する'''修飾子で、式の中でコンパイル時に未定な値が参照されると、エラーとなります。ここでは、数リテラル同士の商を求めているので、コンパイル時値が確定できます。
: _ = ary は、「定義済だが参照のない変数宣言」をサプレッスするときのイディオムです。

&lt;!--
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const i = 0;
    const string = [_]i32{ 1, 2, 3, 4 };
    for (string) |character, index| {
        std.debug.print(&quot;character: {}, index: {}, :{s} \n&quot;, .{ character, index, @typeName(@TypeOf(character)) });
    }
    _ = i;
}
--&gt;

===== インタプリタ的に実行する場合 =====
コンパイル済みファイルの作成を飛ばして、インタプリタ的に直接に実行する方法もあり、たとえばファイル名「hello.zig」なら下記のようなコマンドある。
 zig run hello.zig


===== プロジェクト作成する場合 =====
まず、プロジェクト関連のコマンドを実行すると、自動で数個のフォルダが作成されるので、それをまとめるためのフォルダを別に作っておき（たとえば proj とする）、べつにマウス右クリックでも mldir コマンドでもなんでもいいので proj ディレクトリを作成しておく。

そして、さらにカレント・ディレクトリを proj に移動するために、ターミナルでコマンド
 cd proj
で、そこに移動する。（そうしないと、今後の動作でホームフォルダにいくつものフォルダやファイルが作成され、管理しづらくなる）

その上で、プロジェクト作成のために
 zig init-exe
を行う。このコマンドにより、初期設定ファイルなどがいくつか自動的に作成される。

== 基礎篇 ==
[TODO:書くべき項目を並べてみましたが、例えば「値と型」を網羅的に書いていくと文章量が爆発するのが目に見えているので、過剰になったらリファレンス篇に移動するなどの方法で、各節はコンパクトさを心がけたいです。]

=== コメント ===
Zigでは、&lt;code&gt;//&lt;/code&gt; から行末までがコメントです。
C言語の &lt;code&gt;/* … */&lt;/code&gt; のスタイルの複数行に渡るコメントは'''ありません'''。
これは、コードの各行を文脈に関係なくトークン化できるようにするためです。
:&lt;syntaxhighlight lang=zig&gt;
// @import は組込み関数です。
const std = @import(&quot;std&quot;); // 先頭に @ が付く関数は組込み関数です
pub fn main() !void {
   try std.io.getStdOut().writeAll(&quot;Hello, World!\n&quot;);
}
&lt;/syntaxhighlight&gt;

==== Docコメント ====
Zigでは、&lt;code&gt;///&lt;/code&gt; から始まるコメントは特別なコメントで、Docコメント( ''Doc comments'' )と呼ばれます。
Docコメントは特定の場所にしか許されません。式の途中や非Docコメントの直前など、予想外の場所にdocコメントがあると、コンパイルエラーになります。

[TODO:サンプルコードと整形結果]

==== トップレベルDocコメント ====
Zigでは、&lt;code&gt;//!&lt;/code&gt; から始まるコメントは特別なコメントで、トップレベルDocコメント( ''Top-Level Doc Comments '' )と呼ばれます。
コンテナレベルのドキュメントのように、直後のドキュメントに属さないユーザードキュメントに、トップレベルDocコメントを使います。

[TODO:サンプルコードと整形結果]

DocコメントおよびトップレベルDocコメントは、コンパイル時に zig build-exe -femit-docs ソースファイル.zig の様に、-femit-docs をあたえると、 docs/ 以下にドキュメントが生成されます。

=== 値と型 ===
[TOD0:整数・浮動小数・論理値・文字列・共用体・構造体・列挙・配列・ベクトル・スライス・ポインター・ゼロビットな型]

:&lt;syntaxhighlight lang=zig&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot; (1) = {}\n&quot;, .{42});
    try print(&quot; (2) = {}\n&quot;, .{0x17});
    try print(&quot; (3) = {}\n&quot;, .{0o17});
    try print(&quot; (4) = {}\n&quot;, .{0b0100101});
    try print(&quot; (5) = {}\n&quot;, .{1e222});
    try print(&quot; (6) = {}\n&quot;, .{3.1415926536});
    try print(&quot; (7) = {}\n&quot;, .{'c'});
    try print(&quot; (8) = {c}\n&quot;, .{'c'});
    try print(&quot; (9) = {s}\n&quot;, .{&quot;abcdef&quot;});
    try print(&quot;(10) = {}, {}\n&quot;, .{ 111, 999 });
    try print(&quot;(11) = {1}, {0}\n&quot;, .{ 111, 999 });
    try print(&quot;(12) = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; });
    try print(&quot;(13) = {0d}, {0b}, {0o}, {0x}, {0X}\n&quot;, .{ 123 });
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
 (1) = 42
 (2) = 23
 (3) = 15
 (4) = 37
 (5) = 1.0e+222
 (6) = 3.1415926536e+00
 (7) = 99
 (8) = c
 (9) = abcdef
(10) = 111, 999
(11) = 999, 111
(12) = abc, 111
(13) = 123, 1111011, 173, 7b, 7B
&lt;/syntaxhighlight&gt;
&lt;!-- リテラルの例、というか、@import(&quot;std&quot;).io.getStdOut().writer().print の例になっていますね。--&gt;
ご覧のように、数値（整数と浮動小数点数）や文字・文字列のリテラルがあり、整数は基数を、浮動小数点数は指数表現と少数表現があります。

@import(&quot;std&quot;).io.getStdOut().writer().printの、第一引数は書式化文字列、第二引数は値リストです。
書式化文字列は、通常の文字列ですが &lt;code&gt;{&lt;/code&gt; と &lt;code&gt;}&lt;/code&gt; で囲まれたプレスホルダーが、引数リストの値（を書式化した文字列）に置換わります。
一番素朴なプレスホルダーは {} で、引数の値の一般的な文字列表記に置き換ります（整数なら十進数表記、浮動小数点数なら指数表記）。
ところが、’c’ のような文字型を {} に適用すると文字コード化され整数と同じ十進数表記になってしまいます。そこで、文字型の場合は {c} と文字であることを明記すると文字表現となります。
また、文字列の間合いは {s} を明記しないと（バージョン0.8.0からは）エラーになります。
2つ以上の値を渡す場合は、第二引数を　.{ 1, 2, 3 } の様にカンマ区切りのリストにします（ これが、Zig の配列リテラルの表現で、{} の前の . （点）を忘れがち）。
基本的に、左から順にプレスホルダーにリストの値が左から与えられますが、{0} {1} の書式で参照する引数の順位を明示できます。
書式指定と併用する時は、 &lt;code&gt; print(&quot;? = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; })&lt;/code&gt; の様に順位が先、書式指定文字が後になります。

[TODO:[https://github.com/ziglang/zig/blob/master/lib/std/fmt.zig master/lib/std/fmt.zig]を観て書いています。参照すべき標準ライブラリのドキュメントを発見出来たら、見直し]
[TODO:表組み]

==== comptime ====
Zigでは、コンパイル時に式が既知かどうかという概念を重要視しています。

&lt;!--
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const i = 0;
    const string = [_]i32{ 1, 2, 3, 4 };
    for (string) |character, index| {
        std.debug.print(&quot;character: {}, index: {}, :{s} \n&quot;, .{ character, index, @typeName(@TypeOf(character)) });
    }
    _ = i;
}
--&gt;

=== テスト ===
=== 変数 ===
=== 制御構造 ===
[TODO:Zig の制御構造は文ではなく式]
==== 分岐 ====
[TODO:ifとswitch]
==== 反復 ====
[TODO:whileとfor]
=== 関数 ===
=== エラー ===
=== 演算子 ===
==== 優先順位 ====
高
&lt;syntaxhighlight lang=text line&gt;
 x() x[] x.y x.* x.?
 a!b
 x{}
 !x -x -%x ~x &amp;x ?x
 * / % ** *% *| ||
 + - ++ +% -% +| -|
 &lt;&lt; &gt;&gt; &lt;&lt;|
 &amp; ^ | orelse catch
 == != &lt; &gt; &lt;= &gt;=
 and
 or
 = *= *%= *|= /= %= += +%= +|= -= -%= -|= &lt;&lt;= &lt;&lt;|= &gt;&gt;= &amp;= ^= |=
&lt;/syntaxhighlight&gt;
低

===  optional type ===
===  opaque ===
訳語未定
=== ブロック ===
[TODO:スコープとシャドーイング；deferはここ？]
=== キャスト ===
[TODO:Zig は強い型付け()； 型強制 (Type coercion) について]
=== アセンブリ言語との連携 ===
[TODO:所謂インラインアセンラ]
=== atomic ===
=== 非同期関数 ===
=== 組込み関数 ===
[TODO:組込み関数は、@で始まり、@TypeOfや@alignOfの他@sinや@memcpyも組込み関数]
=== メモリ管理 ===
=== キーワード一覧 ===
&lt;code&gt;align&lt;/code&gt;
&lt;code&gt;allowzero&lt;/code&gt;
&lt;code&gt;and&lt;/code&gt;
&lt;code&gt;anyframe&lt;/code&gt;
&lt;code&gt;anytype&lt;/code&gt;
&lt;code&gt;asm&lt;/code&gt;
&lt;code&gt;async&lt;/code&gt;
&lt;code&gt;await&lt;/code&gt;
&lt;code&gt;break&lt;/code&gt;
&lt;code&gt;catch&lt;/code&gt;
&lt;code&gt;comptime&lt;/code&gt;
&lt;code&gt;const&lt;/code&gt;
&lt;code&gt;continue&lt;/code&gt;
&lt;code&gt;defer&lt;/code&gt;
&lt;code&gt;else&lt;/code&gt;
&lt;code&gt;enum&lt;/code&gt;
&lt;code&gt;errdefer&lt;/code&gt;
&lt;code&gt;error&lt;/code&gt;
&lt;code&gt;export&lt;/code&gt;
&lt;code&gt;extern&lt;/code&gt;
&lt;code&gt;fn&lt;/code&gt;
&lt;code&gt;for&lt;/code&gt;
&lt;code&gt;if&lt;/code&gt;
&lt;code&gt;inline&lt;/code&gt;
&lt;code&gt;noalias&lt;/code&gt;
&lt;code&gt;nosuspend&lt;/code&gt;
&lt;code&gt;or&lt;/code&gt;
&lt;code&gt;orelse&lt;/code&gt;
&lt;code&gt;packed&lt;/code&gt;
&lt;code&gt;pub&lt;/code&gt;
&lt;code&gt;resume&lt;/code&gt;
&lt;code&gt;return&lt;/code&gt;
&lt;code&gt;linksection&lt;/code&gt;
&lt;code&gt;struct&lt;/code&gt;
&lt;code&gt;suspend&lt;/code&gt;
&lt;code&gt;switch&lt;/code&gt;
&lt;code&gt;test&lt;/code&gt;
&lt;code&gt;threadlocal&lt;/code&gt;
&lt;code&gt;try&lt;/code&gt;
&lt;code&gt;union&lt;/code&gt;
&lt;code&gt;unreachable&lt;/code&gt;
&lt;code&gt;usingnamespace&lt;/code&gt;
&lt;code&gt;var&lt;/code&gt;
&lt;code&gt;volatile&lt;/code&gt;
&lt;code&gt;while&lt;/code&gt;

== チートシート ==
[TODO:文法と型と頻用する標準ライブラリの関数と型のアンチョコ]

== リファレンス篇 ==

== 脚註 ==
&lt;references /&gt;

== 外部リンク ==
* [https://ziglang.org/ Home ⚡ Zig Programming Language] {{---}} 公式サイト
** [[https://ziglang.org/documentation/master/ Zig Language Reference]] {{---}} リファレンスマニュアル
* [https://github.com/ziglang/zig ziglang/zig: General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.] {{---}} 公式リポジトリ
* [https://zig-play.dev/ Zig Playground] {{---}} オンライン実行環境
** [https://github.com/gsquire/zig-play About An online Zig compiler inspired by Go and Rust] {{---}} リポジトリ

[[Category:zig|*]]
[[Category:プログラミング言語]]</text>
      <sha1>rqoarxiutayl1x3ww9gu1wfvge62l0s</sha1>
    </revision>
    <revision>
      <id>205772</id>
      <parentid>205771</parentid>
      <timestamp>2022-07-24T07:07:20Z</timestamp>
      <contributor>
        <username>すじにくシチュー</username>
        <id>12058</id>
      </contributor>
      <comment>/* 値と型 */ シングルクォーテーションとダブルクォーテーションの話題が抜けている。</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="22508" xml:space="preserve">{{Pathnav|メインページ|工学|情報技術|プログラミング|frame=1}}
{{Wikipedia|Zig (プログラミング言語)}}
本書は、[[w:Zig|Zig]]のチュートリアルです。
Zigは、堅牢で最適かつ再利用可能なソフトウェアを維持するための汎用プログラミング言語およびツールチェインです&lt;ref&gt;{{Cite web
|url=https://ziglang.org/
|title=Home ⚡ Zig Programming Language
|website=ziglang.org
|accessdate=2022-07-17
|cite=Zig is a general-purpose programming language and toolchain for maintaining '''robust''', '''optimal''' and '''reusable''' software.
}}&lt;/ref&gt;。
Zigは、アンドリュー・ケリー( ''[https://andrewkelley.me/ Andrew Kelley]'' )によって設計され、汎用システムプログラミング言語で、静的で強い型付けで型推論とジェネリックプログラミングをサポートします。

== 概要 ==
Zigは、2016年2月に発表された比較的若いプログラミング言語で&lt;ref&gt;{{Cite web
|last1=Kelley
|first1=Andrew
|title=Introduction to the Zig Programming Language
|url=https://andrewkelley.me/post/intro-to-zig.html
|website=andrewkelley.me
|accessdate=2022-07-17
}}&lt;/ref&gt;、2022年7月現在のバージョンは 0.9.1 で、'''''pre-release''''' と位置づけられています&lt;ref&gt;{{Cite web
|url=https://github.com/ziglang/zig/releases
|title=Releases · ziglang/zig
|website=github.com
|accessdate=2022-07-17
}}&lt;/ref&gt;。このため [[W:Hello world|Hello world]] ですら、バージョン間で互換性がなくなることもあり、リリースバージョンまでは言語仕様やライブラリーおよびツールチェインの仕様が変更される可能性があります。

=== Hello world の変遷 ===
[https://ziglang.org/documentation/master/ Zig Language Reference]の、[[W:Hello world|Hello world]]の変遷（新しい順）。

;master@2022-07-17&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/master/#Hello-World
|title=Zig Documentation(master@2022-07-17)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.8.1に同じ
;0.9.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.9.1/#Hello-World
|title=Zig Documentation(0.9.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.8.1に同じ
;0.8.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.8.1/#Hello-World
|title=Zig Documentation(0.8.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=4&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().writer();
    try stdout.print(&quot;Hello, {s}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: &lt;code&gt;{}&lt;/code&gt; ⇒ &lt;code&gt;{s}&lt;/code&gt;&lt;ref&gt;{{Cite web
|url=https://ziglang.org/download/0.8.0/release-notes.html#Formatted-Printing
|title=0.8.0 Release Notes
|website=ziglang.org
|accessdate=2022-07-17
|quote=Disable the special casing of {} for u8 slices/arrays. Unless {s} is specified the contents won't be treated as a string.
}}&lt;/ref&gt;
;0.7.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.7.1/#Hello-World
|title=Zig Documentation(0.7.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=3&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().writer();
    try stdout.print(&quot;Hello, {}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: s/outStream/writer/
;0.6.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.6.0/#Hello-World
|title=Zig Documentation(0.6.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=3&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().outStream();
    try stdout.print(&quot;Hello, {}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: 初期化の初期値から &lt;code&gt;try&lt;/code&gt; がなくなった。
;0.4.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.4.0/#Hello-World
|title=Zig Documentation(0.4.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.2.0に同じ
;0.5.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.5.0/#Hello-World
|title=Zig Documentation(0.5.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=4&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    // If this program is run without stdout attached, exit with an error.
    const stdout_file = try std.io.getStdOut();
    // If this program encounters pipe failure when printing to stdout, exit
    // with an error.
    try stdout_file.write(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;
: &lt;var&gt;stdout_file&lt;/var&gt; が &lt;code&gt;var&lt;/code&gt; から &lt;code&gt;const&lt;/code&gt; に変更された。

;0.3.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.3.0/#Hello-World
|title=Zig Documentation(0.3.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.2.0に同じ
;0.2.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.2.0/#Hello-World
|title=Zig Documentation(0.2.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    // If this program is run without stdout attached, exit with an error.
    var stdout_file = try std.io.getStdOut();
    // If this program encounters pipe failure when printing to stdout, exit
    // with an error.
    try stdout_file.write(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;
;0.1.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.1.1/#hello-world
|title=Zig Documentation
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig&gt;
const io = @import(&quot;std&quot;).io;
pub fn main() -&gt; %void {
    %%io.stdout.printf(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;

== 環境準備 ==
=== Linuxの場合 ===
==== インストール方法 ====
Fedora 36 の場合、2022年の時点で、コマンド
 sudo dnf install zig
だけでインストールできる事を確認。

その他のOS環境でのインストールについては、[https://github.com/ziglang/zig/wiki/Install-Zig-from-a-Package-Manager  GitHub  &quot;ziglang /zig&quot; ] を参照せよ。

インストールできたと思ったら、バージョン確認コマンドなどで、インストールの成否を確認しよう。コマンド
 zig version
で確認できる。

なお、2022年7月現在、まだバージョンは1未満であり、同7月に実験したところ
 0.9.1
であった。上記のセクションでも掛かれているように2022年の段階ではまだプレリリースであるので、1未満でもインストール成功なので安心していい。

==== コードの実行方法 ====
=== 値と型 ===
[TOD0:整数・浮動小数・論理値・文字列・共用体・構造体・列挙・配列・ベクトル・スライス・ポインター・ゼロビットな型]

:&lt;syntaxhighlight lang=&quot;zig&quot;&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot;abcd \n&quot;, .{} );
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
abcd 
&lt;/syntaxhighlight&gt;

2022年7月現在、引用符中に変数をなにも使っていなくても、&lt;code&gt;.{}&lt;/code&gt;が必要である。ほか&lt;code&gt;try print&lt;/code&gt; の &lt;code&gt;try&lt;/code&gt; については、&lt;code&gt;try&lt;/code&gt;がないとエラーになる。

:&lt;syntaxhighlight lang=&quot;zig&quot;&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot; (1) = {}\n&quot;, .{42});
    try print(&quot; (2) = {}\n&quot;, .{0x17});
    try print(&quot; (3) = {}\n&quot;, .{0o17});
    try print(&quot; (4) = {}\n&quot;, .{0b0100101});
    try print(&quot; (5) = {}\n&quot;, .{1e222});
    try print(&quot; (6) = {}\n&quot;, .{3.1415926536});
    try print(&quot; (7) = {}\n&quot;, .{'c'});
    try print(&quot; (8) = {c}\n&quot;, .{'c'});
    try print(&quot; (9) = {s}\n&quot;, .{&quot;abcdef&quot;});
    try print(&quot;(10) = {}, {}\n&quot;, .{ 111, 999 });
    try print(&quot;(11) = {1}, {0}\n&quot;, .{ 111, 999 });
    try print(&quot;(12) = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; });
    try print(&quot;(13) = {0d}, {0b}, {0o}, {0x}, {0X}\n&quot;, .{ 123 });
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
 (1) = 42
 (2) = 23
 (3) = 15
 (4) = 37
 (5) = 1.0e+222
 (6) = 3.1415926536e+00
 (7) = 99
 (8) = c
 (9) = abcdef
(10) = 111, 999
(11) = 999, 111
(12) = abc, 111
(13) = 123, 1111011, 173, 7b, 7B
&lt;/syntaxhighlight&gt;
&lt;!-- リテラルの例、というか、@import(&quot;std&quot;).io.getStdOut().writer().print の例になっていますね。--&gt;
ご覧のように、数値（整数と浮動小数点数）や文字・文字列のリテラルがあり、整数は基数を、浮動小数点数は指数表現と小数表現があります。

@import(&quot;std&quot;).io.getStdOut().writer().printの、第一引数は書式化文字列、第二引数は値リストです。書式化文字列は、通常の文字列ですが &lt;code&gt;{&lt;/code&gt; と &lt;code&gt;}&lt;/code&gt; で囲まれたプレスホルダーが、引数リストの値（を書式化した文字列）に置き換わります。

一番素朴なプレスホルダーは {} で、引数の値の一般的な文字列表記に置き換ります（整数なら十進数表記、浮動小数点数なら指数表記）。ところが、’c’ のような文字型を &lt;code&gt;{}&lt;/code&gt; そのままに適用すると下記のように文字コード化され整数と同じ十進数表記になってしまいます。そこで、文字型の場合は {c} と文字であることを明記すると文字表現となります。また、引用符の側も、シングルクォーテーションにすることで、厳密に文字型であることを区別しています（Fedora36で実行して確認）。

抜粋すると、
:&lt;syntaxhighlight lang=&quot;zig&quot;&gt;
    try print(&quot; (7) = {}\n&quot;, .{'c'});
    try print(&quot; (8) = {c}\n&quot;, .{'c'});
    try print(&quot; (9) = {s}\n&quot;, .{&quot;abcdef&quot;});
&lt;/syntaxhighlight&gt;
のように、&lt;code&gt;{c}&lt;/code&gt;なら対応する文字の引用符はシングルクォーテーション&lt;code&gt;'  '&lt;/code&gt;に、&lt;code&gt;{s}&lt;/code&gt;なら対応する文字'''列'''の引用符はダブルクォーテーション&lt;code&gt;&quot;  &quot;&lt;/code&gt;でなければなりません。

対応部分:&lt;syntaxhighlight lang=text&gt;
 (7) = 99
 (8) = c
 (9) = abcdef
&lt;/syntaxhighlight&gt;

上記のように（文字ではなく）文字'''列'''の場合は {s} を明記しないと（バージョン0.8.0からは）エラーになります。
2つ以上の値を渡す場合は、第二引数を　.{ 1, 2, 3 } の様にカンマ区切りのリストにします（ {} の前の . （点）を忘れがち）。
基本的に、左から順にプレスホルダーにリストの値が左から与えられますが、{0} {1} の書式で参照する引数の順位を明示できます。
書式指定と併用する時は、 &lt;code&gt; print(&quot;? = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; })&lt;/code&gt; の様に順位が先、書式指定文字が後になります。

[TODO:[https://github.com/ziglang/zig/blob/master/lib/std/fmt.zig master/lib/std/fmt.zig]を観て書いています。参照すべき標準ライブラリのドキュメントを発見出来たら、見直し]
[TODO:表組み]

==== comptime ====
Zigでは、コンパイル時に式が既知かどうかという概念を重要視しています。

下記コードはコンパイル等がエラーになります。
:&lt;syntaxhighlight lang=&quot;zig&quot; line highlight=7&gt;
fn mul(x: usize, y: usize) usize {
    return x * y;
}

pub fn main() void {
    const len : usize = mul(3, 4);
    const ary: [len]i32 = undefined;
    _ = ary;
}
&lt;/syntaxhighlight&gt;
;コンパイル結果:&lt;syntaxhighlight lang=text&gt;
An error occurred: 
/tmp/playground130713503/play.zig:7:17: error: unable to evaluate constant expression 
    const ary: [len]i32 = undefined;
&lt;/syntaxhighlight&gt;
: 「定数式が評価できない 」と宣っています。
: [[C++]]であれば、constexprが適用なケースですが、Zigでは次のような解決方法を取ります。下記コードはエラーになりません。

:&lt;syntaxhighlight lang=&quot;zig&quot; line highlight=6&gt;
fn mul(x: usize, y: usize) usize {
    return x * y;
}

pub fn main() void {
    const len : usize = comptime mul(3, 4); // mul の前に comptime を追加 
    const ary: [len]i32 = undefined;
    _ = ary;
}
&lt;/syntaxhighlight&gt;
:変更点は mul() の呼出しを comptime で修飾しただけです。comptime は、修飾子式を'''コンパイル時に実行する'''修飾子で、式の中でコンパイル時に未定な値が参照されると、エラーとなります。ここでは、数リテラル同士の商を求めているので、コンパイル時値が確定できます。
: _ = ary は、「定義済だが参照のない変数宣言」をサプレッスするときのイディオムです。

&lt;!--
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const i = 0;
    const string = [_]i32{ 1, 2, 3, 4 };
    for (string) |character, index| {
        std.debug.print(&quot;character: {}, index: {}, :{s} \n&quot;, .{ character, index, @typeName(@TypeOf(character)) });
    }
    _ = i;
}
--&gt;

===== インタプリタ的に実行する場合 =====
コンパイル済みファイルの作成を飛ばして、インタプリタ的に直接に実行する方法もあり、たとえばファイル名「hello.zig」なら下記のようなコマンドある。
 zig run hello.zig


===== プロジェクト作成する場合 =====
まず、プロジェクト関連のコマンドを実行すると、自動で数個のフォルダが作成されるので、それをまとめるためのフォルダを別に作っておき（たとえば proj とする）、べつにマウス右クリックでも mldir コマンドでもなんでもいいので proj ディレクトリを作成しておく。

そして、さらにカレント・ディレクトリを proj に移動するために、ターミナルでコマンド
 cd proj
で、そこに移動する。（そうしないと、今後の動作でホームフォルダにいくつものフォルダやファイルが作成され、管理しづらくなる）

その上で、プロジェクト作成のために
 zig init-exe
を行う。このコマンドにより、初期設定ファイルなどがいくつか自動的に作成される。

== 基礎篇 ==
[TODO:書くべき項目を並べてみましたが、例えば「値と型」を網羅的に書いていくと文章量が爆発するのが目に見えているので、過剰になったらリファレンス篇に移動するなどの方法で、各節はコンパクトさを心がけたいです。]

=== コメント ===
Zigでは、&lt;code&gt;//&lt;/code&gt; から行末までがコメントです。
C言語の &lt;code&gt;/* … */&lt;/code&gt; のスタイルの複数行に渡るコメントは'''ありません'''。
これは、コードの各行を文脈に関係なくトークン化できるようにするためです。
:&lt;syntaxhighlight lang=zig&gt;
// @import は組込み関数です。
const std = @import(&quot;std&quot;); // 先頭に @ が付く関数は組込み関数です
pub fn main() !void {
   try std.io.getStdOut().writeAll(&quot;Hello, World!\n&quot;);
}
&lt;/syntaxhighlight&gt;

==== Docコメント ====
Zigでは、&lt;code&gt;///&lt;/code&gt; から始まるコメントは特別なコメントで、Docコメント( ''Doc comments'' )と呼ばれます。
Docコメントは特定の場所にしか許されません。式の途中や非Docコメントの直前など、予想外の場所にdocコメントがあると、コンパイルエラーになります。

[TODO:サンプルコードと整形結果]

==== トップレベルDocコメント ====
Zigでは、&lt;code&gt;//!&lt;/code&gt; から始まるコメントは特別なコメントで、トップレベルDocコメント( ''Top-Level Doc Comments '' )と呼ばれます。
コンテナレベルのドキュメントのように、直後のドキュメントに属さないユーザードキュメントに、トップレベルDocコメントを使います。

[TODO:サンプルコードと整形結果]

DocコメントおよびトップレベルDocコメントは、コンパイル時に zig build-exe -femit-docs ソースファイル.zig の様に、-femit-docs をあたえると、 docs/ 以下にドキュメントが生成されます。

=== 値と型 ===
[TOD0:整数・浮動小数・論理値・文字列・共用体・構造体・列挙・配列・ベクトル・スライス・ポインター・ゼロビットな型]

:&lt;syntaxhighlight lang=zig&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot; (1) = {}\n&quot;, .{42});
    try print(&quot; (2) = {}\n&quot;, .{0x17});
    try print(&quot; (3) = {}\n&quot;, .{0o17});
    try print(&quot; (4) = {}\n&quot;, .{0b0100101});
    try print(&quot; (5) = {}\n&quot;, .{1e222});
    try print(&quot; (6) = {}\n&quot;, .{3.1415926536});
    try print(&quot; (7) = {}\n&quot;, .{'c'});
    try print(&quot; (8) = {c}\n&quot;, .{'c'});
    try print(&quot; (9) = {s}\n&quot;, .{&quot;abcdef&quot;});
    try print(&quot;(10) = {}, {}\n&quot;, .{ 111, 999 });
    try print(&quot;(11) = {1}, {0}\n&quot;, .{ 111, 999 });
    try print(&quot;(12) = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; });
    try print(&quot;(13) = {0d}, {0b}, {0o}, {0x}, {0X}\n&quot;, .{ 123 });
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
 (1) = 42
 (2) = 23
 (3) = 15
 (4) = 37
 (5) = 1.0e+222
 (6) = 3.1415926536e+00
 (7) = 99
 (8) = c
 (9) = abcdef
(10) = 111, 999
(11) = 999, 111
(12) = abc, 111
(13) = 123, 1111011, 173, 7b, 7B
&lt;/syntaxhighlight&gt;
&lt;!-- リテラルの例、というか、@import(&quot;std&quot;).io.getStdOut().writer().print の例になっていますね。--&gt;
ご覧のように、数値（整数と浮動小数点数）や文字・文字列のリテラルがあり、整数は基数を、浮動小数点数は指数表現と少数表現があります。

@import(&quot;std&quot;).io.getStdOut().writer().printの、第一引数は書式化文字列、第二引数は値リストです。
書式化文字列は、通常の文字列ですが &lt;code&gt;{&lt;/code&gt; と &lt;code&gt;}&lt;/code&gt; で囲まれたプレスホルダーが、引数リストの値（を書式化した文字列）に置換わります。
一番素朴なプレスホルダーは {} で、引数の値の一般的な文字列表記に置き換ります（整数なら十進数表記、浮動小数点数なら指数表記）。
ところが、’c’ のような文字型を {} に適用すると文字コード化され整数と同じ十進数表記になってしまいます。そこで、文字型の場合は {c} と文字であることを明記すると文字表現となります。
また、文字列の間合いは {s} を明記しないと（バージョン0.8.0からは）エラーになります。
2つ以上の値を渡す場合は、第二引数を　.{ 1, 2, 3 } の様にカンマ区切りのリストにします（ これが、Zig の配列リテラルの表現で、{} の前の . （点）を忘れがち）。
基本的に、左から順にプレスホルダーにリストの値が左から与えられますが、{0} {1} の書式で参照する引数の順位を明示できます。
書式指定と併用する時は、 &lt;code&gt; print(&quot;? = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; })&lt;/code&gt; の様に順位が先、書式指定文字が後になります。

[TODO:[https://github.com/ziglang/zig/blob/master/lib/std/fmt.zig master/lib/std/fmt.zig]を観て書いています。参照すべき標準ライブラリのドキュメントを発見出来たら、見直し]
[TODO:表組み]

==== comptime ====
Zigでは、コンパイル時に式が既知かどうかという概念を重要視しています。

&lt;!--
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const i = 0;
    const string = [_]i32{ 1, 2, 3, 4 };
    for (string) |character, index| {
        std.debug.print(&quot;character: {}, index: {}, :{s} \n&quot;, .{ character, index, @typeName(@TypeOf(character)) });
    }
    _ = i;
}
--&gt;

=== テスト ===
=== 変数 ===
=== 制御構造 ===
[TODO:Zig の制御構造は文ではなく式]
==== 分岐 ====
[TODO:ifとswitch]
==== 反復 ====
[TODO:whileとfor]
=== 関数 ===
=== エラー ===
=== 演算子 ===
==== 優先順位 ====
高
&lt;syntaxhighlight lang=text line&gt;
 x() x[] x.y x.* x.?
 a!b
 x{}
 !x -x -%x ~x &amp;x ?x
 * / % ** *% *| ||
 + - ++ +% -% +| -|
 &lt;&lt; &gt;&gt; &lt;&lt;|
 &amp; ^ | orelse catch
 == != &lt; &gt; &lt;= &gt;=
 and
 or
 = *= *%= *|= /= %= += +%= +|= -= -%= -|= &lt;&lt;= &lt;&lt;|= &gt;&gt;= &amp;= ^= |=
&lt;/syntaxhighlight&gt;
低

===  optional type ===
===  opaque ===
訳語未定
=== ブロック ===
[TODO:スコープとシャドーイング；deferはここ？]
=== キャスト ===
[TODO:Zig は強い型付け()； 型強制 (Type coercion) について]
=== アセンブリ言語との連携 ===
[TODO:所謂インラインアセンラ]
=== atomic ===
=== 非同期関数 ===
=== 組込み関数 ===
[TODO:組込み関数は、@で始まり、@TypeOfや@alignOfの他@sinや@memcpyも組込み関数]
=== メモリ管理 ===
=== キーワード一覧 ===
&lt;code&gt;align&lt;/code&gt;
&lt;code&gt;allowzero&lt;/code&gt;
&lt;code&gt;and&lt;/code&gt;
&lt;code&gt;anyframe&lt;/code&gt;
&lt;code&gt;anytype&lt;/code&gt;
&lt;code&gt;asm&lt;/code&gt;
&lt;code&gt;async&lt;/code&gt;
&lt;code&gt;await&lt;/code&gt;
&lt;code&gt;break&lt;/code&gt;
&lt;code&gt;catch&lt;/code&gt;
&lt;code&gt;comptime&lt;/code&gt;
&lt;code&gt;const&lt;/code&gt;
&lt;code&gt;continue&lt;/code&gt;
&lt;code&gt;defer&lt;/code&gt;
&lt;code&gt;else&lt;/code&gt;
&lt;code&gt;enum&lt;/code&gt;
&lt;code&gt;errdefer&lt;/code&gt;
&lt;code&gt;error&lt;/code&gt;
&lt;code&gt;export&lt;/code&gt;
&lt;code&gt;extern&lt;/code&gt;
&lt;code&gt;fn&lt;/code&gt;
&lt;code&gt;for&lt;/code&gt;
&lt;code&gt;if&lt;/code&gt;
&lt;code&gt;inline&lt;/code&gt;
&lt;code&gt;noalias&lt;/code&gt;
&lt;code&gt;nosuspend&lt;/code&gt;
&lt;code&gt;or&lt;/code&gt;
&lt;code&gt;orelse&lt;/code&gt;
&lt;code&gt;packed&lt;/code&gt;
&lt;code&gt;pub&lt;/code&gt;
&lt;code&gt;resume&lt;/code&gt;
&lt;code&gt;return&lt;/code&gt;
&lt;code&gt;linksection&lt;/code&gt;
&lt;code&gt;struct&lt;/code&gt;
&lt;code&gt;suspend&lt;/code&gt;
&lt;code&gt;switch&lt;/code&gt;
&lt;code&gt;test&lt;/code&gt;
&lt;code&gt;threadlocal&lt;/code&gt;
&lt;code&gt;try&lt;/code&gt;
&lt;code&gt;union&lt;/code&gt;
&lt;code&gt;unreachable&lt;/code&gt;
&lt;code&gt;usingnamespace&lt;/code&gt;
&lt;code&gt;var&lt;/code&gt;
&lt;code&gt;volatile&lt;/code&gt;
&lt;code&gt;while&lt;/code&gt;

== チートシート ==
[TODO:文法と型と頻用する標準ライブラリの関数と型のアンチョコ]

== リファレンス篇 ==

== 脚註 ==
&lt;references /&gt;

== 外部リンク ==
* [https://ziglang.org/ Home ⚡ Zig Programming Language] {{---}} 公式サイト
** [[https://ziglang.org/documentation/master/ Zig Language Reference]] {{---}} リファレンスマニュアル
* [https://github.com/ziglang/zig ziglang/zig: General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.] {{---}} 公式リポジトリ
* [https://zig-play.dev/ Zig Playground] {{---}} オンライン実行環境
** [https://github.com/gsquire/zig-play About An online Zig compiler inspired by Go and Rust] {{---}} リポジトリ

[[Category:zig|*]]
[[Category:プログラミング言語]]</text>
      <sha1>1jzwe5o8cr78lzb0qzx3zw2l6up5z7r</sha1>
    </revision>
    <revision>
      <id>205774</id>
      <parentid>205772</parentid>
      <timestamp>2022-07-24T07:31:58Z</timestamp>
      <contributor>
        <username>Ef3</username>
        <id>694</id>
      </contributor>
      <comment>[[Special:Contributions/すじにくシチュー|すじにくシチュー]] ([[User talk:すじにくシチュー|トーク]]) による版 205772 を取り消し。前の行と重複。</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="22027" xml:space="preserve">{{Pathnav|メインページ|工学|情報技術|プログラミング|frame=1}}
{{Wikipedia|Zig (プログラミング言語)}}
本書は、[[w:Zig|Zig]]のチュートリアルです。
Zigは、堅牢で最適かつ再利用可能なソフトウェアを維持するための汎用プログラミング言語およびツールチェインです&lt;ref&gt;{{Cite web
|url=https://ziglang.org/
|title=Home ⚡ Zig Programming Language
|website=ziglang.org
|accessdate=2022-07-17
|cite=Zig is a general-purpose programming language and toolchain for maintaining '''robust''', '''optimal''' and '''reusable''' software.
}}&lt;/ref&gt;。
Zigは、アンドリュー・ケリー( ''[https://andrewkelley.me/ Andrew Kelley]'' )によって設計され、汎用システムプログラミング言語で、静的で強い型付けで型推論とジェネリックプログラミングをサポートします。

== 概要 ==
Zigは、2016年2月に発表された比較的若いプログラミング言語で&lt;ref&gt;{{Cite web
|last1=Kelley
|first1=Andrew
|title=Introduction to the Zig Programming Language
|url=https://andrewkelley.me/post/intro-to-zig.html
|website=andrewkelley.me
|accessdate=2022-07-17
}}&lt;/ref&gt;、2022年7月現在のバージョンは 0.9.1 で、'''''pre-release''''' と位置づけられています&lt;ref&gt;{{Cite web
|url=https://github.com/ziglang/zig/releases
|title=Releases · ziglang/zig
|website=github.com
|accessdate=2022-07-17
}}&lt;/ref&gt;。このため [[W:Hello world|Hello world]] ですら、バージョン間で互換性がなくなることもあり、リリースバージョンまでは言語仕様やライブラリーおよびツールチェインの仕様が変更される可能性があります。

=== Hello world の変遷 ===
[https://ziglang.org/documentation/master/ Zig Language Reference]の、[[W:Hello world|Hello world]]の変遷（新しい順）。

;master@2022-07-17&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/master/#Hello-World
|title=Zig Documentation(master@2022-07-17)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.8.1に同じ
;0.9.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.9.1/#Hello-World
|title=Zig Documentation(0.9.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.8.1に同じ
;0.8.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.8.1/#Hello-World
|title=Zig Documentation(0.8.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=4&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().writer();
    try stdout.print(&quot;Hello, {s}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: &lt;code&gt;{}&lt;/code&gt; ⇒ &lt;code&gt;{s}&lt;/code&gt;&lt;ref&gt;{{Cite web
|url=https://ziglang.org/download/0.8.0/release-notes.html#Formatted-Printing
|title=0.8.0 Release Notes
|website=ziglang.org
|accessdate=2022-07-17
|quote=Disable the special casing of {} for u8 slices/arrays. Unless {s} is specified the contents won't be treated as a string.
}}&lt;/ref&gt;
;0.7.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.7.1/#Hello-World
|title=Zig Documentation(0.7.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=3&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().writer();
    try stdout.print(&quot;Hello, {}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: s/outStream/writer/
;0.6.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.6.0/#Hello-World
|title=Zig Documentation(0.6.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=3&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().outStream();
    try stdout.print(&quot;Hello, {}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: 初期化の初期値から &lt;code&gt;try&lt;/code&gt; がなくなった。
;0.4.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.4.0/#Hello-World
|title=Zig Documentation(0.4.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.2.0に同じ
;0.5.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.5.0/#Hello-World
|title=Zig Documentation(0.5.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=4&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    // If this program is run without stdout attached, exit with an error.
    const stdout_file = try std.io.getStdOut();
    // If this program encounters pipe failure when printing to stdout, exit
    // with an error.
    try stdout_file.write(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;
: &lt;var&gt;stdout_file&lt;/var&gt; が &lt;code&gt;var&lt;/code&gt; から &lt;code&gt;const&lt;/code&gt; に変更された。

;0.3.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.3.0/#Hello-World
|title=Zig Documentation(0.3.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.2.0に同じ
;0.2.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.2.0/#Hello-World
|title=Zig Documentation(0.2.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    // If this program is run without stdout attached, exit with an error.
    var stdout_file = try std.io.getStdOut();
    // If this program encounters pipe failure when printing to stdout, exit
    // with an error.
    try stdout_file.write(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;
;0.1.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.1.1/#hello-world
|title=Zig Documentation
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig&gt;
const io = @import(&quot;std&quot;).io;
pub fn main() -&gt; %void {
    %%io.stdout.printf(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;

== 環境準備 ==
=== Linuxの場合 ===
==== インストール方法 ====
Fedora 36 の場合、2022年の時点で、コマンド
 sudo dnf install zig
だけでインストールできる事を確認。

その他のOS環境でのインストールについては、[https://github.com/ziglang/zig/wiki/Install-Zig-from-a-Package-Manager  GitHub  &quot;ziglang /zig&quot; ] を参照せよ。

インストールできたと思ったら、バージョン確認コマンドなどで、インストールの成否を確認しよう。コマンド
 zig version
で確認できる。

なお、2022年7月現在、まだバージョンは1未満であり、同7月に実験したところ
 0.9.1
であった。上記のセクションでも掛かれているように2022年の段階ではまだプレリリースであるので、1未満でもインストール成功なので安心していい。

==== コードの実行方法 ====
=== 値と型 ===
[TOD0:整数・浮動小数・論理値・文字列・共用体・構造体・列挙・配列・ベクトル・スライス・ポインター・ゼロビットな型]

:&lt;syntaxhighlight lang=&quot;zig&quot;&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot;abcd \n&quot;, .{} );
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
abcd 
&lt;/syntaxhighlight&gt;

2022年7月現在、引用符中に変数をなにも使っていなくても、&lt;code&gt;.{}&lt;/code&gt;が必要である。ほか&lt;code&gt;try print&lt;/code&gt; の &lt;code&gt;try&lt;/code&gt; については、&lt;code&gt;try&lt;/code&gt;がないとエラーになる。

:&lt;syntaxhighlight lang=&quot;zig&quot;&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot; (1) = {}\n&quot;, .{42});
    try print(&quot; (2) = {}\n&quot;, .{0x17});
    try print(&quot; (3) = {}\n&quot;, .{0o17});
    try print(&quot; (4) = {}\n&quot;, .{0b0100101});
    try print(&quot; (5) = {}\n&quot;, .{1e222});
    try print(&quot; (6) = {}\n&quot;, .{3.1415926536});
    try print(&quot; (7) = {}\n&quot;, .{'c'});
    try print(&quot; (8) = {c}\n&quot;, .{'c'});
    try print(&quot; (9) = {s}\n&quot;, .{&quot;abcdef&quot;});
    try print(&quot;(10) = {}, {}\n&quot;, .{ 111, 999 });
    try print(&quot;(11) = {1}, {0}\n&quot;, .{ 111, 999 });
    try print(&quot;(12) = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; });
    try print(&quot;(13) = {0d}, {0b}, {0o}, {0x}, {0X}\n&quot;, .{ 123 });
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
 (1) = 42
 (2) = 23
 (3) = 15
 (4) = 37
 (5) = 1.0e+222
 (6) = 3.1415926536e+00
 (7) = 99
 (8) = c
 (9) = abcdef
(10) = 111, 999
(11) = 999, 111
(12) = abc, 111
(13) = 123, 1111011, 173, 7b, 7B
&lt;/syntaxhighlight&gt;
&lt;!-- リテラルの例、というか、@import(&quot;std&quot;).io.getStdOut().writer().print の例になっていますね。--&gt;
ご覧のように、数値（整数と浮動小数点数）や文字・文字列のリテラルがあり、整数は基数を、浮動小数点数は指数表現と小数表現があります。

@import(&quot;std&quot;).io.getStdOut().writer().printの、第一引数は書式化文字列、第二引数は値リストです。書式化文字列は、通常の文字列ですが &lt;code&gt;{&lt;/code&gt; と &lt;code&gt;}&lt;/code&gt; で囲まれたプレスホルダーが、引数リストの値（を書式化した文字列）に置き換わります。

一番素朴なプレスホルダーは {} で、引数の値の一般的な文字列表記に置き換ります（整数なら十進数表記、浮動小数点数なら指数表記）。ところが、’c’ のような文字型を &lt;code&gt;{}&lt;/code&gt; そのままに適用すると下記のように文字コード化され整数と同じ十進数表記になってしまいます。そこで、文字型の場合は {c} と文字であることを明記すると文字表現となります。

上記コードでは、次のような部分のことです。
:&lt;syntaxhighlight lang=&quot;zig&quot;&gt;
    try print(&quot; (7) = {}\n&quot;, .{'c'});
    try print(&quot; (8) = {c}\n&quot;, .{'c'});
&lt;/syntaxhighlight&gt;

対応部分:&lt;syntaxhighlight lang=text&gt;
 (7) = 99
 (8) = c
&lt;/syntaxhighlight&gt;

また、（文字ではなく）文字'''列'''の場合は {s} を明記しないと（バージョン0.8.0からは）エラーになります。
2つ以上の値を渡す場合は、第二引数を　.{ 1, 2, 3 } の様にカンマ区切りのリストにします（ {} の前の . （点）を忘れがち）。
基本的に、左から順にプレスホルダーにリストの値が左から与えられますが、{0} {1} の書式で参照する引数の順位を明示できます。
書式指定と併用する時は、 &lt;code&gt; print(&quot;? = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; })&lt;/code&gt; の様に順位が先、書式指定文字が後になります。

[TODO:[https://github.com/ziglang/zig/blob/master/lib/std/fmt.zig master/lib/std/fmt.zig]を観て書いています。参照すべき標準ライブラリのドキュメントを発見出来たら、見直し]
[TODO:表組み]

==== comptime ====
Zigでは、コンパイル時に式が既知かどうかという概念を重要視しています。

下記コードはコンパイル等がエラーになります。
:&lt;syntaxhighlight lang=&quot;zig&quot; line highlight=7&gt;
fn mul(x: usize, y: usize) usize {
    return x * y;
}

pub fn main() void {
    const len : usize = mul(3, 4);
    const ary: [len]i32 = undefined;
    _ = ary;
}
&lt;/syntaxhighlight&gt;
;コンパイル結果:&lt;syntaxhighlight lang=text&gt;
An error occurred: 
/tmp/playground130713503/play.zig:7:17: error: unable to evaluate constant expression 
    const ary: [len]i32 = undefined;
&lt;/syntaxhighlight&gt;
: 「定数式が評価できない 」と宣っています。
: [[C++]]であれば、constexprが適用なケースですが、Zigでは次のような解決方法を取ります。下記コードはエラーになりません。

:&lt;syntaxhighlight lang=&quot;zig&quot; line highlight=6&gt;
fn mul(x: usize, y: usize) usize {
    return x * y;
}

pub fn main() void {
    const len : usize = comptime mul(3, 4); // mul の前に comptime を追加 
    const ary: [len]i32 = undefined;
    _ = ary;
}
&lt;/syntaxhighlight&gt;
:変更点は mul() の呼出しを comptime で修飾しただけです。comptime は、修飾子式を'''コンパイル時に実行する'''修飾子で、式の中でコンパイル時に未定な値が参照されると、エラーとなります。ここでは、数リテラル同士の商を求めているので、コンパイル時値が確定できます。
: _ = ary は、「定義済だが参照のない変数宣言」をサプレッスするときのイディオムです。

&lt;!--
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const i = 0;
    const string = [_]i32{ 1, 2, 3, 4 };
    for (string) |character, index| {
        std.debug.print(&quot;character: {}, index: {}, :{s} \n&quot;, .{ character, index, @typeName(@TypeOf(character)) });
    }
    _ = i;
}
--&gt;

===== インタプリタ的に実行する場合 =====
コンパイル済みファイルの作成を飛ばして、インタプリタ的に直接に実行する方法もあり、たとえばファイル名「hello.zig」なら下記のようなコマンドある。
 zig run hello.zig


===== プロジェクト作成する場合 =====
まず、プロジェクト関連のコマンドを実行すると、自動で数個のフォルダが作成されるので、それをまとめるためのフォルダを別に作っておき（たとえば proj とする）、べつにマウス右クリックでも mldir コマンドでもなんでもいいので proj ディレクトリを作成しておく。

そして、さらにカレント・ディレクトリを proj に移動するために、ターミナルでコマンド
 cd proj
で、そこに移動する。（そうしないと、今後の動作でホームフォルダにいくつものフォルダやファイルが作成され、管理しづらくなる）

その上で、プロジェクト作成のために
 zig init-exe
を行う。このコマンドにより、初期設定ファイルなどがいくつか自動的に作成される。

== 基礎篇 ==
[TODO:書くべき項目を並べてみましたが、例えば「値と型」を網羅的に書いていくと文章量が爆発するのが目に見えているので、過剰になったらリファレンス篇に移動するなどの方法で、各節はコンパクトさを心がけたいです。]

=== コメント ===
Zigでは、&lt;code&gt;//&lt;/code&gt; から行末までがコメントです。
C言語の &lt;code&gt;/* … */&lt;/code&gt; のスタイルの複数行に渡るコメントは'''ありません'''。
これは、コードの各行を文脈に関係なくトークン化できるようにするためです。
:&lt;syntaxhighlight lang=zig&gt;
// @import は組込み関数です。
const std = @import(&quot;std&quot;); // 先頭に @ が付く関数は組込み関数です
pub fn main() !void {
   try std.io.getStdOut().writeAll(&quot;Hello, World!\n&quot;);
}
&lt;/syntaxhighlight&gt;

==== Docコメント ====
Zigでは、&lt;code&gt;///&lt;/code&gt; から始まるコメントは特別なコメントで、Docコメント( ''Doc comments'' )と呼ばれます。
Docコメントは特定の場所にしか許されません。式の途中や非Docコメントの直前など、予想外の場所にdocコメントがあると、コンパイルエラーになります。

[TODO:サンプルコードと整形結果]

==== トップレベルDocコメント ====
Zigでは、&lt;code&gt;//!&lt;/code&gt; から始まるコメントは特別なコメントで、トップレベルDocコメント( ''Top-Level Doc Comments '' )と呼ばれます。
コンテナレベルのドキュメントのように、直後のドキュメントに属さないユーザードキュメントに、トップレベルDocコメントを使います。

[TODO:サンプルコードと整形結果]

DocコメントおよびトップレベルDocコメントは、コンパイル時に zig build-exe -femit-docs ソースファイル.zig の様に、-femit-docs をあたえると、 docs/ 以下にドキュメントが生成されます。

=== 値と型 ===
[TOD0:整数・浮動小数・論理値・文字列・共用体・構造体・列挙・配列・ベクトル・スライス・ポインター・ゼロビットな型]

:&lt;syntaxhighlight lang=zig&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot; (1) = {}\n&quot;, .{42});
    try print(&quot; (2) = {}\n&quot;, .{0x17});
    try print(&quot; (3) = {}\n&quot;, .{0o17});
    try print(&quot; (4) = {}\n&quot;, .{0b0100101});
    try print(&quot; (5) = {}\n&quot;, .{1e222});
    try print(&quot; (6) = {}\n&quot;, .{3.1415926536});
    try print(&quot; (7) = {}\n&quot;, .{'c'});
    try print(&quot; (8) = {c}\n&quot;, .{'c'});
    try print(&quot; (9) = {s}\n&quot;, .{&quot;abcdef&quot;});
    try print(&quot;(10) = {}, {}\n&quot;, .{ 111, 999 });
    try print(&quot;(11) = {1}, {0}\n&quot;, .{ 111, 999 });
    try print(&quot;(12) = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; });
    try print(&quot;(13) = {0d}, {0b}, {0o}, {0x}, {0X}\n&quot;, .{ 123 });
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
 (1) = 42
 (2) = 23
 (3) = 15
 (4) = 37
 (5) = 1.0e+222
 (6) = 3.1415926536e+00
 (7) = 99
 (8) = c
 (9) = abcdef
(10) = 111, 999
(11) = 999, 111
(12) = abc, 111
(13) = 123, 1111011, 173, 7b, 7B
&lt;/syntaxhighlight&gt;
&lt;!-- リテラルの例、というか、@import(&quot;std&quot;).io.getStdOut().writer().print の例になっていますね。--&gt;
ご覧のように、数値（整数と浮動小数点数）や文字・文字列のリテラルがあり、整数は基数を、浮動小数点数は指数表現と少数表現があります。

@import(&quot;std&quot;).io.getStdOut().writer().printの、第一引数は書式化文字列、第二引数は値リストです。
書式化文字列は、通常の文字列ですが &lt;code&gt;{&lt;/code&gt; と &lt;code&gt;}&lt;/code&gt; で囲まれたプレスホルダーが、引数リストの値（を書式化した文字列）に置換わります。
一番素朴なプレスホルダーは {} で、引数の値の一般的な文字列表記に置き換ります（整数なら十進数表記、浮動小数点数なら指数表記）。
ところが、’c’ のような文字型を {} に適用すると文字コード化され整数と同じ十進数表記になってしまいます。そこで、文字型の場合は {c} と文字であることを明記すると文字表現となります。
また、文字列の間合いは {s} を明記しないと（バージョン0.8.0からは）エラーになります。
2つ以上の値を渡す場合は、第二引数を　.{ 1, 2, 3 } の様にカンマ区切りのリストにします（ これが、Zig の配列リテラルの表現で、{} の前の . （点）を忘れがち）。
基本的に、左から順にプレスホルダーにリストの値が左から与えられますが、{0} {1} の書式で参照する引数の順位を明示できます。
書式指定と併用する時は、 &lt;code&gt; print(&quot;? = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; })&lt;/code&gt; の様に順位が先、書式指定文字が後になります。

[TODO:[https://github.com/ziglang/zig/blob/master/lib/std/fmt.zig master/lib/std/fmt.zig]を観て書いています。参照すべき標準ライブラリのドキュメントを発見出来たら、見直し]
[TODO:表組み]

==== comptime ====
Zigでは、コンパイル時に式が既知かどうかという概念を重要視しています。

&lt;!--
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const i = 0;
    const string = [_]i32{ 1, 2, 3, 4 };
    for (string) |character, index| {
        std.debug.print(&quot;character: {}, index: {}, :{s} \n&quot;, .{ character, index, @typeName(@TypeOf(character)) });
    }
    _ = i;
}
--&gt;

=== テスト ===
=== 変数 ===
=== 制御構造 ===
[TODO:Zig の制御構造は文ではなく式]
==== 分岐 ====
[TODO:ifとswitch]
==== 反復 ====
[TODO:whileとfor]
=== 関数 ===
=== エラー ===
=== 演算子 ===
==== 優先順位 ====
高
&lt;syntaxhighlight lang=text line&gt;
 x() x[] x.y x.* x.?
 a!b
 x{}
 !x -x -%x ~x &amp;x ?x
 * / % ** *% *| ||
 + - ++ +% -% +| -|
 &lt;&lt; &gt;&gt; &lt;&lt;|
 &amp; ^ | orelse catch
 == != &lt; &gt; &lt;= &gt;=
 and
 or
 = *= *%= *|= /= %= += +%= +|= -= -%= -|= &lt;&lt;= &lt;&lt;|= &gt;&gt;= &amp;= ^= |=
&lt;/syntaxhighlight&gt;
低

===  optional type ===
===  opaque ===
訳語未定
=== ブロック ===
[TODO:スコープとシャドーイング；deferはここ？]
=== キャスト ===
[TODO:Zig は強い型付け()； 型強制 (Type coercion) について]
=== アセンブリ言語との連携 ===
[TODO:所謂インラインアセンラ]
=== atomic ===
=== 非同期関数 ===
=== 組込み関数 ===
[TODO:組込み関数は、@で始まり、@TypeOfや@alignOfの他@sinや@memcpyも組込み関数]
=== メモリ管理 ===
=== キーワード一覧 ===
&lt;code&gt;align&lt;/code&gt;
&lt;code&gt;allowzero&lt;/code&gt;
&lt;code&gt;and&lt;/code&gt;
&lt;code&gt;anyframe&lt;/code&gt;
&lt;code&gt;anytype&lt;/code&gt;
&lt;code&gt;asm&lt;/code&gt;
&lt;code&gt;async&lt;/code&gt;
&lt;code&gt;await&lt;/code&gt;
&lt;code&gt;break&lt;/code&gt;
&lt;code&gt;catch&lt;/code&gt;
&lt;code&gt;comptime&lt;/code&gt;
&lt;code&gt;const&lt;/code&gt;
&lt;code&gt;continue&lt;/code&gt;
&lt;code&gt;defer&lt;/code&gt;
&lt;code&gt;else&lt;/code&gt;
&lt;code&gt;enum&lt;/code&gt;
&lt;code&gt;errdefer&lt;/code&gt;
&lt;code&gt;error&lt;/code&gt;
&lt;code&gt;export&lt;/code&gt;
&lt;code&gt;extern&lt;/code&gt;
&lt;code&gt;fn&lt;/code&gt;
&lt;code&gt;for&lt;/code&gt;
&lt;code&gt;if&lt;/code&gt;
&lt;code&gt;inline&lt;/code&gt;
&lt;code&gt;noalias&lt;/code&gt;
&lt;code&gt;nosuspend&lt;/code&gt;
&lt;code&gt;or&lt;/code&gt;
&lt;code&gt;orelse&lt;/code&gt;
&lt;code&gt;packed&lt;/code&gt;
&lt;code&gt;pub&lt;/code&gt;
&lt;code&gt;resume&lt;/code&gt;
&lt;code&gt;return&lt;/code&gt;
&lt;code&gt;linksection&lt;/code&gt;
&lt;code&gt;struct&lt;/code&gt;
&lt;code&gt;suspend&lt;/code&gt;
&lt;code&gt;switch&lt;/code&gt;
&lt;code&gt;test&lt;/code&gt;
&lt;code&gt;threadlocal&lt;/code&gt;
&lt;code&gt;try&lt;/code&gt;
&lt;code&gt;union&lt;/code&gt;
&lt;code&gt;unreachable&lt;/code&gt;
&lt;code&gt;usingnamespace&lt;/code&gt;
&lt;code&gt;var&lt;/code&gt;
&lt;code&gt;volatile&lt;/code&gt;
&lt;code&gt;while&lt;/code&gt;

== チートシート ==
[TODO:文法と型と頻用する標準ライブラリの関数と型のアンチョコ]

== リファレンス篇 ==

== 脚註 ==
&lt;references /&gt;

== 外部リンク ==
* [https://ziglang.org/ Home ⚡ Zig Programming Language] {{---}} 公式サイト
** [[https://ziglang.org/documentation/master/ Zig Language Reference]] {{---}} リファレンスマニュアル
* [https://github.com/ziglang/zig ziglang/zig: General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.] {{---}} 公式リポジトリ
* [https://zig-play.dev/ Zig Playground] {{---}} オンライン実行環境
** [https://github.com/gsquire/zig-play About An online Zig compiler inspired by Go and Rust] {{---}} リポジトリ

[[Category:zig|*]]
[[Category:プログラミング言語]]</text>
      <sha1>rqoarxiutayl1x3ww9gu1wfvge62l0s</sha1>
    </revision>
    <revision>
      <id>205775</id>
      <parentid>205774</parentid>
      <timestamp>2022-07-24T07:37:10Z</timestamp>
      <contributor>
        <username>Ef3</username>
        <id>694</id>
      </contributor>
      <comment>語尾の統一</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="22078" xml:space="preserve">{{Pathnav|メインページ|工学|情報技術|プログラミング|frame=1}}
{{Wikipedia|Zig (プログラミング言語)}}
本書は、[[w:Zig|Zig]]のチュートリアルです。
Zigは、堅牢で最適かつ再利用可能なソフトウェアを維持するための汎用プログラミング言語およびツールチェインです&lt;ref&gt;{{Cite web
|url=https://ziglang.org/
|title=Home ⚡ Zig Programming Language
|website=ziglang.org
|accessdate=2022-07-17
|cite=Zig is a general-purpose programming language and toolchain for maintaining '''robust''', '''optimal''' and '''reusable''' software.
}}&lt;/ref&gt;。
Zigは、アンドリュー・ケリー( ''[https://andrewkelley.me/ Andrew Kelley]'' )によって設計され、汎用システムプログラミング言語で、静的で強い型付けで型推論とジェネリックプログラミングをサポートします。

== 概要 ==
Zigは、2016年2月に発表された比較的若いプログラミング言語で&lt;ref&gt;{{Cite web
|last1=Kelley
|first1=Andrew
|title=Introduction to the Zig Programming Language
|url=https://andrewkelley.me/post/intro-to-zig.html
|website=andrewkelley.me
|accessdate=2022-07-17
}}&lt;/ref&gt;、2022年7月現在のバージョンは 0.9.1 で、'''''pre-release''''' と位置づけられています&lt;ref&gt;{{Cite web
|url=https://github.com/ziglang/zig/releases
|title=Releases · ziglang/zig
|website=github.com
|accessdate=2022-07-17
}}&lt;/ref&gt;。このため [[W:Hello world|Hello world]] ですら、バージョン間で互換性がなくなることもあり、リリースバージョンまでは言語仕様やライブラリーおよびツールチェインの仕様が変更される可能性があります。

=== Hello world の変遷 ===
[https://ziglang.org/documentation/master/ Zig Language Reference]の、[[W:Hello world|Hello world]]の変遷（新しい順）。

;master@2022-07-17&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/master/#Hello-World
|title=Zig Documentation(master@2022-07-17)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.8.1に同じ
;0.9.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.9.1/#Hello-World
|title=Zig Documentation(0.9.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.8.1に同じ
;0.8.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.8.1/#Hello-World
|title=Zig Documentation(0.8.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=4&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().writer();
    try stdout.print(&quot;Hello, {s}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: &lt;code&gt;{}&lt;/code&gt; ⇒ &lt;code&gt;{s}&lt;/code&gt;&lt;ref&gt;{{Cite web
|url=https://ziglang.org/download/0.8.0/release-notes.html#Formatted-Printing
|title=0.8.0 Release Notes
|website=ziglang.org
|accessdate=2022-07-17
|quote=Disable the special casing of {} for u8 slices/arrays. Unless {s} is specified the contents won't be treated as a string.
}}&lt;/ref&gt;
;0.7.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.7.1/#Hello-World
|title=Zig Documentation(0.7.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=3&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().writer();
    try stdout.print(&quot;Hello, {}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: s/outStream/writer/
;0.6.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.6.0/#Hello-World
|title=Zig Documentation(0.6.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=3&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().outStream();
    try stdout.print(&quot;Hello, {}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: 初期化の初期値から &lt;code&gt;try&lt;/code&gt; がなくなった。
;0.4.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.4.0/#Hello-World
|title=Zig Documentation(0.4.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.2.0に同じ
;0.5.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.5.0/#Hello-World
|title=Zig Documentation(0.5.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=4&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    // If this program is run without stdout attached, exit with an error.
    const stdout_file = try std.io.getStdOut();
    // If this program encounters pipe failure when printing to stdout, exit
    // with an error.
    try stdout_file.write(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;
: &lt;var&gt;stdout_file&lt;/var&gt; が &lt;code&gt;var&lt;/code&gt; から &lt;code&gt;const&lt;/code&gt; に変更された。

;0.3.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.3.0/#Hello-World
|title=Zig Documentation(0.3.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.2.0に同じ
;0.2.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.2.0/#Hello-World
|title=Zig Documentation(0.2.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    // If this program is run without stdout attached, exit with an error.
    var stdout_file = try std.io.getStdOut();
    // If this program encounters pipe failure when printing to stdout, exit
    // with an error.
    try stdout_file.write(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;
;0.1.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.1.1/#hello-world
|title=Zig Documentation
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig&gt;
const io = @import(&quot;std&quot;).io;
pub fn main() -&gt; %void {
    %%io.stdout.printf(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;

== 環境準備 ==
=== Linuxの場合 ===
==== インストール方法 ====
Fedora 36 の場合、2022年の時点で、コマンド
 sudo dnf install zig
だけでインストールできる事を確認。

その他のOS環境でのインストールについては、[https://github.com/ziglang/zig/wiki/Install-Zig-from-a-Package-Manager  GitHub  &quot;ziglang /zig&quot; ] を参照せよ。

インストールできたと思ったら、バージョン確認コマンドなどで、インストールの成否を確認しましょう。コマンド
 zig version
で確認できます。

なお、2022年7月現在、まだバージョンは1未満であり、同7月に実験したところ
 0.9.1
であった。上記のセクションでも掛かれているように2022年の段階ではまだプレリリースであるので、1未満でもインストール成功なので安心していいです。

==== コードの実行方法 ====
=== 値と型 ===
[TOD0:整数・浮動小数・論理値・文字列・共用体・構造体・列挙・配列・ベクトル・スライス・ポインター・ゼロビットな型]

:&lt;syntaxhighlight lang=&quot;zig&quot;&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot;abcd \n&quot;, .{} );
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
abcd 
&lt;/syntaxhighlight&gt;

2022年7月現在、引用符中に変数をなにも使っていなくても、&lt;code&gt;.{}&lt;/code&gt;が必要です。ほか&lt;code&gt;try print&lt;/code&gt; の &lt;code&gt;try&lt;/code&gt; については、&lt;code&gt;try&lt;/code&gt;がないとエラーになります。

:&lt;syntaxhighlight lang=&quot;zig&quot;&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot; (1) = {}\n&quot;, .{42});
    try print(&quot; (2) = {}\n&quot;, .{0x17});
    try print(&quot; (3) = {}\n&quot;, .{0o17});
    try print(&quot; (4) = {}\n&quot;, .{0b0100101});
    try print(&quot; (5) = {}\n&quot;, .{1e222});
    try print(&quot; (6) = {}\n&quot;, .{3.1415926536});
    try print(&quot; (7) = {}\n&quot;, .{'c'});
    try print(&quot; (8) = {c}\n&quot;, .{'c'});
    try print(&quot; (9) = {s}\n&quot;, .{&quot;abcdef&quot;});
    try print(&quot;(10) = {}, {}\n&quot;, .{ 111, 999 });
    try print(&quot;(11) = {1}, {0}\n&quot;, .{ 111, 999 });
    try print(&quot;(12) = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; });
    try print(&quot;(13) = {0d}, {0b}, {0o}, {0x}, {0X}\n&quot;, .{ 123 });
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
 (1) = 42
 (2) = 23
 (3) = 15
 (4) = 37
 (5) = 1.0e+222
 (6) = 3.1415926536e+00
 (7) = 99
 (8) = c
 (9) = abcdef
(10) = 111, 999
(11) = 999, 111
(12) = abc, 111
(13) = 123, 1111011, 173, 7b, 7B
&lt;/syntaxhighlight&gt;
&lt;!-- リテラルの例、というか、@import(&quot;std&quot;).io.getStdOut().writer().print の例になっていますね。--&gt;
ご覧のように、数値（整数と浮動小数点数）や文字・文字列のリテラルがあり、整数は基数を、浮動小数点数は指数表現と小数表現があります。

@import(&quot;std&quot;).io.getStdOut().writer().printの、第一引数は書式化文字列、第二引数は値リストです。書式化文字列は、通常の文字列ですが &lt;code&gt;{&lt;/code&gt; と &lt;code&gt;}&lt;/code&gt; で囲まれたプレスホルダーが、引数リストの値（を書式化した文字列）に置き換わります。

一番素朴なプレスホルダーは {} で、引数の値の一般的な文字列表記に置き換ります（整数なら十進数表記、浮動小数点数なら指数表記）。ところが、’c’ のような文字型を &lt;code&gt;{}&lt;/code&gt; そのままに適用すると下記のように文字コード化され整数と同じ十進数表記になってしまいます。そこで、文字型の場合は {c} と文字であることを明記すると文字表現となります。

上記コードでは、次のような部分のことです。
:&lt;syntaxhighlight lang=&quot;zig&quot;&gt;
    try print(&quot; (7) = {}\n&quot;, .{'c'});
    try print(&quot; (8) = {c}\n&quot;, .{'c'});
&lt;/syntaxhighlight&gt;

対応部分:&lt;syntaxhighlight lang=text&gt;
 (7) = 99
 (8) = c
&lt;/syntaxhighlight&gt;

また、（文字ではなく）文字'''列'''の場合は {s} を明記しないと（バージョン0.8.0からは）エラーになります。
2つ以上の値を渡す場合は、第二引数を　.{ 1, 2, 3 } の様にカンマ区切りのリストにします（ {} の前の . （点）を忘れがち）。
基本的に、左から順にプレスホルダーにリストの値が左から与えられますが、{0} {1} の書式で参照する引数の順位を明示できます。
書式指定と併用する時は、 &lt;code&gt; print(&quot;? = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; })&lt;/code&gt; の様に順位が先、書式指定文字が後になります。

[TODO:[https://github.com/ziglang/zig/blob/master/lib/std/fmt.zig master/lib/std/fmt.zig]を観て書いています。参照すべき標準ライブラリのドキュメントを発見出来たら、見直し]
[TODO:表組み]

==== comptime ====
Zigでは、コンパイル時に式が既知かどうかという概念を重要視しています。

下記コードはコンパイル等がエラーになります。
:&lt;syntaxhighlight lang=&quot;zig&quot; line highlight=7&gt;
fn mul(x: usize, y: usize) usize {
    return x * y;
}

pub fn main() void {
    const len : usize = mul(3, 4);
    const ary: [len]i32 = undefined;
    _ = ary;
}
&lt;/syntaxhighlight&gt;
;コンパイル結果:&lt;syntaxhighlight lang=text&gt;
An error occurred: 
/tmp/playground130713503/play.zig:7:17: error: unable to evaluate constant expression 
    const ary: [len]i32 = undefined;
&lt;/syntaxhighlight&gt;
: 「定数式が評価できない 」と宣っています。
: [[C++]]であれば、constexprが適用なケースですが、Zigでは次のような解決方法を取ります。下記コードはエラーになりません。

:&lt;syntaxhighlight lang=&quot;zig&quot; line highlight=6&gt;
fn mul(x: usize, y: usize) usize {
    return x * y;
}

pub fn main() void {
    const len : usize = comptime mul(3, 4); // mul の前に comptime を追加 
    const ary: [len]i32 = undefined;
    _ = ary;
}
&lt;/syntaxhighlight&gt;
:変更点は mul() の呼出しを comptime で修飾しただけです。comptime は、修飾子式を'''コンパイル時に実行する'''修飾子で、式の中でコンパイル時に未定な値が参照されると、エラーとなります。ここでは、数リテラル同士の商を求めているので、コンパイル時値が確定できます。
: _ = ary は、「定義済だが参照のない変数宣言」をサプレッスするときのイディオムです。

&lt;!--
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const i = 0;
    const string = [_]i32{ 1, 2, 3, 4 };
    for (string) |character, index| {
        std.debug.print(&quot;character: {}, index: {}, :{s} \n&quot;, .{ character, index, @typeName(@TypeOf(character)) });
    }
    _ = i;
}
--&gt;

===== インタプリタ的に実行する場合 =====
コンパイル済みファイルの作成を飛ばして、インタプリタ的に直接に実行する方法もあり、たとえばファイル名「hello.zig」なら下記のようなコマンドあります。
 zig run hello.zig


===== プロジェクト作成する場合 =====
まず、プロジェクト関連のコマンドを実行すると、自動で数個のフォルダが作成されるので、それをまとめるためのフォルダを別に作っておき（たとえば proj とします）、べつにマウス右クリックでも mldir コマンドでもなんでもいいので proj ディレクトリを作成しておく。

そして、さらにカレント・ディレクトリを proj に移動するために、ターミナルでコマンド
 cd proj
と、&lt;code&gt;proj&lt;/proj&gt; に移動します。（そうしないと、今後の動作でホームフォルダにいくつものフォルダやファイルが作成され、管理しづらくなります）

その上で、プロジェクト作成のために
 zig init-exe
を行う。このコマンドにより、初期設定ファイルなどがいくつか自動的に作成されます。

== 基礎篇 ==
[TODO:書くべき項目を並べてみましたが、例えば「値と型」を網羅的に書いていくと文章量が爆発するのが目に見えているので、過剰になったらリファレンス篇に移動するなどの方法で、各節はコンパクトさを心がけたいです。]

=== コメント ===
Zigでは、&lt;code&gt;//&lt;/code&gt; から行末までがコメントです。
C言語の &lt;code&gt;/* … */&lt;/code&gt; のスタイルの複数行に渡るコメントは'''ありません'''。
これは、コードの各行を文脈に関係なくトークン化できるようにするためです。
:&lt;syntaxhighlight lang=zig&gt;
// @import は組込み関数です。
const std = @import(&quot;std&quot;); // 先頭に @ が付く関数は組込み関数です
pub fn main() !void {
   try std.io.getStdOut().writeAll(&quot;Hello, World!\n&quot;);
}
&lt;/syntaxhighlight&gt;

==== Docコメント ====
Zigでは、&lt;code&gt;///&lt;/code&gt; から始まるコメントは特別なコメントで、Docコメント( ''Doc comments'' )と呼ばれます。
Docコメントは特定の場所にしか許されません。式の途中や非Docコメントの直前など、予想外の場所にdocコメントがあると、コンパイルエラーになります。

[TODO:サンプルコードと整形結果]

==== トップレベルDocコメント ====
Zigでは、&lt;code&gt;//!&lt;/code&gt; から始まるコメントは特別なコメントで、トップレベルDocコメント( ''Top-Level Doc Comments '' )と呼ばれます。
コンテナレベルのドキュメントのように、直後のドキュメントに属さないユーザードキュメントに、トップレベルDocコメントを使います。

[TODO:サンプルコードと整形結果]

DocコメントおよびトップレベルDocコメントは、コンパイル時に zig build-exe -femit-docs ソースファイル.zig の様に、-femit-docs をあたえると、 docs/ 以下にドキュメントが生成されます。

=== 値と型 ===
[TOD0:整数・浮動小数・論理値・文字列・共用体・構造体・列挙・配列・ベクトル・スライス・ポインター・ゼロビットな型]

:&lt;syntaxhighlight lang=zig&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot; (1) = {}\n&quot;, .{42});
    try print(&quot; (2) = {}\n&quot;, .{0x17});
    try print(&quot; (3) = {}\n&quot;, .{0o17});
    try print(&quot; (4) = {}\n&quot;, .{0b0100101});
    try print(&quot; (5) = {}\n&quot;, .{1e222});
    try print(&quot; (6) = {}\n&quot;, .{3.1415926536});
    try print(&quot; (7) = {}\n&quot;, .{'c'});
    try print(&quot; (8) = {c}\n&quot;, .{'c'});
    try print(&quot; (9) = {s}\n&quot;, .{&quot;abcdef&quot;});
    try print(&quot;(10) = {}, {}\n&quot;, .{ 111, 999 });
    try print(&quot;(11) = {1}, {0}\n&quot;, .{ 111, 999 });
    try print(&quot;(12) = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; });
    try print(&quot;(13) = {0d}, {0b}, {0o}, {0x}, {0X}\n&quot;, .{ 123 });
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
 (1) = 42
 (2) = 23
 (3) = 15
 (4) = 37
 (5) = 1.0e+222
 (6) = 3.1415926536e+00
 (7) = 99
 (8) = c
 (9) = abcdef
(10) = 111, 999
(11) = 999, 111
(12) = abc, 111
(13) = 123, 1111011, 173, 7b, 7B
&lt;/syntaxhighlight&gt;
&lt;!-- リテラルの例、というか、@import(&quot;std&quot;).io.getStdOut().writer().print の例になっていますね。--&gt;
ご覧のように、数値（整数と浮動小数点数）や文字・文字列のリテラルがあり、整数は基数を、浮動小数点数は指数表現と少数表現があります。

@import(&quot;std&quot;).io.getStdOut().writer().printの、第一引数は書式化文字列、第二引数は値リストです。
書式化文字列は、通常の文字列ですが &lt;code&gt;{&lt;/code&gt; と &lt;code&gt;}&lt;/code&gt; で囲まれたプレスホルダーが、引数リストの値（を書式化した文字列）に置換わります。
一番素朴なプレスホルダーは {} で、引数の値の一般的な文字列表記に置き換ります（整数なら十進数表記、浮動小数点数なら指数表記）。
ところが、’c’ のような文字型を {} に適用すると文字コード化され整数と同じ十進数表記になってしまいます。そこで、文字型の場合は {c} と文字であることを明記すると文字表現となります。
また、文字列の間合いは {s} を明記しないと（バージョン0.8.0からは）エラーになります。
2つ以上の値を渡す場合は、第二引数を　.{ 1, 2, 3 } の様にカンマ区切りのリストにします（ これが、Zig の配列リテラルの表現で、{} の前の . （点）を忘れがち）。
基本的に、左から順にプレスホルダーにリストの値が左から与えられますが、{0} {1} の書式で参照する引数の順位を明示できます。
書式指定と併用する時は、 &lt;code&gt; print(&quot;? = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; })&lt;/code&gt; の様に順位が先、書式指定文字が後になります。

[TODO:[https://github.com/ziglang/zig/blob/master/lib/std/fmt.zig master/lib/std/fmt.zig]を観て書いています。参照すべき標準ライブラリのドキュメントを発見出来たら、見直し]
[TODO:表組み]

==== comptime ====
Zigでは、コンパイル時に式が既知かどうかという概念を重要視しています。

&lt;!--
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const i = 0;
    const string = [_]i32{ 1, 2, 3, 4 };
    for (string) |character, index| {
        std.debug.print(&quot;character: {}, index: {}, :{s} \n&quot;, .{ character, index, @typeName(@TypeOf(character)) });
    }
    _ = i;
}
--&gt;

=== テスト ===
=== 変数 ===
=== 制御構造 ===
[TODO:Zig の制御構造は文ではなく式]
==== 分岐 ====
[TODO:ifとswitch]
==== 反復 ====
[TODO:whileとfor]
=== 関数 ===
=== エラー ===
=== 演算子 ===
==== 優先順位 ====
高
&lt;syntaxhighlight lang=text line&gt;
 x() x[] x.y x.* x.?
 a!b
 x{}
 !x -x -%x ~x &amp;x ?x
 * / % ** *% *| ||
 + - ++ +% -% +| -|
 &lt;&lt; &gt;&gt; &lt;&lt;|
 &amp; ^ | orelse catch
 == != &lt; &gt; &lt;= &gt;=
 and
 or
 = *= *%= *|= /= %= += +%= +|= -= -%= -|= &lt;&lt;= &lt;&lt;|= &gt;&gt;= &amp;= ^= |=
&lt;/syntaxhighlight&gt;
低

===  optional type ===
===  opaque ===
訳語未定
=== ブロック ===
[TODO:スコープとシャドーイング；deferはここ？]
=== キャスト ===
[TODO:Zig は強い型付け()； 型強制 (Type coercion) について]
=== アセンブリ言語との連携 ===
[TODO:所謂インラインアセンラ]
=== atomic ===
=== 非同期関数 ===
=== 組込み関数 ===
[TODO:組込み関数は、@で始まり、@TypeOfや@alignOfの他@sinや@memcpyも組込み関数]
=== メモリ管理 ===
=== キーワード一覧 ===
&lt;code&gt;align&lt;/code&gt;
&lt;code&gt;allowzero&lt;/code&gt;
&lt;code&gt;and&lt;/code&gt;
&lt;code&gt;anyframe&lt;/code&gt;
&lt;code&gt;anytype&lt;/code&gt;
&lt;code&gt;asm&lt;/code&gt;
&lt;code&gt;async&lt;/code&gt;
&lt;code&gt;await&lt;/code&gt;
&lt;code&gt;break&lt;/code&gt;
&lt;code&gt;catch&lt;/code&gt;
&lt;code&gt;comptime&lt;/code&gt;
&lt;code&gt;const&lt;/code&gt;
&lt;code&gt;continue&lt;/code&gt;
&lt;code&gt;defer&lt;/code&gt;
&lt;code&gt;else&lt;/code&gt;
&lt;code&gt;enum&lt;/code&gt;
&lt;code&gt;errdefer&lt;/code&gt;
&lt;code&gt;error&lt;/code&gt;
&lt;code&gt;export&lt;/code&gt;
&lt;code&gt;extern&lt;/code&gt;
&lt;code&gt;fn&lt;/code&gt;
&lt;code&gt;for&lt;/code&gt;
&lt;code&gt;if&lt;/code&gt;
&lt;code&gt;inline&lt;/code&gt;
&lt;code&gt;noalias&lt;/code&gt;
&lt;code&gt;nosuspend&lt;/code&gt;
&lt;code&gt;or&lt;/code&gt;
&lt;code&gt;orelse&lt;/code&gt;
&lt;code&gt;packed&lt;/code&gt;
&lt;code&gt;pub&lt;/code&gt;
&lt;code&gt;resume&lt;/code&gt;
&lt;code&gt;return&lt;/code&gt;
&lt;code&gt;linksection&lt;/code&gt;
&lt;code&gt;struct&lt;/code&gt;
&lt;code&gt;suspend&lt;/code&gt;
&lt;code&gt;switch&lt;/code&gt;
&lt;code&gt;test&lt;/code&gt;
&lt;code&gt;threadlocal&lt;/code&gt;
&lt;code&gt;try&lt;/code&gt;
&lt;code&gt;union&lt;/code&gt;
&lt;code&gt;unreachable&lt;/code&gt;
&lt;code&gt;usingnamespace&lt;/code&gt;
&lt;code&gt;var&lt;/code&gt;
&lt;code&gt;volatile&lt;/code&gt;
&lt;code&gt;while&lt;/code&gt;

== チートシート ==
[TODO:文法と型と頻用する標準ライブラリの関数と型のアンチョコ]

== リファレンス篇 ==

== 脚註 ==
&lt;references /&gt;

== 外部リンク ==
* [https://ziglang.org/ Home ⚡ Zig Programming Language] {{---}} 公式サイト
** [[https://ziglang.org/documentation/master/ Zig Language Reference]] {{---}} リファレンスマニュアル
* [https://github.com/ziglang/zig ziglang/zig: General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.] {{---}} 公式リポジトリ
* [https://zig-play.dev/ Zig Playground] {{---}} オンライン実行環境
** [https://github.com/gsquire/zig-play About An online Zig compiler inspired by Go and Rust] {{---}} リポジトリ

[[Category:zig|*]]
[[Category:プログラミング言語]]</text>
      <sha1>rrzmth1mnsq9ani6w4ulhjceo3c99w2</sha1>
    </revision>
    <revision>
      <id>205777</id>
      <parentid>205775</parentid>
      <timestamp>2022-07-24T07:59:00Z</timestamp>
      <contributor>
        <username>Ef3</username>
        <id>694</id>
      </contributor>
      <comment>/* 値と型 */ : &lt;code&gt;print()&lt;/code&gt;の前の、&lt;code&gt;try&lt;/code&gt;は単項演算子です。&lt;code&gt;try&lt;/code&gt; は、右の式が例外を投げると式の値にします。エラーユニオン型を返す関数は、&lt;code&gt;try&lt;/code&gt;単項演算子か&lt;code&gt;catch&lt;/code&gt;二項演算子で、値とエラーを弁別する必要があります（&lt;code&gt;try&lt;/code&gt;あるいは&lt;code&gt;catch&lt;/code&gt;がないと、コンパイル時にエラーになります）。 : &lt;code&gt;print()&lt;/code&gt;の様に、標準ライブラリの &lt;code&gt;format()&lt;/code&gt;を使う関数は、フォーマット文字列と配列 &lt;code&gt;.{ … }&lt;/code&gt; を引数にします。[[C言語/標準ライブラリ/ctype.h|C言語]]のような、可変引数'''ではなく'''可変長の配列を使うので、プレースホルダーがない場合でも、空の配列 &lt;code&gt;.{}&lt;/code&gt; は必須です。</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="22692" xml:space="preserve">{{Pathnav|メインページ|工学|情報技術|プログラミング|frame=1}}
{{Wikipedia|Zig (プログラミング言語)}}
本書は、[[w:Zig|Zig]]のチュートリアルです。
Zigは、堅牢で最適かつ再利用可能なソフトウェアを維持するための汎用プログラミング言語およびツールチェインです&lt;ref&gt;{{Cite web
|url=https://ziglang.org/
|title=Home ⚡ Zig Programming Language
|website=ziglang.org
|accessdate=2022-07-17
|cite=Zig is a general-purpose programming language and toolchain for maintaining '''robust''', '''optimal''' and '''reusable''' software.
}}&lt;/ref&gt;。
Zigは、アンドリュー・ケリー( ''[https://andrewkelley.me/ Andrew Kelley]'' )によって設計され、汎用システムプログラミング言語で、静的で強い型付けで型推論とジェネリックプログラミングをサポートします。

== 概要 ==
Zigは、2016年2月に発表された比較的若いプログラミング言語で&lt;ref&gt;{{Cite web
|last1=Kelley
|first1=Andrew
|title=Introduction to the Zig Programming Language
|url=https://andrewkelley.me/post/intro-to-zig.html
|website=andrewkelley.me
|accessdate=2022-07-17
}}&lt;/ref&gt;、2022年7月現在のバージョンは 0.9.1 で、'''''pre-release''''' と位置づけられています&lt;ref&gt;{{Cite web
|url=https://github.com/ziglang/zig/releases
|title=Releases · ziglang/zig
|website=github.com
|accessdate=2022-07-17
}}&lt;/ref&gt;。このため [[W:Hello world|Hello world]] ですら、バージョン間で互換性がなくなることもあり、リリースバージョンまでは言語仕様やライブラリーおよびツールチェインの仕様が変更される可能性があります。

=== Hello world の変遷 ===
[https://ziglang.org/documentation/master/ Zig Language Reference]の、[[W:Hello world|Hello world]]の変遷（新しい順）。

;master@2022-07-17&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/master/#Hello-World
|title=Zig Documentation(master@2022-07-17)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.8.1に同じ
;0.9.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.9.1/#Hello-World
|title=Zig Documentation(0.9.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.8.1に同じ
;0.8.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.8.1/#Hello-World
|title=Zig Documentation(0.8.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=4&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().writer();
    try stdout.print(&quot;Hello, {s}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: &lt;code&gt;{}&lt;/code&gt; ⇒ &lt;code&gt;{s}&lt;/code&gt;&lt;ref&gt;{{Cite web
|url=https://ziglang.org/download/0.8.0/release-notes.html#Formatted-Printing
|title=0.8.0 Release Notes
|website=ziglang.org
|accessdate=2022-07-17
|quote=Disable the special casing of {} for u8 slices/arrays. Unless {s} is specified the contents won't be treated as a string.
}}&lt;/ref&gt;
;0.7.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.7.1/#Hello-World
|title=Zig Documentation(0.7.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=3&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().writer();
    try stdout.print(&quot;Hello, {}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: s/outStream/writer/
;0.6.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.6.0/#Hello-World
|title=Zig Documentation(0.6.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=3&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().outStream();
    try stdout.print(&quot;Hello, {}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: 初期化の初期値から &lt;code&gt;try&lt;/code&gt; がなくなった。
;0.4.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.4.0/#Hello-World
|title=Zig Documentation(0.4.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.2.0に同じ
;0.5.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.5.0/#Hello-World
|title=Zig Documentation(0.5.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=4&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    // If this program is run without stdout attached, exit with an error.
    const stdout_file = try std.io.getStdOut();
    // If this program encounters pipe failure when printing to stdout, exit
    // with an error.
    try stdout_file.write(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;
: &lt;var&gt;stdout_file&lt;/var&gt; が &lt;code&gt;var&lt;/code&gt; から &lt;code&gt;const&lt;/code&gt; に変更された。

;0.3.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.3.0/#Hello-World
|title=Zig Documentation(0.3.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.2.0に同じ
;0.2.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.2.0/#Hello-World
|title=Zig Documentation(0.2.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    // If this program is run without stdout attached, exit with an error.
    var stdout_file = try std.io.getStdOut();
    // If this program encounters pipe failure when printing to stdout, exit
    // with an error.
    try stdout_file.write(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;
;0.1.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.1.1/#hello-world
|title=Zig Documentation
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig&gt;
const io = @import(&quot;std&quot;).io;
pub fn main() -&gt; %void {
    %%io.stdout.printf(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;

== 環境準備 ==
=== Linuxの場合 ===
==== インストール方法 ====
Fedora 36 の場合、2022年の時点で、コマンド
 sudo dnf install zig
だけでインストールできる事を確認。

その他のOS環境でのインストールについては、[https://github.com/ziglang/zig/wiki/Install-Zig-from-a-Package-Manager  GitHub  &quot;ziglang /zig&quot; ] を参照せよ。

インストールできたと思ったら、バージョン確認コマンドなどで、インストールの成否を確認しましょう。コマンド
 zig version
で確認できます。

なお、2022年7月現在、まだバージョンは1未満であり、同7月に実験したところ
 0.9.1
であった。上記のセクションでも掛かれているように2022年の段階ではまだプレリリースであるので、1未満でもインストール成功なので安心していいです。

==== コードの実行方法 ====
=== 値と型 ===
[TOD0:整数・浮動小数・論理値・文字列・共用体・構造体・列挙・配列・ベクトル・スライス・ポインター・ゼロビットな型]

:&lt;syntaxhighlight lang=&quot;zig&quot;&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot;abcd \n&quot;, .{} );
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
abcd 
&lt;/syntaxhighlight&gt;
: &lt;code&gt;print()&lt;/code&gt;の前の、&lt;code&gt;try&lt;/code&gt;は単項演算子です。&lt;code&gt;try&lt;/code&gt; は、右の式が例外を投げると式の値にします。エラーユニオン型を返す関数は、&lt;code&gt;try&lt;/code&gt;単項演算子か&lt;code&gt;catch&lt;/code&gt;二項演算子で、値とエラーを弁別する必要があります（&lt;code&gt;try&lt;/code&gt;あるいは&lt;code&gt;catch&lt;/code&gt;がないと、コンパイル時にエラーになります）。
: &lt;code&gt;print()&lt;/code&gt;の様に、標準ライブラリの &lt;code&gt;format()&lt;/code&gt;を使う関数は、フォーマット文字列と配列 &lt;code&gt;.{ … }&lt;/code&gt; を引数にします。[[C言語/標準ライブラリ/ctype.h|C言語]]のような、可変引数'''ではなく'''可変長の配列を使うので、プレースホルダーがない場合でも、空の配列 &lt;code&gt;.{}&lt;/code&gt; は必須です。

:&lt;syntaxhighlight lang=&quot;zig&quot;&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot; (1) = {}\n&quot;, .{42});
    try print(&quot; (2) = {}\n&quot;, .{0x17});
    try print(&quot; (3) = {}\n&quot;, .{0o17});
    try print(&quot; (4) = {}\n&quot;, .{0b0100101});
    try print(&quot; (5) = {}\n&quot;, .{1e222});
    try print(&quot; (6) = {}\n&quot;, .{3.1415926536});
    try print(&quot; (7) = {}\n&quot;, .{'c'});
    try print(&quot; (8) = {c}\n&quot;, .{'c'});
    try print(&quot; (9) = {s}\n&quot;, .{&quot;abcdef&quot;});
    try print(&quot;(10) = {}, {}\n&quot;, .{ 111, 999 });
    try print(&quot;(11) = {1}, {0}\n&quot;, .{ 111, 999 });
    try print(&quot;(12) = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; });
    try print(&quot;(13) = {0d}, {0b}, {0o}, {0x}, {0X}\n&quot;, .{ 123 });
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
 (1) = 42
 (2) = 23
 (3) = 15
 (4) = 37
 (5) = 1.0e+222
 (6) = 3.1415926536e+00
 (7) = 99
 (8) = c
 (9) = abcdef
(10) = 111, 999
(11) = 999, 111
(12) = abc, 111
(13) = 123, 1111011, 173, 7b, 7B
&lt;/syntaxhighlight&gt;
&lt;!-- リテラルの例、というか、@import(&quot;std&quot;).io.getStdOut().writer().print の例になっていますね。--&gt;
ご覧のように、数値（整数と浮動小数点数）や文字・文字列のリテラルがあり、整数は基数を、浮動小数点数は指数表現と小数表現があります。

@import(&quot;std&quot;).io.getStdOut().writer().printの、第一引数は書式化文字列、第二引数は値リストです。書式化文字列は、通常の文字列ですが &lt;code&gt;{&lt;/code&gt; と &lt;code&gt;}&lt;/code&gt; で囲まれたプレスホルダーが、引数リストの値（を書式化した文字列）に置き換わります。

一番素朴なプレスホルダーは {} で、引数の値の一般的な文字列表記に置き換ります（整数なら十進数表記、浮動小数点数なら指数表記）。ところが、’c’ のような文字型を &lt;code&gt;{}&lt;/code&gt; そのままに適用すると下記のように文字コード化され整数と同じ十進数表記になってしまいます。そこで、文字型の場合は {c} と文字であることを明記すると文字表現となります。

上記コードでは、次のような部分のことです。
:&lt;syntaxhighlight lang=&quot;zig&quot;&gt;
    try print(&quot; (7) = {}\n&quot;, .{'c'});
    try print(&quot; (8) = {c}\n&quot;, .{'c'});
&lt;/syntaxhighlight&gt;

対応部分:&lt;syntaxhighlight lang=text&gt;
 (7) = 99
 (8) = c
&lt;/syntaxhighlight&gt;

また、（文字ではなく）文字'''列'''の場合は {s} を明記しないと（バージョン0.8.0からは）エラーになります。
2つ以上の値を渡す場合は、第二引数を　.{ 1, 2, 3 } の様にカンマ区切りのリストにします（ {} の前の . （点）を忘れがち）。
基本的に、左から順にプレスホルダーにリストの値が左から与えられますが、{0} {1} の書式で参照する引数の順位を明示できます。
書式指定と併用する時は、 &lt;code&gt; print(&quot;? = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; })&lt;/code&gt; の様に順位が先、書式指定文字が後になります。

[TODO:[https://github.com/ziglang/zig/blob/master/lib/std/fmt.zig master/lib/std/fmt.zig]を観て書いています。参照すべき標準ライブラリのドキュメントを発見出来たら、見直し]
[TODO:表組み]

==== comptime ====
Zigでは、コンパイル時に式が既知かどうかという概念を重要視しています。

下記コードはコンパイル等がエラーになります。
:&lt;syntaxhighlight lang=&quot;zig&quot; line highlight=7&gt;
fn mul(x: usize, y: usize) usize {
    return x * y;
}

pub fn main() void {
    const len : usize = mul(3, 4);
    const ary: [len]i32 = undefined;
    _ = ary;
}
&lt;/syntaxhighlight&gt;
;コンパイル結果:&lt;syntaxhighlight lang=text&gt;
An error occurred: 
/tmp/playground130713503/play.zig:7:17: error: unable to evaluate constant expression 
    const ary: [len]i32 = undefined;
&lt;/syntaxhighlight&gt;
: 「定数式が評価できない 」と宣っています。
: [[C++]]であれば、constexprが適用なケースですが、Zigでは次のような解決方法を取ります。下記コードはエラーになりません。

:&lt;syntaxhighlight lang=&quot;zig&quot; line highlight=6&gt;
fn mul(x: usize, y: usize) usize {
    return x * y;
}

pub fn main() void {
    const len : usize = comptime mul(3, 4); // mul の前に comptime を追加 
    const ary: [len]i32 = undefined;
    _ = ary;
}
&lt;/syntaxhighlight&gt;
:変更点は mul() の呼出しを comptime で修飾しただけです。comptime は、修飾子式を'''コンパイル時に実行する'''修飾子で、式の中でコンパイル時に未定な値が参照されると、エラーとなります。ここでは、数リテラル同士の商を求めているので、コンパイル時値が確定できます。
: _ = ary は、「定義済だが参照のない変数宣言」をサプレッスするときのイディオムです。

&lt;!--
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const i = 0;
    const string = [_]i32{ 1, 2, 3, 4 };
    for (string) |character, index| {
        std.debug.print(&quot;character: {}, index: {}, :{s} \n&quot;, .{ character, index, @typeName(@TypeOf(character)) });
    }
    _ = i;
}
--&gt;

===== インタプリタ的に実行する場合 =====
コンパイル済みファイルの作成を飛ばして、インタプリタ的に直接に実行する方法もあり、たとえばファイル名「hello.zig」なら下記のようなコマンドあります。
 zig run hello.zig


===== プロジェクト作成する場合 =====
まず、プロジェクト関連のコマンドを実行すると、自動で数個のフォルダが作成されるので、それをまとめるためのフォルダを別に作っておき（たとえば proj とします）、べつにマウス右クリックでも mldir コマンドでもなんでもいいので proj ディレクトリを作成しておく。

そして、さらにカレント・ディレクトリを proj に移動するために、ターミナルでコマンド
 cd proj
と、&lt;code&gt;proj&lt;/proj&gt; に移動します。（そうしないと、今後の動作でホームフォルダにいくつものフォルダやファイルが作成され、管理しづらくなります）

その上で、プロジェクト作成のために
 zig init-exe
を行う。このコマンドにより、初期設定ファイルなどがいくつか自動的に作成されます。

== 基礎篇 ==
[TODO:書くべき項目を並べてみましたが、例えば「値と型」を網羅的に書いていくと文章量が爆発するのが目に見えているので、過剰になったらリファレンス篇に移動するなどの方法で、各節はコンパクトさを心がけたいです。]

=== コメント ===
Zigでは、&lt;code&gt;//&lt;/code&gt; から行末までがコメントです。
C言語の &lt;code&gt;/* … */&lt;/code&gt; のスタイルの複数行に渡るコメントは'''ありません'''。
これは、コードの各行を文脈に関係なくトークン化できるようにするためです。
:&lt;syntaxhighlight lang=zig&gt;
// @import は組込み関数です。
const std = @import(&quot;std&quot;); // 先頭に @ が付く関数は組込み関数です
pub fn main() !void {
   try std.io.getStdOut().writeAll(&quot;Hello, World!\n&quot;);
}
&lt;/syntaxhighlight&gt;

==== Docコメント ====
Zigでは、&lt;code&gt;///&lt;/code&gt; から始まるコメントは特別なコメントで、Docコメント( ''Doc comments'' )と呼ばれます。
Docコメントは特定の場所にしか許されません。式の途中や非Docコメントの直前など、予想外の場所にdocコメントがあると、コンパイルエラーになります。

[TODO:サンプルコードと整形結果]

==== トップレベルDocコメント ====
Zigでは、&lt;code&gt;//!&lt;/code&gt; から始まるコメントは特別なコメントで、トップレベルDocコメント( ''Top-Level Doc Comments '' )と呼ばれます。
コンテナレベルのドキュメントのように、直後のドキュメントに属さないユーザードキュメントに、トップレベルDocコメントを使います。

[TODO:サンプルコードと整形結果]

DocコメントおよびトップレベルDocコメントは、コンパイル時に zig build-exe -femit-docs ソースファイル.zig の様に、-femit-docs をあたえると、 docs/ 以下にドキュメントが生成されます。

=== 値と型 ===
[TOD0:整数・浮動小数・論理値・文字列・共用体・構造体・列挙・配列・ベクトル・スライス・ポインター・ゼロビットな型]

:&lt;syntaxhighlight lang=zig&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot; (1) = {}\n&quot;, .{42});
    try print(&quot; (2) = {}\n&quot;, .{0x17});
    try print(&quot; (3) = {}\n&quot;, .{0o17});
    try print(&quot; (4) = {}\n&quot;, .{0b0100101});
    try print(&quot; (5) = {}\n&quot;, .{1e222});
    try print(&quot; (6) = {}\n&quot;, .{3.1415926536});
    try print(&quot; (7) = {}\n&quot;, .{'c'});
    try print(&quot; (8) = {c}\n&quot;, .{'c'});
    try print(&quot; (9) = {s}\n&quot;, .{&quot;abcdef&quot;});
    try print(&quot;(10) = {}, {}\n&quot;, .{ 111, 999 });
    try print(&quot;(11) = {1}, {0}\n&quot;, .{ 111, 999 });
    try print(&quot;(12) = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; });
    try print(&quot;(13) = {0d}, {0b}, {0o}, {0x}, {0X}\n&quot;, .{ 123 });
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
 (1) = 42
 (2) = 23
 (3) = 15
 (4) = 37
 (5) = 1.0e+222
 (6) = 3.1415926536e+00
 (7) = 99
 (8) = c
 (9) = abcdef
(10) = 111, 999
(11) = 999, 111
(12) = abc, 111
(13) = 123, 1111011, 173, 7b, 7B
&lt;/syntaxhighlight&gt;
&lt;!-- リテラルの例、というか、@import(&quot;std&quot;).io.getStdOut().writer().print の例になっていますね。--&gt;
ご覧のように、数値（整数と浮動小数点数）や文字・文字列のリテラルがあり、整数は基数を、浮動小数点数は指数表現と少数表現があります。

@import(&quot;std&quot;).io.getStdOut().writer().printの、第一引数は書式化文字列、第二引数は値リストです。
書式化文字列は、通常の文字列ですが &lt;code&gt;{&lt;/code&gt; と &lt;code&gt;}&lt;/code&gt; で囲まれたプレスホルダーが、引数リストの値（を書式化した文字列）に置換わります。
一番素朴なプレスホルダーは {} で、引数の値の一般的な文字列表記に置き換ります（整数なら十進数表記、浮動小数点数なら指数表記）。
ところが、’c’ のような文字型を {} に適用すると文字コード化され整数と同じ十進数表記になってしまいます。そこで、文字型の場合は {c} と文字であることを明記すると文字表現となります。
また、文字列の間合いは {s} を明記しないと（バージョン0.8.0からは）エラーになります。
2つ以上の値を渡す場合は、第二引数を　.{ 1, 2, 3 } の様にカンマ区切りのリストにします（ これが、Zig の配列リテラルの表現で、{} の前の . （点）を忘れがち）。
基本的に、左から順にプレスホルダーにリストの値が左から与えられますが、{0} {1} の書式で参照する引数の順位を明示できます。
書式指定と併用する時は、 &lt;code&gt; print(&quot;? = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; })&lt;/code&gt; の様に順位が先、書式指定文字が後になります。

[TODO:[https://github.com/ziglang/zig/blob/master/lib/std/fmt.zig master/lib/std/fmt.zig]を観て書いています。参照すべき標準ライブラリのドキュメントを発見出来たら、見直し]
[TODO:表組み]

==== comptime ====
Zigでは、コンパイル時に式が既知かどうかという概念を重要視しています。

&lt;!--
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const i = 0;
    const string = [_]i32{ 1, 2, 3, 4 };
    for (string) |character, index| {
        std.debug.print(&quot;character: {}, index: {}, :{s} \n&quot;, .{ character, index, @typeName(@TypeOf(character)) });
    }
    _ = i;
}
--&gt;

=== テスト ===
=== 変数 ===
=== 制御構造 ===
[TODO:Zig の制御構造は文ではなく式]
==== 分岐 ====
[TODO:ifとswitch]
==== 反復 ====
[TODO:whileとfor]
=== 関数 ===
=== エラー ===
=== 演算子 ===
==== 優先順位 ====
高
&lt;syntaxhighlight lang=text line&gt;
 x() x[] x.y x.* x.?
 a!b
 x{}
 !x -x -%x ~x &amp;x ?x
 * / % ** *% *| ||
 + - ++ +% -% +| -|
 &lt;&lt; &gt;&gt; &lt;&lt;|
 &amp; ^ | orelse catch
 == != &lt; &gt; &lt;= &gt;=
 and
 or
 = *= *%= *|= /= %= += +%= +|= -= -%= -|= &lt;&lt;= &lt;&lt;|= &gt;&gt;= &amp;= ^= |=
&lt;/syntaxhighlight&gt;
低

===  optional type ===
===  opaque ===
訳語未定
=== ブロック ===
[TODO:スコープとシャドーイング；deferはここ？]
=== キャスト ===
[TODO:Zig は強い型付け()； 型強制 (Type coercion) について]
=== アセンブリ言語との連携 ===
[TODO:所謂インラインアセンラ]
=== atomic ===
=== 非同期関数 ===
=== 組込み関数 ===
[TODO:組込み関数は、@で始まり、@TypeOfや@alignOfの他@sinや@memcpyも組込み関数]
=== メモリ管理 ===
=== キーワード一覧 ===
&lt;code&gt;align&lt;/code&gt;
&lt;code&gt;allowzero&lt;/code&gt;
&lt;code&gt;and&lt;/code&gt;
&lt;code&gt;anyframe&lt;/code&gt;
&lt;code&gt;anytype&lt;/code&gt;
&lt;code&gt;asm&lt;/code&gt;
&lt;code&gt;async&lt;/code&gt;
&lt;code&gt;await&lt;/code&gt;
&lt;code&gt;break&lt;/code&gt;
&lt;code&gt;catch&lt;/code&gt;
&lt;code&gt;comptime&lt;/code&gt;
&lt;code&gt;const&lt;/code&gt;
&lt;code&gt;continue&lt;/code&gt;
&lt;code&gt;defer&lt;/code&gt;
&lt;code&gt;else&lt;/code&gt;
&lt;code&gt;enum&lt;/code&gt;
&lt;code&gt;errdefer&lt;/code&gt;
&lt;code&gt;error&lt;/code&gt;
&lt;code&gt;export&lt;/code&gt;
&lt;code&gt;extern&lt;/code&gt;
&lt;code&gt;fn&lt;/code&gt;
&lt;code&gt;for&lt;/code&gt;
&lt;code&gt;if&lt;/code&gt;
&lt;code&gt;inline&lt;/code&gt;
&lt;code&gt;noalias&lt;/code&gt;
&lt;code&gt;nosuspend&lt;/code&gt;
&lt;code&gt;or&lt;/code&gt;
&lt;code&gt;orelse&lt;/code&gt;
&lt;code&gt;packed&lt;/code&gt;
&lt;code&gt;pub&lt;/code&gt;
&lt;code&gt;resume&lt;/code&gt;
&lt;code&gt;return&lt;/code&gt;
&lt;code&gt;linksection&lt;/code&gt;
&lt;code&gt;struct&lt;/code&gt;
&lt;code&gt;suspend&lt;/code&gt;
&lt;code&gt;switch&lt;/code&gt;
&lt;code&gt;test&lt;/code&gt;
&lt;code&gt;threadlocal&lt;/code&gt;
&lt;code&gt;try&lt;/code&gt;
&lt;code&gt;union&lt;/code&gt;
&lt;code&gt;unreachable&lt;/code&gt;
&lt;code&gt;usingnamespace&lt;/code&gt;
&lt;code&gt;var&lt;/code&gt;
&lt;code&gt;volatile&lt;/code&gt;
&lt;code&gt;while&lt;/code&gt;

== チートシート ==
[TODO:文法と型と頻用する標準ライブラリの関数と型のアンチョコ]

== リファレンス篇 ==

== 脚註 ==
&lt;references /&gt;

== 外部リンク ==
* [https://ziglang.org/ Home ⚡ Zig Programming Language] {{---}} 公式サイト
** [[https://ziglang.org/documentation/master/ Zig Language Reference]] {{---}} リファレンスマニュアル
* [https://github.com/ziglang/zig ziglang/zig: General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.] {{---}} 公式リポジトリ
* [https://zig-play.dev/ Zig Playground] {{---}} オンライン実行環境
** [https://github.com/gsquire/zig-play About An online Zig compiler inspired by Go and Rust] {{---}} リポジトリ

[[Category:zig|*]]
[[Category:プログラミング言語]]</text>
      <sha1>iqq3a3js93sfx643b273my2chas6wkj</sha1>
    </revision>
    <revision>
      <id>205778</id>
      <parentid>205777</parentid>
      <timestamp>2022-07-24T08:23:20Z</timestamp>
      <contributor>
        <username>Ef3</username>
        <id>694</id>
      </contributor>
      <comment>/* 環境準備 */ Zigは、2022年7月の時点で '''pre-release''' の段階にあり、インストール手順も何度か変わっているので、まずは https://ziglang.org/learn/getting-started/ を参照し、最新のインストール手順を確認してください。また、ローカルのパッケージデータベースをパッケージシステムのリポジトリと同期を取り、鮮度の高い状態を維持するよう心がけてください。これは、インストール後も同じですし、zigに限ったことでもありません。</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="24428" xml:space="preserve">{{Pathnav|メインページ|工学|情報技術|プログラミング|frame=1}}
{{Wikipedia|Zig (プログラミング言語)}}
本書は、[[w:Zig|Zig]]のチュートリアルです。
Zigは、堅牢で最適かつ再利用可能なソフトウェアを維持するための汎用プログラミング言語およびツールチェインです&lt;ref&gt;{{Cite web
|url=https://ziglang.org/
|title=Home ⚡ Zig Programming Language
|website=ziglang.org
|accessdate=2022-07-17
|cite=Zig is a general-purpose programming language and toolchain for maintaining '''robust''', '''optimal''' and '''reusable''' software.
}}&lt;/ref&gt;。
Zigは、アンドリュー・ケリー( ''[https://andrewkelley.me/ Andrew Kelley]'' )によって設計され、汎用システムプログラミング言語で、静的で強い型付けで型推論とジェネリックプログラミングをサポートします。

== 概要 ==
Zigは、2016年2月に発表された比較的若いプログラミング言語で&lt;ref&gt;{{Cite web
|last1=Kelley
|first1=Andrew
|title=Introduction to the Zig Programming Language
|url=https://andrewkelley.me/post/intro-to-zig.html
|website=andrewkelley.me
|accessdate=2022-07-17
}}&lt;/ref&gt;、2022年7月現在のバージョンは 0.9.1 で、'''''pre-release''''' と位置づけられています&lt;ref&gt;{{Cite web
|url=https://github.com/ziglang/zig/releases
|title=Releases · ziglang/zig
|website=github.com
|accessdate=2022-07-17
}}&lt;/ref&gt;。このため [[W:Hello world|Hello world]] ですら、バージョン間で互換性がなくなることもあり、リリースバージョンまでは言語仕様やライブラリーおよびツールチェインの仕様が変更される可能性があります。

=== Hello world の変遷 ===
[https://ziglang.org/documentation/master/ Zig Language Reference]の、[[W:Hello world|Hello world]]の変遷（新しい順）。

;master@2022-07-17&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/master/#Hello-World
|title=Zig Documentation(master@2022-07-17)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.8.1に同じ
;0.9.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.9.1/#Hello-World
|title=Zig Documentation(0.9.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.8.1に同じ
;0.8.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.8.1/#Hello-World
|title=Zig Documentation(0.8.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=4&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().writer();
    try stdout.print(&quot;Hello, {s}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: &lt;code&gt;{}&lt;/code&gt; ⇒ &lt;code&gt;{s}&lt;/code&gt;&lt;ref&gt;{{Cite web
|url=https://ziglang.org/download/0.8.0/release-notes.html#Formatted-Printing
|title=0.8.0 Release Notes
|website=ziglang.org
|accessdate=2022-07-17
|quote=Disable the special casing of {} for u8 slices/arrays. Unless {s} is specified the contents won't be treated as a string.
}}&lt;/ref&gt;
;0.7.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.7.1/#Hello-World
|title=Zig Documentation(0.7.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=3&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().writer();
    try stdout.print(&quot;Hello, {}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: s/outStream/writer/
;0.6.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.6.0/#Hello-World
|title=Zig Documentation(0.6.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=3&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().outStream();
    try stdout.print(&quot;Hello, {}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: 初期化の初期値から &lt;code&gt;try&lt;/code&gt; がなくなった。
;0.4.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.4.0/#Hello-World
|title=Zig Documentation(0.4.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.2.0に同じ
;0.5.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.5.0/#Hello-World
|title=Zig Documentation(0.5.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=4&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    // If this program is run without stdout attached, exit with an error.
    const stdout_file = try std.io.getStdOut();
    // If this program encounters pipe failure when printing to stdout, exit
    // with an error.
    try stdout_file.write(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;
: &lt;var&gt;stdout_file&lt;/var&gt; が &lt;code&gt;var&lt;/code&gt; から &lt;code&gt;const&lt;/code&gt; に変更された。

;0.3.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.3.0/#Hello-World
|title=Zig Documentation(0.3.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.2.0に同じ
;0.2.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.2.0/#Hello-World
|title=Zig Documentation(0.2.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    // If this program is run without stdout attached, exit with an error.
    var stdout_file = try std.io.getStdOut();
    // If this program encounters pipe failure when printing to stdout, exit
    // with an error.
    try stdout_file.write(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;
;0.1.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.1.1/#hello-world
|title=Zig Documentation
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig&gt;
const io = @import(&quot;std&quot;).io;
pub fn main() -&gt; %void {
    %%io.stdout.printf(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;

=== 環境準備 ===
Zigは、2022年7月の時点で '''pre-release''' の段階にあり、インストール手順も何度か変わっているので、まずは https://ziglang.org/learn/getting-started/ を参照し、最新のインストール手順を確認してください。また、ローカルのパッケージデータベースをパッケージシステムのリポジトリと同期を取り、鮮度の高い状態を維持するよう心がけてください。これは、インストール後も同じですし、zigに限ったことでもありません。

==== パッケージ マネージャー によるインストール ====
あなたが、最新の nightly の Zig を使いたいのでない場合は、それそれのオペレーティング システムやディストリビューションが対応するパッケージ マネージャーを使いインストールするのが早見落ちです。

===== Windows =====
Zig は、[[Chocolatey]]パッケージシステムが対応しています。
:&lt;syntaxhighlight lang=console&gt;
&gt; choco install zig
&lt;/syntaxhighlight&gt;

===== macOS =====
macOS では、[[Homebrew]]と[[MacPorts]]が対応しています。
;最新とタグ付けされたリリース:&lt;syntaxhighlight lang=console&gt;
# brew install zig
&lt;/syntaxhighlight&gt;
;Git の master ブランチの最新ビルド:&lt;syntaxhighlight lang=console&gt;
# brew install zig --HEAD
&lt;/syntaxhighlight&gt;
;MacPorts:&lt;syntaxhighlight lang=console&gt;
# port install zig
&lt;/syntaxhighlight&gt;

===== FreeBSD =====
;pkg:&lt;syntaxhighlight lang=console&gt;
# pkg install zig
&lt;/syntaxhighlight&gt;
;ports:&lt;syntaxhighlight lang=console&gt;
# make -C /usr/ports/lang/zig all install clean
&lt;/syntaxhighlight&gt;

===== GNU/Linuxのディストリビューション =====
====== Fedora 36 ======
Fedora 36 の場合、2022年の時点で、コマンド
 sudo dnf install zig
だけでインストールできる事を確認。

その他のOS環境でのインストールについては、[https://github.com/ziglang/zig/wiki/Install-Zig-from-a-Package-Manager  GitHub  &quot;ziglang /zig&quot; ] を参照してください。

インストールできたと思ったら、バージョン確認コマンドなどで、インストールの成否を確認しましょう。コマンド
 zig version
で確認できます。

なお、2022年7月現在、まだバージョンは1未満であり、同7月に実験したところ
 0.9.1
であった。上記のセクションでも掛かれているように2022年の段階ではまだプレリリースであるので、1未満でもインストール成功なので安心していいです。

===== コードの実行方法 =====
[TBD:]

=== 値と型 ===
[TOD0:整数・浮動小数・論理値・文字列・共用体・構造体・列挙・配列・ベクトル・スライス・ポインター・ゼロビットな型]

:&lt;syntaxhighlight lang=&quot;zig&quot;&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot;abcd \n&quot;, .{} );
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
abcd 
&lt;/syntaxhighlight&gt;
: &lt;code&gt;print()&lt;/code&gt;の前の、&lt;code&gt;try&lt;/code&gt;は単項演算子です。&lt;code&gt;try&lt;/code&gt; は、右の式が例外を投げると式の値にします。エラーユニオン型を返す関数は、&lt;code&gt;try&lt;/code&gt;単項演算子か&lt;code&gt;catch&lt;/code&gt;二項演算子で、値とエラーを弁別する必要があります（&lt;code&gt;try&lt;/code&gt;あるいは&lt;code&gt;catch&lt;/code&gt;がないと、コンパイル時にエラーになります）。
: &lt;code&gt;print()&lt;/code&gt;の様に、標準ライブラリの &lt;code&gt;format()&lt;/code&gt;を使う関数は、フォーマット文字列と配列 &lt;code&gt;.{ … }&lt;/code&gt; を引数にします。[[C言語/標準ライブラリ/ctype.h|C言語]]のような、可変引数'''ではなく'''可変長の配列を使うので、プレースホルダーがない場合でも、空の配列 &lt;code&gt;.{}&lt;/code&gt; は必須です。

:&lt;syntaxhighlight lang=&quot;zig&quot;&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot; (1) = {}\n&quot;, .{42});
    try print(&quot; (2) = {}\n&quot;, .{0x17});
    try print(&quot; (3) = {}\n&quot;, .{0o17});
    try print(&quot; (4) = {}\n&quot;, .{0b0100101});
    try print(&quot; (5) = {}\n&quot;, .{1e222});
    try print(&quot; (6) = {}\n&quot;, .{3.1415926536});
    try print(&quot; (7) = {}\n&quot;, .{'c'});
    try print(&quot; (8) = {c}\n&quot;, .{'c'});
    try print(&quot; (9) = {s}\n&quot;, .{&quot;abcdef&quot;});
    try print(&quot;(10) = {}, {}\n&quot;, .{ 111, 999 });
    try print(&quot;(11) = {1}, {0}\n&quot;, .{ 111, 999 });
    try print(&quot;(12) = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; });
    try print(&quot;(13) = {0d}, {0b}, {0o}, {0x}, {0X}\n&quot;, .{ 123 });
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
 (1) = 42
 (2) = 23
 (3) = 15
 (4) = 37
 (5) = 1.0e+222
 (6) = 3.1415926536e+00
 (7) = 99
 (8) = c
 (9) = abcdef
(10) = 111, 999
(11) = 999, 111
(12) = abc, 111
(13) = 123, 1111011, 173, 7b, 7B
&lt;/syntaxhighlight&gt;
&lt;!-- リテラルの例、というか、@import(&quot;std&quot;).io.getStdOut().writer().print の例になっていますね。--&gt;
ご覧のように、数値（整数と浮動小数点数）や文字・文字列のリテラルがあり、整数は基数を、浮動小数点数は指数表現と小数表現があります。

@import(&quot;std&quot;).io.getStdOut().writer().printの、第一引数は書式化文字列、第二引数は値リストです。書式化文字列は、通常の文字列ですが &lt;code&gt;{&lt;/code&gt; と &lt;code&gt;}&lt;/code&gt; で囲まれたプレスホルダーが、引数リストの値（を書式化した文字列）に置き換わります。

一番素朴なプレスホルダーは {} で、引数の値の一般的な文字列表記に置き換ります（整数なら十進数表記、浮動小数点数なら指数表記）。ところが、’c’ のような文字型を &lt;code&gt;{}&lt;/code&gt; そのままに適用すると下記のように文字コード化され整数と同じ十進数表記になってしまいます。そこで、文字型の場合は {c} と文字であることを明記すると文字表現となります。

上記コードでは、次のような部分のことです。
:&lt;syntaxhighlight lang=&quot;zig&quot;&gt;
    try print(&quot; (7) = {}\n&quot;, .{'c'});
    try print(&quot; (8) = {c}\n&quot;, .{'c'});
&lt;/syntaxhighlight&gt;

対応部分:&lt;syntaxhighlight lang=text&gt;
 (7) = 99
 (8) = c
&lt;/syntaxhighlight&gt;

また、（文字ではなく）文字'''列'''の場合は {s} を明記しないと（バージョン0.8.0からは）エラーになります。
2つ以上の値を渡す場合は、第二引数を　.{ 1, 2, 3 } の様にカンマ区切りのリストにします（ {} の前の . （点）を忘れがち）。
基本的に、左から順にプレスホルダーにリストの値が左から与えられますが、{0} {1} の書式で参照する引数の順位を明示できます。
書式指定と併用する時は、 &lt;code&gt; print(&quot;? = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; })&lt;/code&gt; の様に順位が先、書式指定文字が後になります。

[TODO:[https://github.com/ziglang/zig/blob/master/lib/std/fmt.zig master/lib/std/fmt.zig]を観て書いています。参照すべき標準ライブラリのドキュメントを発見出来たら、見直し]
[TODO:表組み]

==== comptime ====
Zigでは、コンパイル時に式が既知かどうかという概念を重要視しています。

下記コードはコンパイル等がエラーになります。
:&lt;syntaxhighlight lang=&quot;zig&quot; line highlight=7&gt;
fn mul(x: usize, y: usize) usize {
    return x * y;
}

pub fn main() void {
    const len : usize = mul(3, 4);
    const ary: [len]i32 = undefined;
    _ = ary;
}
&lt;/syntaxhighlight&gt;
;コンパイル結果:&lt;syntaxhighlight lang=text&gt;
An error occurred: 
/tmp/playground130713503/play.zig:7:17: error: unable to evaluate constant expression 
    const ary: [len]i32 = undefined;
&lt;/syntaxhighlight&gt;
: 「定数式が評価できない 」と宣っています。
: [[C++]]であれば、constexprが適用なケースですが、Zigでは次のような解決方法を取ります。下記コードはエラーになりません。

:&lt;syntaxhighlight lang=&quot;zig&quot; line highlight=6&gt;
fn mul(x: usize, y: usize) usize {
    return x * y;
}

pub fn main() void {
    const len : usize = comptime mul(3, 4); // mul の前に comptime を追加 
    const ary: [len]i32 = undefined;
    _ = ary;
}
&lt;/syntaxhighlight&gt;
:変更点は mul() の呼出しを comptime で修飾しただけです。comptime は、修飾子式を'''コンパイル時に実行する'''修飾子で、式の中でコンパイル時に未定な値が参照されると、エラーとなります。ここでは、数リテラル同士の商を求めているので、コンパイル時値が確定できます。
: _ = ary は、「定義済だが参照のない変数宣言」をサプレッスするときのイディオムです。

&lt;!--
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const i = 0;
    const string = [_]i32{ 1, 2, 3, 4 };
    for (string) |character, index| {
        std.debug.print(&quot;character: {}, index: {}, :{s} \n&quot;, .{ character, index, @typeName(@TypeOf(character)) });
    }
    _ = i;
}
--&gt;

===== インタプリタ的に実行する場合 =====
コンパイル済みファイルの作成を飛ばして、インタプリタ的に直接に実行する方法もあり、たとえばファイル名「hello.zig」なら下記のようなコマンドあります。
 zig run hello.zig


===== プロジェクト作成する場合 =====
まず、プロジェクト関連のコマンドを実行すると、自動で数個のフォルダが作成されるので、それをまとめるためのフォルダを別に作っておき（たとえば proj とします）、べつにマウス右クリックでも mldir コマンドでもなんでもいいので proj ディレクトリを作成しておく。

そして、さらにカレント・ディレクトリを proj に移動するために、ターミナルでコマンド
 cd proj
と、&lt;code&gt;proj&lt;/proj&gt; に移動します。（そうしないと、今後の動作でホームフォルダにいくつものフォルダやファイルが作成され、管理しづらくなります）

その上で、プロジェクト作成のために
 zig init-exe
を行う。このコマンドにより、初期設定ファイルなどがいくつか自動的に作成されます。

== 基礎篇 ==
[TODO:書くべき項目を並べてみましたが、例えば「値と型」を網羅的に書いていくと文章量が爆発するのが目に見えているので、過剰になったらリファレンス篇に移動するなどの方法で、各節はコンパクトさを心がけたいです。]

=== コメント ===
Zigでは、&lt;code&gt;//&lt;/code&gt; から行末までがコメントです。
C言語の &lt;code&gt;/* … */&lt;/code&gt; のスタイルの複数行に渡るコメントは'''ありません'''。
これは、コードの各行を文脈に関係なくトークン化できるようにするためです。
:&lt;syntaxhighlight lang=zig&gt;
// @import は組込み関数です。
const std = @import(&quot;std&quot;); // 先頭に @ が付く関数は組込み関数です
pub fn main() !void {
   try std.io.getStdOut().writeAll(&quot;Hello, World!\n&quot;);
}
&lt;/syntaxhighlight&gt;

==== Docコメント ====
Zigでは、&lt;code&gt;///&lt;/code&gt; から始まるコメントは特別なコメントで、Docコメント( ''Doc comments'' )と呼ばれます。
Docコメントは特定の場所にしか許されません。式の途中や非Docコメントの直前など、予想外の場所にdocコメントがあると、コンパイルエラーになります。

[TODO:サンプルコードと整形結果]

==== トップレベルDocコメント ====
Zigでは、&lt;code&gt;//!&lt;/code&gt; から始まるコメントは特別なコメントで、トップレベルDocコメント( ''Top-Level Doc Comments '' )と呼ばれます。
コンテナレベルのドキュメントのように、直後のドキュメントに属さないユーザードキュメントに、トップレベルDocコメントを使います。

[TODO:サンプルコードと整形結果]

DocコメントおよびトップレベルDocコメントは、コンパイル時に zig build-exe -femit-docs ソースファイル.zig の様に、-femit-docs をあたえると、 docs/ 以下にドキュメントが生成されます。

=== 値と型 ===
[TOD0:整数・浮動小数・論理値・文字列・共用体・構造体・列挙・配列・ベクトル・スライス・ポインター・ゼロビットな型]

:&lt;syntaxhighlight lang=zig&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot; (1) = {}\n&quot;, .{42});
    try print(&quot; (2) = {}\n&quot;, .{0x17});
    try print(&quot; (3) = {}\n&quot;, .{0o17});
    try print(&quot; (4) = {}\n&quot;, .{0b0100101});
    try print(&quot; (5) = {}\n&quot;, .{1e222});
    try print(&quot; (6) = {}\n&quot;, .{3.1415926536});
    try print(&quot; (7) = {}\n&quot;, .{'c'});
    try print(&quot; (8) = {c}\n&quot;, .{'c'});
    try print(&quot; (9) = {s}\n&quot;, .{&quot;abcdef&quot;});
    try print(&quot;(10) = {}, {}\n&quot;, .{ 111, 999 });
    try print(&quot;(11) = {1}, {0}\n&quot;, .{ 111, 999 });
    try print(&quot;(12) = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; });
    try print(&quot;(13) = {0d}, {0b}, {0o}, {0x}, {0X}\n&quot;, .{ 123 });
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
 (1) = 42
 (2) = 23
 (3) = 15
 (4) = 37
 (5) = 1.0e+222
 (6) = 3.1415926536e+00
 (7) = 99
 (8) = c
 (9) = abcdef
(10) = 111, 999
(11) = 999, 111
(12) = abc, 111
(13) = 123, 1111011, 173, 7b, 7B
&lt;/syntaxhighlight&gt;
&lt;!-- リテラルの例、というか、@import(&quot;std&quot;).io.getStdOut().writer().print の例になっていますね。--&gt;
ご覧のように、数値（整数と浮動小数点数）や文字・文字列のリテラルがあり、整数は基数を、浮動小数点数は指数表現と少数表現があります。

@import(&quot;std&quot;).io.getStdOut().writer().printの、第一引数は書式化文字列、第二引数は値リストです。
書式化文字列は、通常の文字列ですが &lt;code&gt;{&lt;/code&gt; と &lt;code&gt;}&lt;/code&gt; で囲まれたプレスホルダーが、引数リストの値（を書式化した文字列）に置換わります。
一番素朴なプレスホルダーは {} で、引数の値の一般的な文字列表記に置き換ります（整数なら十進数表記、浮動小数点数なら指数表記）。
ところが、’c’ のような文字型を {} に適用すると文字コード化され整数と同じ十進数表記になってしまいます。そこで、文字型の場合は {c} と文字であることを明記すると文字表現となります。
また、文字列の間合いは {s} を明記しないと（バージョン0.8.0からは）エラーになります。
2つ以上の値を渡す場合は、第二引数を　.{ 1, 2, 3 } の様にカンマ区切りのリストにします（ これが、Zig の配列リテラルの表現で、{} の前の . （点）を忘れがち）。
基本的に、左から順にプレスホルダーにリストの値が左から与えられますが、{0} {1} の書式で参照する引数の順位を明示できます。
書式指定と併用する時は、 &lt;code&gt; print(&quot;? = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; })&lt;/code&gt; の様に順位が先、書式指定文字が後になります。

[TODO:[https://github.com/ziglang/zig/blob/master/lib/std/fmt.zig master/lib/std/fmt.zig]を観て書いています。参照すべき標準ライブラリのドキュメントを発見出来たら、見直し]
[TODO:表組み]

==== comptime ====
Zigでは、コンパイル時に式が既知かどうかという概念を重要視しています。

&lt;!--
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const i = 0;
    const string = [_]i32{ 1, 2, 3, 4 };
    for (string) |character, index| {
        std.debug.print(&quot;character: {}, index: {}, :{s} \n&quot;, .{ character, index, @typeName(@TypeOf(character)) });
    }
    _ = i;
}
--&gt;

=== テスト ===
=== 変数 ===
=== 制御構造 ===
[TODO:Zig の制御構造は文ではなく式]
==== 分岐 ====
[TODO:ifとswitch]
==== 反復 ====
[TODO:whileとfor]
=== 関数 ===
=== エラー ===
=== 演算子 ===
==== 優先順位 ====
高
&lt;syntaxhighlight lang=text line&gt;
 x() x[] x.y x.* x.?
 a!b
 x{}
 !x -x -%x ~x &amp;x ?x
 * / % ** *% *| ||
 + - ++ +% -% +| -|
 &lt;&lt; &gt;&gt; &lt;&lt;|
 &amp; ^ | orelse catch
 == != &lt; &gt; &lt;= &gt;=
 and
 or
 = *= *%= *|= /= %= += +%= +|= -= -%= -|= &lt;&lt;= &lt;&lt;|= &gt;&gt;= &amp;= ^= |=
&lt;/syntaxhighlight&gt;
低

===  optional type ===
===  opaque ===
訳語未定
=== ブロック ===
[TODO:スコープとシャドーイング；deferはここ？]
=== キャスト ===
[TODO:Zig は強い型付け()； 型強制 (Type coercion) について]
=== アセンブリ言語との連携 ===
[TODO:所謂インラインアセンラ]
=== atomic ===
=== 非同期関数 ===
=== 組込み関数 ===
[TODO:組込み関数は、@で始まり、@TypeOfや@alignOfの他@sinや@memcpyも組込み関数]
=== メモリ管理 ===
=== キーワード一覧 ===
&lt;code&gt;align&lt;/code&gt;
&lt;code&gt;allowzero&lt;/code&gt;
&lt;code&gt;and&lt;/code&gt;
&lt;code&gt;anyframe&lt;/code&gt;
&lt;code&gt;anytype&lt;/code&gt;
&lt;code&gt;asm&lt;/code&gt;
&lt;code&gt;async&lt;/code&gt;
&lt;code&gt;await&lt;/code&gt;
&lt;code&gt;break&lt;/code&gt;
&lt;code&gt;catch&lt;/code&gt;
&lt;code&gt;comptime&lt;/code&gt;
&lt;code&gt;const&lt;/code&gt;
&lt;code&gt;continue&lt;/code&gt;
&lt;code&gt;defer&lt;/code&gt;
&lt;code&gt;else&lt;/code&gt;
&lt;code&gt;enum&lt;/code&gt;
&lt;code&gt;errdefer&lt;/code&gt;
&lt;code&gt;error&lt;/code&gt;
&lt;code&gt;export&lt;/code&gt;
&lt;code&gt;extern&lt;/code&gt;
&lt;code&gt;fn&lt;/code&gt;
&lt;code&gt;for&lt;/code&gt;
&lt;code&gt;if&lt;/code&gt;
&lt;code&gt;inline&lt;/code&gt;
&lt;code&gt;noalias&lt;/code&gt;
&lt;code&gt;nosuspend&lt;/code&gt;
&lt;code&gt;or&lt;/code&gt;
&lt;code&gt;orelse&lt;/code&gt;
&lt;code&gt;packed&lt;/code&gt;
&lt;code&gt;pub&lt;/code&gt;
&lt;code&gt;resume&lt;/code&gt;
&lt;code&gt;return&lt;/code&gt;
&lt;code&gt;linksection&lt;/code&gt;
&lt;code&gt;struct&lt;/code&gt;
&lt;code&gt;suspend&lt;/code&gt;
&lt;code&gt;switch&lt;/code&gt;
&lt;code&gt;test&lt;/code&gt;
&lt;code&gt;threadlocal&lt;/code&gt;
&lt;code&gt;try&lt;/code&gt;
&lt;code&gt;union&lt;/code&gt;
&lt;code&gt;unreachable&lt;/code&gt;
&lt;code&gt;usingnamespace&lt;/code&gt;
&lt;code&gt;var&lt;/code&gt;
&lt;code&gt;volatile&lt;/code&gt;
&lt;code&gt;while&lt;/code&gt;

== チートシート ==
[TODO:文法と型と頻用する標準ライブラリの関数と型のアンチョコ]

== リファレンス篇 ==

== 脚註 ==
&lt;references /&gt;

== 外部リンク ==
* [https://ziglang.org/ Home ⚡ Zig Programming Language] {{---}} 公式サイト
** [[https://ziglang.org/documentation/master/ Zig Language Reference]] {{---}} リファレンスマニュアル
* [https://github.com/ziglang/zig ziglang/zig: General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.] {{---}} 公式リポジトリ
* [https://zig-play.dev/ Zig Playground] {{---}} オンライン実行環境
** [https://github.com/gsquire/zig-play About An online Zig compiler inspired by Go and Rust] {{---}} リポジトリ

[[Category:zig|*]]
[[Category:プログラミング言語]]</text>
      <sha1>kit0m1sfj8eb3whoswln6uki5fmqanq</sha1>
    </revision>
    <revision>
      <id>205780</id>
      <parentid>205778</parentid>
      <timestamp>2022-07-24T08:36:27Z</timestamp>
      <contributor>
        <username>Ef3</username>
        <id>694</id>
      </contributor>
      <comment>/* ソースコードからのビルド */  Zig は、ソースコードが Github の https://github.com/ziglang/zig.git で公開されているので、必要に応じてソースコードからビルドすることができます。 とはいえ、zig はセルフホストに成功しているので、zig のビルドには zig が必要となり、クロスビルドしたバイナリーを持込むか、一旦、パッケージシステムからインストールする必要があります（FreeBSDのPortsが行っているのは、まさにこれです）。  ビルド方法こそ、頻繁に内容が変わるので個別具体的な手順は述べませんが、zig はコンパイラーであるとともにツールチェインでもあり、ビルドシステムも内包しているので、 zig builfd とすると build.zig ファイルに書かれているレシピにしたがって自動的にビルドが進行します（ストレージとメモリーと時間に余裕を見る必要があります）。</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="25465" xml:space="preserve">{{Pathnav|メインページ|工学|情報技術|プログラミング|frame=1}}
{{Wikipedia|Zig (プログラミング言語)}}
本書は、[[w:Zig|Zig]]のチュートリアルです。
Zigは、堅牢で最適かつ再利用可能なソフトウェアを維持するための汎用プログラミング言語およびツールチェインです&lt;ref&gt;{{Cite web
|url=https://ziglang.org/
|title=Home ⚡ Zig Programming Language
|website=ziglang.org
|accessdate=2022-07-17
|cite=Zig is a general-purpose programming language and toolchain for maintaining '''robust''', '''optimal''' and '''reusable''' software.
}}&lt;/ref&gt;。
Zigは、アンドリュー・ケリー( ''[https://andrewkelley.me/ Andrew Kelley]'' )によって設計され、汎用システムプログラミング言語で、静的で強い型付けで型推論とジェネリックプログラミングをサポートします。

== 概要 ==
Zigは、2016年2月に発表された比較的若いプログラミング言語で&lt;ref&gt;{{Cite web
|last1=Kelley
|first1=Andrew
|title=Introduction to the Zig Programming Language
|url=https://andrewkelley.me/post/intro-to-zig.html
|website=andrewkelley.me
|accessdate=2022-07-17
}}&lt;/ref&gt;、2022年7月現在のバージョンは 0.9.1 で、'''''pre-release''''' と位置づけられています&lt;ref&gt;{{Cite web
|url=https://github.com/ziglang/zig/releases
|title=Releases · ziglang/zig
|website=github.com
|accessdate=2022-07-17
}}&lt;/ref&gt;。このため [[W:Hello world|Hello world]] ですら、バージョン間で互換性がなくなることもあり、リリースバージョンまでは言語仕様やライブラリーおよびツールチェインの仕様が変更される可能性があります。

=== Hello world の変遷 ===
[https://ziglang.org/documentation/master/ Zig Language Reference]の、[[W:Hello world|Hello world]]の変遷（新しい順）。

;master@2022-07-17&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/master/#Hello-World
|title=Zig Documentation(master@2022-07-17)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.8.1に同じ
;0.9.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.9.1/#Hello-World
|title=Zig Documentation(0.9.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.8.1に同じ
;0.8.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.8.1/#Hello-World
|title=Zig Documentation(0.8.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=4&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().writer();
    try stdout.print(&quot;Hello, {s}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: &lt;code&gt;{}&lt;/code&gt; ⇒ &lt;code&gt;{s}&lt;/code&gt;&lt;ref&gt;{{Cite web
|url=https://ziglang.org/download/0.8.0/release-notes.html#Formatted-Printing
|title=0.8.0 Release Notes
|website=ziglang.org
|accessdate=2022-07-17
|quote=Disable the special casing of {} for u8 slices/arrays. Unless {s} is specified the contents won't be treated as a string.
}}&lt;/ref&gt;
;0.7.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.7.1/#Hello-World
|title=Zig Documentation(0.7.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=3&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().writer();
    try stdout.print(&quot;Hello, {}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: s/outStream/writer/
;0.6.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.6.0/#Hello-World
|title=Zig Documentation(0.6.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=3&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().outStream();
    try stdout.print(&quot;Hello, {}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: 初期化の初期値から &lt;code&gt;try&lt;/code&gt; がなくなった。
;0.4.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.4.0/#Hello-World
|title=Zig Documentation(0.4.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.2.0に同じ
;0.5.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.5.0/#Hello-World
|title=Zig Documentation(0.5.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=4&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    // If this program is run without stdout attached, exit with an error.
    const stdout_file = try std.io.getStdOut();
    // If this program encounters pipe failure when printing to stdout, exit
    // with an error.
    try stdout_file.write(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;
: &lt;var&gt;stdout_file&lt;/var&gt; が &lt;code&gt;var&lt;/code&gt; から &lt;code&gt;const&lt;/code&gt; に変更された。

;0.3.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.3.0/#Hello-World
|title=Zig Documentation(0.3.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.2.0に同じ
;0.2.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.2.0/#Hello-World
|title=Zig Documentation(0.2.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    // If this program is run without stdout attached, exit with an error.
    var stdout_file = try std.io.getStdOut();
    // If this program encounters pipe failure when printing to stdout, exit
    // with an error.
    try stdout_file.write(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;
;0.1.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.1.1/#hello-world
|title=Zig Documentation
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig&gt;
const io = @import(&quot;std&quot;).io;
pub fn main() -&gt; %void {
    %%io.stdout.printf(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;

=== 環境準備 ===
Zigは、2022年7月の時点で '''pre-release''' の段階にあり、インストール手順も何度か変わっているので、まずは https://ziglang.org/learn/getting-started/ を参照し、最新のインストール手順を確認してください。また、ローカルのパッケージデータベースをパッケージシステムのリポジトリと同期を取り、鮮度の高い状態を維持するよう心がけてください。これは、インストール後も同じですし、zigに限ったことでもありません。

==== パッケージ マネージャー によるインストール ====
あなたが、最新の nightly の Zig を使いたいのでない場合は、それそれのオペレーティング システムやディストリビューションが対応するパッケージ マネージャーを使いインストールするのが早見落ちです。

===== Windows =====
Zig は、[[Chocolatey]]パッケージシステムが対応しています。
:&lt;syntaxhighlight lang=console&gt;
&gt; choco install zig
&lt;/syntaxhighlight&gt;

===== macOS =====
macOS では、[[Homebrew]]と[[MacPorts]]が対応しています。
;最新とタグ付けされたリリース:&lt;syntaxhighlight lang=console&gt;
# brew install zig
&lt;/syntaxhighlight&gt;
;Git の master ブランチの最新ビルド:&lt;syntaxhighlight lang=console&gt;
# brew install zig --HEAD
&lt;/syntaxhighlight&gt;
;MacPorts:&lt;syntaxhighlight lang=console&gt;
# port install zig
&lt;/syntaxhighlight&gt;

===== FreeBSD =====
;pkg:&lt;syntaxhighlight lang=console&gt;
# pkg install zig
&lt;/syntaxhighlight&gt;
;ports:&lt;syntaxhighlight lang=console&gt;
# make -C /usr/ports/lang/zig all install clean
&lt;/syntaxhighlight&gt;

===== GNU/Linuxのディストリビューション =====
====== Fedora 36 ======
Fedora 36 の場合、2022年の時点で、コマンド
 sudo dnf install zig
だけでインストールできる事を確認。

その他のOS環境でのインストールについては、[https://github.com/ziglang/zig/wiki/Install-Zig-from-a-Package-Manager  GitHub  &quot;ziglang /zig&quot; ] を参照してください。

インストールできたと思ったら、バージョン確認コマンドなどで、インストールの成否を確認しましょう。コマンド
 zig version
で確認できます。

なお、2022年7月現在、まだバージョンは1未満であり、同7月に実験したところ
 0.9.1
であった。上記のセクションでも掛かれているように2022年の段階ではまだプレリリースであるので、1未満でもインストール成功なので安心していいです。

===== コードの実行方法 =====
[TBD:]

==== ソースコードからのビルド ====
Zig は、ソースコードが Github の https://github.com/ziglang/zig.git で公開されているので、必要に応じてソースコードからビルドすることができます。
とはいえ、zig はセルフホストに成功しているので、zig のビルドには zig が必要となり、クロスビルドしたバイナリーを持込むか、一旦、パッケージシステムからインストールする必要があります（FreeBSDのPortsが行っているのは、まさにこれです）。

ビルド方法こそ、頻繁に内容が変わるので個別具体的な手順は述べませんが、zig はコンパイラーであるとともにツールチェインでもあり、ビルドシステムも内包しているので、 zig builfd とすると build.zig ファイルに書かれているレシピにしたがって自動的にビルドが進行します（ストレージとメモリーと時間に余裕を見る必要があります）。

=== 値と型 ===
[TOD0:整数・浮動小数・論理値・文字列・共用体・構造体・列挙・配列・ベクトル・スライス・ポインター・ゼロビットな型]

:&lt;syntaxhighlight lang=&quot;zig&quot;&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot;abcd \n&quot;, .{} );
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
abcd 
&lt;/syntaxhighlight&gt;
: &lt;code&gt;print()&lt;/code&gt;の前の、&lt;code&gt;try&lt;/code&gt;は単項演算子です。&lt;code&gt;try&lt;/code&gt; は、右の式が例外を投げると式の値にします。エラーユニオン型を返す関数は、&lt;code&gt;try&lt;/code&gt;単項演算子か&lt;code&gt;catch&lt;/code&gt;二項演算子で、値とエラーを弁別する必要があります（&lt;code&gt;try&lt;/code&gt;あるいは&lt;code&gt;catch&lt;/code&gt;がないと、コンパイル時にエラーになります）。
: &lt;code&gt;print()&lt;/code&gt;の様に、標準ライブラリの &lt;code&gt;format()&lt;/code&gt;を使う関数は、フォーマット文字列と配列 &lt;code&gt;.{ … }&lt;/code&gt; を引数にします。[[C言語/標準ライブラリ/ctype.h|C言語]]のような、可変引数'''ではなく'''可変長の配列を使うので、プレースホルダーがない場合でも、空の配列 &lt;code&gt;.{}&lt;/code&gt; は必須です。

:&lt;syntaxhighlight lang=&quot;zig&quot;&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot; (1) = {}\n&quot;, .{42});
    try print(&quot; (2) = {}\n&quot;, .{0x17});
    try print(&quot; (3) = {}\n&quot;, .{0o17});
    try print(&quot; (4) = {}\n&quot;, .{0b0100101});
    try print(&quot; (5) = {}\n&quot;, .{1e222});
    try print(&quot; (6) = {}\n&quot;, .{3.1415926536});
    try print(&quot; (7) = {}\n&quot;, .{'c'});
    try print(&quot; (8) = {c}\n&quot;, .{'c'});
    try print(&quot; (9) = {s}\n&quot;, .{&quot;abcdef&quot;});
    try print(&quot;(10) = {}, {}\n&quot;, .{ 111, 999 });
    try print(&quot;(11) = {1}, {0}\n&quot;, .{ 111, 999 });
    try print(&quot;(12) = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; });
    try print(&quot;(13) = {0d}, {0b}, {0o}, {0x}, {0X}\n&quot;, .{ 123 });
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
 (1) = 42
 (2) = 23
 (3) = 15
 (4) = 37
 (5) = 1.0e+222
 (6) = 3.1415926536e+00
 (7) = 99
 (8) = c
 (9) = abcdef
(10) = 111, 999
(11) = 999, 111
(12) = abc, 111
(13) = 123, 1111011, 173, 7b, 7B
&lt;/syntaxhighlight&gt;
&lt;!-- リテラルの例、というか、@import(&quot;std&quot;).io.getStdOut().writer().print の例になっていますね。--&gt;
ご覧のように、数値（整数と浮動小数点数）や文字・文字列のリテラルがあり、整数は基数を、浮動小数点数は指数表現と小数表現があります。

@import(&quot;std&quot;).io.getStdOut().writer().printの、第一引数は書式化文字列、第二引数は値リストです。書式化文字列は、通常の文字列ですが &lt;code&gt;{&lt;/code&gt; と &lt;code&gt;}&lt;/code&gt; で囲まれたプレスホルダーが、引数リストの値（を書式化した文字列）に置き換わります。

一番素朴なプレスホルダーは {} で、引数の値の一般的な文字列表記に置き換ります（整数なら十進数表記、浮動小数点数なら指数表記）。ところが、’c’ のような文字型を &lt;code&gt;{}&lt;/code&gt; そのままに適用すると下記のように文字コード化され整数と同じ十進数表記になってしまいます。そこで、文字型の場合は {c} と文字であることを明記すると文字表現となります。

上記コードでは、次のような部分のことです。
:&lt;syntaxhighlight lang=&quot;zig&quot;&gt;
    try print(&quot; (7) = {}\n&quot;, .{'c'});
    try print(&quot; (8) = {c}\n&quot;, .{'c'});
&lt;/syntaxhighlight&gt;

対応部分:&lt;syntaxhighlight lang=text&gt;
 (7) = 99
 (8) = c
&lt;/syntaxhighlight&gt;

また、（文字ではなく）文字'''列'''の場合は {s} を明記しないと（バージョン0.8.0からは）エラーになります。
2つ以上の値を渡す場合は、第二引数を　.{ 1, 2, 3 } の様にカンマ区切りのリストにします（ {} の前の . （点）を忘れがち）。
基本的に、左から順にプレスホルダーにリストの値が左から与えられますが、{0} {1} の書式で参照する引数の順位を明示できます。
書式指定と併用する時は、 &lt;code&gt; print(&quot;? = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; })&lt;/code&gt; の様に順位が先、書式指定文字が後になります。

[TODO:[https://github.com/ziglang/zig/blob/master/lib/std/fmt.zig master/lib/std/fmt.zig]を観て書いています。参照すべき標準ライブラリのドキュメントを発見出来たら、見直し]
[TODO:表組み]

==== comptime ====
Zigでは、コンパイル時に式が既知かどうかという概念を重要視しています。

下記コードはコンパイル等がエラーになります。
:&lt;syntaxhighlight lang=&quot;zig&quot; line highlight=7&gt;
fn mul(x: usize, y: usize) usize {
    return x * y;
}

pub fn main() void {
    const len : usize = mul(3, 4);
    const ary: [len]i32 = undefined;
    _ = ary;
}
&lt;/syntaxhighlight&gt;
;コンパイル結果:&lt;syntaxhighlight lang=text&gt;
An error occurred: 
/tmp/playground130713503/play.zig:7:17: error: unable to evaluate constant expression 
    const ary: [len]i32 = undefined;
&lt;/syntaxhighlight&gt;
: 「定数式が評価できない 」と宣っています。
: [[C++]]であれば、constexprが適用なケースですが、Zigでは次のような解決方法を取ります。下記コードはエラーになりません。

:&lt;syntaxhighlight lang=&quot;zig&quot; line highlight=6&gt;
fn mul(x: usize, y: usize) usize {
    return x * y;
}

pub fn main() void {
    const len : usize = comptime mul(3, 4); // mul の前に comptime を追加 
    const ary: [len]i32 = undefined;
    _ = ary;
}
&lt;/syntaxhighlight&gt;
:変更点は mul() の呼出しを comptime で修飾しただけです。comptime は、修飾子式を'''コンパイル時に実行する'''修飾子で、式の中でコンパイル時に未定な値が参照されると、エラーとなります。ここでは、数リテラル同士の商を求めているので、コンパイル時値が確定できます。
: _ = ary は、「定義済だが参照のない変数宣言」をサプレッスするときのイディオムです。

&lt;!--
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const i = 0;
    const string = [_]i32{ 1, 2, 3, 4 };
    for (string) |character, index| {
        std.debug.print(&quot;character: {}, index: {}, :{s} \n&quot;, .{ character, index, @typeName(@TypeOf(character)) });
    }
    _ = i;
}
--&gt;

===== インタプリタ的に実行する場合 =====
コンパイル済みファイルの作成を飛ばして、インタプリタ的に直接に実行する方法もあり、たとえばファイル名「hello.zig」なら下記のようなコマンドあります。
 zig run hello.zig


===== プロジェクト作成する場合 =====
まず、プロジェクト関連のコマンドを実行すると、自動で数個のフォルダが作成されるので、それをまとめるためのフォルダを別に作っておき（たとえば proj とします）、べつにマウス右クリックでも mldir コマンドでもなんでもいいので proj ディレクトリを作成しておく。

そして、さらにカレント・ディレクトリを proj に移動するために、ターミナルでコマンド
 cd proj
と、&lt;code&gt;proj&lt;/proj&gt; に移動します。（そうしないと、今後の動作でホームフォルダにいくつものフォルダやファイルが作成され、管理しづらくなります）

その上で、プロジェクト作成のために
 zig init-exe
を行う。このコマンドにより、初期設定ファイルなどがいくつか自動的に作成されます。

== 基礎篇 ==
[TODO:書くべき項目を並べてみましたが、例えば「値と型」を網羅的に書いていくと文章量が爆発するのが目に見えているので、過剰になったらリファレンス篇に移動するなどの方法で、各節はコンパクトさを心がけたいです。]

=== コメント ===
Zigでは、&lt;code&gt;//&lt;/code&gt; から行末までがコメントです。
C言語の &lt;code&gt;/* … */&lt;/code&gt; のスタイルの複数行に渡るコメントは'''ありません'''。
これは、コードの各行を文脈に関係なくトークン化できるようにするためです。
:&lt;syntaxhighlight lang=zig&gt;
// @import は組込み関数です。
const std = @import(&quot;std&quot;); // 先頭に @ が付く関数は組込み関数です
pub fn main() !void {
   try std.io.getStdOut().writeAll(&quot;Hello, World!\n&quot;);
}
&lt;/syntaxhighlight&gt;

==== Docコメント ====
Zigでは、&lt;code&gt;///&lt;/code&gt; から始まるコメントは特別なコメントで、Docコメント( ''Doc comments'' )と呼ばれます。
Docコメントは特定の場所にしか許されません。式の途中や非Docコメントの直前など、予想外の場所にdocコメントがあると、コンパイルエラーになります。

[TODO:サンプルコードと整形結果]

==== トップレベルDocコメント ====
Zigでは、&lt;code&gt;//!&lt;/code&gt; から始まるコメントは特別なコメントで、トップレベルDocコメント( ''Top-Level Doc Comments '' )と呼ばれます。
コンテナレベルのドキュメントのように、直後のドキュメントに属さないユーザードキュメントに、トップレベルDocコメントを使います。

[TODO:サンプルコードと整形結果]

DocコメントおよびトップレベルDocコメントは、コンパイル時に zig build-exe -femit-docs ソースファイル.zig の様に、-femit-docs をあたえると、 docs/ 以下にドキュメントが生成されます。

=== 値と型 ===
[TOD0:整数・浮動小数・論理値・文字列・共用体・構造体・列挙・配列・ベクトル・スライス・ポインター・ゼロビットな型]

:&lt;syntaxhighlight lang=zig&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot; (1) = {}\n&quot;, .{42});
    try print(&quot; (2) = {}\n&quot;, .{0x17});
    try print(&quot; (3) = {}\n&quot;, .{0o17});
    try print(&quot; (4) = {}\n&quot;, .{0b0100101});
    try print(&quot; (5) = {}\n&quot;, .{1e222});
    try print(&quot; (6) = {}\n&quot;, .{3.1415926536});
    try print(&quot; (7) = {}\n&quot;, .{'c'});
    try print(&quot; (8) = {c}\n&quot;, .{'c'});
    try print(&quot; (9) = {s}\n&quot;, .{&quot;abcdef&quot;});
    try print(&quot;(10) = {}, {}\n&quot;, .{ 111, 999 });
    try print(&quot;(11) = {1}, {0}\n&quot;, .{ 111, 999 });
    try print(&quot;(12) = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; });
    try print(&quot;(13) = {0d}, {0b}, {0o}, {0x}, {0X}\n&quot;, .{ 123 });
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
 (1) = 42
 (2) = 23
 (3) = 15
 (4) = 37
 (5) = 1.0e+222
 (6) = 3.1415926536e+00
 (7) = 99
 (8) = c
 (9) = abcdef
(10) = 111, 999
(11) = 999, 111
(12) = abc, 111
(13) = 123, 1111011, 173, 7b, 7B
&lt;/syntaxhighlight&gt;
&lt;!-- リテラルの例、というか、@import(&quot;std&quot;).io.getStdOut().writer().print の例になっていますね。--&gt;
ご覧のように、数値（整数と浮動小数点数）や文字・文字列のリテラルがあり、整数は基数を、浮動小数点数は指数表現と少数表現があります。

@import(&quot;std&quot;).io.getStdOut().writer().printの、第一引数は書式化文字列、第二引数は値リストです。
書式化文字列は、通常の文字列ですが &lt;code&gt;{&lt;/code&gt; と &lt;code&gt;}&lt;/code&gt; で囲まれたプレスホルダーが、引数リストの値（を書式化した文字列）に置換わります。
一番素朴なプレスホルダーは {} で、引数の値の一般的な文字列表記に置き換ります（整数なら十進数表記、浮動小数点数なら指数表記）。
ところが、’c’ のような文字型を {} に適用すると文字コード化され整数と同じ十進数表記になってしまいます。そこで、文字型の場合は {c} と文字であることを明記すると文字表現となります。
また、文字列の間合いは {s} を明記しないと（バージョン0.8.0からは）エラーになります。
2つ以上の値を渡す場合は、第二引数を　.{ 1, 2, 3 } の様にカンマ区切りのリストにします（ これが、Zig の配列リテラルの表現で、{} の前の . （点）を忘れがち）。
基本的に、左から順にプレスホルダーにリストの値が左から与えられますが、{0} {1} の書式で参照する引数の順位を明示できます。
書式指定と併用する時は、 &lt;code&gt; print(&quot;? = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; })&lt;/code&gt; の様に順位が先、書式指定文字が後になります。

[TODO:[https://github.com/ziglang/zig/blob/master/lib/std/fmt.zig master/lib/std/fmt.zig]を観て書いています。参照すべき標準ライブラリのドキュメントを発見出来たら、見直し]
[TODO:表組み]

==== comptime ====
Zigでは、コンパイル時に式が既知かどうかという概念を重要視しています。

&lt;!--
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const i = 0;
    const string = [_]i32{ 1, 2, 3, 4 };
    for (string) |character, index| {
        std.debug.print(&quot;character: {}, index: {}, :{s} \n&quot;, .{ character, index, @typeName(@TypeOf(character)) });
    }
    _ = i;
}
--&gt;

=== テスト ===
=== 変数 ===
=== 制御構造 ===
[TODO:Zig の制御構造は文ではなく式]
==== 分岐 ====
[TODO:ifとswitch]
==== 反復 ====
[TODO:whileとfor]
=== 関数 ===
=== エラー ===
=== 演算子 ===
==== 優先順位 ====
高
&lt;syntaxhighlight lang=text line&gt;
 x() x[] x.y x.* x.?
 a!b
 x{}
 !x -x -%x ~x &amp;x ?x
 * / % ** *% *| ||
 + - ++ +% -% +| -|
 &lt;&lt; &gt;&gt; &lt;&lt;|
 &amp; ^ | orelse catch
 == != &lt; &gt; &lt;= &gt;=
 and
 or
 = *= *%= *|= /= %= += +%= +|= -= -%= -|= &lt;&lt;= &lt;&lt;|= &gt;&gt;= &amp;= ^= |=
&lt;/syntaxhighlight&gt;
低

===  optional type ===
===  opaque ===
訳語未定
=== ブロック ===
[TODO:スコープとシャドーイング；deferはここ？]
=== キャスト ===
[TODO:Zig は強い型付け()； 型強制 (Type coercion) について]
=== アセンブリ言語との連携 ===
[TODO:所謂インラインアセンラ]
=== atomic ===
=== 非同期関数 ===
=== 組込み関数 ===
[TODO:組込み関数は、@で始まり、@TypeOfや@alignOfの他@sinや@memcpyも組込み関数]
=== メモリ管理 ===
=== キーワード一覧 ===
&lt;code&gt;align&lt;/code&gt;
&lt;code&gt;allowzero&lt;/code&gt;
&lt;code&gt;and&lt;/code&gt;
&lt;code&gt;anyframe&lt;/code&gt;
&lt;code&gt;anytype&lt;/code&gt;
&lt;code&gt;asm&lt;/code&gt;
&lt;code&gt;async&lt;/code&gt;
&lt;code&gt;await&lt;/code&gt;
&lt;code&gt;break&lt;/code&gt;
&lt;code&gt;catch&lt;/code&gt;
&lt;code&gt;comptime&lt;/code&gt;
&lt;code&gt;const&lt;/code&gt;
&lt;code&gt;continue&lt;/code&gt;
&lt;code&gt;defer&lt;/code&gt;
&lt;code&gt;else&lt;/code&gt;
&lt;code&gt;enum&lt;/code&gt;
&lt;code&gt;errdefer&lt;/code&gt;
&lt;code&gt;error&lt;/code&gt;
&lt;code&gt;export&lt;/code&gt;
&lt;code&gt;extern&lt;/code&gt;
&lt;code&gt;fn&lt;/code&gt;
&lt;code&gt;for&lt;/code&gt;
&lt;code&gt;if&lt;/code&gt;
&lt;code&gt;inline&lt;/code&gt;
&lt;code&gt;noalias&lt;/code&gt;
&lt;code&gt;nosuspend&lt;/code&gt;
&lt;code&gt;or&lt;/code&gt;
&lt;code&gt;orelse&lt;/code&gt;
&lt;code&gt;packed&lt;/code&gt;
&lt;code&gt;pub&lt;/code&gt;
&lt;code&gt;resume&lt;/code&gt;
&lt;code&gt;return&lt;/code&gt;
&lt;code&gt;linksection&lt;/code&gt;
&lt;code&gt;struct&lt;/code&gt;
&lt;code&gt;suspend&lt;/code&gt;
&lt;code&gt;switch&lt;/code&gt;
&lt;code&gt;test&lt;/code&gt;
&lt;code&gt;threadlocal&lt;/code&gt;
&lt;code&gt;try&lt;/code&gt;
&lt;code&gt;union&lt;/code&gt;
&lt;code&gt;unreachable&lt;/code&gt;
&lt;code&gt;usingnamespace&lt;/code&gt;
&lt;code&gt;var&lt;/code&gt;
&lt;code&gt;volatile&lt;/code&gt;
&lt;code&gt;while&lt;/code&gt;

== チートシート ==
[TODO:文法と型と頻用する標準ライブラリの関数と型のアンチョコ]

== リファレンス篇 ==

== 脚註 ==
&lt;references /&gt;

== 外部リンク ==
* [https://ziglang.org/ Home ⚡ Zig Programming Language] {{---}} 公式サイト
** [[https://ziglang.org/documentation/master/ Zig Language Reference]] {{---}} リファレンスマニュアル
* [https://github.com/ziglang/zig ziglang/zig: General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.] {{---}} 公式リポジトリ
* [https://zig-play.dev/ Zig Playground] {{---}} オンライン実行環境
** [https://github.com/gsquire/zig-play About An online Zig compiler inspired by Go and Rust] {{---}} リポジトリ

[[Category:zig|*]]
[[Category:プログラミング言語]]</text>
      <sha1>nyn9a883x5ywnsg2gxlm114c31cqt8j</sha1>
    </revision>
    <revision>
      <id>205784</id>
      <parentid>205780</parentid>
      <timestamp>2022-07-24T11:01:05Z</timestamp>
      <contributor>
        <username>Ef3</username>
        <id>694</id>
      </contributor>
      <comment>/* パッケージ マネージャー によるインストール */ Sty.</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="26201" xml:space="preserve">{{Pathnav|メインページ|工学|情報技術|プログラミング|frame=1}}
{{Wikipedia|Zig (プログラミング言語)}}
本書は、[[w:Zig|Zig]]のチュートリアルです。
Zigは、堅牢で最適かつ再利用可能なソフトウェアを維持するための汎用プログラミング言語およびツールチェインです&lt;ref&gt;{{Cite web
|url=https://ziglang.org/
|title=Home ⚡ Zig Programming Language
|website=ziglang.org
|accessdate=2022-07-17
|cite=Zig is a general-purpose programming language and toolchain for maintaining '''robust''', '''optimal''' and '''reusable''' software.
}}&lt;/ref&gt;。
Zigは、アンドリュー・ケリー( ''[https://andrewkelley.me/ Andrew Kelley]'' )によって設計され、汎用システムプログラミング言語で、静的で強い型付けで型推論とジェネリックプログラミングをサポートします。

== 概要 ==
Zigは、2016年2月に発表された比較的若いプログラミング言語で&lt;ref&gt;{{Cite web
|last1=Kelley
|first1=Andrew
|title=Introduction to the Zig Programming Language
|url=https://andrewkelley.me/post/intro-to-zig.html
|website=andrewkelley.me
|accessdate=2022-07-17
}}&lt;/ref&gt;、2022年7月現在のバージョンは 0.9.1 で、'''''pre-release''''' と位置づけられています&lt;ref&gt;{{Cite web
|url=https://github.com/ziglang/zig/releases
|title=Releases · ziglang/zig
|website=github.com
|accessdate=2022-07-17
}}&lt;/ref&gt;。このため [[W:Hello world|Hello world]] ですら、バージョン間で互換性がなくなることもあり、リリースバージョンまでは言語仕様やライブラリーおよびツールチェインの仕様が変更される可能性があります。

=== Hello world の変遷 ===
[https://ziglang.org/documentation/master/ Zig Language Reference]の、[[W:Hello world|Hello world]]の変遷（新しい順）。

;master@2022-07-17&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/master/#Hello-World
|title=Zig Documentation(master@2022-07-17)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.8.1に同じ
;0.9.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.9.1/#Hello-World
|title=Zig Documentation(0.9.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.8.1に同じ
;0.8.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.8.1/#Hello-World
|title=Zig Documentation(0.8.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=4&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().writer();
    try stdout.print(&quot;Hello, {s}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: &lt;code&gt;{}&lt;/code&gt; ⇒ &lt;code&gt;{s}&lt;/code&gt;&lt;ref&gt;{{Cite web
|url=https://ziglang.org/download/0.8.0/release-notes.html#Formatted-Printing
|title=0.8.0 Release Notes
|website=ziglang.org
|accessdate=2022-07-17
|quote=Disable the special casing of {} for u8 slices/arrays. Unless {s} is specified the contents won't be treated as a string.
}}&lt;/ref&gt;
;0.7.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.7.1/#Hello-World
|title=Zig Documentation(0.7.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=3&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().writer();
    try stdout.print(&quot;Hello, {}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: s/outStream/writer/
;0.6.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.6.0/#Hello-World
|title=Zig Documentation(0.6.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=3&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().outStream();
    try stdout.print(&quot;Hello, {}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: 初期化の初期値から &lt;code&gt;try&lt;/code&gt; がなくなった。
;0.4.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.4.0/#Hello-World
|title=Zig Documentation(0.4.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.2.0に同じ
;0.5.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.5.0/#Hello-World
|title=Zig Documentation(0.5.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=4&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    // If this program is run without stdout attached, exit with an error.
    const stdout_file = try std.io.getStdOut();
    // If this program encounters pipe failure when printing to stdout, exit
    // with an error.
    try stdout_file.write(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;
: &lt;var&gt;stdout_file&lt;/var&gt; が &lt;code&gt;var&lt;/code&gt; から &lt;code&gt;const&lt;/code&gt; に変更された。

;0.3.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.3.0/#Hello-World
|title=Zig Documentation(0.3.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.2.0に同じ
;0.2.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.2.0/#Hello-World
|title=Zig Documentation(0.2.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    // If this program is run without stdout attached, exit with an error.
    var stdout_file = try std.io.getStdOut();
    // If this program encounters pipe failure when printing to stdout, exit
    // with an error.
    try stdout_file.write(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;
;0.1.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.1.1/#hello-world
|title=Zig Documentation
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig&gt;
const io = @import(&quot;std&quot;).io;
pub fn main() -&gt; %void {
    %%io.stdout.printf(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;

=== 環境準備 ===
Zigは、2022年7月の時点で '''pre-release''' の段階にあり、インストール手順も何度か変わっているので、まずは https://ziglang.org/learn/getting-started/ を参照し、最新のインストール手順を確認してください。また、ローカルのパッケージデータベースをパッケージシステムのリポジトリと同期を取り、鮮度の高い状態を維持するよう心がけてください。これは、インストール後も同じですし、zigに限ったことでもありません。

==== パッケージ マネージャー によるインストール ====
nightly の Zigを使いたい場合でない限り、お使いのOSやディストリビューションでサポートされているパッケージ マネージャを使ってインストールする事をお勧めします。

===== Windows =====
Zig は、[[Chocolatey]]パッケージシステムが対応しています。
:&lt;syntaxhighlight lang=console&gt;
&gt; choco install zig
&lt;/syntaxhighlight&gt;
{{See also|w:Chocolatey}}

===== macOS =====
macOS では、[[Homebrew]]と[[MacPorts]]が対応しています。
;最新とタグ付けされたリリース:&lt;syntaxhighlight lang=console&gt;
# brew install zig
&lt;/syntaxhighlight&gt;
;Git の master ブランチの最新ビルド:&lt;syntaxhighlight lang=console&gt;
# brew install zig --HEAD
&lt;/syntaxhighlight&gt;
;MacPorts:&lt;syntaxhighlight lang=console&gt;
# port install zig
&lt;/syntaxhighlight&gt;
{{See also|w:Homebrew|w:MacPorts}}

===== FreeBSD =====
;pkg:&lt;syntaxhighlight lang=console&gt;
# pkg install zig
&lt;/syntaxhighlight&gt;
;ports:&lt;syntaxhighlight lang=console&gt;
# make -C /usr/ports/lang/zig all install clean
&lt;/syntaxhighlight&gt;
{{See also|w:Ports}}

===== GNU/Linuxのディストリビューション =====
いわゆるLinuxは、Linux（ここではOSカーネル）と、FSFがHurdカーネルのために設計・開発したGNUユーザーランド（OSの基本機能を提供するソフトウェアの集合）を組合わせたものです。
このように、LinuxカーネルとGNUユーザーランドを組合わせたソフトウェアプラットフォームをGNU/Linuxと呼びます&lt;ref&gt;GNU/Linuxの中核として、商用・非商用を問わず、再配布可能なユーティリティを収集・配布するディストリビューターが登場しました。これらのディストリビューターは、それぞれの配布物（しばしば互換性のない）を、ディストリビューションとして区別する必要が生じました（特に、共有ライブラリの非互換性は目立ち、Linux支持者自身が嫌悪するWindowsのDLL-Hellに酷似しています)。 このようにして、ディストリビューション間の区別がなされたのです(また、ほかにもマーケティング上の理由などもあります)。&lt;hr/&gt;Unixでディストリビューションという言葉は、ソースコードで配布されるBSDのD (''distribution'') と関連付けられ、一方、非ソースコード指向のGNU/Linuxディストリビューションが、Unix訴訟の間隙を利する形で386 BSDのニッチをに受入れているのは皮肉なことです。&lt;/ref&gt;

====== Fedora 36 ======
:&lt;syntaxhighlight lang=console&gt;
# dnf install zig
&lt;/syntaxhighlight&gt;
{{See also|w:Dandified Yum}}

===== コードの実行方法 =====
[TBD:]

==== ソースコードからのビルド ====
Zig は、ソースコードが Github の https://github.com/ziglang/zig.git で公開されているので、必要に応じてソースコードからビルドすることができます。
とはいえ、zig はセルフホストに成功しているので、zig のビルドには zig が必要となり、クロスビルドしたバイナリーを持込むか、一旦、パッケージシステムからインストールする必要があります（FreeBSDのPortsが行っているのは、まさにこれです）。

ビルド方法こそ、頻繁に内容が変わるので個別具体的な手順は述べませんが、zig はコンパイラーであるとともにツールチェインでもあり、ビルドシステムも内包しているので、 zig builfd とすると build.zig ファイルに書かれているレシピにしたがって自動的にビルドが進行します（ストレージとメモリーと時間に余裕を見る必要があります）。

=== 値と型 ===
[TOD0:整数・浮動小数・論理値・文字列・共用体・構造体・列挙・配列・ベクトル・スライス・ポインター・ゼロビットな型]

:&lt;syntaxhighlight lang=&quot;zig&quot;&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot;abcd \n&quot;, .{} );
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
abcd 
&lt;/syntaxhighlight&gt;
: &lt;code&gt;print()&lt;/code&gt;の前の、&lt;code&gt;try&lt;/code&gt;は単項演算子です。&lt;code&gt;try&lt;/code&gt; は、右の式が例外を投げると式の値にします。エラーユニオン型を返す関数は、&lt;code&gt;try&lt;/code&gt;単項演算子か&lt;code&gt;catch&lt;/code&gt;二項演算子で、値とエラーを弁別する必要があります（&lt;code&gt;try&lt;/code&gt;あるいは&lt;code&gt;catch&lt;/code&gt;がないと、コンパイル時にエラーになります）。
: &lt;code&gt;print()&lt;/code&gt;の様に、標準ライブラリの &lt;code&gt;format()&lt;/code&gt;を使う関数は、フォーマット文字列と配列 &lt;code&gt;.{ … }&lt;/code&gt; を引数にします。[[C言語/標準ライブラリ/ctype.h|C言語]]のような、可変引数'''ではなく'''可変長の配列を使うので、プレースホルダーがない場合でも、空の配列 &lt;code&gt;.{}&lt;/code&gt; は必須です。

:&lt;syntaxhighlight lang=&quot;zig&quot;&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot; (1) = {}\n&quot;, .{42});
    try print(&quot; (2) = {}\n&quot;, .{0x17});
    try print(&quot; (3) = {}\n&quot;, .{0o17});
    try print(&quot; (4) = {}\n&quot;, .{0b0100101});
    try print(&quot; (5) = {}\n&quot;, .{1e222});
    try print(&quot; (6) = {}\n&quot;, .{3.1415926536});
    try print(&quot; (7) = {}\n&quot;, .{'c'});
    try print(&quot; (8) = {c}\n&quot;, .{'c'});
    try print(&quot; (9) = {s}\n&quot;, .{&quot;abcdef&quot;});
    try print(&quot;(10) = {}, {}\n&quot;, .{ 111, 999 });
    try print(&quot;(11) = {1}, {0}\n&quot;, .{ 111, 999 });
    try print(&quot;(12) = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; });
    try print(&quot;(13) = {0d}, {0b}, {0o}, {0x}, {0X}\n&quot;, .{ 123 });
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
 (1) = 42
 (2) = 23
 (3) = 15
 (4) = 37
 (5) = 1.0e+222
 (6) = 3.1415926536e+00
 (7) = 99
 (8) = c
 (9) = abcdef
(10) = 111, 999
(11) = 999, 111
(12) = abc, 111
(13) = 123, 1111011, 173, 7b, 7B
&lt;/syntaxhighlight&gt;
&lt;!-- リテラルの例、というか、@import(&quot;std&quot;).io.getStdOut().writer().print の例になっていますね。--&gt;
ご覧のように、数値（整数と浮動小数点数）や文字・文字列のリテラルがあり、整数は基数を、浮動小数点数は指数表現と小数表現があります。

@import(&quot;std&quot;).io.getStdOut().writer().printの、第一引数は書式化文字列、第二引数は値リストです。書式化文字列は、通常の文字列ですが &lt;code&gt;{&lt;/code&gt; と &lt;code&gt;}&lt;/code&gt; で囲まれたプレスホルダーが、引数リストの値（を書式化した文字列）に置き換わります。

一番素朴なプレスホルダーは {} で、引数の値の一般的な文字列表記に置き換ります（整数なら十進数表記、浮動小数点数なら指数表記）。ところが、’c’ のような文字型を &lt;code&gt;{}&lt;/code&gt; そのままに適用すると下記のように文字コード化され整数と同じ十進数表記になってしまいます。そこで、文字型の場合は {c} と文字であることを明記すると文字表現となります。

上記コードでは、次のような部分のことです。
:&lt;syntaxhighlight lang=&quot;zig&quot;&gt;
    try print(&quot; (7) = {}\n&quot;, .{'c'});
    try print(&quot; (8) = {c}\n&quot;, .{'c'});
&lt;/syntaxhighlight&gt;

対応部分:&lt;syntaxhighlight lang=text&gt;
 (7) = 99
 (8) = c
&lt;/syntaxhighlight&gt;

また、（文字ではなく）文字'''列'''の場合は {s} を明記しないと（バージョン0.8.0からは）エラーになります。
2つ以上の値を渡す場合は、第二引数を　.{ 1, 2, 3 } の様にカンマ区切りのリストにします（ {} の前の . （点）を忘れがち）。
基本的に、左から順にプレスホルダーにリストの値が左から与えられますが、{0} {1} の書式で参照する引数の順位を明示できます。
書式指定と併用する時は、 &lt;code&gt; print(&quot;? = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; })&lt;/code&gt; の様に順位が先、書式指定文字が後になります。

[TODO:[https://github.com/ziglang/zig/blob/master/lib/std/fmt.zig master/lib/std/fmt.zig]を観て書いています。参照すべき標準ライブラリのドキュメントを発見出来たら、見直し]
[TODO:表組み]

==== comptime ====
Zigでは、コンパイル時に式が既知かどうかという概念を重要視しています。

下記コードはコンパイル等がエラーになります。
:&lt;syntaxhighlight lang=&quot;zig&quot; line highlight=7&gt;
fn mul(x: usize, y: usize) usize {
    return x * y;
}

pub fn main() void {
    const len : usize = mul(3, 4);
    const ary: [len]i32 = undefined;
    _ = ary;
}
&lt;/syntaxhighlight&gt;
;コンパイル結果:&lt;syntaxhighlight lang=text&gt;
An error occurred: 
/tmp/playground130713503/play.zig:7:17: error: unable to evaluate constant expression 
    const ary: [len]i32 = undefined;
&lt;/syntaxhighlight&gt;
: 「定数式が評価できない 」と宣っています。
: [[C++]]であれば、constexprが適用なケースですが、Zigでは次のような解決方法を取ります。下記コードはエラーになりません。

:&lt;syntaxhighlight lang=&quot;zig&quot; line highlight=6&gt;
fn mul(x: usize, y: usize) usize {
    return x * y;
}

pub fn main() void {
    const len : usize = comptime mul(3, 4); // mul の前に comptime を追加 
    const ary: [len]i32 = undefined;
    _ = ary;
}
&lt;/syntaxhighlight&gt;
:変更点は mul() の呼出しを comptime で修飾しただけです。comptime は、修飾子式を'''コンパイル時に実行する'''修飾子で、式の中でコンパイル時に未定な値が参照されると、エラーとなります。ここでは、数リテラル同士の商を求めているので、コンパイル時値が確定できます。
: _ = ary は、「定義済だが参照のない変数宣言」をサプレッスするときのイディオムです。

&lt;!--
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const i = 0;
    const string = [_]i32{ 1, 2, 3, 4 };
    for (string) |character, index| {
        std.debug.print(&quot;character: {}, index: {}, :{s} \n&quot;, .{ character, index, @typeName(@TypeOf(character)) });
    }
    _ = i;
}
--&gt;

===== インタプリタ的に実行する場合 =====
コンパイル済みファイルの作成を飛ばして、インタプリタ的に直接に実行する方法もあり、たとえばファイル名「hello.zig」なら下記のようなコマンドあります。
 zig run hello.zig


===== プロジェクト作成する場合 =====
まず、プロジェクト関連のコマンドを実行すると、自動で数個のフォルダが作成されるので、それをまとめるためのフォルダを別に作っておき（たとえば proj とします）、べつにマウス右クリックでも mldir コマンドでもなんでもいいので proj ディレクトリを作成しておく。

そして、さらにカレント・ディレクトリを proj に移動するために、ターミナルでコマンド
 cd proj
と、&lt;code&gt;proj&lt;/proj&gt; に移動します。（そうしないと、今後の動作でホームフォルダにいくつものフォルダやファイルが作成され、管理しづらくなります）

その上で、プロジェクト作成のために
 zig init-exe
を行う。このコマンドにより、初期設定ファイルなどがいくつか自動的に作成されます。

== 基礎篇 ==
[TODO:書くべき項目を並べてみましたが、例えば「値と型」を網羅的に書いていくと文章量が爆発するのが目に見えているので、過剰になったらリファレンス篇に移動するなどの方法で、各節はコンパクトさを心がけたいです。]

=== コメント ===
Zigでは、&lt;code&gt;//&lt;/code&gt; から行末までがコメントです。
C言語の &lt;code&gt;/* … */&lt;/code&gt; のスタイルの複数行に渡るコメントは'''ありません'''。
これは、コードの各行を文脈に関係なくトークン化できるようにするためです。
:&lt;syntaxhighlight lang=zig&gt;
// @import は組込み関数です。
const std = @import(&quot;std&quot;); // 先頭に @ が付く関数は組込み関数です
pub fn main() !void {
   try std.io.getStdOut().writeAll(&quot;Hello, World!\n&quot;);
}
&lt;/syntaxhighlight&gt;

==== Docコメント ====
Zigでは、&lt;code&gt;///&lt;/code&gt; から始まるコメントは特別なコメントで、Docコメント( ''Doc comments'' )と呼ばれます。
Docコメントは特定の場所にしか許されません。式の途中や非Docコメントの直前など、予想外の場所にdocコメントがあると、コンパイルエラーになります。

[TODO:サンプルコードと整形結果]

==== トップレベルDocコメント ====
Zigでは、&lt;code&gt;//!&lt;/code&gt; から始まるコメントは特別なコメントで、トップレベルDocコメント( ''Top-Level Doc Comments '' )と呼ばれます。
コンテナレベルのドキュメントのように、直後のドキュメントに属さないユーザードキュメントに、トップレベルDocコメントを使います。

[TODO:サンプルコードと整形結果]

DocコメントおよびトップレベルDocコメントは、コンパイル時に zig build-exe -femit-docs ソースファイル.zig の様に、-femit-docs をあたえると、 docs/ 以下にドキュメントが生成されます。

=== 値と型 ===
[TOD0:整数・浮動小数・論理値・文字列・共用体・構造体・列挙・配列・ベクトル・スライス・ポインター・ゼロビットな型]

:&lt;syntaxhighlight lang=zig&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot; (1) = {}\n&quot;, .{42});
    try print(&quot; (2) = {}\n&quot;, .{0x17});
    try print(&quot; (3) = {}\n&quot;, .{0o17});
    try print(&quot; (4) = {}\n&quot;, .{0b0100101});
    try print(&quot; (5) = {}\n&quot;, .{1e222});
    try print(&quot; (6) = {}\n&quot;, .{3.1415926536});
    try print(&quot; (7) = {}\n&quot;, .{'c'});
    try print(&quot; (8) = {c}\n&quot;, .{'c'});
    try print(&quot; (9) = {s}\n&quot;, .{&quot;abcdef&quot;});
    try print(&quot;(10) = {}, {}\n&quot;, .{ 111, 999 });
    try print(&quot;(11) = {1}, {0}\n&quot;, .{ 111, 999 });
    try print(&quot;(12) = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; });
    try print(&quot;(13) = {0d}, {0b}, {0o}, {0x}, {0X}\n&quot;, .{ 123 });
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
 (1) = 42
 (2) = 23
 (3) = 15
 (4) = 37
 (5) = 1.0e+222
 (6) = 3.1415926536e+00
 (7) = 99
 (8) = c
 (9) = abcdef
(10) = 111, 999
(11) = 999, 111
(12) = abc, 111
(13) = 123, 1111011, 173, 7b, 7B
&lt;/syntaxhighlight&gt;
&lt;!-- リテラルの例、というか、@import(&quot;std&quot;).io.getStdOut().writer().print の例になっていますね。--&gt;
ご覧のように、数値（整数と浮動小数点数）や文字・文字列のリテラルがあり、整数は基数を、浮動小数点数は指数表現と少数表現があります。

@import(&quot;std&quot;).io.getStdOut().writer().printの、第一引数は書式化文字列、第二引数は値リストです。
書式化文字列は、通常の文字列ですが &lt;code&gt;{&lt;/code&gt; と &lt;code&gt;}&lt;/code&gt; で囲まれたプレスホルダーが、引数リストの値（を書式化した文字列）に置換わります。
一番素朴なプレスホルダーは {} で、引数の値の一般的な文字列表記に置き換ります（整数なら十進数表記、浮動小数点数なら指数表記）。
ところが、’c’ のような文字型を {} に適用すると文字コード化され整数と同じ十進数表記になってしまいます。そこで、文字型の場合は {c} と文字であることを明記すると文字表現となります。
また、文字列の間合いは {s} を明記しないと（バージョン0.8.0からは）エラーになります。
2つ以上の値を渡す場合は、第二引数を　.{ 1, 2, 3 } の様にカンマ区切りのリストにします（ これが、Zig の配列リテラルの表現で、{} の前の . （点）を忘れがち）。
基本的に、左から順にプレスホルダーにリストの値が左から与えられますが、{0} {1} の書式で参照する引数の順位を明示できます。
書式指定と併用する時は、 &lt;code&gt; print(&quot;? = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; })&lt;/code&gt; の様に順位が先、書式指定文字が後になります。

[TODO:[https://github.com/ziglang/zig/blob/master/lib/std/fmt.zig master/lib/std/fmt.zig]を観て書いています。参照すべき標準ライブラリのドキュメントを発見出来たら、見直し]
[TODO:表組み]

==== comptime ====
Zigでは、コンパイル時に式が既知かどうかという概念を重要視しています。

&lt;!--
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const i = 0;
    const string = [_]i32{ 1, 2, 3, 4 };
    for (string) |character, index| {
        std.debug.print(&quot;character: {}, index: {}, :{s} \n&quot;, .{ character, index, @typeName(@TypeOf(character)) });
    }
    _ = i;
}
--&gt;

=== テスト ===
=== 変数 ===
=== 制御構造 ===
[TODO:Zig の制御構造は文ではなく式]
==== 分岐 ====
[TODO:ifとswitch]
==== 反復 ====
[TODO:whileとfor]
=== 関数 ===
=== エラー ===
=== 演算子 ===
==== 優先順位 ====
高
&lt;syntaxhighlight lang=text line&gt;
 x() x[] x.y x.* x.?
 a!b
 x{}
 !x -x -%x ~x &amp;x ?x
 * / % ** *% *| ||
 + - ++ +% -% +| -|
 &lt;&lt; &gt;&gt; &lt;&lt;|
 &amp; ^ | orelse catch
 == != &lt; &gt; &lt;= &gt;=
 and
 or
 = *= *%= *|= /= %= += +%= +|= -= -%= -|= &lt;&lt;= &lt;&lt;|= &gt;&gt;= &amp;= ^= |=
&lt;/syntaxhighlight&gt;
低

===  optional type ===
===  opaque ===
訳語未定
=== ブロック ===
[TODO:スコープとシャドーイング；deferはここ？]
=== キャスト ===
[TODO:Zig は強い型付け()； 型強制 (Type coercion) について]
=== アセンブリ言語との連携 ===
[TODO:所謂インラインアセンラ]
=== atomic ===
=== 非同期関数 ===
=== 組込み関数 ===
[TODO:組込み関数は、@で始まり、@TypeOfや@alignOfの他@sinや@memcpyも組込み関数]
=== メモリ管理 ===
=== キーワード一覧 ===
&lt;code&gt;align&lt;/code&gt;
&lt;code&gt;allowzero&lt;/code&gt;
&lt;code&gt;and&lt;/code&gt;
&lt;code&gt;anyframe&lt;/code&gt;
&lt;code&gt;anytype&lt;/code&gt;
&lt;code&gt;asm&lt;/code&gt;
&lt;code&gt;async&lt;/code&gt;
&lt;code&gt;await&lt;/code&gt;
&lt;code&gt;break&lt;/code&gt;
&lt;code&gt;catch&lt;/code&gt;
&lt;code&gt;comptime&lt;/code&gt;
&lt;code&gt;const&lt;/code&gt;
&lt;code&gt;continue&lt;/code&gt;
&lt;code&gt;defer&lt;/code&gt;
&lt;code&gt;else&lt;/code&gt;
&lt;code&gt;enum&lt;/code&gt;
&lt;code&gt;errdefer&lt;/code&gt;
&lt;code&gt;error&lt;/code&gt;
&lt;code&gt;export&lt;/code&gt;
&lt;code&gt;extern&lt;/code&gt;
&lt;code&gt;fn&lt;/code&gt;
&lt;code&gt;for&lt;/code&gt;
&lt;code&gt;if&lt;/code&gt;
&lt;code&gt;inline&lt;/code&gt;
&lt;code&gt;noalias&lt;/code&gt;
&lt;code&gt;nosuspend&lt;/code&gt;
&lt;code&gt;or&lt;/code&gt;
&lt;code&gt;orelse&lt;/code&gt;
&lt;code&gt;packed&lt;/code&gt;
&lt;code&gt;pub&lt;/code&gt;
&lt;code&gt;resume&lt;/code&gt;
&lt;code&gt;return&lt;/code&gt;
&lt;code&gt;linksection&lt;/code&gt;
&lt;code&gt;struct&lt;/code&gt;
&lt;code&gt;suspend&lt;/code&gt;
&lt;code&gt;switch&lt;/code&gt;
&lt;code&gt;test&lt;/code&gt;
&lt;code&gt;threadlocal&lt;/code&gt;
&lt;code&gt;try&lt;/code&gt;
&lt;code&gt;union&lt;/code&gt;
&lt;code&gt;unreachable&lt;/code&gt;
&lt;code&gt;usingnamespace&lt;/code&gt;
&lt;code&gt;var&lt;/code&gt;
&lt;code&gt;volatile&lt;/code&gt;
&lt;code&gt;while&lt;/code&gt;

== チートシート ==
[TODO:文法と型と頻用する標準ライブラリの関数と型のアンチョコ]

== リファレンス篇 ==

== 脚註 ==
&lt;references /&gt;

== 外部リンク ==
* [https://ziglang.org/ Home ⚡ Zig Programming Language] {{---}} 公式サイト
** [[https://ziglang.org/documentation/master/ Zig Language Reference]] {{---}} リファレンスマニュアル
* [https://github.com/ziglang/zig ziglang/zig: General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.] {{---}} 公式リポジトリ
* [https://zig-play.dev/ Zig Playground] {{---}} オンライン実行環境
** [https://github.com/gsquire/zig-play About An online Zig compiler inspired by Go and Rust] {{---}} リポジトリ

[[Category:zig|*]]
[[Category:プログラミング言語]]</text>
      <sha1>j1dghdcfcii3cts0yr4kvvxlbb4hhvp</sha1>
    </revision>
    <revision>
      <id>205786</id>
      <parentid>205784</parentid>
      <timestamp>2022-07-24T11:36:25Z</timestamp>
      <contributor>
        <username>Ef3</username>
        <id>694</id>
      </contributor>
      <comment>/* プロジェクト作成する場合 */ ここで作るプロジェクトの名前は myproj としましょう。 予め、作業用に適したファイルシステムに、ディレキトリー myproj を用意し、zig init-exe を実行します。</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="26444" xml:space="preserve">{{Pathnav|メインページ|工学|情報技術|プログラミング|frame=1}}
{{Wikipedia|Zig (プログラミング言語)}}
本書は、[[w:Zig|Zig]]のチュートリアルです。
Zigは、堅牢で最適かつ再利用可能なソフトウェアを維持するための汎用プログラミング言語およびツールチェインです&lt;ref&gt;{{Cite web
|url=https://ziglang.org/
|title=Home ⚡ Zig Programming Language
|website=ziglang.org
|accessdate=2022-07-17
|cite=Zig is a general-purpose programming language and toolchain for maintaining '''robust''', '''optimal''' and '''reusable''' software.
}}&lt;/ref&gt;。
Zigは、アンドリュー・ケリー( ''[https://andrewkelley.me/ Andrew Kelley]'' )によって設計され、汎用システムプログラミング言語で、静的で強い型付けで型推論とジェネリックプログラミングをサポートします。

== 概要 ==
Zigは、2016年2月に発表された比較的若いプログラミング言語で&lt;ref&gt;{{Cite web
|last1=Kelley
|first1=Andrew
|title=Introduction to the Zig Programming Language
|url=https://andrewkelley.me/post/intro-to-zig.html
|website=andrewkelley.me
|accessdate=2022-07-17
}}&lt;/ref&gt;、2022年7月現在のバージョンは 0.9.1 で、'''''pre-release''''' と位置づけられています&lt;ref&gt;{{Cite web
|url=https://github.com/ziglang/zig/releases
|title=Releases · ziglang/zig
|website=github.com
|accessdate=2022-07-17
}}&lt;/ref&gt;。このため [[W:Hello world|Hello world]] ですら、バージョン間で互換性がなくなることもあり、リリースバージョンまでは言語仕様やライブラリーおよびツールチェインの仕様が変更される可能性があります。

=== Hello world の変遷 ===
[https://ziglang.org/documentation/master/ Zig Language Reference]の、[[W:Hello world|Hello world]]の変遷（新しい順）。

;master@2022-07-17&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/master/#Hello-World
|title=Zig Documentation(master@2022-07-17)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.8.1に同じ
;0.9.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.9.1/#Hello-World
|title=Zig Documentation(0.9.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.8.1に同じ
;0.8.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.8.1/#Hello-World
|title=Zig Documentation(0.8.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=4&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().writer();
    try stdout.print(&quot;Hello, {s}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: &lt;code&gt;{}&lt;/code&gt; ⇒ &lt;code&gt;{s}&lt;/code&gt;&lt;ref&gt;{{Cite web
|url=https://ziglang.org/download/0.8.0/release-notes.html#Formatted-Printing
|title=0.8.0 Release Notes
|website=ziglang.org
|accessdate=2022-07-17
|quote=Disable the special casing of {} for u8 slices/arrays. Unless {s} is specified the contents won't be treated as a string.
}}&lt;/ref&gt;
;0.7.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.7.1/#Hello-World
|title=Zig Documentation(0.7.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=3&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().writer();
    try stdout.print(&quot;Hello, {}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: s/outStream/writer/
;0.6.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.6.0/#Hello-World
|title=Zig Documentation(0.6.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=3&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().outStream();
    try stdout.print(&quot;Hello, {}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: 初期化の初期値から &lt;code&gt;try&lt;/code&gt; がなくなった。
;0.4.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.4.0/#Hello-World
|title=Zig Documentation(0.4.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.2.0に同じ
;0.5.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.5.0/#Hello-World
|title=Zig Documentation(0.5.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=4&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    // If this program is run without stdout attached, exit with an error.
    const stdout_file = try std.io.getStdOut();
    // If this program encounters pipe failure when printing to stdout, exit
    // with an error.
    try stdout_file.write(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;
: &lt;var&gt;stdout_file&lt;/var&gt; が &lt;code&gt;var&lt;/code&gt; から &lt;code&gt;const&lt;/code&gt; に変更された。

;0.3.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.3.0/#Hello-World
|title=Zig Documentation(0.3.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.2.0に同じ
;0.2.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.2.0/#Hello-World
|title=Zig Documentation(0.2.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    // If this program is run without stdout attached, exit with an error.
    var stdout_file = try std.io.getStdOut();
    // If this program encounters pipe failure when printing to stdout, exit
    // with an error.
    try stdout_file.write(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;
;0.1.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.1.1/#hello-world
|title=Zig Documentation
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig&gt;
const io = @import(&quot;std&quot;).io;
pub fn main() -&gt; %void {
    %%io.stdout.printf(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;

=== 環境準備 ===
Zigは、2022年7月の時点で '''pre-release''' の段階にあり、インストール手順も何度か変わっているので、まずは https://ziglang.org/learn/getting-started/ を参照し、最新のインストール手順を確認してください。また、ローカルのパッケージデータベースをパッケージシステムのリポジトリと同期を取り、鮮度の高い状態を維持するよう心がけてください。これは、インストール後も同じですし、zigに限ったことでもありません。

==== パッケージ マネージャー によるインストール ====
nightly の Zigを使いたい場合でない限り、お使いのOSやディストリビューションでサポートされているパッケージ マネージャを使ってインストールする事をお勧めします。

===== Windows =====
Zig は、[[Chocolatey]]パッケージシステムが対応しています。
:&lt;syntaxhighlight lang=console&gt;
&gt; choco install zig
&lt;/syntaxhighlight&gt;
{{See also|w:Chocolatey}}

===== macOS =====
macOS では、[[Homebrew]]と[[MacPorts]]が対応しています。
;最新とタグ付けされたリリース:&lt;syntaxhighlight lang=console&gt;
# brew install zig
&lt;/syntaxhighlight&gt;
;Git の master ブランチの最新ビルド:&lt;syntaxhighlight lang=console&gt;
# brew install zig --HEAD
&lt;/syntaxhighlight&gt;
;MacPorts:&lt;syntaxhighlight lang=console&gt;
# port install zig
&lt;/syntaxhighlight&gt;
{{See also|w:Homebrew|w:MacPorts}}

===== FreeBSD =====
;pkg:&lt;syntaxhighlight lang=console&gt;
# pkg install zig
&lt;/syntaxhighlight&gt;
;ports:&lt;syntaxhighlight lang=console&gt;
# make -C /usr/ports/lang/zig all install clean
&lt;/syntaxhighlight&gt;
{{See also|w:Ports}}

===== GNU/Linuxのディストリビューション =====
いわゆるLinuxは、Linux（ここではOSカーネル）と、FSFがHurdカーネルのために設計・開発したGNUユーザーランド（OSの基本機能を提供するソフトウェアの集合）を組合わせたものです。
このように、LinuxカーネルとGNUユーザーランドを組合わせたソフトウェアプラットフォームをGNU/Linuxと呼びます&lt;ref&gt;GNU/Linuxの中核として、商用・非商用を問わず、再配布可能なユーティリティを収集・配布するディストリビューターが登場しました。これらのディストリビューターは、それぞれの配布物（しばしば互換性のない）を、ディストリビューションとして区別する必要が生じました（特に、共有ライブラリの非互換性は目立ち、Linux支持者自身が嫌悪するWindowsのDLL-Hellに酷似しています)。 このようにして、ディストリビューション間の区別がなされたのです(また、ほかにもマーケティング上の理由などもあります)。&lt;hr/&gt;Unixでディストリビューションという言葉は、ソースコードで配布されるBSDのD (''distribution'') と関連付けられ、一方、非ソースコード指向のGNU/Linuxディストリビューションが、Unix訴訟の間隙を利する形で386 BSDのニッチをに受入れているのは皮肉なことです。&lt;/ref&gt;

====== Fedora 36 ======
:&lt;syntaxhighlight lang=console&gt;
# dnf install zig
&lt;/syntaxhighlight&gt;
{{See also|w:Dandified Yum}}

===== コードの実行方法 =====
[TBD:]

==== ソースコードからのビルド ====
Zig は、ソースコードが Github の https://github.com/ziglang/zig.git で公開されているので、必要に応じてソースコードからビルドすることができます。
とはいえ、zig はセルフホストに成功しているので、zig のビルドには zig が必要となり、クロスビルドしたバイナリーを持込むか、一旦、パッケージシステムからインストールする必要があります（FreeBSDのPortsが行っているのは、まさにこれです）。

ビルド方法こそ、頻繁に内容が変わるので個別具体的な手順は述べませんが、zig はコンパイラーであるとともにツールチェインでもあり、ビルドシステムも内包しているので、 zig builfd とすると build.zig ファイルに書かれているレシピにしたがって自動的にビルドが進行します（ストレージとメモリーと時間に余裕を見る必要があります）。

=== 値と型 ===
[TOD0:整数・浮動小数・論理値・文字列・共用体・構造体・列挙・配列・ベクトル・スライス・ポインター・ゼロビットな型]

:&lt;syntaxhighlight lang=&quot;zig&quot;&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot;abcd \n&quot;, .{} );
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
abcd 
&lt;/syntaxhighlight&gt;
: &lt;code&gt;print()&lt;/code&gt;の前の、&lt;code&gt;try&lt;/code&gt;は単項演算子です。&lt;code&gt;try&lt;/code&gt; は、右の式が例外を投げると式の値にします。エラーユニオン型を返す関数は、&lt;code&gt;try&lt;/code&gt;単項演算子か&lt;code&gt;catch&lt;/code&gt;二項演算子で、値とエラーを弁別する必要があります（&lt;code&gt;try&lt;/code&gt;あるいは&lt;code&gt;catch&lt;/code&gt;がないと、コンパイル時にエラーになります）。
: &lt;code&gt;print()&lt;/code&gt;の様に、標準ライブラリの &lt;code&gt;format()&lt;/code&gt;を使う関数は、フォーマット文字列と配列 &lt;code&gt;.{ … }&lt;/code&gt; を引数にします。[[C言語/標準ライブラリ/ctype.h|C言語]]のような、可変引数'''ではなく'''可変長の配列を使うので、プレースホルダーがない場合でも、空の配列 &lt;code&gt;.{}&lt;/code&gt; は必須です。

:&lt;syntaxhighlight lang=&quot;zig&quot;&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot; (1) = {}\n&quot;, .{42});
    try print(&quot; (2) = {}\n&quot;, .{0x17});
    try print(&quot; (3) = {}\n&quot;, .{0o17});
    try print(&quot; (4) = {}\n&quot;, .{0b0100101});
    try print(&quot; (5) = {}\n&quot;, .{1e222});
    try print(&quot; (6) = {}\n&quot;, .{3.1415926536});
    try print(&quot; (7) = {}\n&quot;, .{'c'});
    try print(&quot; (8) = {c}\n&quot;, .{'c'});
    try print(&quot; (9) = {s}\n&quot;, .{&quot;abcdef&quot;});
    try print(&quot;(10) = {}, {}\n&quot;, .{ 111, 999 });
    try print(&quot;(11) = {1}, {0}\n&quot;, .{ 111, 999 });
    try print(&quot;(12) = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; });
    try print(&quot;(13) = {0d}, {0b}, {0o}, {0x}, {0X}\n&quot;, .{ 123 });
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
 (1) = 42
 (2) = 23
 (3) = 15
 (4) = 37
 (5) = 1.0e+222
 (6) = 3.1415926536e+00
 (7) = 99
 (8) = c
 (9) = abcdef
(10) = 111, 999
(11) = 999, 111
(12) = abc, 111
(13) = 123, 1111011, 173, 7b, 7B
&lt;/syntaxhighlight&gt;
&lt;!-- リテラルの例、というか、@import(&quot;std&quot;).io.getStdOut().writer().print の例になっていますね。--&gt;
ご覧のように、数値（整数と浮動小数点数）や文字・文字列のリテラルがあり、整数は基数を、浮動小数点数は指数表現と小数表現があります。

@import(&quot;std&quot;).io.getStdOut().writer().printの、第一引数は書式化文字列、第二引数は配列です。書式化文字列は、通常の文字列ですが &lt;code&gt;{&lt;/code&gt; と &lt;code&gt;}&lt;/code&gt; で囲まれたプレスホルダーが、配列の当該順位の値（を書式化した文字列）に置換わります。
文字列の場合は、 {s} を明記しないと（バージョン0.8.0からは）エラーになります。
2つ以上の値を渡す場合は、第二引数を　.{ 1, 2, 3 } の様にカンマ区切りの配列にします（ {} の前の . （点）を忘れがち）。
基本的に、左から順にプレスホルダーに配列の値が左から与えられますが、{0} {1} の書式で参照する引数の順位を明示できます。
書式指定と併用する時は、 &lt;code&gt; print(&quot;? = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; })&lt;/code&gt; の様に順位が先、書式指定文字が後になります。

[TODO:[https://github.com/ziglang/zig/blob/master/lib/std/fmt.zig master/lib/std/fmt.zig]を観て書いています。参照すべき標準ライブラリのドキュメントを発見出来たら、見直し]
[TODO:表組み]

==== comptime ====
Zigでは、コンパイル時に'''式が既知かどうか'''という概念を重要視しています。

下記コードはコンパイルエラーになります。
:&lt;syntaxhighlight lang=&quot;zig&quot; line highlight=7&gt;
fn mul(x: usize, y: usize) usize {
    return x * y;
}

pub fn main() void {
    const len : usize = mul(3, 4);
    const ary: [len]i32 = undefined;
    _ = ary;
}
&lt;/syntaxhighlight&gt;
;コンパイル結果:&lt;syntaxhighlight lang=text&gt;
An error occurred: 
/tmp/playground130713503/play.zig:7:17: error: unable to evaluate constant expression 
    const ary: [len]i32 = undefined;
&lt;/syntaxhighlight&gt;
: 「定数式が評価できない 」と宣っています。
: [[C++]]であれば、constexprが適用なケースですが、Zigでは次のような解決方法を取ります。下記コードはエラーになりません。

:&lt;syntaxhighlight lang=&quot;zig&quot; line highlight=6&gt;
fn mul(x: usize, y: usize) usize {
    return x * y;
}

pub fn main() void {
    const len : usize = comptime mul(3, 4); // mul の前に comptime を追加 
    const ary: [len]i32 = undefined;
    _ = ary;
}
&lt;/syntaxhighlight&gt;
:変更点は mul() の呼出しを comptime で修飾しただけです。comptime は、修飾子式を'''コンパイル時に実行する'''修飾子で、式の中でコンパイル時に未定な値が参照されると、エラーとなります。ここでは、数リテラル同士の商を求めているので、コンパイル時値が確定できます。
: _ = ary は、「定義済だが参照のない変数宣言」をサプレッスするときのイディオムです。

&lt;!--
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const i = 0;
    const string = [_]i32{ 1, 2, 3, 4 };
    for (string) |character, index| {
        std.debug.print(&quot;character: {}, index: {}, :{s} \n&quot;, .{ character, index, @typeName(@TypeOf(character)) });
    }
    _ = i;
}
--&gt;

===== build &amp; exec  =====
zig コマンドは、コッンパイラーにとどまらずビルドツールの機能を持ち、&lt;code&gt;run&lt;/code&gt;サブコマンドは、当該ソースファイルのコンパイル（ソースコードの変更などの必要性があれば）とコンパイルの成果物の実行を行います。

;適用例:&lt;syntaxhighlight lang=console&gt;
zig run hello.zig
&lt;/syntaxhighlight&gt;

===== プロジェクト作成する場合 =====
ここで作るプロジェクトの名前は myproj としましょう。
予め、作業用に適したファイルシステムに、ディレキトリー myproj を用意し、zig init-exe を実行します。

:&lt;syntaxhighlight lang=console&gt;
% cd myproj/
% zig init-exe
% % find -s * -type f
build.zig
src/main.zig
% cat build.zig
const std = @import(&quot;std&quot;);

pub fn build(b: *std.build.Builder) void {
    // Standard target options allows the person running `zig build` to choose
    // what target to build for. Here we do not override the defaults, which
    // means any target is allowed, and the default is native. Other options
    // for restricting supported target set are available.
    const target = b.standardTargetOptions(.{});

    // Standard release options allow the person running `zig build` to select
    // between Debug, ReleaseSafe, ReleaseFast, and ReleaseSmall.
    const mode = b.standardReleaseOptions();

    const exe = b.addExecutable(&quot;myproj&quot;, &quot;src/main.zig&quot;);
    exe.setTarget(target);
    exe.setBuildMode(mode);
    exe.install();

    const run_cmd = exe.run();
    run_cmd.step.dependOn(b.getInstallStep());
    if (b.args) |args| {
        run_cmd.addArgs(args);
    }

    const run_step = b.step(&quot;run&quot;, &quot;Run the app&quot;);
    run_step.dependOn(&amp;run_cmd.step);

    const exe_tests = b.addTest(&quot;src/main.zig&quot;);
    exe_tests.setTarget(target);
    exe_tests.setBuildMode(mode);

    const test_step = b.step(&quot;test&quot;, &quot;Run unit tests&quot;);
    test_step.dependOn(&amp;exe_tests.step);
}
% cat src/main.zig 
const std = @import(&quot;std&quot;);

pub fn main() anyerror!void {
    std.log.info(&quot;All your codebase are belong to us.&quot;, .{});
}

test &quot;basic test&quot; {
    try std.testing.expectEqual(10, 3 + 7);
}
% zig build
% zig-out/bin/myproj 
info: All your codebase are belong to us.
&lt;/syntaxhighlight&gt;

== 基礎篇 ==
[TODO:書くべき項目を並べてみましたが、例えば「値と型」を網羅的に書いていくと文章量が爆発するのが目に見えているので、過剰になったらリファレンス篇に移動するなどの方法で、各節はコンパクトさを心がけたいです。]

=== コメント ===
Zigでは、&lt;code&gt;//&lt;/code&gt; から行末までがコメントです。
C言語の &lt;code&gt;/* … */&lt;/code&gt; のスタイルの複数行に渡るコメントは'''ありません'''。
これは、コードの各行を文脈に関係なくトークン化できるようにするためです。
:&lt;syntaxhighlight lang=zig&gt;
// @import は組込み関数です。
const std = @import(&quot;std&quot;); // 先頭に @ が付く関数は組込み関数です
pub fn main() !void {
   try std.io.getStdOut().writeAll(&quot;Hello, World!\n&quot;);
}
&lt;/syntaxhighlight&gt;

==== Docコメント ====
Zigでは、&lt;code&gt;///&lt;/code&gt; から始まるコメントは特別なコメントで、Docコメント( ''Doc comments'' )と呼ばれます。
Docコメントは特定の場所にしか許されません。式の途中や非Docコメントの直前など、予想外の場所にdocコメントがあると、コンパイルエラーになります。

[TODO:サンプルコードと整形結果]

==== トップレベルDocコメント ====
Zigでは、&lt;code&gt;//!&lt;/code&gt; から始まるコメントは特別なコメントで、トップレベルDocコメント( ''Top-Level Doc Comments '' )と呼ばれます。
コンテナレベルのドキュメントのように、直後のドキュメントに属さないユーザードキュメントに、トップレベルDocコメントを使います。

[TODO:サンプルコードと整形結果]

DocコメントおよびトップレベルDocコメントは、コンパイル時に zig build-exe -femit-docs ソースファイル.zig の様に、-femit-docs をあたえると、 docs/ 以下にドキュメントが生成されます。

=== 値と型 ===
[TOD0:整数・浮動小数・論理値・文字列・共用体・構造体・列挙・配列・ベクトル・スライス・ポインター・ゼロビットな型]

:&lt;syntaxhighlight lang=zig&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot; (1) = {}\n&quot;, .{42});
    try print(&quot; (2) = {}\n&quot;, .{0x17});
    try print(&quot; (3) = {}\n&quot;, .{0o17});
    try print(&quot; (4) = {}\n&quot;, .{0b0100101});
    try print(&quot; (5) = {}\n&quot;, .{1e222});
    try print(&quot; (6) = {}\n&quot;, .{3.1415926536});
    try print(&quot; (7) = {}\n&quot;, .{'c'});
    try print(&quot; (8) = {c}\n&quot;, .{'c'});
    try print(&quot; (9) = {s}\n&quot;, .{&quot;abcdef&quot;});
    try print(&quot;(10) = {}, {}\n&quot;, .{ 111, 999 });
    try print(&quot;(11) = {1}, {0}\n&quot;, .{ 111, 999 });
    try print(&quot;(12) = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; });
    try print(&quot;(13) = {0d}, {0b}, {0o}, {0x}, {0X}\n&quot;, .{ 123 });
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
 (1) = 42
 (2) = 23
 (3) = 15
 (4) = 37
 (5) = 1.0e+222
 (6) = 3.1415926536e+00
 (7) = 99
 (8) = c
 (9) = abcdef
(10) = 111, 999
(11) = 999, 111
(12) = abc, 111
(13) = 123, 1111011, 173, 7b, 7B
&lt;/syntaxhighlight&gt;
&lt;!-- リテラルの例、というか、@import(&quot;std&quot;).io.getStdOut().writer().print の例になっていますね。--&gt;
ご覧のように、数値（整数と浮動小数点数）や文字・文字列のリテラルがあり、整数は基数を、浮動小数点数は指数表現と少数表現があります。

@import(&quot;std&quot;).io.getStdOut().writer().printの、第一引数は書式化文字列、第二引数は値リストです。
書式化文字列は、通常の文字列ですが &lt;code&gt;{&lt;/code&gt; と &lt;code&gt;}&lt;/code&gt; で囲まれたプレスホルダーが、引数リストの値（を書式化した文字列）に置換わります。
一番素朴なプレスホルダーは {} で、引数の値の一般的な文字列表記に置き換ります（整数なら十進数表記、浮動小数点数なら指数表記）。
ところが、’c’ のような文字型を {} に適用すると文字コード化され整数と同じ十進数表記になってしまいます。そこで、文字型の場合は {c} と文字であることを明記すると文字表現となります。
また、文字列の間合いは {s} を明記しないと（バージョン0.8.0からは）エラーになります。
2つ以上の値を渡す場合は、第二引数を　.{ 1, 2, 3 } の様にカンマ区切りのリストにします（ これが、Zig の配列リテラルの表現で、{} の前の . （点）を忘れがち）。
基本的に、左から順にプレスホルダーにリストの値が左から与えられますが、{0} {1} の書式で参照する引数の順位を明示できます。
書式指定と併用する時は、 &lt;code&gt; print(&quot;? = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; })&lt;/code&gt; の様に順位が先、書式指定文字が後になります。

[TODO:[https://github.com/ziglang/zig/blob/master/lib/std/fmt.zig master/lib/std/fmt.zig]を観て書いています。参照すべき標準ライブラリのドキュメントを発見出来たら、見直し]
[TODO:表組み]

==== comptime ====
Zigでは、コンパイル時に式が既知かどうかという概念を重要視しています。

&lt;!--
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const i = 0;
    const string = [_]i32{ 1, 2, 3, 4 };
    for (string) |character, index| {
        std.debug.print(&quot;character: {}, index: {}, :{s} \n&quot;, .{ character, index, @typeName(@TypeOf(character)) });
    }
    _ = i;
}
--&gt;

=== テスト ===
=== 変数 ===
=== 制御構造 ===
[TODO:Zig の制御構造は文ではなく式]
==== 分岐 ====
[TODO:ifとswitch]
==== 反復 ====
[TODO:whileとfor]
=== 関数 ===
=== エラー ===
=== 演算子 ===
==== 優先順位 ====
高
&lt;syntaxhighlight lang=text line&gt;
 x() x[] x.y x.* x.?
 a!b
 x{}
 !x -x -%x ~x &amp;x ?x
 * / % ** *% *| ||
 + - ++ +% -% +| -|
 &lt;&lt; &gt;&gt; &lt;&lt;|
 &amp; ^ | orelse catch
 == != &lt; &gt; &lt;= &gt;=
 and
 or
 = *= *%= *|= /= %= += +%= +|= -= -%= -|= &lt;&lt;= &lt;&lt;|= &gt;&gt;= &amp;= ^= |=
&lt;/syntaxhighlight&gt;
低

===  optional type ===
===  opaque ===
訳語未定
=== ブロック ===
[TODO:スコープとシャドーイング；deferはここ？]
=== キャスト ===
[TODO:Zig は強い型付け()； 型強制 (Type coercion) について]
=== アセンブリ言語との連携 ===
[TODO:所謂インラインアセンラ]
=== atomic ===
=== 非同期関数 ===
=== 組込み関数 ===
[TODO:組込み関数は、@で始まり、@TypeOfや@alignOfの他@sinや@memcpyも組込み関数]
=== メモリ管理 ===
=== キーワード一覧 ===
&lt;code&gt;align&lt;/code&gt;
&lt;code&gt;allowzero&lt;/code&gt;
&lt;code&gt;and&lt;/code&gt;
&lt;code&gt;anyframe&lt;/code&gt;
&lt;code&gt;anytype&lt;/code&gt;
&lt;code&gt;asm&lt;/code&gt;
&lt;code&gt;async&lt;/code&gt;
&lt;code&gt;await&lt;/code&gt;
&lt;code&gt;break&lt;/code&gt;
&lt;code&gt;catch&lt;/code&gt;
&lt;code&gt;comptime&lt;/code&gt;
&lt;code&gt;const&lt;/code&gt;
&lt;code&gt;continue&lt;/code&gt;
&lt;code&gt;defer&lt;/code&gt;
&lt;code&gt;else&lt;/code&gt;
&lt;code&gt;enum&lt;/code&gt;
&lt;code&gt;errdefer&lt;/code&gt;
&lt;code&gt;error&lt;/code&gt;
&lt;code&gt;export&lt;/code&gt;
&lt;code&gt;extern&lt;/code&gt;
&lt;code&gt;fn&lt;/code&gt;
&lt;code&gt;for&lt;/code&gt;
&lt;code&gt;if&lt;/code&gt;
&lt;code&gt;inline&lt;/code&gt;
&lt;code&gt;noalias&lt;/code&gt;
&lt;code&gt;nosuspend&lt;/code&gt;
&lt;code&gt;or&lt;/code&gt;
&lt;code&gt;orelse&lt;/code&gt;
&lt;code&gt;packed&lt;/code&gt;
&lt;code&gt;pub&lt;/code&gt;
&lt;code&gt;resume&lt;/code&gt;
&lt;code&gt;return&lt;/code&gt;
&lt;code&gt;linksection&lt;/code&gt;
&lt;code&gt;struct&lt;/code&gt;
&lt;code&gt;suspend&lt;/code&gt;
&lt;code&gt;switch&lt;/code&gt;
&lt;code&gt;test&lt;/code&gt;
&lt;code&gt;threadlocal&lt;/code&gt;
&lt;code&gt;try&lt;/code&gt;
&lt;code&gt;union&lt;/code&gt;
&lt;code&gt;unreachable&lt;/code&gt;
&lt;code&gt;usingnamespace&lt;/code&gt;
&lt;code&gt;var&lt;/code&gt;
&lt;code&gt;volatile&lt;/code&gt;
&lt;code&gt;while&lt;/code&gt;

== チートシート ==
[TODO:文法と型と頻用する標準ライブラリの関数と型のアンチョコ]

== リファレンス篇 ==

== 脚註 ==
&lt;references /&gt;

== 外部リンク ==
* [https://ziglang.org/ Home ⚡ Zig Programming Language] {{---}} 公式サイト
** [[https://ziglang.org/documentation/master/ Zig Language Reference]] {{---}} リファレンスマニュアル
* [https://github.com/ziglang/zig ziglang/zig: General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.] {{---}} 公式リポジトリ
* [https://zig-play.dev/ Zig Playground] {{---}} オンライン実行環境
** [https://github.com/gsquire/zig-play About An online Zig compiler inspired by Go and Rust] {{---}} リポジトリ

[[Category:zig|*]]
[[Category:プログラミング言語]]</text>
      <sha1>ayzgrcv1frz0emigl7mdkusyth5eevc</sha1>
    </revision>
    <revision>
      <id>205787</id>
      <parentid>205786</parentid>
      <timestamp>2022-07-24T11:40:02Z</timestamp>
      <contributor>
        <username>Ef3</username>
        <id>694</id>
      </contributor>
      <minor />
      <comment>/* ソースコードからのビルド */ Fixt ypo</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="26443" xml:space="preserve">{{Pathnav|メインページ|工学|情報技術|プログラミング|frame=1}}
{{Wikipedia|Zig (プログラミング言語)}}
本書は、[[w:Zig|Zig]]のチュートリアルです。
Zigは、堅牢で最適かつ再利用可能なソフトウェアを維持するための汎用プログラミング言語およびツールチェインです&lt;ref&gt;{{Cite web
|url=https://ziglang.org/
|title=Home ⚡ Zig Programming Language
|website=ziglang.org
|accessdate=2022-07-17
|cite=Zig is a general-purpose programming language and toolchain for maintaining '''robust''', '''optimal''' and '''reusable''' software.
}}&lt;/ref&gt;。
Zigは、アンドリュー・ケリー( ''[https://andrewkelley.me/ Andrew Kelley]'' )によって設計され、汎用システムプログラミング言語で、静的で強い型付けで型推論とジェネリックプログラミングをサポートします。

== 概要 ==
Zigは、2016年2月に発表された比較的若いプログラミング言語で&lt;ref&gt;{{Cite web
|last1=Kelley
|first1=Andrew
|title=Introduction to the Zig Programming Language
|url=https://andrewkelley.me/post/intro-to-zig.html
|website=andrewkelley.me
|accessdate=2022-07-17
}}&lt;/ref&gt;、2022年7月現在のバージョンは 0.9.1 で、'''''pre-release''''' と位置づけられています&lt;ref&gt;{{Cite web
|url=https://github.com/ziglang/zig/releases
|title=Releases · ziglang/zig
|website=github.com
|accessdate=2022-07-17
}}&lt;/ref&gt;。このため [[W:Hello world|Hello world]] ですら、バージョン間で互換性がなくなることもあり、リリースバージョンまでは言語仕様やライブラリーおよびツールチェインの仕様が変更される可能性があります。

=== Hello world の変遷 ===
[https://ziglang.org/documentation/master/ Zig Language Reference]の、[[W:Hello world|Hello world]]の変遷（新しい順）。

;master@2022-07-17&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/master/#Hello-World
|title=Zig Documentation(master@2022-07-17)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.8.1に同じ
;0.9.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.9.1/#Hello-World
|title=Zig Documentation(0.9.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.8.1に同じ
;0.8.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.8.1/#Hello-World
|title=Zig Documentation(0.8.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=4&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().writer();
    try stdout.print(&quot;Hello, {s}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: &lt;code&gt;{}&lt;/code&gt; ⇒ &lt;code&gt;{s}&lt;/code&gt;&lt;ref&gt;{{Cite web
|url=https://ziglang.org/download/0.8.0/release-notes.html#Formatted-Printing
|title=0.8.0 Release Notes
|website=ziglang.org
|accessdate=2022-07-17
|quote=Disable the special casing of {} for u8 slices/arrays. Unless {s} is specified the contents won't be treated as a string.
}}&lt;/ref&gt;
;0.7.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.7.1/#Hello-World
|title=Zig Documentation(0.7.1)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=3&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().writer();
    try stdout.print(&quot;Hello, {}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: s/outStream/writer/
;0.6.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.6.0/#Hello-World
|title=Zig Documentation(0.6.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=3&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const stdout = std.io.getStdOut().outStream();
    try stdout.print(&quot;Hello, {}!\n&quot;, .{&quot;world&quot;});
}
&lt;/syntaxhighlight&gt;
: 初期化の初期値から &lt;code&gt;try&lt;/code&gt; がなくなった。
;0.4.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.4.0/#Hello-World
|title=Zig Documentation(0.4.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.2.0に同じ
;0.5.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.5.0/#Hello-World
|title=Zig Documentation(0.5.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig highlight=4&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    // If this program is run without stdout attached, exit with an error.
    const stdout_file = try std.io.getStdOut();
    // If this program encounters pipe failure when printing to stdout, exit
    // with an error.
    try stdout_file.write(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;
: &lt;var&gt;stdout_file&lt;/var&gt; が &lt;code&gt;var&lt;/code&gt; から &lt;code&gt;const&lt;/code&gt; に変更された。

;0.3.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.3.0/#Hello-World
|title=Zig Documentation(0.3.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:0.2.0に同じ
;0.2.0&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.2.0/#Hello-World
|title=Zig Documentation(0.2.0)
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig&gt;
const std = @import(&quot;std&quot;);
pub fn main() !void {
    // If this program is run without stdout attached, exit with an error.
    var stdout_file = try std.io.getStdOut();
    // If this program encounters pipe failure when printing to stdout, exit
    // with an error.
    try stdout_file.write(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;
;0.1.1&lt;ref&gt;{{Cite web
|url=https://ziglang.org/documentation/0.1.1/#hello-world
|title=Zig Documentation
|website=ziglang.org
|accessdate=2022-07-17
}}&lt;/ref&gt;:&lt;syntaxhighlight lang=zig&gt;
const io = @import(&quot;std&quot;).io;
pub fn main() -&gt; %void {
    %%io.stdout.printf(&quot;Hello, world!\n&quot;);
}
&lt;/syntaxhighlight&gt;

=== 環境準備 ===
Zigは、2022年7月の時点で '''pre-release''' の段階にあり、インストール手順も何度か変わっているので、まずは https://ziglang.org/learn/getting-started/ を参照し、最新のインストール手順を確認してください。また、ローカルのパッケージデータベースをパッケージシステムのリポジトリと同期を取り、鮮度の高い状態を維持するよう心がけてください。これは、インストール後も同じですし、zigに限ったことでもありません。

==== パッケージ マネージャー によるインストール ====
nightly の Zigを使いたい場合でない限り、お使いのOSやディストリビューションでサポートされているパッケージ マネージャを使ってインストールする事をお勧めします。

===== Windows =====
Zig は、[[Chocolatey]]パッケージシステムが対応しています。
:&lt;syntaxhighlight lang=console&gt;
&gt; choco install zig
&lt;/syntaxhighlight&gt;
{{See also|w:Chocolatey}}

===== macOS =====
macOS では、[[Homebrew]]と[[MacPorts]]が対応しています。
;最新とタグ付けされたリリース:&lt;syntaxhighlight lang=console&gt;
# brew install zig
&lt;/syntaxhighlight&gt;
;Git の master ブランチの最新ビルド:&lt;syntaxhighlight lang=console&gt;
# brew install zig --HEAD
&lt;/syntaxhighlight&gt;
;MacPorts:&lt;syntaxhighlight lang=console&gt;
# port install zig
&lt;/syntaxhighlight&gt;
{{See also|w:Homebrew|w:MacPorts}}

===== FreeBSD =====
;pkg:&lt;syntaxhighlight lang=console&gt;
# pkg install zig
&lt;/syntaxhighlight&gt;
;ports:&lt;syntaxhighlight lang=console&gt;
# make -C /usr/ports/lang/zig all install clean
&lt;/syntaxhighlight&gt;
{{See also|w:Ports}}

===== GNU/Linuxのディストリビューション =====
いわゆるLinuxは、Linux（ここではOSカーネル）と、FSFがHurdカーネルのために設計・開発したGNUユーザーランド（OSの基本機能を提供するソフトウェアの集合）を組合わせたものです。
このように、LinuxカーネルとGNUユーザーランドを組合わせたソフトウェアプラットフォームをGNU/Linuxと呼びます&lt;ref&gt;GNU/Linuxの中核として、商用・非商用を問わず、再配布可能なユーティリティを収集・配布するディストリビューターが登場しました。これらのディストリビューターは、それぞれの配布物（しばしば互換性のない）を、ディストリビューションとして区別する必要が生じました（特に、共有ライブラリの非互換性は目立ち、Linux支持者自身が嫌悪するWindowsのDLL-Hellに酷似しています)。 このようにして、ディストリビューション間の区別がなされたのです(また、ほかにもマーケティング上の理由などもあります)。&lt;hr/&gt;Unixでディストリビューションという言葉は、ソースコードで配布されるBSDのD (''distribution'') と関連付けられ、一方、非ソースコード指向のGNU/Linuxディストリビューションが、Unix訴訟の間隙を利する形で386 BSDのニッチをに受入れているのは皮肉なことです。&lt;/ref&gt;

====== Fedora 36 ======
:&lt;syntaxhighlight lang=console&gt;
# dnf install zig
&lt;/syntaxhighlight&gt;
{{See also|w:Dandified Yum}}

===== コードの実行方法 =====
[TBD:]

==== ソースコードからのビルド ====
Zig は、ソースコードが Github の https://github.com/ziglang/zig.git で公開されているので、必要に応じてソースコードからビルドすることができます。
とはいえ、zig はセルフホストに成功しているので、zig のビルドには zig が必要となり、クロスビルドしたバイナリーを持込むか、一旦、パッケージシステムからインストールする必要があります（FreeBSDのPortsが行っているのは、まさにこれです）。

ビルド方法こそ、頻繁に内容が変わるので個別具体的な手順は述べませんが、zig はコンパイラーであるとともにツールチェインでもあり、ビルドシステムも内包しているので、 zig build とすると build.zig ファイルに書かれているレシピにしたがって自動的にビルドが進行します（ストレージとメモリーと時間に余裕を見る必要があります）。

=== 値と型 ===
[TOD0:整数・浮動小数・論理値・文字列・共用体・構造体・列挙・配列・ベクトル・スライス・ポインター・ゼロビットな型]

:&lt;syntaxhighlight lang=&quot;zig&quot;&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot;abcd \n&quot;, .{} );
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
abcd 
&lt;/syntaxhighlight&gt;
: &lt;code&gt;print()&lt;/code&gt;の前の、&lt;code&gt;try&lt;/code&gt;は単項演算子です。&lt;code&gt;try&lt;/code&gt; は、右の式が例外を投げると式の値にします。エラーユニオン型を返す関数は、&lt;code&gt;try&lt;/code&gt;単項演算子か&lt;code&gt;catch&lt;/code&gt;二項演算子で、値とエラーを弁別する必要があります（&lt;code&gt;try&lt;/code&gt;あるいは&lt;code&gt;catch&lt;/code&gt;がないと、コンパイル時にエラーになります）。
: &lt;code&gt;print()&lt;/code&gt;の様に、標準ライブラリの &lt;code&gt;format()&lt;/code&gt;を使う関数は、フォーマット文字列と配列 &lt;code&gt;.{ … }&lt;/code&gt; を引数にします。[[C言語/標準ライブラリ/ctype.h|C言語]]のような、可変引数'''ではなく'''可変長の配列を使うので、プレースホルダーがない場合でも、空の配列 &lt;code&gt;.{}&lt;/code&gt; は必須です。

:&lt;syntaxhighlight lang=&quot;zig&quot;&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot; (1) = {}\n&quot;, .{42});
    try print(&quot; (2) = {}\n&quot;, .{0x17});
    try print(&quot; (3) = {}\n&quot;, .{0o17});
    try print(&quot; (4) = {}\n&quot;, .{0b0100101});
    try print(&quot; (5) = {}\n&quot;, .{1e222});
    try print(&quot; (6) = {}\n&quot;, .{3.1415926536});
    try print(&quot; (7) = {}\n&quot;, .{'c'});
    try print(&quot; (8) = {c}\n&quot;, .{'c'});
    try print(&quot; (9) = {s}\n&quot;, .{&quot;abcdef&quot;});
    try print(&quot;(10) = {}, {}\n&quot;, .{ 111, 999 });
    try print(&quot;(11) = {1}, {0}\n&quot;, .{ 111, 999 });
    try print(&quot;(12) = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; });
    try print(&quot;(13) = {0d}, {0b}, {0o}, {0x}, {0X}\n&quot;, .{ 123 });
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
 (1) = 42
 (2) = 23
 (3) = 15
 (4) = 37
 (5) = 1.0e+222
 (6) = 3.1415926536e+00
 (7) = 99
 (8) = c
 (9) = abcdef
(10) = 111, 999
(11) = 999, 111
(12) = abc, 111
(13) = 123, 1111011, 173, 7b, 7B
&lt;/syntaxhighlight&gt;
&lt;!-- リテラルの例、というか、@import(&quot;std&quot;).io.getStdOut().writer().print の例になっていますね。--&gt;
ご覧のように、数値（整数と浮動小数点数）や文字・文字列のリテラルがあり、整数は基数を、浮動小数点数は指数表現と小数表現があります。

@import(&quot;std&quot;).io.getStdOut().writer().printの、第一引数は書式化文字列、第二引数は配列です。書式化文字列は、通常の文字列ですが &lt;code&gt;{&lt;/code&gt; と &lt;code&gt;}&lt;/code&gt; で囲まれたプレスホルダーが、配列の当該順位の値（を書式化した文字列）に置換わります。
文字列の場合は、 {s} を明記しないと（バージョン0.8.0からは）エラーになります。
2つ以上の値を渡す場合は、第二引数を　.{ 1, 2, 3 } の様にカンマ区切りの配列にします（ {} の前の . （点）を忘れがち）。
基本的に、左から順にプレスホルダーに配列の値が左から与えられますが、{0} {1} の書式で参照する引数の順位を明示できます。
書式指定と併用する時は、 &lt;code&gt; print(&quot;? = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; })&lt;/code&gt; の様に順位が先、書式指定文字が後になります。

[TODO:[https://github.com/ziglang/zig/blob/master/lib/std/fmt.zig master/lib/std/fmt.zig]を観て書いています。参照すべき標準ライブラリのドキュメントを発見出来たら、見直し]
[TODO:表組み]

==== comptime ====
Zigでは、コンパイル時に'''式が既知かどうか'''という概念を重要視しています。

下記コードはコンパイルエラーになります。
:&lt;syntaxhighlight lang=&quot;zig&quot; line highlight=7&gt;
fn mul(x: usize, y: usize) usize {
    return x * y;
}

pub fn main() void {
    const len : usize = mul(3, 4);
    const ary: [len]i32 = undefined;
    _ = ary;
}
&lt;/syntaxhighlight&gt;
;コンパイル結果:&lt;syntaxhighlight lang=text&gt;
An error occurred: 
/tmp/playground130713503/play.zig:7:17: error: unable to evaluate constant expression 
    const ary: [len]i32 = undefined;
&lt;/syntaxhighlight&gt;
: 「定数式が評価できない 」と宣っています。
: [[C++]]であれば、constexprが適用なケースですが、Zigでは次のような解決方法を取ります。下記コードはエラーになりません。

:&lt;syntaxhighlight lang=&quot;zig&quot; line highlight=6&gt;
fn mul(x: usize, y: usize) usize {
    return x * y;
}

pub fn main() void {
    const len : usize = comptime mul(3, 4); // mul の前に comptime を追加 
    const ary: [len]i32 = undefined;
    _ = ary;
}
&lt;/syntaxhighlight&gt;
:変更点は mul() の呼出しを comptime で修飾しただけです。comptime は、修飾子式を'''コンパイル時に実行する'''修飾子で、式の中でコンパイル時に未定な値が参照されると、エラーとなります。ここでは、数リテラル同士の商を求めているので、コンパイル時値が確定できます。
: _ = ary は、「定義済だが参照のない変数宣言」をサプレッスするときのイディオムです。

&lt;!--
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const i = 0;
    const string = [_]i32{ 1, 2, 3, 4 };
    for (string) |character, index| {
        std.debug.print(&quot;character: {}, index: {}, :{s} \n&quot;, .{ character, index, @typeName(@TypeOf(character)) });
    }
    _ = i;
}
--&gt;

===== build &amp; exec  =====
zig コマンドは、コッンパイラーにとどまらずビルドツールの機能を持ち、&lt;code&gt;run&lt;/code&gt;サブコマンドは、当該ソースファイルのコンパイル（ソースコードの変更などの必要性があれば）とコンパイルの成果物の実行を行います。

;適用例:&lt;syntaxhighlight lang=console&gt;
zig run hello.zig
&lt;/syntaxhighlight&gt;

===== プロジェクト作成する場合 =====
ここで作るプロジェクトの名前は myproj としましょう。
予め、作業用に適したファイルシステムに、ディレキトリー myproj を用意し、zig init-exe を実行します。

:&lt;syntaxhighlight lang=console&gt;
% cd myproj/
% zig init-exe
% % find -s * -type f
build.zig
src/main.zig
% cat build.zig
const std = @import(&quot;std&quot;);

pub fn build(b: *std.build.Builder) void {
    // Standard target options allows the person running `zig build` to choose
    // what target to build for. Here we do not override the defaults, which
    // means any target is allowed, and the default is native. Other options
    // for restricting supported target set are available.
    const target = b.standardTargetOptions(.{});

    // Standard release options allow the person running `zig build` to select
    // between Debug, ReleaseSafe, ReleaseFast, and ReleaseSmall.
    const mode = b.standardReleaseOptions();

    const exe = b.addExecutable(&quot;myproj&quot;, &quot;src/main.zig&quot;);
    exe.setTarget(target);
    exe.setBuildMode(mode);
    exe.install();

    const run_cmd = exe.run();
    run_cmd.step.dependOn(b.getInstallStep());
    if (b.args) |args| {
        run_cmd.addArgs(args);
    }

    const run_step = b.step(&quot;run&quot;, &quot;Run the app&quot;);
    run_step.dependOn(&amp;run_cmd.step);

    const exe_tests = b.addTest(&quot;src/main.zig&quot;);
    exe_tests.setTarget(target);
    exe_tests.setBuildMode(mode);

    const test_step = b.step(&quot;test&quot;, &quot;Run unit tests&quot;);
    test_step.dependOn(&amp;exe_tests.step);
}
% cat src/main.zig 
const std = @import(&quot;std&quot;);

pub fn main() anyerror!void {
    std.log.info(&quot;All your codebase are belong to us.&quot;, .{});
}

test &quot;basic test&quot; {
    try std.testing.expectEqual(10, 3 + 7);
}
% zig build
% zig-out/bin/myproj 
info: All your codebase are belong to us.
&lt;/syntaxhighlight&gt;

== 基礎篇 ==
[TODO:書くべき項目を並べてみましたが、例えば「値と型」を網羅的に書いていくと文章量が爆発するのが目に見えているので、過剰になったらリファレンス篇に移動するなどの方法で、各節はコンパクトさを心がけたいです。]

=== コメント ===
Zigでは、&lt;code&gt;//&lt;/code&gt; から行末までがコメントです。
C言語の &lt;code&gt;/* … */&lt;/code&gt; のスタイルの複数行に渡るコメントは'''ありません'''。
これは、コードの各行を文脈に関係なくトークン化できるようにするためです。
:&lt;syntaxhighlight lang=zig&gt;
// @import は組込み関数です。
const std = @import(&quot;std&quot;); // 先頭に @ が付く関数は組込み関数です
pub fn main() !void {
   try std.io.getStdOut().writeAll(&quot;Hello, World!\n&quot;);
}
&lt;/syntaxhighlight&gt;

==== Docコメント ====
Zigでは、&lt;code&gt;///&lt;/code&gt; から始まるコメントは特別なコメントで、Docコメント( ''Doc comments'' )と呼ばれます。
Docコメントは特定の場所にしか許されません。式の途中や非Docコメントの直前など、予想外の場所にdocコメントがあると、コンパイルエラーになります。

[TODO:サンプルコードと整形結果]

==== トップレベルDocコメント ====
Zigでは、&lt;code&gt;//!&lt;/code&gt; から始まるコメントは特別なコメントで、トップレベルDocコメント( ''Top-Level Doc Comments '' )と呼ばれます。
コンテナレベルのドキュメントのように、直後のドキュメントに属さないユーザードキュメントに、トップレベルDocコメントを使います。

[TODO:サンプルコードと整形結果]

DocコメントおよびトップレベルDocコメントは、コンパイル時に zig build-exe -femit-docs ソースファイル.zig の様に、-femit-docs をあたえると、 docs/ 以下にドキュメントが生成されます。

=== 値と型 ===
[TOD0:整数・浮動小数・論理値・文字列・共用体・構造体・列挙・配列・ベクトル・スライス・ポインター・ゼロビットな型]

:&lt;syntaxhighlight lang=zig&gt;
pub fn main() !void {
    const print = @import(&quot;std&quot;).io.getStdOut().writer().print;
    try print(&quot; (1) = {}\n&quot;, .{42});
    try print(&quot; (2) = {}\n&quot;, .{0x17});
    try print(&quot; (3) = {}\n&quot;, .{0o17});
    try print(&quot; (4) = {}\n&quot;, .{0b0100101});
    try print(&quot; (5) = {}\n&quot;, .{1e222});
    try print(&quot; (6) = {}\n&quot;, .{3.1415926536});
    try print(&quot; (7) = {}\n&quot;, .{'c'});
    try print(&quot; (8) = {c}\n&quot;, .{'c'});
    try print(&quot; (9) = {s}\n&quot;, .{&quot;abcdef&quot;});
    try print(&quot;(10) = {}, {}\n&quot;, .{ 111, 999 });
    try print(&quot;(11) = {1}, {0}\n&quot;, .{ 111, 999 });
    try print(&quot;(12) = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; });
    try print(&quot;(13) = {0d}, {0b}, {0o}, {0x}, {0X}\n&quot;, .{ 123 });
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
 (1) = 42
 (2) = 23
 (3) = 15
 (4) = 37
 (5) = 1.0e+222
 (6) = 3.1415926536e+00
 (7) = 99
 (8) = c
 (9) = abcdef
(10) = 111, 999
(11) = 999, 111
(12) = abc, 111
(13) = 123, 1111011, 173, 7b, 7B
&lt;/syntaxhighlight&gt;
&lt;!-- リテラルの例、というか、@import(&quot;std&quot;).io.getStdOut().writer().print の例になっていますね。--&gt;
ご覧のように、数値（整数と浮動小数点数）や文字・文字列のリテラルがあり、整数は基数を、浮動小数点数は指数表現と少数表現があります。

@import(&quot;std&quot;).io.getStdOut().writer().printの、第一引数は書式化文字列、第二引数は値リストです。
書式化文字列は、通常の文字列ですが &lt;code&gt;{&lt;/code&gt; と &lt;code&gt;}&lt;/code&gt; で囲まれたプレスホルダーが、引数リストの値（を書式化した文字列）に置換わります。
一番素朴なプレスホルダーは {} で、引数の値の一般的な文字列表記に置き換ります（整数なら十進数表記、浮動小数点数なら指数表記）。
ところが、’c’ のような文字型を {} に適用すると文字コード化され整数と同じ十進数表記になってしまいます。そこで、文字型の場合は {c} と文字であることを明記すると文字表現となります。
また、文字列の間合いは {s} を明記しないと（バージョン0.8.0からは）エラーになります。
2つ以上の値を渡す場合は、第二引数を　.{ 1, 2, 3 } の様にカンマ区切りのリストにします（ これが、Zig の配列リテラルの表現で、{} の前の . （点）を忘れがち）。
基本的に、左から順にプレスホルダーにリストの値が左から与えられますが、{0} {1} の書式で参照する引数の順位を明示できます。
書式指定と併用する時は、 &lt;code&gt; print(&quot;? = {1s}, {0}\n&quot;, .{ 111, &quot;abc&quot; })&lt;/code&gt; の様に順位が先、書式指定文字が後になります。

[TODO:[https://github.com/ziglang/zig/blob/master/lib/std/fmt.zig master/lib/std/fmt.zig]を観て書いています。参照すべき標準ライブラリのドキュメントを発見出来たら、見直し]
[TODO:表組み]

==== comptime ====
Zigでは、コンパイル時に式が既知かどうかという概念を重要視しています。

&lt;!--
const std = @import(&quot;std&quot;);
pub fn main() !void {
    const i = 0;
    const string = [_]i32{ 1, 2, 3, 4 };
    for (string) |character, index| {
        std.debug.print(&quot;character: {}, index: {}, :{s} \n&quot;, .{ character, index, @typeName(@TypeOf(character)) });
    }
    _ = i;
}
--&gt;

=== テスト ===
=== 変数 ===
=== 制御構造 ===
[TODO:Zig の制御構造は文ではなく式]
==== 分岐 ====
[TODO:ifとswitch]
==== 反復 ====
[TODO:whileとfor]
=== 関数 ===
=== エラー ===
=== 演算子 ===
==== 優先順位 ====
高
&lt;syntaxhighlight lang=text line&gt;
 x() x[] x.y x.* x.?
 a!b
 x{}
 !x -x -%x ~x &amp;x ?x
 * / % ** *% *| ||
 + - ++ +% -% +| -|
 &lt;&lt; &gt;&gt; &lt;&lt;|
 &amp; ^ | orelse catch
 == != &lt; &gt; &lt;= &gt;=
 and
 or
 = *= *%= *|= /= %= += +%= +|= -= -%= -|= &lt;&lt;= &lt;&lt;|= &gt;&gt;= &amp;= ^= |=
&lt;/syntaxhighlight&gt;
低

===  optional type ===
===  opaque ===
訳語未定
=== ブロック ===
[TODO:スコープとシャドーイング；deferはここ？]
=== キャスト ===
[TODO:Zig は強い型付け()； 型強制 (Type coercion) について]
=== アセンブリ言語との連携 ===
[TODO:所謂インラインアセンラ]
=== atomic ===
=== 非同期関数 ===
=== 組込み関数 ===
[TODO:組込み関数は、@で始まり、@TypeOfや@alignOfの他@sinや@memcpyも組込み関数]
=== メモリ管理 ===
=== キーワード一覧 ===
&lt;code&gt;align&lt;/code&gt;
&lt;code&gt;allowzero&lt;/code&gt;
&lt;code&gt;and&lt;/code&gt;
&lt;code&gt;anyframe&lt;/code&gt;
&lt;code&gt;anytype&lt;/code&gt;
&lt;code&gt;asm&lt;/code&gt;
&lt;code&gt;async&lt;/code&gt;
&lt;code&gt;await&lt;/code&gt;
&lt;code&gt;break&lt;/code&gt;
&lt;code&gt;catch&lt;/code&gt;
&lt;code&gt;comptime&lt;/code&gt;
&lt;code&gt;const&lt;/code&gt;
&lt;code&gt;continue&lt;/code&gt;
&lt;code&gt;defer&lt;/code&gt;
&lt;code&gt;else&lt;/code&gt;
&lt;code&gt;enum&lt;/code&gt;
&lt;code&gt;errdefer&lt;/code&gt;
&lt;code&gt;error&lt;/code&gt;
&lt;code&gt;export&lt;/code&gt;
&lt;code&gt;extern&lt;/code&gt;
&lt;code&gt;fn&lt;/code&gt;
&lt;code&gt;for&lt;/code&gt;
&lt;code&gt;if&lt;/code&gt;
&lt;code&gt;inline&lt;/code&gt;
&lt;code&gt;noalias&lt;/code&gt;
&lt;code&gt;nosuspend&lt;/code&gt;
&lt;code&gt;or&lt;/code&gt;
&lt;code&gt;orelse&lt;/code&gt;
&lt;code&gt;packed&lt;/code&gt;
&lt;code&gt;pub&lt;/code&gt;
&lt;code&gt;resume&lt;/code&gt;
&lt;code&gt;return&lt;/code&gt;
&lt;code&gt;linksection&lt;/code&gt;
&lt;code&gt;struct&lt;/code&gt;
&lt;code&gt;suspend&lt;/code&gt;
&lt;code&gt;switch&lt;/code&gt;
&lt;code&gt;test&lt;/code&gt;
&lt;code&gt;threadlocal&lt;/code&gt;
&lt;code&gt;try&lt;/code&gt;
&lt;code&gt;union&lt;/code&gt;
&lt;code&gt;unreachable&lt;/code&gt;
&lt;code&gt;usingnamespace&lt;/code&gt;
&lt;code&gt;var&lt;/code&gt;
&lt;code&gt;volatile&lt;/code&gt;
&lt;code&gt;while&lt;/code&gt;

== チートシート ==
[TODO:文法と型と頻用する標準ライブラリの関数と型のアンチョコ]

== リファレンス篇 ==

== 脚註 ==
&lt;references /&gt;

== 外部リンク ==
* [https://ziglang.org/ Home ⚡ Zig Programming Language] {{---}} 公式サイト
** [[https://ziglang.org/documentation/master/ Zig Language Reference]] {{---}} リファレンスマニュアル
* [https://github.com/ziglang/zig ziglang/zig: General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.] {{---}} 公式リポジトリ
* [https://zig-play.dev/ Zig Playground] {{---}} オンライン実行環境
** [https://github.com/gsquire/zig-play About An online Zig compiler inspired by Go and Rust] {{---}} リポジトリ

[[Category:zig|*]]
[[Category:プログラミング言語]]</text>
      <sha1>ads4hbhu724s2kaw9av3l1r9hu5rta6</sha1>
    </revision>
  </page>
  <page>
    <title>Crystal</title>
    <ns>0</ns>
    <id>35227</id>
    <revision>
      <id>205748</id>
      <parentid>205714</parentid>
      <timestamp>2022-07-24T02:17:55Z</timestamp>
      <contributor>
        <username>Ef3</username>
        <id>694</id>
      </contributor>
      <comment>/* superclass と subclasses */  Crystal には、RubyのClassにあるメソッド superclass と subclasses がないので、マクロで実装しました。</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="59919" xml:space="preserve">{{Pathnav|メインページ|工学|情報技術|プログラミング|frame=1}}
{{Wikipedia|Crystal (プログラミング言語)}}
本書は、[[w:Crystal (プログラミング言語)|Crystal]]のチュートリアルです。
'''Crystal'''は、Ary Borenszweig、Juan Wajnerman、Brian Cardiffと300人以上の貢献者によって設計・開発された[汎用オブジェクト指向プログラミング言語です&lt;ref&gt;{{Cite web
|url=https://github.com/crystal-lang/crystal/graphs/contributors
|title=Contributors
|accessdate=2022-07-18
|website=github.com
}}&lt;/ref&gt;。[[Ruby]] にヒントを得た構文を持ち、静的型チェックを備えた [[コンパイル型言語]]ですが、変数やメソッドの引数の型は一般には不要です。型は高度なグローバル[[型推論]]アルゴリズムによって解決される。&lt;ref&gt;{{Cite web
|url=http://crystal-lang.org/2013/09/23/type-inference-part-1.html
|title=Type inference part 1
|last=Brian J.
|first=Cardiff
|date=2013-09-09
|accessdate=2022-07-18
|website=crystal-lang.org
}}&lt;/ref&gt;Crystalは[[Apache License]]バージョン2.0のもと、FOSSとしてリリースされています。

__TOC__

== Hello, World! ==
他の多くのチュートリアルがそうであるように、
私たちもまずはCrystalの世界にあいさつすることから始めましょう。

Rubyとの比較も兼ねて、[[Ruby#Hello, World!]]をそのまま実行してみます。

''hello.cr''というファイルを作り、次のように書いて保存して下さい&lt;ref&gt;Crystalのソースファイルの拡張子は''.cr'' です&lt;/ref&gt;。

;hello.cr:&lt;syntaxhighlight lang=Crystal&gt;
puts 'Hello, World!'
&lt;/syntaxhighlight&gt;

;コマンドラインでの操作:&lt;syntaxhighlight lang=&quot;console&quot;&gt;
% cat hello.cr 
puts 'Hello, World!'
% crystal hello.cr
In hello.cr:1:6

 1 | puts 'Hello, World!'
          ^
Error: unterminated char literal, use double quotes for strings

% sed -i -e &quot;s@'@Q@g&quot; -e 's@Q@&quot;@g' hello.cr
% cat hello.cr 
puts &quot;Hello, World!&quot;
% crystal hello.cr
Hello, World!
&lt;/syntaxhighlight&gt;
この１行のスクリプトは、メソッド&lt;code&gt;puts&lt;/code&gt; に文字リテラル&lt;code&gt;&quot;Hello, World!&quot;&lt;/code&gt;を渡し呼出しています。

このプログラムは、[[Ruby#Hello, World!]]と同じですが、Crystalでは文字列リテラルは &lt;code&gt;&quot;…&quot;&lt;/code&gt; で囲うのでそれだけ変更しました。

[TODO: コマンドラインツール crystal の解説。 crystal ファイル名 は crystal run ファイル名 の短縮形で、インタープリタ的な実行…ではなく、内部ビルドツールでコンパイル・実行を行う]

== Ruby との違い ==
Crystalは、Rubyに触発された構文を持つものの、Rubyとの互換性をゴールに定めては'''いません'''。
このため、細部を見ると仕様に差異があり、Rubyのソースコードをcrystalに掛けるても前節の 'Hello World' の様にコンパイルに失敗することがあります。
また、コンパイルできても実行結果に違いが出ることがあります。

ここでは、Ruby との違いについて実際のコードと双方の結果を比較することで、差異についての理解を深めていきます。

=== 整数型の特性 ===
;大きな整数:&lt;syntaxhighlight lang=Crystal&gt;
p 2 ** 999
p (2 ** 999).class
&lt;/syntaxhighlight&gt;
;rubyの実行結果:&lt;syntaxhighlight lang=&quot;console&quot;&gt;
5357543035931336604742125245300009052807024058527668037218751941851755255624680612465991894078479290637973364587765734125935726428461570217992288787349287401967283887412115492710537302531185570938977091076523237491790970633699383779582771973038531457285598238843271083830214915826312193418602834034688
Integer
&lt;/syntaxhighlight&gt;
;crystalの実行結果:&lt;syntaxhighlight lang=&quot;console&quot;&gt;
Unhandled exception: Arithmetic overflow (OverflowError)
  from /usr/local/share/crystal/share/crystal/src/int.cr:295:9 in '**'
  from pow.cr:1:1 in '__crystal_main'
  from /usr/local/share/crystal/share/crystal/src/crystal/main.cr:115:5 in 'main_user_code'
  from /usr/local/share/crystal/share/crystal/src/crystal/main.cr:101:7 in 'main'
  from /usr/local/share/crystal/share/crystal/src/crystal/main.cr:127:3 in 'main'
  from /usr/local/lib64/libc.so.6 in '__libc_start_main'
  from /usr/local/.cache/crystal/crystal-run-pow.tmp in '_start'
  from ???
&lt;/syntaxhighlight&gt;
: Ruby の整数は、桁あふれが起こると自動的に多倍長整数に型変換されるので、継ぎ目なしに大きな数を扱うアルゴルズムが使えます。
: Crystal の整数は、固定長です（大きさについては[[#リテラルと型|後述]]）。なので大きな答えになる式を評価すると桁あふれが生じます。桁あふれが生じますが、C言語のように寡黙に処理を続けるのではなく、実行時に例外（OverflowError）が上がるので、例外を捕捉し然るべき処置を施すことが可能です。

==== BigInt ====
&lt;code&gt;big&lt;/code&gt; を &lt;code&gt;require&lt;/code&gt; すると &lt;code&gt;BigInt&lt;/code&gt; が使えるようになります。
;BigInt:&lt;syntaxhighlight lang=Crystal&gt;
require &quot;big&quot;

p BigInt.new(2) ** 999
p (BigInt.new(2) ** 999).class
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;console&quot;&gt;
5357543035931336604742125245300009052807024058527668037218751941851755255624680612465991894078479290637973364587765734125935726428461570217992288787349287401967283887412115492710537302531185570938977091076523237491790970633699383779582771973038531457285598238843271083830214915826312193418602834034688
BigInt
&lt;/syntaxhighlight&gt;
: BigIntはプリミティブではなので、リテラル表現はありません。また、
::&lt;syntaxhighlight lang=Crystal&gt;
n : BigInt = 2
&lt;/syntaxhighlight&gt;
::&lt;syntaxhighlight lang=console&gt;
Error: type must be BigInt, not Int32
&lt;/syntaxhighlight&gt;
:: のように型アノテーションすることも出来ません。

=== リテラルと型 ===
;様々なリテラルと型:&lt;syntaxhighlight lang=Crystal&gt;
[nil, false, true, 42, 2.73, 'Q', &quot;string&quot;, [1,2,3], {a:1, b:2}].each{|x|
  p [x, x.class]
}
&lt;/syntaxhighlight&gt;
;rubyの実行結果:&lt;syntaxhighlight lang=&quot;console&quot;&gt;
[nil, NilClass]
[false, FalseClass]
[true, TrueClass]
[42, Integer]
[2.73, Float]
[&quot;Q&quot;, String]
[&quot;string&quot;, String]
[[1, 2, 3], Array] 
[{:a=&gt;1, :b=&gt;2}, Hash]
&lt;/syntaxhighlight&gt;
;crystalの実行結果:&lt;syntaxhighlight lang=&quot;console&quot;&gt;
[nil, Nil]
[false, Bool]
[true, Bool]
[42, Int32]
[2.73, Float64]
['Q', Char]
[&quot;string&quot;, String]
[[1, 2, 3], Array(Int32)] 
[{a: 1, b: 2}, NamedTuple(a: Int32, b: Int32)]
&lt;/syntaxhighlight&gt;
: Crystal の整数は Int32、浮動小数点数は Float64 です。

;サイズを指定した数リテラル:&lt;syntaxhighlight lang=Crystal&gt;
[1_i64, 2_u32, 3_u64, 4_i32, 5_i16, 6_u8, 7_i128, 8_u128, 3.14_f32, 1.44_f64].each{|x|
  p [x, x.class]
}
&lt;/syntaxhighlight&gt;
;ruby:Rubyでは、サーフィックスの付いた数値リテラルは無効
;crystalの実行結果:&lt;syntaxhighlight lang=&quot;console&quot;&gt;
[1, Int64]
[2, UInt32]
[3, UInt64]
[4, Int32]
[5, Int16]
[6, UInt8]
[7, Int128]
[8, UInt128]
[3.14, Float32] 
[1.44, Float64]
&lt;/syntaxhighlight&gt;
: Crystal では、数値リテラルに _ で始まるサーフィックスを付け { i:符号付き整数, u:符号なし整数, f:浮動小数点数 } と { 8,16,32,64,128 } のビット幅の組合せです&lt;ref&gt;[https://crystal-lang.org/reference/1.5/syntax_and_semantics/literals/ Literals]&lt;/ref&gt;。

=== for式がない ===
Crystal には、Ruby にはある for式がありません。
;Rubyのfor式の構文:&lt;syntaxhighlight lang=&quot;ruby&quot;&gt;
for 変数 in コレクション
  文
end
&lt;/syntaxhighlight&gt;
:コレクションは Range, Array, Hash など内部構造を持つオブジェクトです。
:for式は、最後に評価した値を返すので、for'''式'''です。

;for式のeachメソッドによる置換え:&lt;syntaxhighlight lang=&quot;ruby&quot;&gt;
for x in [ 2, 3, 5, 7, 11 ] do
  p x
end
# ↓
[ 2, 3, 5, 7, 11 ].each do | x |
  p x
end
&lt;/syntaxhighlight&gt;
: の様にコレクションの each メソッドで置換え可能なので、Rubyからの移植でも小規模な書換えで済みます&lt;ref&gt;[https://github.com/crystal-lang/crystal/issues/830 &quot;For&quot; Loop support #830]&lt;/ref&gt;（後述のマクロで実装できないかと思いましたが、いまのところ無理のようです）。
また loop 式もありませんが while true;  … end で間に合います。Ruby では while 式の条件の次に do が置けますが、Crystal では置けません。

=== eval()がない ===
Crystal には eval() はありません。
Crystalはコンパイル型言語ですので、無理もないことです。
もし、Crystal で eval() を実装しようとすると、Common Lisp の様にインタープリターを丸ごとランタイムに含む必要があります。
これはリーズナブルな選択ではありません。
Crystal では、eval() が必要なケースに（限定的ですが）マクロを使うことが出来る可能性があります。

=== マクロ ===
Crystalには、Rubyにはないマクロがあります&lt;ref&gt;[https://crystal-lang.org/reference/1.5/syntax_and_semantics/macros/ Macros - Crystal]&lt;/ref&gt;。Rubyは実行時にすべてのオブジェクトにアクセス出来て、メソッド生やし放題なのでマクロは必要ありませんが、Crystalはコンパイル時に型やメソッドを確定する必要があり、特にメソッドジェネレターとしてのマクロにニーズがあります。また、テンプレート言語的なマクロなので、環境変数による条件分岐や、コンテナを渡し繰返し処理する構文もあります（面白いことにマクロには for 文があり、反対にマクロの中では、eachメソッドは使えません）。マクロには &lt;code&gt;&lt;nowiki&gt;{{&lt;/nowiki&gt;attr.id}}&lt;/code&gt; の様にASTへのアクセス手順が用意されており、半ば言語を拡張するようなアプローチを取ることも出来ます。

[TODO:ASTについての解説；コラム向き？]

;マクロを使ったattr_accessorのイミュレーション:&lt;syntaxhighlight lang=crystal&gt;
class Point
  def initialize(@x : Int32, @y : Int32)
  end

  # macro定義
  macro attr_accessor(*attrs)
    {% for attr in attrs %}
      def {{attr.id}}() @{{attr.id}} end
      def {{attr.id}}=(var) @{{attr.id}} = var end
    {% end %}
  end

  # macro呼出し
  attr_accessor :x, :y
end

pt = Point.new(20, 30)
p [pt.x, pt.y]
t = pt.x
pt.x = pt.y
pt.y = t
p [pt.x, pt.y]
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
[20, 30]
[30, 20]
&lt;/syntaxhighlight&gt;
: Ruby には、attr_accessor と言う「クラスのメンバーのアクセサーを自動生成するメソッド」がありますが、Crystalにはないようなので、マクロで実装しました。
:: attr_accessor :name からは
::&lt;syntaxhighlight lang=ruby&gt;
def name()     @name end
def name=(val) @name = val end
&lt;/syntaxhighlight&gt;相当のコードが生成されます。
[TODO:マクロの機能と構文の説明 *の付いた引数、 &lt;nowiki&gt;{{&lt;/nowiki&gt;引数}}、{% … %} 構文]

==== マクロ p! ====
メソッド p は、与えられた「式」の inspaect() の返す値を puts しますが、マクロ p! は、それに先んじて（評価前の）「式」を表示します&lt;ref&gt;[https://crystal-lang.org/api/1.5.0/Crystal/Macros.html#p%21%28%2Aexpressions%29%3ANop-instance-method def p!(*expressions) : Nop]&lt;/ref&gt;。
;p!の例:&lt;syntaxhighlight lang=crystal&gt;
x, y = true, false

p! x,y,x &amp;&amp; y, x || y, x ^ y, !x, x != y, x == y

ary = [ 1, 2, 3 ]

p! ary

p! ary.map(&amp;. &lt;&lt; 1)

p! ary.map(&amp;.to_f)
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
x      # =&gt; true
y      # =&gt; false
x &amp;&amp; y # =&gt; false
x || y # =&gt; true
x ^ y  # =&gt; true
!x     # =&gt; false
x != y # =&gt; true
x == y # =&gt; false
ary # =&gt; [1, 2, 3]
ary.map(&amp;.&lt;&lt;(1)) # =&gt; [2, 4, 6]
ary.map(&amp;.to_f) # =&gt; [1.0, 2.0, 3.0]
&lt;/syntaxhighlight&gt;

===== 入れ子のp! =====
マクロ p! は入れ子に出来ます。また、一旦ASTに変換してから再度ソースコードに変換するので、等価な別の構文に変換されることがあります。
;入れ子のp!:&lt;syntaxhighlight lang=crystal&gt;
p! (
  100.times{|i|
    p! i
    break i if i &gt; 12
  }
)
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
(100.times do |i|
 p!(i)
 if i &gt; 12
   break i
 end
end) # =&gt; i
# =&gt; 0
i # =&gt; 1
i # =&gt; 2
i # =&gt; 3
i # =&gt; 4
i # =&gt; 5
i # =&gt; 6
i # =&gt; 7
i # =&gt; 8
i # =&gt; 9
i # =&gt; 10
i # =&gt; 11
i # =&gt; 12
i # =&gt; 13
13
&lt;/syntaxhighlight&gt;

=== クラス ===

==== シンプルなクラス ====
;シンプルなクラス:&lt;syntaxhighlight lang=crystal highlight=&quot;2&quot; line&gt;
class Hello
  def initialize(@name : String = &quot;World&quot;)
  end

  def greeting
    puts &quot;Hello #{@name}!&quot;
  end
end

hello = Hello.new()
hello.greeting

universe = Hello.new(&quot;Universe&quot;)
universe.greeting
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
Hello World!
Hello Universe!
&lt;/syntaxhighlight&gt;
:;初期化メソッド
:: &lt;syntaxhighlight lang=crystal line start=4&gt;
  def initialize(@name : String = &quot;World&quot;)
  end
&lt;/syntaxhighlight&gt;
::Rubyであれば
:: &lt;syntaxhighlight lang=ruby line start=4&gt;
  def initialize(name = &quot;World&quot;)
    @name = name
  end
&lt;/syntaxhighlight&gt;
::とするところですが、Crystalでは、型アノテーション &lt;code&gt; : String&lt;/code&gt; を使い、引数の型を限定しました。
::また、（@ 付きの）アトリビュート名を仮引数にすると、そのままアトリビュート（a.k.a. インスタンス変数）に仮引数が代入されます。
::これは、C++のコンストラクターのメンバー初期化リストと同じアイディアですが、Crystalではインスタンス変数に @ が前置されるので、仮引数に @ が出現すればインスタンス変数の初期値だと自明で、聡明な選択です。


==== 都市間の大圏距離 ====
[[Ruby#ユーザー定義クラス]]の都市間の大圏距離を求めるメソッドを追加した例を、Crystalに移植しました。

;都市間の大圏距離:&lt;syntaxhighlight lang=crystal highlight=”2,7,12” line&gt;
class GeoCoord
  getter :longitude, :latitude

  def initialize(@longitude : Float64, @latitude : Float64)
  end

  def to_s(io)
    ew, ns = &quot;東経&quot;, &quot;北緯&quot;
    long, lat = @longitude, @latitude
    ew, long = &quot;西経&quot;, -long if long &lt; 0.0
    ns, lat = &quot;南緯&quot;, -lat if lat &lt; 0.0
    io &lt;&lt; &quot;(#{ew}: #{long}, #{ns}: #{lat})&quot;
  end # https://github.com/crystal-lang/crystal/issues/259
  def distance(other)
    i, r = Math::PI / 180, 6371.008
    Math.acos(Math.sin(@latitude*i) * Math.sin(other.latitude * i) +
              Math.cos(@latitude*i) * Math.cos(other.latitude * i) * Math.cos(@longitude * i - other.longitude * i)) * r
  end
end

# メソッドの先頭を大文字に出来ないのでクラス名のメソッドは作ることが出来ない
# def GeoCoord(lng : Float64, lat : Float64)
#  GeoCoord.new(lng, lat)
# end

Sites = {
  &quot;東京駅&quot;:         GeoCoord.new(139.7673068, 35.6809591),
  &quot;シドニー・オペラハウス&quot;: GeoCoord.new(151.215278, -33.856778),
  &quot;グリニッジ天文台&quot;:    GeoCoord.new(-0.0014, 51.4778),
}

Sites.each { |name, gc|
  puts &quot;#{name}: #{gc}&quot;
}

puts &quot;&quot;

keys, len = Sites.keys, Sites.size
keys.each_with_index { |x, i|
  y = keys[(i + 1) % len]
  puts &quot;#{x} ⇔ #{y}: #{Sites[x].distance(Sites[y])} [km]&quot;
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
東京駅: (東経: 139.7673068, 北緯: 35.6809591)
シドニー・オペラハウス: (東経: 151.215278, 南緯: 33.856778)
グリニッジ天文台: (西経: 0.0014, 北緯: 51.4778)

東京駅 ⇔ シドニー・オペラハウス: 7823.269299386704 [km]
シドニー・オペラハウス ⇔ グリニッジ天文台: 16987.2708377249 [km]
グリニッジ天文台 ⇔ 東京駅: 9560.546566490015 [km]
&lt;/syntaxhighlight&gt;
:Crystal には、&lt;syntaxhighlight lang=ruby inline&gt;  attr_accessor &lt;/syntaxhighlight&gt; はありませんが、標準ライブラリーのマクロに &lt;syntaxhighlight lang=crystal inline&gt;  getter &lt;/syntaxhighlight&gt;があるので
:: &lt;syntaxhighlight lang=crystal line start=2&gt;
  getter :longitude, :latitude
&lt;/syntaxhighlight&gt;
::としました。
::将来、&lt;syntaxhighlight lang=ruby inline&gt;  attr_accessor &lt;/syntaxhighlight&gt; が実装される可能性はありますが、姉妹品の&lt;syntaxhighlight lang=crystal inline&gt;  setter &lt;/syntaxhighlight&gt;　との併用が下位互換性を考えると確実です。
: to_s は、Ruby ならば
:: &lt;syntaxhighlight lang=ruby line start=7&gt;
  def to_s()
&lt;/syntaxhighlight&gt;
:: &lt;syntaxhighlight lang=ruby line start=12&gt;
    &quot;(#{ew}: #{long}, #{ns}: #{lat})&quot;
&lt;/syntaxhighlight&gt;
:: ですが、Crystalでは追加の引数 &lt;var&gt;io&lt;/var&gt; が必要で
:: &lt;syntaxhighlight lang=ruby line start=7&gt;
  def to_s(io)
&lt;/syntaxhighlight&gt;
:: &lt;syntaxhighlight lang=ruby line start=12&gt;
    io &lt;&lt; &quot;(#{ew}: #{long}, #{ns}: #{lat})&quot;
&lt;/syntaxhighlight&gt;
: Ruby にはクラス名と同じ名前のメソッドで .new を呼出す文化があるのですが、Crystalはメソッドの先頭を大文字に出来ないので、これは見送りました。

==== 包含と継承 ====
[[JavaScript/クラス#包含と継承]]を、Rubyに移植した[[Ruby#包含と継承]]を、Crystalに移植しました。

;包含と継承の例:&lt;syntaxhighlight lang=crystal line&gt;
class Point
  def initialize(@x = 0, @y = 0)
  end

  def inspect(io)
    io &lt;&lt; &quot;x:#{@x}, y:#{@y}&quot;
  end

  def move(dx = 0, dy = 0)
    @x, @y = @x + dx, @y + dy
    self
  end
end

class Shape
  def initialize(x = 0, y = 0)
    @location = Point.new(x, y)
  end

  def inspect(io)
    @location.inspect(io)
  end

  def move(x, y)
    @location.move(x, y)
    self
  end
end

class Rectangle &lt; Shape
  def initialize(x = 0, y = 0, @width = 0, @height = 0)
    super(x, y)
  end

  def inspect(io)
    super(io)
    io &lt;&lt; &quot;, width:#{@width}, height:#{@height}&quot;
  end
end

rct = Rectangle.new(12, 32, 100, 50)
p! rct,
  rct.is_a?(Rectangle),
  rct.is_a?(Shape),
  rct.is_a?(Point),
  rct.move(11, 21)
(END)&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
rct                  # =&gt; x:12, y:32, width:100, height:50 
rct.is_a?(Rectangle) # =&gt; true 
rct.is_a?(Shape)     # =&gt; true 
rct.is_a?(Point)     # =&gt; false 
rct.move(11, 21)     # =&gt; x:23, y:53, width:100, height:50 
&lt;/syntaxhighlight&gt;
;crystal tool hierarchy:&lt;syntaxhighlight lang=console&gt;
% crystal tool hierarchy inclusion-and-inheritance.cr -e Shape
- class Object (4 bytes)
  |
  +- class Reference (4 bytes)
     |
     +- class Shape (16 bytes)
        .   @location : Point (8 bytes)
        |
        +- class Rectangle (24 bytes)
               @width  : Int32 (4 bytes)
               @height : Int32 (4 bytes)
&lt;/syntaxhighlight&gt;
: crystal の tool hierarchy サブコマンドで、クラスの継承関係がわかります。

===== superclass と subclasses =====
Crystal には、RubyのClassにあるメソッド superclass と subclasses がないので、マクロで実装しました。
;superclass と subclasses:&lt;syntaxhighlight lang=crystal line&gt;
class Class
  def self.superclass
    {{ @type.superclass }}
  end

  def self.subclasses : Array(self.class)
    {{ @type.subclasses }}.map(&amp;.as(self.class))
  end

  def self.all_subclasses : Array(self.class)
    {% begin %}
      [{{ @type.all_subclasses.join(&quot;,&quot;).id }}] of self.class
    {% end %}
  end
end
 
class A end
class AA &lt; A end
class AAA &lt; AA end
class AAB &lt; AA end
class AB &lt; A end

p! A,
  A.subclasses,
  A.all_subclasses,
  AAA.superclass,
  A.superclass
 
c = AAA
while !c.is_a? Nil
  p! c.superclass
  c = c.superclass
end&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
A                # =&gt; A 
A.subclasses     # =&gt; [AA, AB] 
A.all_subclasses # =&gt; [AA, AAA, AAB, AB] 
AAA.superclass   # =&gt; AA 
A.superclass     # =&gt; Reference 
c.superclass # =&gt; AA 
c.superclass # =&gt; A 
c.superclass # =&gt; Reference 
c.superclass # =&gt; Object 
c.superclass # =&gt; nil
&lt;/syntaxhighlight&gt;

==== 抽象クラス ====
[[Java/抽象クラス]]を、Crystalに移植しました。

;抽象クラスの宣言:&lt;syntaxhighlight lang=Java&gt;
abstract class クラス名
  #
end
&lt;/syntaxhighlight&gt;
: このクラス名は、 .new でインスタンス化出来ません。
:: Error: can't instantiate abstract class クラス名
: となります。
:インスタンス化することは出来ませんが、抽象クラスを別のクラスが継承する事は出来ます。
:また、抽象クラスを &lt;code&gt;super()&lt;/code&gt; を使うことでメソッドを呼び出せるので、抽象メソッドではないメソッド（具象メソッド）を持つことも、インスタンス変数も持つことも出来ます。
:'''抽象クラスの例'''では、Shapeのinitializeメソッドが抽象クラスの具象メソッドとなっています。
;抽象メソッドの宣言:&lt;syntaxhighlight lang=Java&gt;
  abstract def メソッド名
&lt;/syntaxhighlight&gt;
: 派生先のクラスで、「メソッド名」を定義(def)し忘れると
:: Error: abstract `def クラス名#メソッド名()` must be implemented by クラス名
: となります

;抽象クラスの例:&lt;syntaxhighlight lang=crystal line&gt;
abstract class Shape
  def initialize(@x = 0.0, @y = 0.0)
  end

  abstract def to_s(io)
  abstract def area
end

class Square &lt; Shape
  def initialize(x, y, @wh = 0.0)
    super(x, y)
  end

  def to_s(io)
    io &lt;&lt; &quot;Square(#{@x}, #{@y}, #{@wh})&quot;
  end

  def area
    @wh * @wh
  end
end

abstract class Shape
  def initialize(@x = 0.0, @y = 0.0)
  end

  abstract def to_s(io)
  abstract def area
end

class Square &lt; Shape
  def initialize(x, y, @wh = 0.0)
    super(x, y)
  end

  def to_s(io)
    io &lt;&lt; &quot;Square(#{@x}, #{@y}, #{@wh})&quot;
  end

  def area
    @wh * @wh
  end
end

class Recrangle &lt; Shape
  def initialize(x, y, @w = 0.0, @h = 0.0)
    super(x, y)
  end

  def to_s(io)
    io &lt;&lt; &quot;Rectanle(#{@x}, #{@y}, #{@w}, #{@h})&quot;
  end

  def area
    @w * @h
  end
end

class Circle &lt; Shape
  def initialize(x, y, @r = 0.0)
    super(x, y)
  end

  def to_s(io)
    io &lt;&lt; &quot;Circle(#{@x}, #{@y}, #{@r})&quot;
  end

  def area
    3.1425926536 * @r * @r
  end
end

shapes = [
  Square.new(5.0, 10.0, 15.0),
  Recrangle.new(13.0, 23.0, 20.0, 10.0),
  Circle.new(3.0, 2.0, 20.0),
] of Shape

shapes.each do |shape|
  puts(&quot;#{shape}: #{shape.area}&quot;)
end
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
Square(5.0, 10.0, 15.0): 225.0
Rectanle(13.0, 23.0, 20.0, 10.0): 200.0
Circle(3.0, 2.0, 20.0): 1257.03706144
&lt;/syntaxhighlight&gt;
;crystal tool hierarchy:&lt;syntaxhighlight lang=console&gt;
% crystal tool hierarchy abstract.cr -e Shape
- class Object (4 bytes)
  |
  +- class Reference (4 bytes)
     |
     +- class Shape (24 bytes)
        .   @x : Float64 (8 bytes)
        .   @y : Float64 (8 bytes)
        |
        +- class Circle (32 bytes)
        |      @r : Float64 (8 bytes)
        |
        +- class Recrangle (40 bytes)
        |      @w : Float64 (8 bytes)
        |      @h : Float64 (8 bytes)
        |
        +- class Square (32 bytes)
               @wh : Float64 (8 bytes)
&lt;/syntaxhighlight&gt;
: crystal の tool hierarchy サブコマンドで、クラスの継承関係がわかります。
: 「包含と継承の例」と比べると、ShapeとRectangleが同じ階層にあることがわかると思います。

[TODO:virtual class::いい例がない]

== キーワード ==
Crystalのキーワード( ''keywords'' ) は、以下の通り。

&lt;code&gt;abstract&lt;/code&gt; &lt;code&gt;alias&lt;/code&gt; &lt;code&gt;as&lt;/code&gt; &lt;code&gt;asm&lt;/code&gt; &lt;code&gt;begin&lt;/code&gt; &lt;code&gt;break&lt;/code&gt; &lt;code&gt;case&lt;/code&gt; &lt;code&gt;class&lt;/code&gt; &lt;code&gt;def&lt;/code&gt; &lt;code&gt;do&lt;/code&gt; &lt;code&gt;else&lt;/code&gt; &lt;code&gt;elsif&lt;/code&gt; &lt;code&gt;end&lt;/code&gt; &lt;code&gt;ensure&lt;/code&gt; &lt;code&gt;enum&lt;/code&gt; &lt;code&gt;extend&lt;/code&gt; &lt;code&gt;for&lt;/code&gt; &lt;code&gt;fun&lt;/code&gt; &lt;code&gt;if&lt;/code&gt; &lt;code&gt;include&lt;/code&gt; &lt;code&gt;instance_sizeof&lt;/code&gt; &lt;code&gt;lib&lt;/code&gt; &lt;code&gt;macro&lt;/code&gt; &lt;code&gt;module&lt;/code&gt; &lt;code&gt;next&lt;/code&gt; &lt;code&gt;of&lt;/code&gt; &lt;code&gt;out&lt;/code&gt; &lt;code&gt;pointerof&lt;/code&gt; &lt;code&gt;private&lt;/code&gt; &lt;code&gt;protected&lt;/code&gt; &lt;code&gt;rescue&lt;/code&gt; &lt;code&gt;return&lt;/code&gt; &lt;code&gt;require&lt;/code&gt; &lt;code&gt;select&lt;/code&gt; &lt;code&gt;sizeof&lt;/code&gt; &lt;code&gt;struct&lt;/code&gt; &lt;code&gt;super&lt;/code&gt; &lt;code&gt;then&lt;/code&gt; &lt;code&gt;type&lt;/code&gt; &lt;code&gt;typeof&lt;/code&gt; &lt;code&gt;uninitialized&lt;/code&gt; &lt;code&gt;union&lt;/code&gt; &lt;code&gt;unless&lt;/code&gt; &lt;code&gt;until&lt;/code&gt; &lt;code&gt;when&lt;/code&gt; &lt;code&gt;while&lt;/code&gt; &lt;code&gt;with&lt;/code&gt; &lt;code&gt;yield&lt;/code&gt;
&lt;!--
 &lt;code&gt;__DIR__&lt;/code&gt; &lt;code&gt;__END_LINE__&lt;/code&gt; &lt;code&gt;__FILE__&lt;/code&gt; &lt;code&gt;__LINE__&lt;/code&gt;
--&gt;

==  演算子 ==
Crystalは、1つ、2つ、または3つのオペランドを持つ数多くの演算子をサポートしています&lt;ref&gt;[https://crystal-lang.org/reference/1.5/syntax_and_semantics/operators.html Operators]access-date:2022-07-22&lt;/ref&gt;。

演算子式は、実際にはメソッド呼び出しとしてパースされます。例えば、&lt;code&gt;a + b&lt;/code&gt; は &lt;code&gt;a.+(b)&lt;/code&gt; と意味的に同じで、引数 b を持つ a のメソッド + を呼び出すことになります。

{| class=&quot;wikitable&quot;
|+ 演算子の優先度
!種類
!演算子
|-
|インデックス アクセサー
|&lt;code&gt;[]&lt;/code&gt;, &lt;code&gt;[]?&lt;/code&gt;
|-
|単項
|&lt;code&gt;+&lt;/code&gt;, &lt;code&gt;&amp;+&lt;/code&gt;, &lt;code&gt;-&lt;/code&gt;, &lt;code&gt;&amp;-&lt;/code&gt;, &lt;code&gt;!&lt;/code&gt;, &lt;code&gt;~&lt;/code&gt;
|-
|指数
|&lt;code&gt;**&lt;/code&gt;, &lt;code&gt;&amp;**&lt;/code&gt;
|-
|乗除
|&lt;code&gt;*&lt;/code&gt;, &lt;code&gt;&amp;*&lt;/code&gt;, &lt;code&gt;/&lt;/code&gt;, &lt;code&gt;//&lt;/code&gt;, &lt;code&gt;%&lt;/code&gt;
|-
|加減
|&lt;code&gt;+&lt;/code&gt;, &lt;code&gt;&amp;+&lt;/code&gt;, &lt;code&gt;-&lt;/code&gt;, &lt;code&gt;&amp;-&lt;/code&gt;
|-
|シフト
|&lt;code&gt;&lt;&lt;&lt;/code&gt;, &lt;code&gt;&gt;&gt;&lt;/code&gt;
|-
|ビット間 AND
|&lt;code&gt;&amp;&lt;/code&gt;
|-
|ビット間 OR/XOR
|&lt;code&gt;&lt;nowiki&gt;|&lt;/nowiki&gt;&lt;/code&gt;,&lt;code&gt;^&lt;/code&gt;
|-
|等値
|&lt;code&gt;==&lt;/code&gt;, &lt;code&gt;!=&lt;/code&gt;, &lt;code&gt;=~&lt;/code&gt;, &lt;code&gt;!~&lt;/code&gt;, &lt;code&gt;===&lt;/code&gt;
|-
|比較
|&lt;code&gt;&lt;&lt;/code&gt;, &lt;code&gt;&lt;=&lt;/code&gt;, &lt;code&gt;&gt;&lt;/code&gt;, &lt;code&gt;&gt;=&lt;/code&gt;, &lt;code&gt;&lt;=&gt;&lt;/code&gt;
|-
|論理 AND
|&lt;code&gt;&amp;&amp;&lt;/code&gt;
|-
|論理 OR
|&lt;code&gt;&lt;nowiki&gt;||&lt;/nowiki&gt;&lt;/code&gt;
|-
|Range
|&lt;code&gt;..&lt;/code&gt;, &lt;code&gt;...&lt;/code&gt;
|-
|条件
|&lt;code&gt;?:&lt;/code&gt;
|-
|代入
|&lt;code&gt;=&lt;/code&gt;, &lt;code&gt;[]=&lt;/code&gt;, &lt;code&gt;+=&lt;/code&gt;, &lt;code&gt;&amp;+=&lt;/code&gt;, &lt;code&gt;-=&lt;/code&gt;, &lt;code&gt;&amp;-=&lt;/code&gt;, &lt;code&gt;*=&lt;/code&gt;, &lt;code&gt;&amp;*=&lt;/code&gt;, &lt;code&gt;/=&lt;/code&gt;, &lt;code&gt;//=&lt;/code&gt;, &lt;code&gt;%=&lt;/code&gt;, &lt;code&gt;&lt;nowiki&gt;|=&lt;/nowiki&gt;&lt;/code&gt;, &lt;code&gt;&amp;=&lt;/code&gt;,&lt;code&gt;^=&lt;/code&gt;,&lt;code&gt;**=&lt;/code&gt;,&lt;code&gt;&lt;&lt;=&lt;/code&gt;,&lt;code&gt;&gt;&gt;=&lt;/code&gt;, &lt;code&gt;&lt;nowiki&gt;||=&lt;/nowiki&gt;&lt;/code&gt;, &lt;code&gt;&amp;&amp;=&lt;/code&gt;
|-
|スプラット
|&lt;code&gt;*&lt;/code&gt;, &lt;code&gt;**&lt;/code&gt;
|}

== 制御構造 ==
'''[[w:制御構造|制御構造]]'''（せいぎょこうぞう、''control flow''）とは、「順次」「分岐」「反復」という基本的な処理のことを言います。

{{コラム|Crystalの真理値|2=
制御構造は「条件式」が真であるか偽であるかによって分岐や反復の振る舞いが変わります。
では「条件式」が真・偽はどの様に決まるのでしょう？

Crystalでは &lt;code&gt;false&lt;/code&gt; あるいは &lt;code&gt;nil&lt;/code&gt; であると偽、それ以外が真です。

なので &lt;code&gt;0&lt;/code&gt; も &lt;code&gt;[]&lt;/code&gt;（空のArray） も &lt;code&gt;{}&lt;/code&gt;（空のNamedTuple）も真です。
}}
=== 条件分岐 ===
Crystalの条件分岐には、[[#if|if]], [[#until|until]] と [[#case|case]]の3つの構文があります。

==== if ====
'''[[w:if|if]]'''は条件式によって実行・否を切り替える構造構文で、評価した式の値を返すので条件演算子でもあります。

;ifの例:&lt;syntaxhighlight lang=crystal line&gt;
a = 0.0 / 0.0

if a &lt; 0
    puts &quot;minus&quot;
elsif a &gt; 0
    puts &quot;plus&quot;
elsif a == 0
    puts &quot;zero&quot;
else
    puts a
end

p! (
    if a &lt; 0
        &quot;minus&quot;
    elsif a &gt; 0
        &quot;plus&quot;
    elsif a == 0
        &quot;zero&quot;
    else
        a
    end
)
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
NaN 
(if a &lt; 0 
 &quot;minus&quot; 
else 
 if a &gt; 0 
   &quot;plus&quot; 
 else 
   if a == 0 
     &quot;zero&quot; 
   else 
     a 
   end 
 end 
end) # =&gt; NaN
&lt;/syntaxhighlight&gt;
:; elsif節:ifは、オプショナルな elsif 節を設け、条件式が偽であった時に別の条件に合致した処理を実行させることが出来ます。
:; else節:ifは、オプショナルな else 節を設け、条件式が偽であった時に処理を実行させることが出来ます。
: ifは値を返すので、メソッドの実引数に使うことが出来ますし、代入演算の右辺にも使えます。

==== 後置のif ====
Crystalには、RubyやPerlのような後置のifがあります。

;後置のifの例:&lt;syntaxhighlight lang=crystal&gt;
n = 0

puts &quot;nは0&quot; if n == 0
puts &quot;nは1&quot; if n == 1
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
nは0
&lt;/syntaxhighlight&gt;

==== unless====
'''unless'''（アンレス）は条件式によって実行・否を切り替える構造構文ですが、ifとは条件式に対する挙動が逆です。

;unless文の例:&lt;syntaxhighlight lang=crystal line&gt;
a = 0.0 / 0.0

unless a == 0
    puts &quot;Non-zero&quot;
else
    puts a
end
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
Non-zero
&lt;/syntaxhighlight&gt;
:; else節 : unless文は、オプショナルな else 節を設け、条件式が真であった時に処理を実行させることが出来ます。
::また、unless文は elsif 節は持てません。

==== 後置のunless ====
Crystalには、RubyやPerlのような後置のunlessがあります。

;後置のunlessの例:&lt;syntaxhighlight lang=crystal&gt;
n = 0

puts &quot;nは0&quot; unless n == 0
puts &quot;nは1&quot; unless n == 1
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
nは1ではない
&lt;/syntaxhighlight&gt;

==== case ====
caseは、複数の条件式によって処理を降る分ける用途の為に用意されています。

;caseの例:&lt;syntaxhighlight lang=crystal line&gt;
n = 2

case n
when 1
    puts &quot;one&quot;
when 2
    puts &quot;two&quot;
when 3
    puts &quot;three&quot;
else
    puts &quot;other&quot;
end

p! (
case n
when 1
    &quot;one&quot;
when 2
    &quot;two&quot;
when 3
    &quot;three&quot;
else
    &quot;other&quot;
end
)
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
two 
(case n 
when 1 
 &quot;one&quot; 
when 2 
 &quot;two&quot; 
when 3 
 &quot;three&quot; 
else 
 &quot;other&quot; 
end) # =&gt; &quot;two&quot;&lt;/syntaxhighlight&gt;
:C言語系のswitch文に慣れた人はbreakがないことに気がつくと思います。Crystalのcaseはfall throughしませんし、fall throughさせる方法もありません。

===== when節が定数でなく式を受付けます =====
[[#if|if]]を使ったコードをcaseに書き換えてみましょう。

;case の式の省略:&lt;syntaxhighlight lang=crystal line&gt;
a = 0.0 / 0.0
 
case
when a &lt; 0
  puts &quot;minus&quot;
when a &gt; 0
  puts &quot;plus&quot;
when a == 0
  puts &quot;zero&quot;
else
  puts a
end
 
p! (
case true
when a &lt; 0
  &quot;minus&quot;
when a &gt; 0
  &quot;plus&quot;
when a == 0
  &quot;zero&quot;
else
  a
end
)
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
NaN 
(case true 
when a &lt; 0 
 &quot;minus&quot; 
when a &gt; 0 
 &quot;plus&quot; 
when a == 0 
 &quot;zero&quot; 
else 
 a 
end) # =&gt; NaN
&lt;/syntaxhighlight&gt;
このコードは when 節の式の値とcaseの式を &lt;code&gt;===&lt;/code&gt; で比較し、最初に一致した when に対応する式が実行される事を利用しています。

===== 型による分岐 =====
when 節が式ではなく型であった場合、caseの式を &lt;code&gt;is_a?&lt;/code&gt; で評価し、最初に一致した when に対応する式が実行されます。

;型による分岐:&lt;syntaxhighlight lang=crystal line&gt;
p! 0.class,
	0.is_a?(Object),
	0.is_a?(Int32),
	0.is_a?(Number),
	0.is_a?(String)
 
case 0
when String
    puts &quot;String&quot;
when Number
    puts &quot;Number&quot;
when Int32
    puts &quot;Int32&quot;
when Object
    puts &quot;Object&quot;
else
    puts &quot;Unknown&quot;
end
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
0.class         # =&gt; Int32 
0.is_a?(Object) # =&gt; true 
0.is_a?(Int32)  # =&gt; true 
0.is_a?(Number) # =&gt; true 
0.is_a?(String) # =&gt; false 
Number
&lt;/syntaxhighlight&gt;
暗黙のオブジェクト構文を使うと
:&lt;syntaxhighlight lang=crystal line&gt;
case 0
when .is_a?(String)
    puts &quot;String&quot;
when .is_a?(Number)
    puts &quot;Number&quot;
when .is_a(Int32)
    puts &quot;Int32&quot;
when .is_a(Object)
    puts &quot;Object&quot;
else
    puts &quot;Unknown&quot;
end
&lt;/syntaxhighlight&gt;
:と書くことが出来ます。
:: メソッドは、.is_a? に限定しないので、 .odd? .even? .include? など Bool を返すメソッドなら何でも使えます。
when に対応する式は、1つのことが珍しくないので、その場合は省略可能な then を補うと、１行で書けます。
:&lt;syntaxhighlight lang=crystal line&gt;
case 0
when String then puts &quot;String&quot;
when Number then puts &quot;Number&quot;
when Int32  then puts &quot;Int32&quot;
when Object then puts &quot;Object&quot;
else             puts &quot;Unknown&quot;
end
&lt;/syntaxhighlight&gt;

[TODO:タプルとダミー識別子 _ ]

===== 網羅性の検査 =====
when の代わりに in を使用すると、exhaustive case 式が作成されます。exhaustive case では、必要な in 条件を省略するとコンパイル時にエラーとなります。排他的論理和では、when 節と else 節を含むことはできません。

コンパイラは、以下の in 条件をサポートしています。
:&lt;syntaxhighlight lang=crystal line&gt;
case 0
when String then puts &quot;String&quot;
when Number then puts &quot;Number&quot;
when Int32  then puts &quot;Int32&quot;
when Object then puts &quot;Object&quot;
else             puts &quot;Unknown&quot;
end
&lt;/syntaxhighlight&gt;

caseの式がユニオンの場合、各要素型を条件として使用することができる。
;組合型チェック:&lt;syntaxhighlight lang=crystal line&gt;
var : ( Bool | Int32 | Float64 )?
 
var = 3.14
 
p! (
case var
in Bool    then var ? 1 : 0
in Int32   then var
in Float64 then var.to_i
end
)
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
(case var 
in Bool 
 var ? 1 : 0 
in Int32 
 var 
in Float64 
 var.to_i 
end) # =&gt; 3
&lt;/syntaxhighlight&gt;

[TODO:case in は enum にも使える]

[TODO:短絡評価 &amp;&amp; || ]

=== 繰返し ===
Crystalには、他のプログラミング言語のような[[#繰返し構文|繰返し構文]]と、[[#イテレーターメソッド|イテレーターメソッド]]があります。

==== 繰返し構文 ====
Crystalの繰返し構文には、while と untilの2つがあります&lt;ref&gt;for も do-while も loop もありません。&lt;/ref&gt;。

===== while =====
while（ホワイル）は条件が'''真'''である間、式を実行しつづけます。
;構文:&lt;syntaxhighlight lang=crystal&gt;
while 条件式
    式１
    式２
      ：
    式ｎ
end
&lt;/syntaxhighlight&gt;
: Rubyと違い、条件式の後ろに &lt;code&gt;do&lt;/code&gt; をつけることは出来ません。

;while文のコード例:&lt;syntaxhighlight lang=crystal line&gt;
i = 0
p! (
while i &lt; 10
    p! i
    i += 1
    break i if i &gt; 5
end
)
&lt;/syntaxhighlight&gt;
: ２行目の &lt;code&gt;i &lt; 5&lt;/code&gt;が真の間、次の２行を繰返します。
: ４行目の &lt;code&gt;i += 1&lt;/code&gt; は &lt;code&gt;i = i + 1&lt;/code&gt; の構文糖
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
(while i &lt; 10 
 p!(i) 
 i = i + 1 
 if i &gt; 5 
   break i 
  end 
end)# =&gt; 
i # =&gt; 0 
i # =&gt; 1 
i # =&gt; 2 
i # =&gt; 3 
i # =&gt; 4 
i # =&gt; 5 
6
&lt;/syntaxhighlight&gt;

===== until =====
until（アンティル）は条件が'''偽'''である間、式を実行しつづけます。whileとは条件に対する挙動が逆です。
;構文:&lt;syntaxhighlight lang=crystal&gt;
until 条件式 [ do ]
    文１
    文２
      ：
    文ｎ
end
&lt;/syntaxhighlight&gt;
: &lt;code&gt;do&lt;/code&gt; は省略できます。

;untilのコード例:&lt;syntaxhighlight lang=crystal line&gt;
i = 0
until i == 3
    puts i
    i += 1
end
&lt;/syntaxhighlight&gt;
: ２行目の &lt;code&gt;i == 3&lt;/code&gt;が偽の間、次の２行を繰返します。
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
0
1
2
&lt;/syntaxhighlight&gt;

===== for =====
Crystalにはforがありませんが、コレクションのイテレーションメソッドを使うことで繰返しを簡素に実現出来ます。

==== Rangeオブジェクト ====
Rangeオブジェクトは、整数の区間を表し範囲演算子 &lt;code&gt;開始 ... 終了&lt;/code&gt; で生成します。

;コード:&lt;syntaxhighlight lang=crystal&gt;
rng = 1..3
puts rng.class
rng.each do | n |
  puts &quot;#{n}番&quot;;
end
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
Range(Int32, Int32) 
1番 
2番 
3番
&lt;/syntaxhighlight&gt;

==== Arrayオブジェクト ====
Arrayオブジェクトは、任意の Crystal オブジェクトを要素として持つことができます。
配列式&lt;code&gt;[要素1, 要素2, … 要素n]&lt;/code&gt; で生成します。

;コード:&lt;syntaxhighlight lang=crystal&gt;
animals = [&quot;ネコ&quot;, &quot;金魚&quot;, &quot;ハムスター&quot;]
 
puts animals.class
animals.each do | animal |
  puts &quot;動物 #{animal}&quot;
end
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
Array(String) 
動物 ネコ 
動物 金魚 
動物 ハムスター
&lt;/syntaxhighlight&gt;

==== NamedTupleオブジェクト ====
NamedTupleオブジェクトは、任意の Crystal オブジェクトをキーに、任意の Crystal オブジェクトを値に持つことができる連想配列です。
NamedTuple式&lt;code&gt;{キー1 =&gt; 値1, キー2 =&gt; 値2, キーn =&gt; 値n}&lt;/code&gt; で生成します。
また、キーが Symbol の場合
NamedTuple式&lt;code&gt;{キー1: 値1, キー2: 値2, キーn: 値n}&lt;/code&gt; で生成することが出来ます。

;コード:&lt;syntaxhighlight lang=crystal&gt;
animals = {cat: &quot;ネコ&quot;, gold_fish: &quot;金魚&quot;, hamster: &quot;ハムスター&quot;}
 
puts animals.class
 
animals.each do | en, animal |
  puts &quot;動物 #{en}: #{animal}&quot;
end
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
NamedTuple(cat: String, gold_fish: String, hamster: String)
動物 cat: ネコ
動物 gold_fish: 金魚
動物 hamster: ハムスター
&lt;/syntaxhighlight&gt;

このように、Crystalではforがなくてもコレクションのメソッドで同様の処理を実現できます。

===== loop =====
loop、ありません。
while true で代用します。

;loopの代用コード例:&lt;syntaxhighlight lang=crystal line&gt;
i = 1
while true
    puts &quot;0b%b&quot; % i
    i &lt;&lt;= 1
    break if i &gt; 2**8
end
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
0b1
0b10
0b100
0b1000
0b10000
0b100000
0b1000000
0b10000000 
0b100000000
&lt;/syntaxhighlight&gt;
:５行目の、&lt;code&gt;break if i &gt; 2**8&lt;/code&gt;でループを脱出するようにしています。この様に break や return あるいは例外が上がらないとループは永久に終わりません。
:このコードは、Crystalにはない do-while文を模倣する例にもなっています。

==== イテレーターメソッド ====
===== Integer#times =====
Integer#timesは与えられたブロックをオブジェクトの示す整数値回くりかえします。

:コード&lt;syntaxhighlight lang=crystal&gt;
3.times{ puts &quot;Hello, world!&quot; }
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
Hello, world!
Hello, world!
Hello, world!
&lt;/syntaxhighlight&gt;

;繰返したい処理が2行以上ある場合:&lt;syntaxhighlight lang=crystal&gt;
3.times {
  puts &quot;Hello&quot;
  puts &quot;World&quot;
  puts &quot;&quot;
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
Hello
World

Hello
World

Hello
World
&lt;/syntaxhighlight&gt;

;ループ変数を使た例:&lt;syntaxhighlight lang=crystal&gt;
3.times do |i|
  puts &quot;#{i}の倍は#{2 * i}&quot;
end
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
0の倍は0
1の倍は2
2の倍は4
&lt;/syntaxhighlight&gt;

;ブロックを伴わないtimesメソッド:&lt;syntaxhighlight lang=crystal&gt;
iter = 3.times
puts iter.class
p! iter.next
p! iter.next
p! iter.next
p! iter.next
p! iter.next
p! iter.next
# puts iter.next #  `next': StopIteration: iteration reached an end
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
Int::TimesIterator(Int32) 
iter.next # =&gt; 0 
iter.next # =&gt; 1 
iter.next # =&gt; 2 
iter.next # =&gt; #&lt;Iterator::Stop:0x7fb5bedd7fe0&gt; 
iter.next # =&gt; #&lt;Iterator::Stop:0x7fb5bedd7fe0&gt; 
iter.next # =&gt; #&lt;Iterator::Stop:0x7fb5bedd7fe0&gt;
&lt;/syntaxhighlight&gt;
: Integer#times にブロックを渡さないと、Int::TimesIterator([T])オブジェクトが返ります。
: Int::TimesIterator([T])オブジェクトは外部イテレーターと呼ばれnextメソッドで反復を行えます。

== メソッド ==
=== クラスのメソッド一覧 ===
Crystal には、Objectクラスにmethodsメソッドがないので、マクロで実装しました。

;RubyのObject#methods:&lt;syntaxhighlight lang=ruby&gt;
p Object.methods.sort,
  Integer.methods.sort,
  Float.methods.sort,
  Array.methods.sort,
  Range.methods.sort
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
[:!, :!=, :!~, :&lt;, :&lt;=, :&lt;=&gt;, :==, :===, :=~, :&gt;, :&gt;=, :__id__, :__send__, :alias_method, :allocate, :ancestors, :attr, :attr_accessor, :attr_reader, :attr_writer, :autoload, :autoload?, :class, :class_eval, :class_exec, :class_variable_defined?, :class_variable_get, :class_variable_set, :class_variables, :clone, :const_defined?, :const_get, :const_missing, :const_set, :const_source_location, :constants, :define_method, :define_singleton_method, :deprecate_constant, :display, :dup, :enum_for, :eql?, :equal?, :extend, :freeze, :frozen?, :hash, :include, :include?, :included_modules, :inspect, :instance_eval, :instance_exec, :instance_method, :instance_methods, :instance_of?, :instance_variable_defined?, :instance_variable_get, :instance_variable_set, :instance_variables, :is_a?, :itself, :kind_of?, :method, :method_defined?, :methods, :module_eval, :module_exec, :name, :new, :nil?, :object_id, :prepend, :private_class_method, :private_constant, :private_instance_methods, :private_method_defined?, :private_methods, :protected_instance_methods, :protected_method_defined?, :protected_methods, :public_class_method, :public_constant, :public_instance_method, :public_instance_methods, :public_method, :public_method_defined?, :public_methods, :public_send, :remove_class_variable, :remove_instance_variable, :remove_method, :respond_to?, :send, :singleton_class, :singleton_class?, :singleton_method, :singleton_methods, :subclasses, :superclass, :taint, :tainted?, :tap, :then, :to_enum, :to_s, :trust, :undef_method, :untaint, :untrust, :untrusted?, :yield_self]
[:!, :!=, :!~, :&lt;, :&lt;=, :&lt;=&gt;, :==, :===, :=~, :&gt;, :&gt;=, :__id__, :__send__, :alias_method, :allocate, :ancestors, :attr, :attr_accessor, :attr_reader, :attr_writer, :autoload, :autoload?, :class, :class_eval, :class_exec, :class_variable_defined?, :class_variable_get, :class_variable_set, :class_variables, :clone, :const_defined?, :const_get, :const_missing, :const_set, :const_source_location, :constants, :define_method, :define_singleton_method, :deprecate_constant, :display, :dup, :enum_for, :eql?, :equal?, :extend, :freeze, :frozen?, :hash, :include, :include?, :included_modules, :inspect, :instance_eval, :instance_exec, :instance_method, :instance_methods, :instance_of?, :instance_variable_defined?, :instance_variable_get, :instance_variable_set, :instance_variables, :is_a?, :itself, :kind_of?, :method, :method_defined?, :methods, :module_eval, :module_exec, :name, :nil?, :object_id, :prepend, :private_class_method, :private_constant, :private_instance_methods, :private_method_defined?, :private_methods, :protected_instance_methods, :protected_method_defined?, :protected_methods, :public_class_method, :public_constant, :public_instance_method, :public_instance_methods, :public_method, :public_method_defined?, :public_methods, :public_send, :remove_class_variable, :remove_instance_variable, :remove_method, :respond_to?, :send, :singleton_class, :singleton_class?, :singleton_method, :singleton_methods, :sqrt, :subclasses, :superclass, :taint, :tainted?, :tap, :then, :to_enum, :to_s, :trust, :try_convert, :undef_method, :untaint, :untrust, :untrusted?, :yield_self]
[:!, :!=, :!~, :&lt;, :&lt;=, :&lt;=&gt;, :==, :===, :=~, :&gt;, :&gt;=, :__id__, :__send__, :alias_method, :allocate, :ancestors, :attr, :attr_accessor, :attr_reader, :attr_writer, :autoload, :autoload?, :class, :class_eval, :class_exec, :class_variable_defined?, :class_variable_get, :class_variable_set, :class_variables, :clone, :const_defined?, :const_get, :const_missing, :const_set, :const_source_location, :constants, :define_method, :define_singleton_method, :deprecate_constant, :display, :dup, :enum_for, :eql?, :equal?, :extend, :freeze, :frozen?, :hash, :include, :include?, :included_modules, :inspect, :instance_eval, :instance_exec, :instance_method, :instance_methods, :instance_of?, :instance_variable_defined?, :instance_variable_get, :instance_variable_set, :instance_variables, :is_a?, :itself, :kind_of?, :method, :method_defined?, :methods, :module_eval, :module_exec, :name, :nil?, :object_id, :prepend, :private_class_method, :private_constant, :private_instance_methods, :private_method_defined?, :private_methods, :protected_instance_methods, :protected_method_defined?, :protected_methods, :public_class_method, :public_constant, :public_instance_method, :public_instance_methods, :public_method, :public_method_defined?, :public_methods, :public_send, :remove_class_variable, :remove_instance_variable, :remove_method, :respond_to?, :send, :singleton_class, :singleton_class?, :singleton_method, :singleton_methods, :subclasses, :superclass, :taint, :tainted?, :tap, :then, :to_enum, :to_s, :trust, :undef_method, :untaint, :untrust, :untrusted?, :yield_self]
[:!, :!=, :!~, :&lt;, :&lt;=, :&lt;=&gt;, :==, :===, :=~, :&gt;, :&gt;=, :[], :__id__, :__send__, :alias_method, :allocate, :ancestors, :attr, :attr_accessor, :attr_reader, :attr_writer, :autoload, :autoload?, :class, :class_eval, :class_exec, :class_variable_defined?, :class_variable_get, :class_variable_set, :class_variables, :clone, :const_defined?, :const_get, :const_missing, :const_set, :const_source_location, :constants, :define_method, :define_singleton_method, :deprecate_constant, :display, :dup, :enum_for, :eql?, :equal?, :extend, :freeze, :frozen?, :hash, :include, :include?, :included_modules, :inspect, :instance_eval, :instance_exec, :instance_method, :instance_methods, :instance_of?, :instance_variable_defined?, :instance_variable_get, :instance_variable_set, :instance_variables, :is_a?, :itself, :kind_of?, :method, :method_defined?, :methods, :module_eval, :module_exec, :name, :new, :nil?, :object_id, :prepend, :private_class_method, :private_constant, :private_instance_methods, :private_method_defined?, :private_methods, :protected_instance_methods, :protected_method_defined?, :protected_methods, :public_class_method, :public_constant, :public_instance_method, :public_instance_methods, :public_method, :public_method_defined?, :public_methods, :public_send, :remove_class_variable, :remove_instance_variable, :remove_method, :respond_to?, :send, :singleton_class, :singleton_class?, :singleton_method, :singleton_methods, :subclasses, :superclass, :taint, :tainted?, :tap, :then, :to_enum, :to_s, :trust, :try_convert, :undef_method, :untaint, :untrust, :untrusted?, :yield_self] 
[:!, :!=, :!~, :&lt;, :&lt;=, :&lt;=&gt;, :==, :===, :=~, :&gt;, :&gt;=, :__id__, :__send__, :alias_method, :allocate, :ancestors, :attr, :attr_accessor, :attr_reader, :attr_writer, :autoload, :autoload?, :class, :class_eval, :class_exec, :class_variable_defined?, :class_variable_get, :class_variable_set, :class_variables, :clone, :const_defined?, :const_get, :const_missing, :const_set, :const_source_location, :constants, :define_method, :define_singleton_method, :deprecate_constant, :display, :dup, :enum_for, :eql?, :equal?, :extend, :freeze, :frozen?, :hash, :include, :include?, :included_modules, :inspect, :instance_eval, :instance_exec, :instance_method, :instance_methods, :instance_of?, :instance_variable_defined?, :instance_variable_get, :instance_variable_set, :instance_variables, :is_a?, :itself, :kind_of?, :method, :method_defined?, :methods, :module_eval, :module_exec, :name, :new, :nil?, :object_id, :prepend, :private_class_method, :private_constant, :private_instance_methods, :private_method_defined?, :private_methods, :protected_instance_methods, :protected_method_defined?, :protected_methods, :public_class_method, :public_constant, :public_instance_method, :public_instance_methods, :public_method, :public_method_defined?, :public_methods, :public_send, :remove_class_variable, :remove_instance_variable, :remove_method, :respond_to?, :send, :singleton_class, :singleton_class?, :singleton_method, :singleton_methods, :subclasses, :superclass, :taint, :tainted?, :tap, :then, :to_enum, :to_s, :trust, :undef_method, :untaint, :untrust, :untrusted?, :yield_self]
&lt;/syntaxhighlight&gt;
;Crystalに実装したmethodsマクロ:&lt;syntaxhighlight lang=crystal&gt;
class Object
  macro methods
    {{ @type.methods.map(&amp;.name.stringify).sort.uniq }}
  end
end

p! Object.methods,
  Reference.methods,
  Array.methods,
  Box.methods,
  Channel.methods,
  Deque.methods,
  Dir.methods,
  Exception.methods,
  ArgumentError.methods,
  DivisionByZeroError.methods,
  IndexError.methods,
  InvalidByteSequenceError.methods,
  Fiber.methods,
  Hash.methods,
  IO.methods,
  File.methods,
  Mutex.methods,
  PrettyPrint.methods,
  Process.methods,
  Regex.methods,
  String.methods,
  Thread.methods,
  Bool.methods,
  Int32.methods,
  Float64.methods,
  Proc.methods
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
Object.methods                   # =&gt; [&quot;!=&quot;, &quot;!~&quot;, &quot;==&quot;, &quot;===&quot;, &quot;=~&quot;, &quot;class&quot;, &quot;crystal_type_id&quot;, &quot;dup&quot;, &quot;hash&quot;, &quot;in?&quot;, &quot;inspect&quot;, &quot;itself&quot;, &quot;not_nil!&quot;, &quot;pretty_inspect&quot;, &quot;pretty_print&quot;, &quot;tap&quot;, &quot;to_s&quot;, &quot;try&quot;, &quot;unsafe_as&quot;]
Reference.methods                # =&gt; [&quot;==&quot;, &quot;dup&quot;, &quot;exec_recursive&quot;, &quot;exec_recursive_clone&quot;, &quot;hash&quot;, &quot;inspect&quot;, &quot;object_id&quot;, &quot;pretty_print&quot;, &quot;same?&quot;, &quot;to_s&quot;]
Array.methods                    # =&gt; [&quot;&amp;&quot;, &quot;*&quot;, &quot;+&quot;, &quot;-&quot;, &quot;&lt;&lt;&quot;, &quot;&lt;=&gt;&quot;, &quot;==&quot;, &quot;[]&quot;, &quot;[]=&quot;, &quot;[]?&quot;, &quot;calculate_new_capacity&quot;, &quot;check_needs_resize&quot;, &quot;check_needs_resize_for_unshift&quot;, &quot;clear&quot;, &quot;clone&quot;, &quot;compact&quot;, &quot;compact!&quot;, &quot;concat&quot;, &quot;delete&quot;, &quot;delete_at&quot;, &quot;dup&quot;, &quot;each_repeated_permutation&quot;, &quot;fill&quot;, &quot;first&quot;, &quot;flatten&quot;, &quot;increase_capacity&quot;, &quot;increase_capacity_for_unshift&quot;, &quot;index&quot;, &quot;initialize&quot;, &quot;insert&quot;, &quot;inspect&quot;, &quot;internal_delete&quot;, &quot;last&quot;, &quot;map&quot;, &quot;map_with_index&quot;, &quot;needs_resize?&quot;, &quot;pop&quot;, &quot;pop?&quot;, &quot;pretty_print&quot;, &quot;product&quot;, &quot;push&quot;, &quot;reject!&quot;, &quot;remaining_capacity&quot;, &quot;repeated_permutations&quot;, &quot;replace&quot;, &quot;reset_buffer_to_root_buffer&quot;, &quot;resize_if_cant_insert&quot;, &quot;resize_to_capacity&quot;, &quot;resize_to_capacity_for_unshift&quot;, &quot;reverse&quot;, &quot;root_buffer&quot;, &quot;rotate&quot;, &quot;rotate!&quot;, &quot;select!&quot;, &quot;shift&quot;, &quot;shift?&quot;, &quot;shift_buffer_by&quot;, &quot;shift_when_not_empty&quot;, &quot;shuffle&quot;, &quot;size&quot;, &quot;size=&quot;, &quot;skip&quot;, &quot;sort&quot;, &quot;sort!&quot;, &quot;sort_by&quot;, &quot;sort_by!&quot;, &quot;to_a&quot;, &quot;to_lookup_hash&quot;, &quot;to_s&quot;, &quot;to_unsafe&quot;, &quot;to_unsafe_slice&quot;, &quot;transpose&quot;, &quot;truncate&quot;, &quot;uniq&quot;, &quot;uniq!&quot;, &quot;unsafe_fetch&quot;, &quot;unsafe_put&quot;, &quot;unshift&quot;, &quot;unstable_sort&quot;, &quot;unstable_sort!&quot;, &quot;unstable_sort_by&quot;, &quot;unstable_sort_by!&quot;, &quot;|&quot;]
Box.methods                      # =&gt; [&quot;initialize&quot;, &quot;object&quot;]
Channel.methods                  # =&gt; [&quot;close&quot;, &quot;closed?&quot;, &quot;dequeue_receiver&quot;, &quot;dequeue_sender&quot;, &quot;initialize&quot;, &quot;inspect&quot;, &quot;pretty_print&quot;, &quot;receive&quot;, &quot;receive?&quot;, &quot;receive_impl&quot;, &quot;receive_internal&quot;, &quot;receive_select_action&quot;, &quot;receive_select_action?&quot;, &quot;send&quot;, &quot;send_internal&quot;, &quot;send_select_action&quot;]
Deque.methods                    # =&gt; [&quot;+&quot;, &quot;&lt;&lt;&quot;, &quot;==&quot;, &quot;buffer&quot;, &quot;clear&quot;, &quot;clone&quot;, &quot;concat&quot;, &quot;delete&quot;, &quot;delete_at&quot;, &quot;dup&quot;, &quot;each&quot;, &quot;halfs&quot;, &quot;increase_capacity&quot;, &quot;initialize&quot;, &quot;insert&quot;, &quot;inspect&quot;, &quot;internal_delete&quot;, &quot;pop&quot;, &quot;pop?&quot;, &quot;pretty_print&quot;, &quot;push&quot;, &quot;reject!&quot;, &quot;rotate!&quot;, &quot;select!&quot;, &quot;shift&quot;, &quot;shift?&quot;, &quot;size&quot;, &quot;size=&quot;, &quot;to_s&quot;, &quot;unsafe_fetch&quot;, &quot;unsafe_put&quot;, &quot;unshift&quot;]
Dir.methods                      # =&gt; [&quot;children&quot;, &quot;close&quot;, &quot;each&quot;, &quot;each_child&quot;, &quot;entries&quot;, &quot;initialize&quot;, &quot;inspect&quot;, &quot;path&quot;, &quot;pretty_print&quot;, &quot;read&quot;, &quot;rewind&quot;, &quot;to_s&quot;]
Exception.methods                # =&gt; [&quot;backtrace&quot;, &quot;backtrace?&quot;, &quot;callstack&quot;, &quot;callstack=&quot;, &quot;cause&quot;, &quot;initialize&quot;, &quot;inspect&quot;, &quot;inspect_with_backtrace&quot;, &quot;message&quot;, &quot;to_s&quot;]
ArgumentError.methods            # =&gt; [&quot;initialize&quot;]
DivisionByZeroError.methods      # =&gt; [&quot;initialize&quot;]
IndexError.methods               # =&gt; [&quot;initialize&quot;]
InvalidByteSequenceError.methods # =&gt; [&quot;initialize&quot;]
Fiber.methods                    # =&gt; [&quot;cancel_timeout&quot;, &quot;dead?&quot;, &quot;enqueue&quot;, &quot;initialize&quot;, &quot;inspect&quot;, &quot;makecontext&quot;, &quot;name&quot;, &quot;name=&quot;, &quot;next&quot;, &quot;next=&quot;, &quot;previous&quot;, &quot;previous=&quot;, &quot;push_gc_roots&quot;, &quot;resumable?&quot;, &quot;resume&quot;, &quot;resume_event&quot;, &quot;run&quot;, &quot;running?&quot;, &quot;stack_bottom&quot;, &quot;stack_bottom=&quot;, &quot;timeout&quot;, &quot;timeout_event&quot;, &quot;timeout_select_action&quot;, &quot;timeout_select_action=&quot;, &quot;to_s&quot;]
Hash.methods                     # =&gt; [&quot;==&quot;, &quot;[]&quot;, &quot;[]=&quot;, &quot;[]?&quot;, &quot;add_entry_and_increment_size&quot;, &quot;clear&quot;, &quot;clear_entries&quot;, &quot;clear_impl&quot;, &quot;clear_indices&quot;, &quot;clone&quot;, &quot;compact&quot;, &quot;compact!&quot;, &quot;compare_by_identity&quot;, &quot;compare_by_identity?&quot;, &quot;compute_indices_bytesize&quot;, &quot;delete&quot;, &quot;delete_entry&quot;, &quot;delete_entry_and_update_counts&quot;, &quot;delete_impl&quot;, &quot;delete_linear_scan&quot;, &quot;dig&quot;, &quot;dig?&quot;, &quot;do_compaction&quot;, &quot;double_indices_size&quot;, &quot;dup&quot;, &quot;each&quot;, &quot;each_entry_with_index&quot;, &quot;each_key&quot;, &quot;each_value&quot;, &quot;empty?&quot;, &quot;entries&quot;, &quot;entries_capacity&quot;, &quot;entries_full?&quot;, &quot;entries_size&quot;, &quot;entry_matches?&quot;, &quot;fetch&quot;, &quot;find_entry&quot;, &quot;find_entry_with_index&quot;, &quot;find_entry_with_index_linear_scan&quot;, &quot;first_entry?&quot;, &quot;first_key&quot;, &quot;first_key?&quot;, &quot;first_value&quot;, &quot;first_value?&quot;, &quot;fit_in_indices&quot;, &quot;get_entry&quot;, &quot;get_index&quot;, &quot;has_key?&quot;, &quot;has_value?&quot;, &quot;hash&quot;, &quot;indices_malloc_size&quot;, &quot;indices_size&quot;, &quot;initialize&quot;, &quot;initialize_clone&quot;, &quot;initialize_clone_entries&quot;, &quot;initialize_compare_by_identity&quot;, &quot;initialize_copy_non_entries_vars&quot;, &quot;initialize_default_block&quot;, &quot;initialize_dup&quot;, &quot;initialize_dup_entries&quot;, &quot;inspect&quot;, &quot;invert&quot;, &quot;key_for&quot;, &quot;key_for?&quot;, &quot;key_hash&quot;, &quot;keys&quot;, &quot;last_entry?&quot;, &quot;last_key&quot;, &quot;last_key?&quot;, &quot;last_value&quot;, &quot;last_value?&quot;, &quot;malloc_entries&quot;, &quot;malloc_indices&quot;, &quot;merge&quot;, &quot;merge!&quot;, &quot;merge_into!&quot;, &quot;next_index&quot;, &quot;pretty_print&quot;, &quot;proper_subset_of?&quot;, &quot;proper_superset_of?&quot;, &quot;put&quot;, &quot;realloc_entries&quot;, &quot;realloc_indices&quot;, &quot;rehash&quot;, &quot;reject&quot;, &quot;reject!&quot;, &quot;resize&quot;, &quot;select&quot;, &quot;select!&quot;, &quot;set_entry&quot;, &quot;set_index&quot;, &quot;shift&quot;, &quot;shift?&quot;, &quot;size&quot;, &quot;subset_of?&quot;, &quot;superset_of?&quot;, &quot;to_a&quot;, &quot;to_a_impl&quot;, &quot;to_h&quot;, &quot;to_s&quot;, &quot;transform_keys&quot;, &quot;transform_values&quot;, &quot;transform_values!&quot;, &quot;update&quot;, &quot;update_linear_scan&quot;, &quot;upsert&quot;, &quot;values&quot;, &quot;values_at&quot;]
IO.methods                       # =&gt; [&quot;&lt;&lt;&quot;, &quot;check_open&quot;, &quot;close&quot;, &quot;closed?&quot;, &quot;decoder&quot;, &quot;each_byte&quot;, &quot;each_char&quot;, &quot;each_line&quot;, &quot;encoder&quot;, &quot;encoding&quot;, &quot;flush&quot;, &quot;getb_to_end&quot;, &quot;gets&quot;, &quot;gets_peek&quot;, &quot;gets_slow&quot;, &quot;gets_to_end&quot;, &quot;has_non_utf8_encoding?&quot;, &quot;peek&quot;, &quot;peek_or_read_utf8&quot;, &quot;peek_or_read_utf8_masked&quot;, &quot;pos&quot;, &quot;pos=&quot;, &quot;print&quot;, &quot;printf&quot;, &quot;puts&quot;, &quot;read&quot;, &quot;read_at&quot;, &quot;read_byte&quot;, &quot;read_bytes&quot;, &quot;read_char&quot;, &quot;read_char_with_bytesize&quot;, &quot;read_fully&quot;, &quot;read_fully?&quot;, &quot;read_line&quot;, &quot;read_string&quot;, &quot;read_utf8&quot;, &quot;read_utf8_byte&quot;, &quot;rewind&quot;, &quot;seek&quot;, &quot;set_encoding&quot;, &quot;skip&quot;, &quot;skip_to_end&quot;, &quot;tell&quot;, &quot;tty?&quot;, &quot;utf8_encoding?&quot;, &quot;write&quot;, &quot;write_byte&quot;, &quot;write_bytes&quot;, &quot;write_string&quot;, &quot;write_utf8&quot;]
File.methods                     # =&gt; [&quot;delete&quot;, &quot;initialize&quot;, &quot;inspect&quot;, &quot;path&quot;, &quot;read_at&quot;, &quot;size&quot;, &quot;truncate&quot;]
Mutex.methods                    # =&gt; [&quot;initialize&quot;, &quot;lock&quot;, &quot;lock_slow&quot;, &quot;synchronize&quot;, &quot;try_lock&quot;, &quot;unlock&quot;]
PrettyPrint.methods              # =&gt; [&quot;break_outmost_groups&quot;, &quot;breakable&quot;, &quot;comma&quot;, &quot;current_group&quot;, &quot;fill_breakable&quot;, &quot;flush&quot;, &quot;group&quot;, &quot;group_queue&quot;, &quot;group_sub&quot;, &quot;indent&quot;, &quot;initialize&quot;, &quot;list&quot;, &quot;nest&quot;, &quot;newline&quot;, &quot;surround&quot;, &quot;text&quot;]
Process.methods                  # =&gt; [&quot;channel&quot;, &quot;close&quot;, &quot;close_io&quot;, &quot;copy_io&quot;, &quot;ensure_channel&quot;, &quot;error&quot;, &quot;error?&quot;, &quot;exists?&quot;, &quot;finalize&quot;, &quot;initialize&quot;, &quot;input&quot;, &quot;input?&quot;, &quot;output&quot;, &quot;output?&quot;, &quot;pid&quot;, &quot;signal&quot;, &quot;stdio_to_fd&quot;, &quot;terminate&quot;, &quot;terminated?&quot;, &quot;wait&quot;]
Regex.methods                    # =&gt; [&quot;+&quot;, &quot;==&quot;, &quot;===&quot;, &quot;=~&quot;, &quot;capture_count&quot;, &quot;clone&quot;, &quot;dup&quot;, &quot;finalize&quot;, &quot;hash&quot;, &quot;initialize&quot;, &quot;inspect&quot;, &quot;internal_matches?&quot;, &quot;match&quot;, &quot;match_at_byte_index&quot;, &quot;matches?&quot;, &quot;matches_at_byte_index?&quot;, &quot;name_table&quot;, &quot;options&quot;, &quot;source&quot;, &quot;to_s&quot;]
String.methods                   # =&gt; [&quot;%&quot;, &quot;*&quot;, &quot;+&quot;, &quot;&lt;=&gt;&quot;, &quot;==&quot;, &quot;=~&quot;, &quot;[]&quot;, &quot;[]?&quot;, &quot;ascii_only?&quot;, &quot;blank?&quot;, &quot;byte_at&quot;, &quot;byte_at?&quot;, &quot;byte_delete_at&quot;, &quot;byte_index&quot;, &quot;byte_index_to_char_index&quot;, &quot;byte_slice&quot;, &quot;byte_slice?&quot;, &quot;bytes&quot;, &quot;bytesize&quot;, &quot;calc_excess_left&quot;, &quot;calc_excess_right&quot;, &quot;camelcase&quot;, &quot;capitalize&quot;, &quot;center&quot;, &quot;char_at&quot;, &quot;char_bytesize_at&quot;, &quot;char_index_to_byte_index&quot;, &quot;chars&quot;, &quot;check_no_null_byte&quot;, &quot;chomp&quot;, &quot;clone&quot;, &quot;codepoint_at&quot;, &quot;codepoints&quot;, &quot;compare&quot;, &quot;count&quot;, &quot;delete&quot;, &quot;delete_at&quot;, &quot;downcase&quot;, &quot;dump&quot;, &quot;dump_char&quot;, &quot;dump_hex&quot;, &quot;dump_or_inspect&quot;, &quot;dump_or_inspect_char&quot;, &quot;dump_or_inspect_unquoted&quot;, &quot;dump_unquoted&quot;, &quot;dup&quot;, &quot;each_byte&quot;, &quot;each_byte_index_and_char_index&quot;, &quot;each_char&quot;, &quot;each_char_with_index&quot;, &quot;each_codepoint&quot;, &quot;each_grapheme&quot;, &quot;each_grapheme_boundary&quot;, &quot;each_line&quot;, &quot;empty?&quot;, &quot;encode&quot;, &quot;ends_with?&quot;, &quot;find_start_and_end&quot;, &quot;grapheme_size&quot;, &quot;graphemes&quot;, &quot;gsub&quot;, &quot;gsub_append&quot;, &quot;gsub_ascii_char&quot;, &quot;has_back_references?&quot;, &quot;hash&quot;, &quot;hexbytes&quot;, &quot;hexbytes?&quot;, &quot;includes?&quot;, &quot;index&quot;, &quot;insert&quot;, &quot;insert_impl&quot;, &quot;inspect&quot;, &quot;inspect_char&quot;, &quot;inspect_unquoted&quot;, &quot;just&quot;, &quot;lchop&quot;, &quot;lchop?&quot;, &quot;lines&quot;, &quot;ljust&quot;, &quot;lstrip&quot;, &quot;match&quot;, &quot;matches?&quot;, &quot;partition&quot;, &quot;presence&quot;, &quot;pretty_print&quot;, &quot;rchop&quot;, &quot;rchop?&quot;, &quot;remove_excess&quot;, &quot;remove_excess_left&quot;, &quot;remove_excess_right&quot;, &quot;reverse&quot;, &quot;rindex&quot;, &quot;rjust&quot;, &quot;rpartition&quot;, &quot;rstrip&quot;, &quot;scan&quot;, &quot;scan_backreferences&quot;, &quot;scrub&quot;, &quot;single_byte_optimizable?&quot;, &quot;size&quot;, &quot;size_known?&quot;, &quot;split&quot;, &quot;split_by_empty_separator&quot;, &quot;split_single_byte&quot;, &quot;squeeze&quot;, &quot;starts_with?&quot;, &quot;strip&quot;, &quot;sub&quot;, &quot;sub_append&quot;, &quot;sub_index&quot;, &quot;sub_range&quot;, &quot;succ&quot;, &quot;titleize&quot;, &quot;to_f&quot;, &quot;to_f32&quot;, &quot;to_f32?&quot;, &quot;to_f64&quot;, &quot;to_f64?&quot;, &quot;to_f?&quot;, &quot;to_f_impl&quot;, &quot;to_i&quot;, &quot;to_i128&quot;, &quot;to_i128?&quot;, &quot;to_i16&quot;, &quot;to_i16?&quot;, &quot;to_i32&quot;, &quot;to_i32?&quot;, &quot;to_i64&quot;, &quot;to_i64?&quot;, &quot;to_i8&quot;, &quot;to_i8?&quot;, &quot;to_i?&quot;, &quot;to_s&quot;, &quot;to_slice&quot;, &quot;to_u128&quot;, &quot;to_u128?&quot;, &quot;to_u16&quot;, &quot;to_u16?&quot;, &quot;to_u32&quot;, &quot;to_u32?&quot;, &quot;to_u64&quot;, &quot;to_u64?&quot;, &quot;to_u8&quot;, &quot;to_u8?&quot;, &quot;to_unsafe&quot;, &quot;to_unsigned_info&quot;, &quot;to_utf16&quot;, &quot;tr&quot;, &quot;underscore&quot;, &quot;unicode_delete_at&quot;, &quot;unsafe_byte_at&quot;, &quot;unsafe_byte_slice&quot;, &quot;unsafe_byte_slice_string&quot;, &quot;upcase&quot;, &quot;valid_encoding?&quot;]
Thread.methods                   # =&gt; [&quot;detach&quot;, &quot;event_base&quot;, &quot;gc_thread_handler&quot;, &quot;gc_thread_handler=&quot;, &quot;initialize&quot;, &quot;join&quot;, &quot;main_fiber&quot;, &quot;next&quot;, &quot;next=&quot;, &quot;previous&quot;, &quot;previous=&quot;, &quot;scheduler&quot;, &quot;stack_address&quot;, &quot;start&quot;, &quot;to_unsafe&quot;]
Bool.methods                     # =&gt; [&quot;!=&quot;, &quot;&amp;&quot;, &quot;==&quot;, &quot;^&quot;, &quot;clone&quot;, &quot;hash&quot;, &quot;to_s&quot;, &quot;to_unsafe&quot;, &quot;|&quot;]
Int32.methods                    # =&gt; [&quot;!=&quot;, &quot;&amp;&quot;, &quot;&amp;*&quot;, &quot;&amp;+&quot;, &quot;&amp;-&quot;, &quot;*&quot;, &quot;+&quot;, &quot;-&quot;, &quot;/&quot;, &quot;&lt;&quot;, &quot;&lt;=&quot;, &quot;==&quot;, &quot;&gt;&quot;, &quot;&gt;=&quot;, &quot;^&quot;, &quot;clone&quot;, &quot;leading_zeros_count&quot;, &quot;popcount&quot;, &quot;to_f&quot;, &quot;to_f!&quot;, &quot;to_f32&quot;, &quot;to_f32!&quot;, &quot;to_f64&quot;, &quot;to_f64!&quot;, &quot;to_i&quot;, &quot;to_i!&quot;, &quot;to_i128&quot;, &quot;to_i128!&quot;, &quot;to_i16&quot;, &quot;to_i16!&quot;, &quot;to_i32&quot;, &quot;to_i32!&quot;, &quot;to_i64&quot;, &quot;to_i64!&quot;, &quot;to_i8&quot;, &quot;to_i8!&quot;, &quot;to_u&quot;, &quot;to_u!&quot;, &quot;to_u128&quot;, &quot;to_u128!&quot;, &quot;to_u16&quot;, &quot;to_u16!&quot;, &quot;to_u32&quot;, &quot;to_u32!&quot;, &quot;to_u64&quot;, &quot;to_u64!&quot;, &quot;to_u8&quot;, &quot;to_u8!&quot;, &quot;trailing_zeros_count&quot;, &quot;unsafe_chr&quot;, &quot;unsafe_div&quot;, &quot;unsafe_mod&quot;, &quot;unsafe_shl&quot;, &quot;unsafe_shr&quot;, &quot;|&quot;]
Float64.methods                  # =&gt; [&quot;!=&quot;, &quot;*&quot;, &quot;**&quot;, &quot;+&quot;, &quot;-&quot;, &quot;/&quot;, &quot;&lt;&quot;, &quot;&lt;=&quot;, &quot;==&quot;, &quot;&gt;&quot;, &quot;&gt;=&quot;, &quot;ceil&quot;, &quot;clone&quot;, &quot;fdiv&quot;, &quot;floor&quot;, &quot;next_float&quot;, &quot;prev_float&quot;, &quot;round_away&quot;, &quot;round_even&quot;, &quot;to_f&quot;, &quot;to_f!&quot;, &quot;to_f32&quot;, &quot;to_f32!&quot;, &quot;to_f64&quot;, &quot;to_f64!&quot;, &quot;to_i&quot;, &quot;to_i!&quot;, &quot;to_i128&quot;, &quot;to_i128!&quot;, &quot;to_i16&quot;, &quot;to_i16!&quot;, &quot;to_i32&quot;, &quot;to_i32!&quot;, &quot;to_i64&quot;, &quot;to_i64!&quot;, &quot;to_i8&quot;, &quot;to_i8!&quot;, &quot;to_s&quot;, &quot;to_u&quot;, &quot;to_u!&quot;, &quot;to_u128&quot;, &quot;to_u128!&quot;, &quot;to_u16&quot;, &quot;to_u16!&quot;, &quot;to_u32&quot;, &quot;to_u32!&quot;, &quot;to_u64&quot;, &quot;to_u64!&quot;, &quot;to_u8&quot;, &quot;to_u8!&quot;, &quot;trunc&quot;]
Proc.methods                     # =&gt; [&quot;==&quot;, &quot;===&quot;, &quot;arity&quot;, &quot;call&quot;, &quot;clone&quot;, &quot;closure?&quot;, &quot;closure_data&quot;, &quot;hash&quot;, &quot;internal_representation&quot;, &quot;partial&quot;, &quot;pointer&quot;, &quot;to_s&quot;]&lt;/syntaxhighlight&gt;

== 脚註 ==
&lt;references /&gt;

== 外部リンク ==
* [https://crystal-lang.org/ The Crystal Programming Language] {{---}} 公式サイト
** [https://crystal-lang.org/api/1.5.0/ Crystal 1.5.0 リファレンス]
** [https://play.crystal-lang.org/#/cr Compile &amp; run code in Crystal] {{---}} playground

[[Category:Crystal|*]]
[[Category:プログラミング言語]]
{{NDC|007.64}}</text>
      <sha1>tjwqpvmbfsg8xnddhy84g8jq3z9hoj0</sha1>
    </revision>
    <revision>
      <id>205749</id>
      <parentid>205748</parentid>
      <timestamp>2022-07-24T02:33:12Z</timestamp>
      <contributor>
        <username>Ef3</username>
        <id>694</id>
      </contributor>
      <comment>/* プログラミング環境 */ Crystalのプログラムを作り、コンパイル・実装するには、「オンライン実行環境を使う」・「エディト・コンパイル・実行環境を用意してそれを使う」の２通りの方法があります。</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="60739" xml:space="preserve">{{Pathnav|メインページ|工学|情報技術|プログラミング|frame=1}}
{{Wikipedia|Crystal (プログラミング言語)}}
本書は、[[w:Crystal (プログラミング言語)|Crystal]]のチュートリアルです。
'''Crystal'''は、Ary Borenszweig、Juan Wajnerman、Brian Cardiffと300人以上の貢献者によって設計・開発された[汎用オブジェクト指向プログラミング言語です&lt;ref&gt;{{Cite web
|url=https://github.com/crystal-lang/crystal/graphs/contributors
|title=Contributors
|accessdate=2022-07-18
|website=github.com
}}&lt;/ref&gt;。[[Ruby]] にヒントを得た構文を持ち、静的型チェックを備えた [[コンパイル型言語]]ですが、変数やメソッドの引数の型は一般には不要です。型は高度なグローバル[[型推論]]アルゴリズムによって解決される。&lt;ref&gt;{{Cite web
|url=http://crystal-lang.org/2013/09/23/type-inference-part-1.html
|title=Type inference part 1
|last=Brian J.
|first=Cardiff
|date=2013-09-09
|accessdate=2022-07-18
|website=crystal-lang.org
}}&lt;/ref&gt;Crystalは[[Apache License]]バージョン2.0のもと、FOSSとしてリリースされています。

__TOC__

== Hello, World! ==
他の多くのチュートリアルがそうであるように、
私たちもまずはCrystalの世界にあいさつすることから始めましょう。

Rubyとの比較も兼ねて、[[Ruby#Hello, World!]]をそのまま実行してみます。

''hello.cr''というファイルを作り、次のように書いて保存して下さい&lt;ref&gt;Crystalのソースファイルの拡張子は''.cr'' です&lt;/ref&gt;。

;hello.cr:&lt;syntaxhighlight lang=Crystal&gt;
puts 'Hello, World!'
&lt;/syntaxhighlight&gt;

;コマンドラインでの操作:&lt;syntaxhighlight lang=&quot;console&quot;&gt;
% cat hello.cr 
puts 'Hello, World!'
% crystal hello.cr
In hello.cr:1:6

 1 | puts 'Hello, World!'
          ^
Error: unterminated char literal, use double quotes for strings

% sed -i -e &quot;s@'@Q@g&quot; -e 's@Q@&quot;@g' hello.cr
% cat hello.cr 
puts &quot;Hello, World!&quot;
% crystal hello.cr
Hello, World!
&lt;/syntaxhighlight&gt;
この１行のスクリプトは、メソッド&lt;code&gt;puts&lt;/code&gt; に文字リテラル&lt;code&gt;&quot;Hello, World!&quot;&lt;/code&gt;を渡し呼出しています。

このプログラムは、[[Ruby#Hello, World!]]と同じですが、Crystalでは文字列リテラルは &lt;code&gt;&quot;…&quot;&lt;/code&gt; で囲うのでそれだけ変更しました。

== プログラミング環境 ==
Crystalのプログラムを作り、コンパイル・実装するには、「オンライン実行環境を使う」・「エディト・コンパイル・実行環境を用意してそれを使う」の２通りの方法があります。

=== オンライン実行環境 ===
公式のオンライン実行環境、 https://play.crystal-lang.org/ があります。
まずは、これを使って本書に例示されているコードを実行してみることをお勧めします。

=== エディト・コンパイル・実行環境 ====
エディタについては本書では触れませんが、プログラミング時間の大半はエディタの操作に費やされるため、良いエディタを選択することが重要です。

Crystal の言語処理系は、

[TODO: コマンドラインツール crystal の解説。 crystal ファイル名 は crystal run ファイル名 の短縮形で、インタープリタ的な実行…ではなく、内部ビルドツールでコンパイル・実行を行う]

== Ruby との違い ==
Crystalは、Rubyに触発された構文を持つものの、Rubyとの互換性をゴールに定めては'''いません'''。
このため、細部を見ると仕様に差異があり、Rubyのソースコードをcrystalに掛けるても前節の 'Hello World' の様にコンパイルに失敗することがあります。
また、コンパイルできても実行結果に違いが出ることがあります。

ここでは、Ruby との違いについて実際のコードと双方の結果を比較することで、差異についての理解を深めていきます。

=== 整数型の特性 ===
;大きな整数:&lt;syntaxhighlight lang=Crystal&gt;
p 2 ** 999
p (2 ** 999).class
&lt;/syntaxhighlight&gt;
;rubyの実行結果:&lt;syntaxhighlight lang=&quot;console&quot;&gt;
5357543035931336604742125245300009052807024058527668037218751941851755255624680612465991894078479290637973364587765734125935726428461570217992288787349287401967283887412115492710537302531185570938977091076523237491790970633699383779582771973038531457285598238843271083830214915826312193418602834034688
Integer
&lt;/syntaxhighlight&gt;
;crystalの実行結果:&lt;syntaxhighlight lang=&quot;console&quot;&gt;
Unhandled exception: Arithmetic overflow (OverflowError)
  from /usr/local/share/crystal/share/crystal/src/int.cr:295:9 in '**'
  from pow.cr:1:1 in '__crystal_main'
  from /usr/local/share/crystal/share/crystal/src/crystal/main.cr:115:5 in 'main_user_code'
  from /usr/local/share/crystal/share/crystal/src/crystal/main.cr:101:7 in 'main'
  from /usr/local/share/crystal/share/crystal/src/crystal/main.cr:127:3 in 'main'
  from /usr/local/lib64/libc.so.6 in '__libc_start_main'
  from /usr/local/.cache/crystal/crystal-run-pow.tmp in '_start'
  from ???
&lt;/syntaxhighlight&gt;
: Ruby の整数は、桁あふれが起こると自動的に多倍長整数に型変換されるので、継ぎ目なしに大きな数を扱うアルゴルズムが使えます。
: Crystal の整数は、固定長です（大きさについては[[#リテラルと型|後述]]）。なので大きな答えになる式を評価すると桁あふれが生じます。桁あふれが生じますが、C言語のように寡黙に処理を続けるのではなく、実行時に例外（OverflowError）が上がるので、例外を捕捉し然るべき処置を施すことが可能です。

==== BigInt ====
&lt;code&gt;big&lt;/code&gt; を &lt;code&gt;require&lt;/code&gt; すると &lt;code&gt;BigInt&lt;/code&gt; が使えるようになります。
;BigInt:&lt;syntaxhighlight lang=Crystal&gt;
require &quot;big&quot;

p BigInt.new(2) ** 999
p (BigInt.new(2) ** 999).class
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;console&quot;&gt;
5357543035931336604742125245300009052807024058527668037218751941851755255624680612465991894078479290637973364587765734125935726428461570217992288787349287401967283887412115492710537302531185570938977091076523237491790970633699383779582771973038531457285598238843271083830214915826312193418602834034688
BigInt
&lt;/syntaxhighlight&gt;
: BigIntはプリミティブではなので、リテラル表現はありません。また、
::&lt;syntaxhighlight lang=Crystal&gt;
n : BigInt = 2
&lt;/syntaxhighlight&gt;
::&lt;syntaxhighlight lang=console&gt;
Error: type must be BigInt, not Int32
&lt;/syntaxhighlight&gt;
:: のように型アノテーションすることも出来ません。

=== リテラルと型 ===
;様々なリテラルと型:&lt;syntaxhighlight lang=Crystal&gt;
[nil, false, true, 42, 2.73, 'Q', &quot;string&quot;, [1,2,3], {a:1, b:2}].each{|x|
  p [x, x.class]
}
&lt;/syntaxhighlight&gt;
;rubyの実行結果:&lt;syntaxhighlight lang=&quot;console&quot;&gt;
[nil, NilClass]
[false, FalseClass]
[true, TrueClass]
[42, Integer]
[2.73, Float]
[&quot;Q&quot;, String]
[&quot;string&quot;, String]
[[1, 2, 3], Array] 
[{:a=&gt;1, :b=&gt;2}, Hash]
&lt;/syntaxhighlight&gt;
;crystalの実行結果:&lt;syntaxhighlight lang=&quot;console&quot;&gt;
[nil, Nil]
[false, Bool]
[true, Bool]
[42, Int32]
[2.73, Float64]
['Q', Char]
[&quot;string&quot;, String]
[[1, 2, 3], Array(Int32)] 
[{a: 1, b: 2}, NamedTuple(a: Int32, b: Int32)]
&lt;/syntaxhighlight&gt;
: Crystal の整数は Int32、浮動小数点数は Float64 です。

;サイズを指定した数リテラル:&lt;syntaxhighlight lang=Crystal&gt;
[1_i64, 2_u32, 3_u64, 4_i32, 5_i16, 6_u8, 7_i128, 8_u128, 3.14_f32, 1.44_f64].each{|x|
  p [x, x.class]
}
&lt;/syntaxhighlight&gt;
;ruby:Rubyでは、サーフィックスの付いた数値リテラルは無効
;crystalの実行結果:&lt;syntaxhighlight lang=&quot;console&quot;&gt;
[1, Int64]
[2, UInt32]
[3, UInt64]
[4, Int32]
[5, Int16]
[6, UInt8]
[7, Int128]
[8, UInt128]
[3.14, Float32] 
[1.44, Float64]
&lt;/syntaxhighlight&gt;
: Crystal では、数値リテラルに _ で始まるサーフィックスを付け { i:符号付き整数, u:符号なし整数, f:浮動小数点数 } と { 8,16,32,64,128 } のビット幅の組合せです&lt;ref&gt;[https://crystal-lang.org/reference/1.5/syntax_and_semantics/literals/ Literals]&lt;/ref&gt;。

=== for式がない ===
Crystal には、Ruby にはある for式がありません。
;Rubyのfor式の構文:&lt;syntaxhighlight lang=&quot;ruby&quot;&gt;
for 変数 in コレクション
  文
end
&lt;/syntaxhighlight&gt;
:コレクションは Range, Array, Hash など内部構造を持つオブジェクトです。
:for式は、最後に評価した値を返すので、for'''式'''です。

;for式のeachメソッドによる置換え:&lt;syntaxhighlight lang=&quot;ruby&quot;&gt;
for x in [ 2, 3, 5, 7, 11 ] do
  p x
end
# ↓
[ 2, 3, 5, 7, 11 ].each do | x |
  p x
end
&lt;/syntaxhighlight&gt;
: の様にコレクションの each メソッドで置換え可能なので、Rubyからの移植でも小規模な書換えで済みます&lt;ref&gt;[https://github.com/crystal-lang/crystal/issues/830 &quot;For&quot; Loop support #830]&lt;/ref&gt;（後述のマクロで実装できないかと思いましたが、いまのところ無理のようです）。
また loop 式もありませんが while true;  … end で間に合います。Ruby では while 式の条件の次に do が置けますが、Crystal では置けません。

=== eval()がない ===
Crystal には eval() はありません。
Crystalはコンパイル型言語ですので、無理もないことです。
もし、Crystal で eval() を実装しようとすると、Common Lisp の様にインタープリターを丸ごとランタイムに含む必要があります。
これはリーズナブルな選択ではありません。
Crystal では、eval() が必要なケースに（限定的ですが）マクロを使うことが出来る可能性があります。

=== マクロ ===
Crystalには、Rubyにはないマクロがあります&lt;ref&gt;[https://crystal-lang.org/reference/1.5/syntax_and_semantics/macros/ Macros - Crystal]&lt;/ref&gt;。Rubyは実行時にすべてのオブジェクトにアクセス出来て、メソッド生やし放題なのでマクロは必要ありませんが、Crystalはコンパイル時に型やメソッドを確定する必要があり、特にメソッドジェネレターとしてのマクロにニーズがあります。また、テンプレート言語的なマクロなので、環境変数による条件分岐や、コンテナを渡し繰返し処理する構文もあります（面白いことにマクロには for 文があり、反対にマクロの中では、eachメソッドは使えません）。マクロには &lt;code&gt;&lt;nowiki&gt;{{&lt;/nowiki&gt;attr.id}}&lt;/code&gt; の様にASTへのアクセス手順が用意されており、半ば言語を拡張するようなアプローチを取ることも出来ます。

[TODO:ASTについての解説；コラム向き？]

;マクロを使ったattr_accessorのイミュレーション:&lt;syntaxhighlight lang=crystal&gt;
class Point
  def initialize(@x : Int32, @y : Int32)
  end

  # macro定義
  macro attr_accessor(*attrs)
    {% for attr in attrs %}
      def {{attr.id}}() @{{attr.id}} end
      def {{attr.id}}=(var) @{{attr.id}} = var end
    {% end %}
  end

  # macro呼出し
  attr_accessor :x, :y
end

pt = Point.new(20, 30)
p [pt.x, pt.y]
t = pt.x
pt.x = pt.y
pt.y = t
p [pt.x, pt.y]
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
[20, 30]
[30, 20]
&lt;/syntaxhighlight&gt;
: Ruby には、attr_accessor と言う「クラスのメンバーのアクセサーを自動生成するメソッド」がありますが、Crystalにはないようなので、マクロで実装しました。
:: attr_accessor :name からは
::&lt;syntaxhighlight lang=ruby&gt;
def name()     @name end
def name=(val) @name = val end
&lt;/syntaxhighlight&gt;相当のコードが生成されます。
[TODO:マクロの機能と構文の説明 *の付いた引数、 &lt;nowiki&gt;{{&lt;/nowiki&gt;引数}}、{% … %} 構文]

==== マクロ p! ====
メソッド p は、与えられた「式」の inspaect() の返す値を puts しますが、マクロ p! は、それに先んじて（評価前の）「式」を表示します&lt;ref&gt;[https://crystal-lang.org/api/1.5.0/Crystal/Macros.html#p%21%28%2Aexpressions%29%3ANop-instance-method def p!(*expressions) : Nop]&lt;/ref&gt;。
;p!の例:&lt;syntaxhighlight lang=crystal&gt;
x, y = true, false

p! x,y,x &amp;&amp; y, x || y, x ^ y, !x, x != y, x == y

ary = [ 1, 2, 3 ]

p! ary

p! ary.map(&amp;. &lt;&lt; 1)

p! ary.map(&amp;.to_f)
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
x      # =&gt; true
y      # =&gt; false
x &amp;&amp; y # =&gt; false
x || y # =&gt; true
x ^ y  # =&gt; true
!x     # =&gt; false
x != y # =&gt; true
x == y # =&gt; false
ary # =&gt; [1, 2, 3]
ary.map(&amp;.&lt;&lt;(1)) # =&gt; [2, 4, 6]
ary.map(&amp;.to_f) # =&gt; [1.0, 2.0, 3.0]
&lt;/syntaxhighlight&gt;

===== 入れ子のp! =====
マクロ p! は入れ子に出来ます。また、一旦ASTに変換してから再度ソースコードに変換するので、等価な別の構文に変換されることがあります。
;入れ子のp!:&lt;syntaxhighlight lang=crystal&gt;
p! (
  100.times{|i|
    p! i
    break i if i &gt; 12
  }
)
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
(100.times do |i|
 p!(i)
 if i &gt; 12
   break i
 end
end) # =&gt; i
# =&gt; 0
i # =&gt; 1
i # =&gt; 2
i # =&gt; 3
i # =&gt; 4
i # =&gt; 5
i # =&gt; 6
i # =&gt; 7
i # =&gt; 8
i # =&gt; 9
i # =&gt; 10
i # =&gt; 11
i # =&gt; 12
i # =&gt; 13
13
&lt;/syntaxhighlight&gt;

=== クラス ===

==== シンプルなクラス ====
;シンプルなクラス:&lt;syntaxhighlight lang=crystal highlight=&quot;2&quot; line&gt;
class Hello
  def initialize(@name : String = &quot;World&quot;)
  end

  def greeting
    puts &quot;Hello #{@name}!&quot;
  end
end

hello = Hello.new()
hello.greeting

universe = Hello.new(&quot;Universe&quot;)
universe.greeting
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
Hello World!
Hello Universe!
&lt;/syntaxhighlight&gt;
:;初期化メソッド
:: &lt;syntaxhighlight lang=crystal line start=4&gt;
  def initialize(@name : String = &quot;World&quot;)
  end
&lt;/syntaxhighlight&gt;
::Rubyであれば
:: &lt;syntaxhighlight lang=ruby line start=4&gt;
  def initialize(name = &quot;World&quot;)
    @name = name
  end
&lt;/syntaxhighlight&gt;
::とするところですが、Crystalでは、型アノテーション &lt;code&gt; : String&lt;/code&gt; を使い、引数の型を限定しました。
::また、（@ 付きの）アトリビュート名を仮引数にすると、そのままアトリビュート（a.k.a. インスタンス変数）に仮引数が代入されます。
::これは、C++のコンストラクターのメンバー初期化リストと同じアイディアですが、Crystalではインスタンス変数に @ が前置されるので、仮引数に @ が出現すればインスタンス変数の初期値だと自明で、聡明な選択です。


==== 都市間の大圏距離 ====
[[Ruby#ユーザー定義クラス]]の都市間の大圏距離を求めるメソッドを追加した例を、Crystalに移植しました。

;都市間の大圏距離:&lt;syntaxhighlight lang=crystal highlight=”2,7,12” line&gt;
class GeoCoord
  getter :longitude, :latitude

  def initialize(@longitude : Float64, @latitude : Float64)
  end

  def to_s(io)
    ew, ns = &quot;東経&quot;, &quot;北緯&quot;
    long, lat = @longitude, @latitude
    ew, long = &quot;西経&quot;, -long if long &lt; 0.0
    ns, lat = &quot;南緯&quot;, -lat if lat &lt; 0.0
    io &lt;&lt; &quot;(#{ew}: #{long}, #{ns}: #{lat})&quot;
  end # https://github.com/crystal-lang/crystal/issues/259
  def distance(other)
    i, r = Math::PI / 180, 6371.008
    Math.acos(Math.sin(@latitude*i) * Math.sin(other.latitude * i) +
              Math.cos(@latitude*i) * Math.cos(other.latitude * i) * Math.cos(@longitude * i - other.longitude * i)) * r
  end
end

# メソッドの先頭を大文字に出来ないのでクラス名のメソッドは作ることが出来ない
# def GeoCoord(lng : Float64, lat : Float64)
#  GeoCoord.new(lng, lat)
# end

Sites = {
  &quot;東京駅&quot;:         GeoCoord.new(139.7673068, 35.6809591),
  &quot;シドニー・オペラハウス&quot;: GeoCoord.new(151.215278, -33.856778),
  &quot;グリニッジ天文台&quot;:    GeoCoord.new(-0.0014, 51.4778),
}

Sites.each { |name, gc|
  puts &quot;#{name}: #{gc}&quot;
}

puts &quot;&quot;

keys, len = Sites.keys, Sites.size
keys.each_with_index { |x, i|
  y = keys[(i + 1) % len]
  puts &quot;#{x} ⇔ #{y}: #{Sites[x].distance(Sites[y])} [km]&quot;
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
東京駅: (東経: 139.7673068, 北緯: 35.6809591)
シドニー・オペラハウス: (東経: 151.215278, 南緯: 33.856778)
グリニッジ天文台: (西経: 0.0014, 北緯: 51.4778)

東京駅 ⇔ シドニー・オペラハウス: 7823.269299386704 [km]
シドニー・オペラハウス ⇔ グリニッジ天文台: 16987.2708377249 [km]
グリニッジ天文台 ⇔ 東京駅: 9560.546566490015 [km]
&lt;/syntaxhighlight&gt;
:Crystal には、&lt;syntaxhighlight lang=ruby inline&gt;  attr_accessor &lt;/syntaxhighlight&gt; はありませんが、標準ライブラリーのマクロに &lt;syntaxhighlight lang=crystal inline&gt;  getter &lt;/syntaxhighlight&gt;があるので
:: &lt;syntaxhighlight lang=crystal line start=2&gt;
  getter :longitude, :latitude
&lt;/syntaxhighlight&gt;
::としました。
::将来、&lt;syntaxhighlight lang=ruby inline&gt;  attr_accessor &lt;/syntaxhighlight&gt; が実装される可能性はありますが、姉妹品の&lt;syntaxhighlight lang=crystal inline&gt;  setter &lt;/syntaxhighlight&gt;　との併用が下位互換性を考えると確実です。
: to_s は、Ruby ならば
:: &lt;syntaxhighlight lang=ruby line start=7&gt;
  def to_s()
&lt;/syntaxhighlight&gt;
:: &lt;syntaxhighlight lang=ruby line start=12&gt;
    &quot;(#{ew}: #{long}, #{ns}: #{lat})&quot;
&lt;/syntaxhighlight&gt;
:: ですが、Crystalでは追加の引数 &lt;var&gt;io&lt;/var&gt; が必要で
:: &lt;syntaxhighlight lang=ruby line start=7&gt;
  def to_s(io)
&lt;/syntaxhighlight&gt;
:: &lt;syntaxhighlight lang=ruby line start=12&gt;
    io &lt;&lt; &quot;(#{ew}: #{long}, #{ns}: #{lat})&quot;
&lt;/syntaxhighlight&gt;
: Ruby にはクラス名と同じ名前のメソッドで .new を呼出す文化があるのですが、Crystalはメソッドの先頭を大文字に出来ないので、これは見送りました。

==== 包含と継承 ====
[[JavaScript/クラス#包含と継承]]を、Rubyに移植した[[Ruby#包含と継承]]を、Crystalに移植しました。

;包含と継承の例:&lt;syntaxhighlight lang=crystal line&gt;
class Point
  def initialize(@x = 0, @y = 0)
  end

  def inspect(io)
    io &lt;&lt; &quot;x:#{@x}, y:#{@y}&quot;
  end

  def move(dx = 0, dy = 0)
    @x, @y = @x + dx, @y + dy
    self
  end
end

class Shape
  def initialize(x = 0, y = 0)
    @location = Point.new(x, y)
  end

  def inspect(io)
    @location.inspect(io)
  end

  def move(x, y)
    @location.move(x, y)
    self
  end
end

class Rectangle &lt; Shape
  def initialize(x = 0, y = 0, @width = 0, @height = 0)
    super(x, y)
  end

  def inspect(io)
    super(io)
    io &lt;&lt; &quot;, width:#{@width}, height:#{@height}&quot;
  end
end

rct = Rectangle.new(12, 32, 100, 50)
p! rct,
  rct.is_a?(Rectangle),
  rct.is_a?(Shape),
  rct.is_a?(Point),
  rct.move(11, 21)
(END)&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
rct                  # =&gt; x:12, y:32, width:100, height:50 
rct.is_a?(Rectangle) # =&gt; true 
rct.is_a?(Shape)     # =&gt; true 
rct.is_a?(Point)     # =&gt; false 
rct.move(11, 21)     # =&gt; x:23, y:53, width:100, height:50 
&lt;/syntaxhighlight&gt;
;crystal tool hierarchy:&lt;syntaxhighlight lang=console&gt;
% crystal tool hierarchy inclusion-and-inheritance.cr -e Shape
- class Object (4 bytes)
  |
  +- class Reference (4 bytes)
     |
     +- class Shape (16 bytes)
        .   @location : Point (8 bytes)
        |
        +- class Rectangle (24 bytes)
               @width  : Int32 (4 bytes)
               @height : Int32 (4 bytes)
&lt;/syntaxhighlight&gt;
: crystal の tool hierarchy サブコマンドで、クラスの継承関係がわかります。

===== superclass と subclasses =====
Crystal には、RubyのClassにあるメソッド superclass と subclasses がないので、マクロで実装しました。
;superclass と subclasses:&lt;syntaxhighlight lang=crystal line&gt;
class Class
  def self.superclass
    {{ @type.superclass }}
  end

  def self.subclasses : Array(self.class)
    {{ @type.subclasses }}.map(&amp;.as(self.class))
  end

  def self.all_subclasses : Array(self.class)
    {% begin %}
      [{{ @type.all_subclasses.join(&quot;,&quot;).id }}] of self.class
    {% end %}
  end
end
 
class A end
class AA &lt; A end
class AAA &lt; AA end
class AAB &lt; AA end
class AB &lt; A end

p! A,
  A.subclasses,
  A.all_subclasses,
  AAA.superclass,
  A.superclass
 
c = AAA
while !c.is_a? Nil
  p! c.superclass
  c = c.superclass
end&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
A                # =&gt; A 
A.subclasses     # =&gt; [AA, AB] 
A.all_subclasses # =&gt; [AA, AAA, AAB, AB] 
AAA.superclass   # =&gt; AA 
A.superclass     # =&gt; Reference 
c.superclass # =&gt; AA 
c.superclass # =&gt; A 
c.superclass # =&gt; Reference 
c.superclass # =&gt; Object 
c.superclass # =&gt; nil
&lt;/syntaxhighlight&gt;

==== 抽象クラス ====
[[Java/抽象クラス]]を、Crystalに移植しました。

;抽象クラスの宣言:&lt;syntaxhighlight lang=Java&gt;
abstract class クラス名
  #
end
&lt;/syntaxhighlight&gt;
: このクラス名は、 .new でインスタンス化出来ません。
:: Error: can't instantiate abstract class クラス名
: となります。
:インスタンス化することは出来ませんが、抽象クラスを別のクラスが継承する事は出来ます。
:また、抽象クラスを &lt;code&gt;super()&lt;/code&gt; を使うことでメソッドを呼び出せるので、抽象メソッドではないメソッド（具象メソッド）を持つことも、インスタンス変数も持つことも出来ます。
:'''抽象クラスの例'''では、Shapeのinitializeメソッドが抽象クラスの具象メソッドとなっています。
;抽象メソッドの宣言:&lt;syntaxhighlight lang=Java&gt;
  abstract def メソッド名
&lt;/syntaxhighlight&gt;
: 派生先のクラスで、「メソッド名」を定義(def)し忘れると
:: Error: abstract `def クラス名#メソッド名()` must be implemented by クラス名
: となります

;抽象クラスの例:&lt;syntaxhighlight lang=crystal line&gt;
abstract class Shape
  def initialize(@x = 0.0, @y = 0.0)
  end

  abstract def to_s(io)
  abstract def area
end

class Square &lt; Shape
  def initialize(x, y, @wh = 0.0)
    super(x, y)
  end

  def to_s(io)
    io &lt;&lt; &quot;Square(#{@x}, #{@y}, #{@wh})&quot;
  end

  def area
    @wh * @wh
  end
end

abstract class Shape
  def initialize(@x = 0.0, @y = 0.0)
  end

  abstract def to_s(io)
  abstract def area
end

class Square &lt; Shape
  def initialize(x, y, @wh = 0.0)
    super(x, y)
  end

  def to_s(io)
    io &lt;&lt; &quot;Square(#{@x}, #{@y}, #{@wh})&quot;
  end

  def area
    @wh * @wh
  end
end

class Recrangle &lt; Shape
  def initialize(x, y, @w = 0.0, @h = 0.0)
    super(x, y)
  end

  def to_s(io)
    io &lt;&lt; &quot;Rectanle(#{@x}, #{@y}, #{@w}, #{@h})&quot;
  end

  def area
    @w * @h
  end
end

class Circle &lt; Shape
  def initialize(x, y, @r = 0.0)
    super(x, y)
  end

  def to_s(io)
    io &lt;&lt; &quot;Circle(#{@x}, #{@y}, #{@r})&quot;
  end

  def area
    3.1425926536 * @r * @r
  end
end

shapes = [
  Square.new(5.0, 10.0, 15.0),
  Recrangle.new(13.0, 23.0, 20.0, 10.0),
  Circle.new(3.0, 2.0, 20.0),
] of Shape

shapes.each do |shape|
  puts(&quot;#{shape}: #{shape.area}&quot;)
end
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
Square(5.0, 10.0, 15.0): 225.0
Rectanle(13.0, 23.0, 20.0, 10.0): 200.0
Circle(3.0, 2.0, 20.0): 1257.03706144
&lt;/syntaxhighlight&gt;
;crystal tool hierarchy:&lt;syntaxhighlight lang=console&gt;
% crystal tool hierarchy abstract.cr -e Shape
- class Object (4 bytes)
  |
  +- class Reference (4 bytes)
     |
     +- class Shape (24 bytes)
        .   @x : Float64 (8 bytes)
        .   @y : Float64 (8 bytes)
        |
        +- class Circle (32 bytes)
        |      @r : Float64 (8 bytes)
        |
        +- class Recrangle (40 bytes)
        |      @w : Float64 (8 bytes)
        |      @h : Float64 (8 bytes)
        |
        +- class Square (32 bytes)
               @wh : Float64 (8 bytes)
&lt;/syntaxhighlight&gt;
: crystal の tool hierarchy サブコマンドで、クラスの継承関係がわかります。
: 「包含と継承の例」と比べると、ShapeとRectangleが同じ階層にあることがわかると思います。

[TODO:virtual class::いい例がない]

== キーワード ==
Crystalのキーワード( ''keywords'' ) は、以下の通り。

&lt;code&gt;abstract&lt;/code&gt; &lt;code&gt;alias&lt;/code&gt; &lt;code&gt;as&lt;/code&gt; &lt;code&gt;asm&lt;/code&gt; &lt;code&gt;begin&lt;/code&gt; &lt;code&gt;break&lt;/code&gt; &lt;code&gt;case&lt;/code&gt; &lt;code&gt;class&lt;/code&gt; &lt;code&gt;def&lt;/code&gt; &lt;code&gt;do&lt;/code&gt; &lt;code&gt;else&lt;/code&gt; &lt;code&gt;elsif&lt;/code&gt; &lt;code&gt;end&lt;/code&gt; &lt;code&gt;ensure&lt;/code&gt; &lt;code&gt;enum&lt;/code&gt; &lt;code&gt;extend&lt;/code&gt; &lt;code&gt;for&lt;/code&gt; &lt;code&gt;fun&lt;/code&gt; &lt;code&gt;if&lt;/code&gt; &lt;code&gt;include&lt;/code&gt; &lt;code&gt;instance_sizeof&lt;/code&gt; &lt;code&gt;lib&lt;/code&gt; &lt;code&gt;macro&lt;/code&gt; &lt;code&gt;module&lt;/code&gt; &lt;code&gt;next&lt;/code&gt; &lt;code&gt;of&lt;/code&gt; &lt;code&gt;out&lt;/code&gt; &lt;code&gt;pointerof&lt;/code&gt; &lt;code&gt;private&lt;/code&gt; &lt;code&gt;protected&lt;/code&gt; &lt;code&gt;rescue&lt;/code&gt; &lt;code&gt;return&lt;/code&gt; &lt;code&gt;require&lt;/code&gt; &lt;code&gt;select&lt;/code&gt; &lt;code&gt;sizeof&lt;/code&gt; &lt;code&gt;struct&lt;/code&gt; &lt;code&gt;super&lt;/code&gt; &lt;code&gt;then&lt;/code&gt; &lt;code&gt;type&lt;/code&gt; &lt;code&gt;typeof&lt;/code&gt; &lt;code&gt;uninitialized&lt;/code&gt; &lt;code&gt;union&lt;/code&gt; &lt;code&gt;unless&lt;/code&gt; &lt;code&gt;until&lt;/code&gt; &lt;code&gt;when&lt;/code&gt; &lt;code&gt;while&lt;/code&gt; &lt;code&gt;with&lt;/code&gt; &lt;code&gt;yield&lt;/code&gt;
&lt;!--
 &lt;code&gt;__DIR__&lt;/code&gt; &lt;code&gt;__END_LINE__&lt;/code&gt; &lt;code&gt;__FILE__&lt;/code&gt; &lt;code&gt;__LINE__&lt;/code&gt;
--&gt;

==  演算子 ==
Crystalは、1つ、2つ、または3つのオペランドを持つ数多くの演算子をサポートしています&lt;ref&gt;[https://crystal-lang.org/reference/1.5/syntax_and_semantics/operators.html Operators]access-date:2022-07-22&lt;/ref&gt;。

演算子式は、実際にはメソッド呼び出しとしてパースされます。例えば、&lt;code&gt;a + b&lt;/code&gt; は &lt;code&gt;a.+(b)&lt;/code&gt; と意味的に同じで、引数 b を持つ a のメソッド + を呼び出すことになります。

{| class=&quot;wikitable&quot;
|+ 演算子の優先度
!種類
!演算子
|-
|インデックス アクセサー
|&lt;code&gt;[]&lt;/code&gt;, &lt;code&gt;[]?&lt;/code&gt;
|-
|単項
|&lt;code&gt;+&lt;/code&gt;, &lt;code&gt;&amp;+&lt;/code&gt;, &lt;code&gt;-&lt;/code&gt;, &lt;code&gt;&amp;-&lt;/code&gt;, &lt;code&gt;!&lt;/code&gt;, &lt;code&gt;~&lt;/code&gt;
|-
|指数
|&lt;code&gt;**&lt;/code&gt;, &lt;code&gt;&amp;**&lt;/code&gt;
|-
|乗除
|&lt;code&gt;*&lt;/code&gt;, &lt;code&gt;&amp;*&lt;/code&gt;, &lt;code&gt;/&lt;/code&gt;, &lt;code&gt;//&lt;/code&gt;, &lt;code&gt;%&lt;/code&gt;
|-
|加減
|&lt;code&gt;+&lt;/code&gt;, &lt;code&gt;&amp;+&lt;/code&gt;, &lt;code&gt;-&lt;/code&gt;, &lt;code&gt;&amp;-&lt;/code&gt;
|-
|シフト
|&lt;code&gt;&lt;&lt;&lt;/code&gt;, &lt;code&gt;&gt;&gt;&lt;/code&gt;
|-
|ビット間 AND
|&lt;code&gt;&amp;&lt;/code&gt;
|-
|ビット間 OR/XOR
|&lt;code&gt;&lt;nowiki&gt;|&lt;/nowiki&gt;&lt;/code&gt;,&lt;code&gt;^&lt;/code&gt;
|-
|等値
|&lt;code&gt;==&lt;/code&gt;, &lt;code&gt;!=&lt;/code&gt;, &lt;code&gt;=~&lt;/code&gt;, &lt;code&gt;!~&lt;/code&gt;, &lt;code&gt;===&lt;/code&gt;
|-
|比較
|&lt;code&gt;&lt;&lt;/code&gt;, &lt;code&gt;&lt;=&lt;/code&gt;, &lt;code&gt;&gt;&lt;/code&gt;, &lt;code&gt;&gt;=&lt;/code&gt;, &lt;code&gt;&lt;=&gt;&lt;/code&gt;
|-
|論理 AND
|&lt;code&gt;&amp;&amp;&lt;/code&gt;
|-
|論理 OR
|&lt;code&gt;&lt;nowiki&gt;||&lt;/nowiki&gt;&lt;/code&gt;
|-
|Range
|&lt;code&gt;..&lt;/code&gt;, &lt;code&gt;...&lt;/code&gt;
|-
|条件
|&lt;code&gt;?:&lt;/code&gt;
|-
|代入
|&lt;code&gt;=&lt;/code&gt;, &lt;code&gt;[]=&lt;/code&gt;, &lt;code&gt;+=&lt;/code&gt;, &lt;code&gt;&amp;+=&lt;/code&gt;, &lt;code&gt;-=&lt;/code&gt;, &lt;code&gt;&amp;-=&lt;/code&gt;, &lt;code&gt;*=&lt;/code&gt;, &lt;code&gt;&amp;*=&lt;/code&gt;, &lt;code&gt;/=&lt;/code&gt;, &lt;code&gt;//=&lt;/code&gt;, &lt;code&gt;%=&lt;/code&gt;, &lt;code&gt;&lt;nowiki&gt;|=&lt;/nowiki&gt;&lt;/code&gt;, &lt;code&gt;&amp;=&lt;/code&gt;,&lt;code&gt;^=&lt;/code&gt;,&lt;code&gt;**=&lt;/code&gt;,&lt;code&gt;&lt;&lt;=&lt;/code&gt;,&lt;code&gt;&gt;&gt;=&lt;/code&gt;, &lt;code&gt;&lt;nowiki&gt;||=&lt;/nowiki&gt;&lt;/code&gt;, &lt;code&gt;&amp;&amp;=&lt;/code&gt;
|-
|スプラット
|&lt;code&gt;*&lt;/code&gt;, &lt;code&gt;**&lt;/code&gt;
|}

== 制御構造 ==
'''[[w:制御構造|制御構造]]'''（せいぎょこうぞう、''control flow''）とは、「順次」「分岐」「反復」という基本的な処理のことを言います。

{{コラム|Crystalの真理値|2=
制御構造は「条件式」が真であるか偽であるかによって分岐や反復の振る舞いが変わります。
では「条件式」が真・偽はどの様に決まるのでしょう？

Crystalでは &lt;code&gt;false&lt;/code&gt; あるいは &lt;code&gt;nil&lt;/code&gt; であると偽、それ以外が真です。

なので &lt;code&gt;0&lt;/code&gt; も &lt;code&gt;[]&lt;/code&gt;（空のArray） も &lt;code&gt;{}&lt;/code&gt;（空のNamedTuple）も真です。
}}
=== 条件分岐 ===
Crystalの条件分岐には、[[#if|if]], [[#until|until]] と [[#case|case]]の3つの構文があります。

==== if ====
'''[[w:if|if]]'''は条件式によって実行・否を切り替える構造構文で、評価した式の値を返すので条件演算子でもあります。

;ifの例:&lt;syntaxhighlight lang=crystal line&gt;
a = 0.0 / 0.0

if a &lt; 0
    puts &quot;minus&quot;
elsif a &gt; 0
    puts &quot;plus&quot;
elsif a == 0
    puts &quot;zero&quot;
else
    puts a
end

p! (
    if a &lt; 0
        &quot;minus&quot;
    elsif a &gt; 0
        &quot;plus&quot;
    elsif a == 0
        &quot;zero&quot;
    else
        a
    end
)
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
NaN 
(if a &lt; 0 
 &quot;minus&quot; 
else 
 if a &gt; 0 
   &quot;plus&quot; 
 else 
   if a == 0 
     &quot;zero&quot; 
   else 
     a 
   end 
 end 
end) # =&gt; NaN
&lt;/syntaxhighlight&gt;
:; elsif節:ifは、オプショナルな elsif 節を設け、条件式が偽であった時に別の条件に合致した処理を実行させることが出来ます。
:; else節:ifは、オプショナルな else 節を設け、条件式が偽であった時に処理を実行させることが出来ます。
: ifは値を返すので、メソッドの実引数に使うことが出来ますし、代入演算の右辺にも使えます。

==== 後置のif ====
Crystalには、RubyやPerlのような後置のifがあります。

;後置のifの例:&lt;syntaxhighlight lang=crystal&gt;
n = 0

puts &quot;nは0&quot; if n == 0
puts &quot;nは1&quot; if n == 1
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
nは0
&lt;/syntaxhighlight&gt;

==== unless====
'''unless'''（アンレス）は条件式によって実行・否を切り替える構造構文ですが、ifとは条件式に対する挙動が逆です。

;unless文の例:&lt;syntaxhighlight lang=crystal line&gt;
a = 0.0 / 0.0

unless a == 0
    puts &quot;Non-zero&quot;
else
    puts a
end
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
Non-zero
&lt;/syntaxhighlight&gt;
:; else節 : unless文は、オプショナルな else 節を設け、条件式が真であった時に処理を実行させることが出来ます。
::また、unless文は elsif 節は持てません。

==== 後置のunless ====
Crystalには、RubyやPerlのような後置のunlessがあります。

;後置のunlessの例:&lt;syntaxhighlight lang=crystal&gt;
n = 0

puts &quot;nは0&quot; unless n == 0
puts &quot;nは1&quot; unless n == 1
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
nは1ではない
&lt;/syntaxhighlight&gt;

==== case ====
caseは、複数の条件式によって処理を降る分ける用途の為に用意されています。

;caseの例:&lt;syntaxhighlight lang=crystal line&gt;
n = 2

case n
when 1
    puts &quot;one&quot;
when 2
    puts &quot;two&quot;
when 3
    puts &quot;three&quot;
else
    puts &quot;other&quot;
end

p! (
case n
when 1
    &quot;one&quot;
when 2
    &quot;two&quot;
when 3
    &quot;three&quot;
else
    &quot;other&quot;
end
)
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
two 
(case n 
when 1 
 &quot;one&quot; 
when 2 
 &quot;two&quot; 
when 3 
 &quot;three&quot; 
else 
 &quot;other&quot; 
end) # =&gt; &quot;two&quot;&lt;/syntaxhighlight&gt;
:C言語系のswitch文に慣れた人はbreakがないことに気がつくと思います。Crystalのcaseはfall throughしませんし、fall throughさせる方法もありません。

===== when節が定数でなく式を受付けます =====
[[#if|if]]を使ったコードをcaseに書き換えてみましょう。

;case の式の省略:&lt;syntaxhighlight lang=crystal line&gt;
a = 0.0 / 0.0
 
case
when a &lt; 0
  puts &quot;minus&quot;
when a &gt; 0
  puts &quot;plus&quot;
when a == 0
  puts &quot;zero&quot;
else
  puts a
end
 
p! (
case true
when a &lt; 0
  &quot;minus&quot;
when a &gt; 0
  &quot;plus&quot;
when a == 0
  &quot;zero&quot;
else
  a
end
)
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
NaN 
(case true 
when a &lt; 0 
 &quot;minus&quot; 
when a &gt; 0 
 &quot;plus&quot; 
when a == 0 
 &quot;zero&quot; 
else 
 a 
end) # =&gt; NaN
&lt;/syntaxhighlight&gt;
このコードは when 節の式の値とcaseの式を &lt;code&gt;===&lt;/code&gt; で比較し、最初に一致した when に対応する式が実行される事を利用しています。

===== 型による分岐 =====
when 節が式ではなく型であった場合、caseの式を &lt;code&gt;is_a?&lt;/code&gt; で評価し、最初に一致した when に対応する式が実行されます。

;型による分岐:&lt;syntaxhighlight lang=crystal line&gt;
p! 0.class,
	0.is_a?(Object),
	0.is_a?(Int32),
	0.is_a?(Number),
	0.is_a?(String)
 
case 0
when String
    puts &quot;String&quot;
when Number
    puts &quot;Number&quot;
when Int32
    puts &quot;Int32&quot;
when Object
    puts &quot;Object&quot;
else
    puts &quot;Unknown&quot;
end
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
0.class         # =&gt; Int32 
0.is_a?(Object) # =&gt; true 
0.is_a?(Int32)  # =&gt; true 
0.is_a?(Number) # =&gt; true 
0.is_a?(String) # =&gt; false 
Number
&lt;/syntaxhighlight&gt;
暗黙のオブジェクト構文を使うと
:&lt;syntaxhighlight lang=crystal line&gt;
case 0
when .is_a?(String)
    puts &quot;String&quot;
when .is_a?(Number)
    puts &quot;Number&quot;
when .is_a(Int32)
    puts &quot;Int32&quot;
when .is_a(Object)
    puts &quot;Object&quot;
else
    puts &quot;Unknown&quot;
end
&lt;/syntaxhighlight&gt;
:と書くことが出来ます。
:: メソッドは、.is_a? に限定しないので、 .odd? .even? .include? など Bool を返すメソッドなら何でも使えます。
when に対応する式は、1つのことが珍しくないので、その場合は省略可能な then を補うと、１行で書けます。
:&lt;syntaxhighlight lang=crystal line&gt;
case 0
when String then puts &quot;String&quot;
when Number then puts &quot;Number&quot;
when Int32  then puts &quot;Int32&quot;
when Object then puts &quot;Object&quot;
else             puts &quot;Unknown&quot;
end
&lt;/syntaxhighlight&gt;

[TODO:タプルとダミー識別子 _ ]

===== 網羅性の検査 =====
when の代わりに in を使用すると、exhaustive case 式が作成されます。exhaustive case では、必要な in 条件を省略するとコンパイル時にエラーとなります。排他的論理和では、when 節と else 節を含むことはできません。

コンパイラは、以下の in 条件をサポートしています。
:&lt;syntaxhighlight lang=crystal line&gt;
case 0
when String then puts &quot;String&quot;
when Number then puts &quot;Number&quot;
when Int32  then puts &quot;Int32&quot;
when Object then puts &quot;Object&quot;
else             puts &quot;Unknown&quot;
end
&lt;/syntaxhighlight&gt;

caseの式がユニオンの場合、各要素型を条件として使用することができる。
;組合型チェック:&lt;syntaxhighlight lang=crystal line&gt;
var : ( Bool | Int32 | Float64 )?
 
var = 3.14
 
p! (
case var
in Bool    then var ? 1 : 0
in Int32   then var
in Float64 then var.to_i
end
)
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
(case var 
in Bool 
 var ? 1 : 0 
in Int32 
 var 
in Float64 
 var.to_i 
end) # =&gt; 3
&lt;/syntaxhighlight&gt;

[TODO:case in は enum にも使える]

[TODO:短絡評価 &amp;&amp; || ]

=== 繰返し ===
Crystalには、他のプログラミング言語のような[[#繰返し構文|繰返し構文]]と、[[#イテレーターメソッド|イテレーターメソッド]]があります。

==== 繰返し構文 ====
Crystalの繰返し構文には、while と untilの2つがあります&lt;ref&gt;for も do-while も loop もありません。&lt;/ref&gt;。

===== while =====
while（ホワイル）は条件が'''真'''である間、式を実行しつづけます。
;構文:&lt;syntaxhighlight lang=crystal&gt;
while 条件式
    式１
    式２
      ：
    式ｎ
end
&lt;/syntaxhighlight&gt;
: Rubyと違い、条件式の後ろに &lt;code&gt;do&lt;/code&gt; をつけることは出来ません。

;while文のコード例:&lt;syntaxhighlight lang=crystal line&gt;
i = 0
p! (
while i &lt; 10
    p! i
    i += 1
    break i if i &gt; 5
end
)
&lt;/syntaxhighlight&gt;
: ２行目の &lt;code&gt;i &lt; 5&lt;/code&gt;が真の間、次の２行を繰返します。
: ４行目の &lt;code&gt;i += 1&lt;/code&gt; は &lt;code&gt;i = i + 1&lt;/code&gt; の構文糖
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
(while i &lt; 10 
 p!(i) 
 i = i + 1 
 if i &gt; 5 
   break i 
  end 
end)# =&gt; 
i # =&gt; 0 
i # =&gt; 1 
i # =&gt; 2 
i # =&gt; 3 
i # =&gt; 4 
i # =&gt; 5 
6
&lt;/syntaxhighlight&gt;

===== until =====
until（アンティル）は条件が'''偽'''である間、式を実行しつづけます。whileとは条件に対する挙動が逆です。
;構文:&lt;syntaxhighlight lang=crystal&gt;
until 条件式 [ do ]
    文１
    文２
      ：
    文ｎ
end
&lt;/syntaxhighlight&gt;
: &lt;code&gt;do&lt;/code&gt; は省略できます。

;untilのコード例:&lt;syntaxhighlight lang=crystal line&gt;
i = 0
until i == 3
    puts i
    i += 1
end
&lt;/syntaxhighlight&gt;
: ２行目の &lt;code&gt;i == 3&lt;/code&gt;が偽の間、次の２行を繰返します。
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
0
1
2
&lt;/syntaxhighlight&gt;

===== for =====
Crystalにはforがありませんが、コレクションのイテレーションメソッドを使うことで繰返しを簡素に実現出来ます。

==== Rangeオブジェクト ====
Rangeオブジェクトは、整数の区間を表し範囲演算子 &lt;code&gt;開始 ... 終了&lt;/code&gt; で生成します。

;コード:&lt;syntaxhighlight lang=crystal&gt;
rng = 1..3
puts rng.class
rng.each do | n |
  puts &quot;#{n}番&quot;;
end
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
Range(Int32, Int32) 
1番 
2番 
3番
&lt;/syntaxhighlight&gt;

==== Arrayオブジェクト ====
Arrayオブジェクトは、任意の Crystal オブジェクトを要素として持つことができます。
配列式&lt;code&gt;[要素1, 要素2, … 要素n]&lt;/code&gt; で生成します。

;コード:&lt;syntaxhighlight lang=crystal&gt;
animals = [&quot;ネコ&quot;, &quot;金魚&quot;, &quot;ハムスター&quot;]
 
puts animals.class
animals.each do | animal |
  puts &quot;動物 #{animal}&quot;
end
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
Array(String) 
動物 ネコ 
動物 金魚 
動物 ハムスター
&lt;/syntaxhighlight&gt;

==== NamedTupleオブジェクト ====
NamedTupleオブジェクトは、任意の Crystal オブジェクトをキーに、任意の Crystal オブジェクトを値に持つことができる連想配列です。
NamedTuple式&lt;code&gt;{キー1 =&gt; 値1, キー2 =&gt; 値2, キーn =&gt; 値n}&lt;/code&gt; で生成します。
また、キーが Symbol の場合
NamedTuple式&lt;code&gt;{キー1: 値1, キー2: 値2, キーn: 値n}&lt;/code&gt; で生成することが出来ます。

;コード:&lt;syntaxhighlight lang=crystal&gt;
animals = {cat: &quot;ネコ&quot;, gold_fish: &quot;金魚&quot;, hamster: &quot;ハムスター&quot;}
 
puts animals.class
 
animals.each do | en, animal |
  puts &quot;動物 #{en}: #{animal}&quot;
end
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
NamedTuple(cat: String, gold_fish: String, hamster: String)
動物 cat: ネコ
動物 gold_fish: 金魚
動物 hamster: ハムスター
&lt;/syntaxhighlight&gt;

このように、Crystalではforがなくてもコレクションのメソッドで同様の処理を実現できます。

===== loop =====
loop、ありません。
while true で代用します。

;loopの代用コード例:&lt;syntaxhighlight lang=crystal line&gt;
i = 1
while true
    puts &quot;0b%b&quot; % i
    i &lt;&lt;= 1
    break if i &gt; 2**8
end
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
0b1
0b10
0b100
0b1000
0b10000
0b100000
0b1000000
0b10000000 
0b100000000
&lt;/syntaxhighlight&gt;
:５行目の、&lt;code&gt;break if i &gt; 2**8&lt;/code&gt;でループを脱出するようにしています。この様に break や return あるいは例外が上がらないとループは永久に終わりません。
:このコードは、Crystalにはない do-while文を模倣する例にもなっています。

==== イテレーターメソッド ====
===== Integer#times =====
Integer#timesは与えられたブロックをオブジェクトの示す整数値回くりかえします。

:コード&lt;syntaxhighlight lang=crystal&gt;
3.times{ puts &quot;Hello, world!&quot; }
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
Hello, world!
Hello, world!
Hello, world!
&lt;/syntaxhighlight&gt;

;繰返したい処理が2行以上ある場合:&lt;syntaxhighlight lang=crystal&gt;
3.times {
  puts &quot;Hello&quot;
  puts &quot;World&quot;
  puts &quot;&quot;
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
Hello
World

Hello
World

Hello
World
&lt;/syntaxhighlight&gt;

;ループ変数を使た例:&lt;syntaxhighlight lang=crystal&gt;
3.times do |i|
  puts &quot;#{i}の倍は#{2 * i}&quot;
end
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
0の倍は0
1の倍は2
2の倍は4
&lt;/syntaxhighlight&gt;

;ブロックを伴わないtimesメソッド:&lt;syntaxhighlight lang=crystal&gt;
iter = 3.times
puts iter.class
p! iter.next
p! iter.next
p! iter.next
p! iter.next
p! iter.next
p! iter.next
# puts iter.next #  `next': StopIteration: iteration reached an end
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
Int::TimesIterator(Int32) 
iter.next # =&gt; 0 
iter.next # =&gt; 1 
iter.next # =&gt; 2 
iter.next # =&gt; #&lt;Iterator::Stop:0x7fb5bedd7fe0&gt; 
iter.next # =&gt; #&lt;Iterator::Stop:0x7fb5bedd7fe0&gt; 
iter.next # =&gt; #&lt;Iterator::Stop:0x7fb5bedd7fe0&gt;
&lt;/syntaxhighlight&gt;
: Integer#times にブロックを渡さないと、Int::TimesIterator([T])オブジェクトが返ります。
: Int::TimesIterator([T])オブジェクトは外部イテレーターと呼ばれnextメソッドで反復を行えます。

== メソッド ==
=== クラスのメソッド一覧 ===
Crystal には、Objectクラスにmethodsメソッドがないので、マクロで実装しました。

;RubyのObject#methods:&lt;syntaxhighlight lang=ruby&gt;
p Object.methods.sort,
  Integer.methods.sort,
  Float.methods.sort,
  Array.methods.sort,
  Range.methods.sort
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
[:!, :!=, :!~, :&lt;, :&lt;=, :&lt;=&gt;, :==, :===, :=~, :&gt;, :&gt;=, :__id__, :__send__, :alias_method, :allocate, :ancestors, :attr, :attr_accessor, :attr_reader, :attr_writer, :autoload, :autoload?, :class, :class_eval, :class_exec, :class_variable_defined?, :class_variable_get, :class_variable_set, :class_variables, :clone, :const_defined?, :const_get, :const_missing, :const_set, :const_source_location, :constants, :define_method, :define_singleton_method, :deprecate_constant, :display, :dup, :enum_for, :eql?, :equal?, :extend, :freeze, :frozen?, :hash, :include, :include?, :included_modules, :inspect, :instance_eval, :instance_exec, :instance_method, :instance_methods, :instance_of?, :instance_variable_defined?, :instance_variable_get, :instance_variable_set, :instance_variables, :is_a?, :itself, :kind_of?, :method, :method_defined?, :methods, :module_eval, :module_exec, :name, :new, :nil?, :object_id, :prepend, :private_class_method, :private_constant, :private_instance_methods, :private_method_defined?, :private_methods, :protected_instance_methods, :protected_method_defined?, :protected_methods, :public_class_method, :public_constant, :public_instance_method, :public_instance_methods, :public_method, :public_method_defined?, :public_methods, :public_send, :remove_class_variable, :remove_instance_variable, :remove_method, :respond_to?, :send, :singleton_class, :singleton_class?, :singleton_method, :singleton_methods, :subclasses, :superclass, :taint, :tainted?, :tap, :then, :to_enum, :to_s, :trust, :undef_method, :untaint, :untrust, :untrusted?, :yield_self]
[:!, :!=, :!~, :&lt;, :&lt;=, :&lt;=&gt;, :==, :===, :=~, :&gt;, :&gt;=, :__id__, :__send__, :alias_method, :allocate, :ancestors, :attr, :attr_accessor, :attr_reader, :attr_writer, :autoload, :autoload?, :class, :class_eval, :class_exec, :class_variable_defined?, :class_variable_get, :class_variable_set, :class_variables, :clone, :const_defined?, :const_get, :const_missing, :const_set, :const_source_location, :constants, :define_method, :define_singleton_method, :deprecate_constant, :display, :dup, :enum_for, :eql?, :equal?, :extend, :freeze, :frozen?, :hash, :include, :include?, :included_modules, :inspect, :instance_eval, :instance_exec, :instance_method, :instance_methods, :instance_of?, :instance_variable_defined?, :instance_variable_get, :instance_variable_set, :instance_variables, :is_a?, :itself, :kind_of?, :method, :method_defined?, :methods, :module_eval, :module_exec, :name, :nil?, :object_id, :prepend, :private_class_method, :private_constant, :private_instance_methods, :private_method_defined?, :private_methods, :protected_instance_methods, :protected_method_defined?, :protected_methods, :public_class_method, :public_constant, :public_instance_method, :public_instance_methods, :public_method, :public_method_defined?, :public_methods, :public_send, :remove_class_variable, :remove_instance_variable, :remove_method, :respond_to?, :send, :singleton_class, :singleton_class?, :singleton_method, :singleton_methods, :sqrt, :subclasses, :superclass, :taint, :tainted?, :tap, :then, :to_enum, :to_s, :trust, :try_convert, :undef_method, :untaint, :untrust, :untrusted?, :yield_self]
[:!, :!=, :!~, :&lt;, :&lt;=, :&lt;=&gt;, :==, :===, :=~, :&gt;, :&gt;=, :__id__, :__send__, :alias_method, :allocate, :ancestors, :attr, :attr_accessor, :attr_reader, :attr_writer, :autoload, :autoload?, :class, :class_eval, :class_exec, :class_variable_defined?, :class_variable_get, :class_variable_set, :class_variables, :clone, :const_defined?, :const_get, :const_missing, :const_set, :const_source_location, :constants, :define_method, :define_singleton_method, :deprecate_constant, :display, :dup, :enum_for, :eql?, :equal?, :extend, :freeze, :frozen?, :hash, :include, :include?, :included_modules, :inspect, :instance_eval, :instance_exec, :instance_method, :instance_methods, :instance_of?, :instance_variable_defined?, :instance_variable_get, :instance_variable_set, :instance_variables, :is_a?, :itself, :kind_of?, :method, :method_defined?, :methods, :module_eval, :module_exec, :name, :nil?, :object_id, :prepend, :private_class_method, :private_constant, :private_instance_methods, :private_method_defined?, :private_methods, :protected_instance_methods, :protected_method_defined?, :protected_methods, :public_class_method, :public_constant, :public_instance_method, :public_instance_methods, :public_method, :public_method_defined?, :public_methods, :public_send, :remove_class_variable, :remove_instance_variable, :remove_method, :respond_to?, :send, :singleton_class, :singleton_class?, :singleton_method, :singleton_methods, :subclasses, :superclass, :taint, :tainted?, :tap, :then, :to_enum, :to_s, :trust, :undef_method, :untaint, :untrust, :untrusted?, :yield_self]
[:!, :!=, :!~, :&lt;, :&lt;=, :&lt;=&gt;, :==, :===, :=~, :&gt;, :&gt;=, :[], :__id__, :__send__, :alias_method, :allocate, :ancestors, :attr, :attr_accessor, :attr_reader, :attr_writer, :autoload, :autoload?, :class, :class_eval, :class_exec, :class_variable_defined?, :class_variable_get, :class_variable_set, :class_variables, :clone, :const_defined?, :const_get, :const_missing, :const_set, :const_source_location, :constants, :define_method, :define_singleton_method, :deprecate_constant, :display, :dup, :enum_for, :eql?, :equal?, :extend, :freeze, :frozen?, :hash, :include, :include?, :included_modules, :inspect, :instance_eval, :instance_exec, :instance_method, :instance_methods, :instance_of?, :instance_variable_defined?, :instance_variable_get, :instance_variable_set, :instance_variables, :is_a?, :itself, :kind_of?, :method, :method_defined?, :methods, :module_eval, :module_exec, :name, :new, :nil?, :object_id, :prepend, :private_class_method, :private_constant, :private_instance_methods, :private_method_defined?, :private_methods, :protected_instance_methods, :protected_method_defined?, :protected_methods, :public_class_method, :public_constant, :public_instance_method, :public_instance_methods, :public_method, :public_method_defined?, :public_methods, :public_send, :remove_class_variable, :remove_instance_variable, :remove_method, :respond_to?, :send, :singleton_class, :singleton_class?, :singleton_method, :singleton_methods, :subclasses, :superclass, :taint, :tainted?, :tap, :then, :to_enum, :to_s, :trust, :try_convert, :undef_method, :untaint, :untrust, :untrusted?, :yield_self] 
[:!, :!=, :!~, :&lt;, :&lt;=, :&lt;=&gt;, :==, :===, :=~, :&gt;, :&gt;=, :__id__, :__send__, :alias_method, :allocate, :ancestors, :attr, :attr_accessor, :attr_reader, :attr_writer, :autoload, :autoload?, :class, :class_eval, :class_exec, :class_variable_defined?, :class_variable_get, :class_variable_set, :class_variables, :clone, :const_defined?, :const_get, :const_missing, :const_set, :const_source_location, :constants, :define_method, :define_singleton_method, :deprecate_constant, :display, :dup, :enum_for, :eql?, :equal?, :extend, :freeze, :frozen?, :hash, :include, :include?, :included_modules, :inspect, :instance_eval, :instance_exec, :instance_method, :instance_methods, :instance_of?, :instance_variable_defined?, :instance_variable_get, :instance_variable_set, :instance_variables, :is_a?, :itself, :kind_of?, :method, :method_defined?, :methods, :module_eval, :module_exec, :name, :new, :nil?, :object_id, :prepend, :private_class_method, :private_constant, :private_instance_methods, :private_method_defined?, :private_methods, :protected_instance_methods, :protected_method_defined?, :protected_methods, :public_class_method, :public_constant, :public_instance_method, :public_instance_methods, :public_method, :public_method_defined?, :public_methods, :public_send, :remove_class_variable, :remove_instance_variable, :remove_method, :respond_to?, :send, :singleton_class, :singleton_class?, :singleton_method, :singleton_methods, :subclasses, :superclass, :taint, :tainted?, :tap, :then, :to_enum, :to_s, :trust, :undef_method, :untaint, :untrust, :untrusted?, :yield_self]
&lt;/syntaxhighlight&gt;
;Crystalに実装したmethodsマクロ:&lt;syntaxhighlight lang=crystal&gt;
class Object
  macro methods
    {{ @type.methods.map(&amp;.name.stringify).sort.uniq }}
  end
end

p! Object.methods,
  Reference.methods,
  Array.methods,
  Box.methods,
  Channel.methods,
  Deque.methods,
  Dir.methods,
  Exception.methods,
  ArgumentError.methods,
  DivisionByZeroError.methods,
  IndexError.methods,
  InvalidByteSequenceError.methods,
  Fiber.methods,
  Hash.methods,
  IO.methods,
  File.methods,
  Mutex.methods,
  PrettyPrint.methods,
  Process.methods,
  Regex.methods,
  String.methods,
  Thread.methods,
  Bool.methods,
  Int32.methods,
  Float64.methods,
  Proc.methods
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
Object.methods                   # =&gt; [&quot;!=&quot;, &quot;!~&quot;, &quot;==&quot;, &quot;===&quot;, &quot;=~&quot;, &quot;class&quot;, &quot;crystal_type_id&quot;, &quot;dup&quot;, &quot;hash&quot;, &quot;in?&quot;, &quot;inspect&quot;, &quot;itself&quot;, &quot;not_nil!&quot;, &quot;pretty_inspect&quot;, &quot;pretty_print&quot;, &quot;tap&quot;, &quot;to_s&quot;, &quot;try&quot;, &quot;unsafe_as&quot;]
Reference.methods                # =&gt; [&quot;==&quot;, &quot;dup&quot;, &quot;exec_recursive&quot;, &quot;exec_recursive_clone&quot;, &quot;hash&quot;, &quot;inspect&quot;, &quot;object_id&quot;, &quot;pretty_print&quot;, &quot;same?&quot;, &quot;to_s&quot;]
Array.methods                    # =&gt; [&quot;&amp;&quot;, &quot;*&quot;, &quot;+&quot;, &quot;-&quot;, &quot;&lt;&lt;&quot;, &quot;&lt;=&gt;&quot;, &quot;==&quot;, &quot;[]&quot;, &quot;[]=&quot;, &quot;[]?&quot;, &quot;calculate_new_capacity&quot;, &quot;check_needs_resize&quot;, &quot;check_needs_resize_for_unshift&quot;, &quot;clear&quot;, &quot;clone&quot;, &quot;compact&quot;, &quot;compact!&quot;, &quot;concat&quot;, &quot;delete&quot;, &quot;delete_at&quot;, &quot;dup&quot;, &quot;each_repeated_permutation&quot;, &quot;fill&quot;, &quot;first&quot;, &quot;flatten&quot;, &quot;increase_capacity&quot;, &quot;increase_capacity_for_unshift&quot;, &quot;index&quot;, &quot;initialize&quot;, &quot;insert&quot;, &quot;inspect&quot;, &quot;internal_delete&quot;, &quot;last&quot;, &quot;map&quot;, &quot;map_with_index&quot;, &quot;needs_resize?&quot;, &quot;pop&quot;, &quot;pop?&quot;, &quot;pretty_print&quot;, &quot;product&quot;, &quot;push&quot;, &quot;reject!&quot;, &quot;remaining_capacity&quot;, &quot;repeated_permutations&quot;, &quot;replace&quot;, &quot;reset_buffer_to_root_buffer&quot;, &quot;resize_if_cant_insert&quot;, &quot;resize_to_capacity&quot;, &quot;resize_to_capacity_for_unshift&quot;, &quot;reverse&quot;, &quot;root_buffer&quot;, &quot;rotate&quot;, &quot;rotate!&quot;, &quot;select!&quot;, &quot;shift&quot;, &quot;shift?&quot;, &quot;shift_buffer_by&quot;, &quot;shift_when_not_empty&quot;, &quot;shuffle&quot;, &quot;size&quot;, &quot;size=&quot;, &quot;skip&quot;, &quot;sort&quot;, &quot;sort!&quot;, &quot;sort_by&quot;, &quot;sort_by!&quot;, &quot;to_a&quot;, &quot;to_lookup_hash&quot;, &quot;to_s&quot;, &quot;to_unsafe&quot;, &quot;to_unsafe_slice&quot;, &quot;transpose&quot;, &quot;truncate&quot;, &quot;uniq&quot;, &quot;uniq!&quot;, &quot;unsafe_fetch&quot;, &quot;unsafe_put&quot;, &quot;unshift&quot;, &quot;unstable_sort&quot;, &quot;unstable_sort!&quot;, &quot;unstable_sort_by&quot;, &quot;unstable_sort_by!&quot;, &quot;|&quot;]
Box.methods                      # =&gt; [&quot;initialize&quot;, &quot;object&quot;]
Channel.methods                  # =&gt; [&quot;close&quot;, &quot;closed?&quot;, &quot;dequeue_receiver&quot;, &quot;dequeue_sender&quot;, &quot;initialize&quot;, &quot;inspect&quot;, &quot;pretty_print&quot;, &quot;receive&quot;, &quot;receive?&quot;, &quot;receive_impl&quot;, &quot;receive_internal&quot;, &quot;receive_select_action&quot;, &quot;receive_select_action?&quot;, &quot;send&quot;, &quot;send_internal&quot;, &quot;send_select_action&quot;]
Deque.methods                    # =&gt; [&quot;+&quot;, &quot;&lt;&lt;&quot;, &quot;==&quot;, &quot;buffer&quot;, &quot;clear&quot;, &quot;clone&quot;, &quot;concat&quot;, &quot;delete&quot;, &quot;delete_at&quot;, &quot;dup&quot;, &quot;each&quot;, &quot;halfs&quot;, &quot;increase_capacity&quot;, &quot;initialize&quot;, &quot;insert&quot;, &quot;inspect&quot;, &quot;internal_delete&quot;, &quot;pop&quot;, &quot;pop?&quot;, &quot;pretty_print&quot;, &quot;push&quot;, &quot;reject!&quot;, &quot;rotate!&quot;, &quot;select!&quot;, &quot;shift&quot;, &quot;shift?&quot;, &quot;size&quot;, &quot;size=&quot;, &quot;to_s&quot;, &quot;unsafe_fetch&quot;, &quot;unsafe_put&quot;, &quot;unshift&quot;]
Dir.methods                      # =&gt; [&quot;children&quot;, &quot;close&quot;, &quot;each&quot;, &quot;each_child&quot;, &quot;entries&quot;, &quot;initialize&quot;, &quot;inspect&quot;, &quot;path&quot;, &quot;pretty_print&quot;, &quot;read&quot;, &quot;rewind&quot;, &quot;to_s&quot;]
Exception.methods                # =&gt; [&quot;backtrace&quot;, &quot;backtrace?&quot;, &quot;callstack&quot;, &quot;callstack=&quot;, &quot;cause&quot;, &quot;initialize&quot;, &quot;inspect&quot;, &quot;inspect_with_backtrace&quot;, &quot;message&quot;, &quot;to_s&quot;]
ArgumentError.methods            # =&gt; [&quot;initialize&quot;]
DivisionByZeroError.methods      # =&gt; [&quot;initialize&quot;]
IndexError.methods               # =&gt; [&quot;initialize&quot;]
InvalidByteSequenceError.methods # =&gt; [&quot;initialize&quot;]
Fiber.methods                    # =&gt; [&quot;cancel_timeout&quot;, &quot;dead?&quot;, &quot;enqueue&quot;, &quot;initialize&quot;, &quot;inspect&quot;, &quot;makecontext&quot;, &quot;name&quot;, &quot;name=&quot;, &quot;next&quot;, &quot;next=&quot;, &quot;previous&quot;, &quot;previous=&quot;, &quot;push_gc_roots&quot;, &quot;resumable?&quot;, &quot;resume&quot;, &quot;resume_event&quot;, &quot;run&quot;, &quot;running?&quot;, &quot;stack_bottom&quot;, &quot;stack_bottom=&quot;, &quot;timeout&quot;, &quot;timeout_event&quot;, &quot;timeout_select_action&quot;, &quot;timeout_select_action=&quot;, &quot;to_s&quot;]
Hash.methods                     # =&gt; [&quot;==&quot;, &quot;[]&quot;, &quot;[]=&quot;, &quot;[]?&quot;, &quot;add_entry_and_increment_size&quot;, &quot;clear&quot;, &quot;clear_entries&quot;, &quot;clear_impl&quot;, &quot;clear_indices&quot;, &quot;clone&quot;, &quot;compact&quot;, &quot;compact!&quot;, &quot;compare_by_identity&quot;, &quot;compare_by_identity?&quot;, &quot;compute_indices_bytesize&quot;, &quot;delete&quot;, &quot;delete_entry&quot;, &quot;delete_entry_and_update_counts&quot;, &quot;delete_impl&quot;, &quot;delete_linear_scan&quot;, &quot;dig&quot;, &quot;dig?&quot;, &quot;do_compaction&quot;, &quot;double_indices_size&quot;, &quot;dup&quot;, &quot;each&quot;, &quot;each_entry_with_index&quot;, &quot;each_key&quot;, &quot;each_value&quot;, &quot;empty?&quot;, &quot;entries&quot;, &quot;entries_capacity&quot;, &quot;entries_full?&quot;, &quot;entries_size&quot;, &quot;entry_matches?&quot;, &quot;fetch&quot;, &quot;find_entry&quot;, &quot;find_entry_with_index&quot;, &quot;find_entry_with_index_linear_scan&quot;, &quot;first_entry?&quot;, &quot;first_key&quot;, &quot;first_key?&quot;, &quot;first_value&quot;, &quot;first_value?&quot;, &quot;fit_in_indices&quot;, &quot;get_entry&quot;, &quot;get_index&quot;, &quot;has_key?&quot;, &quot;has_value?&quot;, &quot;hash&quot;, &quot;indices_malloc_size&quot;, &quot;indices_size&quot;, &quot;initialize&quot;, &quot;initialize_clone&quot;, &quot;initialize_clone_entries&quot;, &quot;initialize_compare_by_identity&quot;, &quot;initialize_copy_non_entries_vars&quot;, &quot;initialize_default_block&quot;, &quot;initialize_dup&quot;, &quot;initialize_dup_entries&quot;, &quot;inspect&quot;, &quot;invert&quot;, &quot;key_for&quot;, &quot;key_for?&quot;, &quot;key_hash&quot;, &quot;keys&quot;, &quot;last_entry?&quot;, &quot;last_key&quot;, &quot;last_key?&quot;, &quot;last_value&quot;, &quot;last_value?&quot;, &quot;malloc_entries&quot;, &quot;malloc_indices&quot;, &quot;merge&quot;, &quot;merge!&quot;, &quot;merge_into!&quot;, &quot;next_index&quot;, &quot;pretty_print&quot;, &quot;proper_subset_of?&quot;, &quot;proper_superset_of?&quot;, &quot;put&quot;, &quot;realloc_entries&quot;, &quot;realloc_indices&quot;, &quot;rehash&quot;, &quot;reject&quot;, &quot;reject!&quot;, &quot;resize&quot;, &quot;select&quot;, &quot;select!&quot;, &quot;set_entry&quot;, &quot;set_index&quot;, &quot;shift&quot;, &quot;shift?&quot;, &quot;size&quot;, &quot;subset_of?&quot;, &quot;superset_of?&quot;, &quot;to_a&quot;, &quot;to_a_impl&quot;, &quot;to_h&quot;, &quot;to_s&quot;, &quot;transform_keys&quot;, &quot;transform_values&quot;, &quot;transform_values!&quot;, &quot;update&quot;, &quot;update_linear_scan&quot;, &quot;upsert&quot;, &quot;values&quot;, &quot;values_at&quot;]
IO.methods                       # =&gt; [&quot;&lt;&lt;&quot;, &quot;check_open&quot;, &quot;close&quot;, &quot;closed?&quot;, &quot;decoder&quot;, &quot;each_byte&quot;, &quot;each_char&quot;, &quot;each_line&quot;, &quot;encoder&quot;, &quot;encoding&quot;, &quot;flush&quot;, &quot;getb_to_end&quot;, &quot;gets&quot;, &quot;gets_peek&quot;, &quot;gets_slow&quot;, &quot;gets_to_end&quot;, &quot;has_non_utf8_encoding?&quot;, &quot;peek&quot;, &quot;peek_or_read_utf8&quot;, &quot;peek_or_read_utf8_masked&quot;, &quot;pos&quot;, &quot;pos=&quot;, &quot;print&quot;, &quot;printf&quot;, &quot;puts&quot;, &quot;read&quot;, &quot;read_at&quot;, &quot;read_byte&quot;, &quot;read_bytes&quot;, &quot;read_char&quot;, &quot;read_char_with_bytesize&quot;, &quot;read_fully&quot;, &quot;read_fully?&quot;, &quot;read_line&quot;, &quot;read_string&quot;, &quot;read_utf8&quot;, &quot;read_utf8_byte&quot;, &quot;rewind&quot;, &quot;seek&quot;, &quot;set_encoding&quot;, &quot;skip&quot;, &quot;skip_to_end&quot;, &quot;tell&quot;, &quot;tty?&quot;, &quot;utf8_encoding?&quot;, &quot;write&quot;, &quot;write_byte&quot;, &quot;write_bytes&quot;, &quot;write_string&quot;, &quot;write_utf8&quot;]
File.methods                     # =&gt; [&quot;delete&quot;, &quot;initialize&quot;, &quot;inspect&quot;, &quot;path&quot;, &quot;read_at&quot;, &quot;size&quot;, &quot;truncate&quot;]
Mutex.methods                    # =&gt; [&quot;initialize&quot;, &quot;lock&quot;, &quot;lock_slow&quot;, &quot;synchronize&quot;, &quot;try_lock&quot;, &quot;unlock&quot;]
PrettyPrint.methods              # =&gt; [&quot;break_outmost_groups&quot;, &quot;breakable&quot;, &quot;comma&quot;, &quot;current_group&quot;, &quot;fill_breakable&quot;, &quot;flush&quot;, &quot;group&quot;, &quot;group_queue&quot;, &quot;group_sub&quot;, &quot;indent&quot;, &quot;initialize&quot;, &quot;list&quot;, &quot;nest&quot;, &quot;newline&quot;, &quot;surround&quot;, &quot;text&quot;]
Process.methods                  # =&gt; [&quot;channel&quot;, &quot;close&quot;, &quot;close_io&quot;, &quot;copy_io&quot;, &quot;ensure_channel&quot;, &quot;error&quot;, &quot;error?&quot;, &quot;exists?&quot;, &quot;finalize&quot;, &quot;initialize&quot;, &quot;input&quot;, &quot;input?&quot;, &quot;output&quot;, &quot;output?&quot;, &quot;pid&quot;, &quot;signal&quot;, &quot;stdio_to_fd&quot;, &quot;terminate&quot;, &quot;terminated?&quot;, &quot;wait&quot;]
Regex.methods                    # =&gt; [&quot;+&quot;, &quot;==&quot;, &quot;===&quot;, &quot;=~&quot;, &quot;capture_count&quot;, &quot;clone&quot;, &quot;dup&quot;, &quot;finalize&quot;, &quot;hash&quot;, &quot;initialize&quot;, &quot;inspect&quot;, &quot;internal_matches?&quot;, &quot;match&quot;, &quot;match_at_byte_index&quot;, &quot;matches?&quot;, &quot;matches_at_byte_index?&quot;, &quot;name_table&quot;, &quot;options&quot;, &quot;source&quot;, &quot;to_s&quot;]
String.methods                   # =&gt; [&quot;%&quot;, &quot;*&quot;, &quot;+&quot;, &quot;&lt;=&gt;&quot;, &quot;==&quot;, &quot;=~&quot;, &quot;[]&quot;, &quot;[]?&quot;, &quot;ascii_only?&quot;, &quot;blank?&quot;, &quot;byte_at&quot;, &quot;byte_at?&quot;, &quot;byte_delete_at&quot;, &quot;byte_index&quot;, &quot;byte_index_to_char_index&quot;, &quot;byte_slice&quot;, &quot;byte_slice?&quot;, &quot;bytes&quot;, &quot;bytesize&quot;, &quot;calc_excess_left&quot;, &quot;calc_excess_right&quot;, &quot;camelcase&quot;, &quot;capitalize&quot;, &quot;center&quot;, &quot;char_at&quot;, &quot;char_bytesize_at&quot;, &quot;char_index_to_byte_index&quot;, &quot;chars&quot;, &quot;check_no_null_byte&quot;, &quot;chomp&quot;, &quot;clone&quot;, &quot;codepoint_at&quot;, &quot;codepoints&quot;, &quot;compare&quot;, &quot;count&quot;, &quot;delete&quot;, &quot;delete_at&quot;, &quot;downcase&quot;, &quot;dump&quot;, &quot;dump_char&quot;, &quot;dump_hex&quot;, &quot;dump_or_inspect&quot;, &quot;dump_or_inspect_char&quot;, &quot;dump_or_inspect_unquoted&quot;, &quot;dump_unquoted&quot;, &quot;dup&quot;, &quot;each_byte&quot;, &quot;each_byte_index_and_char_index&quot;, &quot;each_char&quot;, &quot;each_char_with_index&quot;, &quot;each_codepoint&quot;, &quot;each_grapheme&quot;, &quot;each_grapheme_boundary&quot;, &quot;each_line&quot;, &quot;empty?&quot;, &quot;encode&quot;, &quot;ends_with?&quot;, &quot;find_start_and_end&quot;, &quot;grapheme_size&quot;, &quot;graphemes&quot;, &quot;gsub&quot;, &quot;gsub_append&quot;, &quot;gsub_ascii_char&quot;, &quot;has_back_references?&quot;, &quot;hash&quot;, &quot;hexbytes&quot;, &quot;hexbytes?&quot;, &quot;includes?&quot;, &quot;index&quot;, &quot;insert&quot;, &quot;insert_impl&quot;, &quot;inspect&quot;, &quot;inspect_char&quot;, &quot;inspect_unquoted&quot;, &quot;just&quot;, &quot;lchop&quot;, &quot;lchop?&quot;, &quot;lines&quot;, &quot;ljust&quot;, &quot;lstrip&quot;, &quot;match&quot;, &quot;matches?&quot;, &quot;partition&quot;, &quot;presence&quot;, &quot;pretty_print&quot;, &quot;rchop&quot;, &quot;rchop?&quot;, &quot;remove_excess&quot;, &quot;remove_excess_left&quot;, &quot;remove_excess_right&quot;, &quot;reverse&quot;, &quot;rindex&quot;, &quot;rjust&quot;, &quot;rpartition&quot;, &quot;rstrip&quot;, &quot;scan&quot;, &quot;scan_backreferences&quot;, &quot;scrub&quot;, &quot;single_byte_optimizable?&quot;, &quot;size&quot;, &quot;size_known?&quot;, &quot;split&quot;, &quot;split_by_empty_separator&quot;, &quot;split_single_byte&quot;, &quot;squeeze&quot;, &quot;starts_with?&quot;, &quot;strip&quot;, &quot;sub&quot;, &quot;sub_append&quot;, &quot;sub_index&quot;, &quot;sub_range&quot;, &quot;succ&quot;, &quot;titleize&quot;, &quot;to_f&quot;, &quot;to_f32&quot;, &quot;to_f32?&quot;, &quot;to_f64&quot;, &quot;to_f64?&quot;, &quot;to_f?&quot;, &quot;to_f_impl&quot;, &quot;to_i&quot;, &quot;to_i128&quot;, &quot;to_i128?&quot;, &quot;to_i16&quot;, &quot;to_i16?&quot;, &quot;to_i32&quot;, &quot;to_i32?&quot;, &quot;to_i64&quot;, &quot;to_i64?&quot;, &quot;to_i8&quot;, &quot;to_i8?&quot;, &quot;to_i?&quot;, &quot;to_s&quot;, &quot;to_slice&quot;, &quot;to_u128&quot;, &quot;to_u128?&quot;, &quot;to_u16&quot;, &quot;to_u16?&quot;, &quot;to_u32&quot;, &quot;to_u32?&quot;, &quot;to_u64&quot;, &quot;to_u64?&quot;, &quot;to_u8&quot;, &quot;to_u8?&quot;, &quot;to_unsafe&quot;, &quot;to_unsigned_info&quot;, &quot;to_utf16&quot;, &quot;tr&quot;, &quot;underscore&quot;, &quot;unicode_delete_at&quot;, &quot;unsafe_byte_at&quot;, &quot;unsafe_byte_slice&quot;, &quot;unsafe_byte_slice_string&quot;, &quot;upcase&quot;, &quot;valid_encoding?&quot;]
Thread.methods                   # =&gt; [&quot;detach&quot;, &quot;event_base&quot;, &quot;gc_thread_handler&quot;, &quot;gc_thread_handler=&quot;, &quot;initialize&quot;, &quot;join&quot;, &quot;main_fiber&quot;, &quot;next&quot;, &quot;next=&quot;, &quot;previous&quot;, &quot;previous=&quot;, &quot;scheduler&quot;, &quot;stack_address&quot;, &quot;start&quot;, &quot;to_unsafe&quot;]
Bool.methods                     # =&gt; [&quot;!=&quot;, &quot;&amp;&quot;, &quot;==&quot;, &quot;^&quot;, &quot;clone&quot;, &quot;hash&quot;, &quot;to_s&quot;, &quot;to_unsafe&quot;, &quot;|&quot;]
Int32.methods                    # =&gt; [&quot;!=&quot;, &quot;&amp;&quot;, &quot;&amp;*&quot;, &quot;&amp;+&quot;, &quot;&amp;-&quot;, &quot;*&quot;, &quot;+&quot;, &quot;-&quot;, &quot;/&quot;, &quot;&lt;&quot;, &quot;&lt;=&quot;, &quot;==&quot;, &quot;&gt;&quot;, &quot;&gt;=&quot;, &quot;^&quot;, &quot;clone&quot;, &quot;leading_zeros_count&quot;, &quot;popcount&quot;, &quot;to_f&quot;, &quot;to_f!&quot;, &quot;to_f32&quot;, &quot;to_f32!&quot;, &quot;to_f64&quot;, &quot;to_f64!&quot;, &quot;to_i&quot;, &quot;to_i!&quot;, &quot;to_i128&quot;, &quot;to_i128!&quot;, &quot;to_i16&quot;, &quot;to_i16!&quot;, &quot;to_i32&quot;, &quot;to_i32!&quot;, &quot;to_i64&quot;, &quot;to_i64!&quot;, &quot;to_i8&quot;, &quot;to_i8!&quot;, &quot;to_u&quot;, &quot;to_u!&quot;, &quot;to_u128&quot;, &quot;to_u128!&quot;, &quot;to_u16&quot;, &quot;to_u16!&quot;, &quot;to_u32&quot;, &quot;to_u32!&quot;, &quot;to_u64&quot;, &quot;to_u64!&quot;, &quot;to_u8&quot;, &quot;to_u8!&quot;, &quot;trailing_zeros_count&quot;, &quot;unsafe_chr&quot;, &quot;unsafe_div&quot;, &quot;unsafe_mod&quot;, &quot;unsafe_shl&quot;, &quot;unsafe_shr&quot;, &quot;|&quot;]
Float64.methods                  # =&gt; [&quot;!=&quot;, &quot;*&quot;, &quot;**&quot;, &quot;+&quot;, &quot;-&quot;, &quot;/&quot;, &quot;&lt;&quot;, &quot;&lt;=&quot;, &quot;==&quot;, &quot;&gt;&quot;, &quot;&gt;=&quot;, &quot;ceil&quot;, &quot;clone&quot;, &quot;fdiv&quot;, &quot;floor&quot;, &quot;next_float&quot;, &quot;prev_float&quot;, &quot;round_away&quot;, &quot;round_even&quot;, &quot;to_f&quot;, &quot;to_f!&quot;, &quot;to_f32&quot;, &quot;to_f32!&quot;, &quot;to_f64&quot;, &quot;to_f64!&quot;, &quot;to_i&quot;, &quot;to_i!&quot;, &quot;to_i128&quot;, &quot;to_i128!&quot;, &quot;to_i16&quot;, &quot;to_i16!&quot;, &quot;to_i32&quot;, &quot;to_i32!&quot;, &quot;to_i64&quot;, &quot;to_i64!&quot;, &quot;to_i8&quot;, &quot;to_i8!&quot;, &quot;to_s&quot;, &quot;to_u&quot;, &quot;to_u!&quot;, &quot;to_u128&quot;, &quot;to_u128!&quot;, &quot;to_u16&quot;, &quot;to_u16!&quot;, &quot;to_u32&quot;, &quot;to_u32!&quot;, &quot;to_u64&quot;, &quot;to_u64!&quot;, &quot;to_u8&quot;, &quot;to_u8!&quot;, &quot;trunc&quot;]
Proc.methods                     # =&gt; [&quot;==&quot;, &quot;===&quot;, &quot;arity&quot;, &quot;call&quot;, &quot;clone&quot;, &quot;closure?&quot;, &quot;closure_data&quot;, &quot;hash&quot;, &quot;internal_representation&quot;, &quot;partial&quot;, &quot;pointer&quot;, &quot;to_s&quot;]&lt;/syntaxhighlight&gt;

== 脚註 ==
&lt;references /&gt;

== 外部リンク ==
* [https://crystal-lang.org/ The Crystal Programming Language] {{---}} 公式サイト
** [https://crystal-lang.org/api/1.5.0/ Crystal 1.5.0 リファレンス]
** [https://play.crystal-lang.org/#/cr Compile &amp; run code in Crystal] {{---}} playground

[[Category:Crystal|*]]
[[Category:プログラミング言語]]
{{NDC|007.64}}</text>
      <sha1>nsk08ywwdz79zi64wn8x6jabza0azx7</sha1>
    </revision>
    <revision>
      <id>205750</id>
      <parentid>205749</parentid>
      <timestamp>2022-07-24T03:04:14Z</timestamp>
      <contributor>
        <username>Ef3</username>
        <id>694</id>
      </contributor>
      <comment>/* crystal コマンド */  crystal コマンドは Crystal のコンパイラであると同時に、ビルドツールなどを含んだツールチェインです（プログラミング言語のCrystalは、先頭を大文字、コマンドのcrystalは、先頭を小文字にして区別します）。</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="61806" xml:space="preserve">{{Pathnav|メインページ|工学|情報技術|プログラミング|frame=1}}
{{Wikipedia|Crystal (プログラミング言語)}}
本書は、[[w:Crystal (プログラミング言語)|Crystal]]のチュートリアルです。
'''Crystal'''は、Ary Borenszweig、Juan Wajnerman、Brian Cardiffと300人以上の貢献者によって設計・開発された[汎用オブジェクト指向プログラミング言語です&lt;ref&gt;{{Cite web
|url=https://github.com/crystal-lang/crystal/graphs/contributors
|title=Contributors
|accessdate=2022-07-18
|website=github.com
}}&lt;/ref&gt;。[[Ruby]] にヒントを得た構文を持ち、静的型チェックを備えた [[コンパイル型言語]]ですが、変数やメソッドの引数の型は一般には不要です。型は高度なグローバル[[型推論]]アルゴリズムによって解決される。&lt;ref&gt;{{Cite web
|url=http://crystal-lang.org/2013/09/23/type-inference-part-1.html
|title=Type inference part 1
|last=Brian J.
|first=Cardiff
|date=2013-09-09
|accessdate=2022-07-18
|website=crystal-lang.org
}}&lt;/ref&gt;Crystalは[[Apache License]]バージョン2.0のもと、FOSSとしてリリースされています。

__TOC__

== Hello, World! ==
他の多くのチュートリアルがそうであるように、
私たちもまずはCrystalの世界にあいさつすることから始めましょう。

Rubyとの比較も兼ねて、[[Ruby#Hello, World!]]をそのまま実行してみます。

''hello.cr''というファイルを作り、次のように書いて保存して下さい&lt;ref&gt;Crystalのソースファイルの拡張子は''.cr'' です&lt;/ref&gt;。

;hello.cr:&lt;syntaxhighlight lang=Crystal&gt;
puts 'Hello, World!'
&lt;/syntaxhighlight&gt;

;コマンドラインでの操作:&lt;syntaxhighlight lang=&quot;console&quot;&gt;
% cat hello.cr 
puts 'Hello, World!'
% crystal hello.cr
In hello.cr:1:6

 1 | puts 'Hello, World!'
          ^
Error: unterminated char literal, use double quotes for strings

% sed -i -e &quot;s@'@Q@g&quot; -e 's@Q@&quot;@g' hello.cr
% cat hello.cr 
puts &quot;Hello, World!&quot;
% crystal hello.cr
Hello, World!
&lt;/syntaxhighlight&gt;
この１行のスクリプトは、メソッド&lt;code&gt;puts&lt;/code&gt; に文字リテラル&lt;code&gt;&quot;Hello, World!&quot;&lt;/code&gt;を渡し呼出しています。

このプログラムは、[[Ruby#Hello, World!]]と同じですが、Crystalでは文字列リテラルは &lt;code&gt;&quot;…&quot;&lt;/code&gt; で囲うのでそれだけ変更しました。

== プログラミング環境 ==
Crystalのプログラムを作り、コンパイル・実装するには、「オンライン実行環境を使う」・「エディト・コンパイル・実行環境を用意してそれを使う」の２通りの方法があります。

=== オンライン実行環境 ===
公式のオンライン実行環境、 https://play.crystal-lang.org/ があります。
まずは、これを使って本書に例示されているコードを実行してみることをお勧めします。

=== エディト・コンパイル・実行環境 ===
エディタについては本書では触れませんが、プログラミング時間の大半はエディタの操作に費やされるため、良いエディタを選択することが重要です。

Crystal の言語処理系は、 https://crystal-lang.org/install/ から入手します。

自分の、OSやGNU/Linuxであればディストリビューションに合わせてインストールしてください。
また、FreeBSDのように crystal と shards が別パッケージとなっていることもあるので、その場合は shards も追加インストールします。

多くの場合、インストールされた、 crystal はスタティック リンクされているので、ダイナミック リンク版の crystal を入手するには、スタティック リンク版の実行ファイルとソースコードを入手し、スタティック リンク版でソースから crystal をコンパイル・インストールする必要があります。

=== crystal コマンド ===
crystal コマンドは Crystal のコンパイラであると同時に、ビルドツールなどを含んだツールチェインです（プログラミング言語のCrystalは、先頭を大文字、コマンドのcrystalは、先頭を小文字にして区別します）。


[TODO: コマンドラインツール crystal の解説。 crystal ファイル名 は crystal run ファイル名 の短縮形で、インタープリタ的な実行…ではなく、内部ビルドツールでコンパイル・実行を行う]

== Ruby との違い ==
Crystalは、Rubyに触発された構文を持つものの、Rubyとの互換性をゴールに定めては'''いません'''。
このため、細部を見ると仕様に差異があり、Rubyのソースコードをcrystalに掛けるても前節の 'Hello World' の様にコンパイルに失敗することがあります。
また、コンパイルできても実行結果に違いが出ることがあります。

ここでは、Ruby との違いについて実際のコードと双方の結果を比較することで、差異についての理解を深めていきます。

=== 整数型の特性 ===
;大きな整数:&lt;syntaxhighlight lang=Crystal&gt;
p 2 ** 999
p (2 ** 999).class
&lt;/syntaxhighlight&gt;
;rubyの実行結果:&lt;syntaxhighlight lang=&quot;console&quot;&gt;
5357543035931336604742125245300009052807024058527668037218751941851755255624680612465991894078479290637973364587765734125935726428461570217992288787349287401967283887412115492710537302531185570938977091076523237491790970633699383779582771973038531457285598238843271083830214915826312193418602834034688
Integer
&lt;/syntaxhighlight&gt;
;crystalの実行結果:&lt;syntaxhighlight lang=&quot;console&quot;&gt;
Unhandled exception: Arithmetic overflow (OverflowError)
  from /usr/local/share/crystal/share/crystal/src/int.cr:295:9 in '**'
  from pow.cr:1:1 in '__crystal_main'
  from /usr/local/share/crystal/share/crystal/src/crystal/main.cr:115:5 in 'main_user_code'
  from /usr/local/share/crystal/share/crystal/src/crystal/main.cr:101:7 in 'main'
  from /usr/local/share/crystal/share/crystal/src/crystal/main.cr:127:3 in 'main'
  from /usr/local/lib64/libc.so.6 in '__libc_start_main'
  from /usr/local/.cache/crystal/crystal-run-pow.tmp in '_start'
  from ???
&lt;/syntaxhighlight&gt;
: Ruby の整数は、桁あふれが起こると自動的に多倍長整数に型変換されるので、継ぎ目なしに大きな数を扱うアルゴルズムが使えます。
: Crystal の整数は、固定長です（大きさについては[[#リテラルと型|後述]]）。なので大きな答えになる式を評価すると桁あふれが生じます。桁あふれが生じますが、C言語のように寡黙に処理を続けるのではなく、実行時に例外（OverflowError）が上がるので、例外を捕捉し然るべき処置を施すことが可能です。

==== BigInt ====
&lt;code&gt;big&lt;/code&gt; を &lt;code&gt;require&lt;/code&gt; すると &lt;code&gt;BigInt&lt;/code&gt; が使えるようになります。
;BigInt:&lt;syntaxhighlight lang=Crystal&gt;
require &quot;big&quot;

p BigInt.new(2) ** 999
p (BigInt.new(2) ** 999).class
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;console&quot;&gt;
5357543035931336604742125245300009052807024058527668037218751941851755255624680612465991894078479290637973364587765734125935726428461570217992288787349287401967283887412115492710537302531185570938977091076523237491790970633699383779582771973038531457285598238843271083830214915826312193418602834034688
BigInt
&lt;/syntaxhighlight&gt;
: BigIntはプリミティブではなので、リテラル表現はありません。また、
::&lt;syntaxhighlight lang=Crystal&gt;
n : BigInt = 2
&lt;/syntaxhighlight&gt;
::&lt;syntaxhighlight lang=console&gt;
Error: type must be BigInt, not Int32
&lt;/syntaxhighlight&gt;
:: のように型アノテーションすることも出来ません。

=== リテラルと型 ===
;様々なリテラルと型:&lt;syntaxhighlight lang=Crystal&gt;
[nil, false, true, 42, 2.73, 'Q', &quot;string&quot;, [1,2,3], {a:1, b:2}].each{|x|
  p [x, x.class]
}
&lt;/syntaxhighlight&gt;
;rubyの実行結果:&lt;syntaxhighlight lang=&quot;console&quot;&gt;
[nil, NilClass]
[false, FalseClass]
[true, TrueClass]
[42, Integer]
[2.73, Float]
[&quot;Q&quot;, String]
[&quot;string&quot;, String]
[[1, 2, 3], Array] 
[{:a=&gt;1, :b=&gt;2}, Hash]
&lt;/syntaxhighlight&gt;
;crystalの実行結果:&lt;syntaxhighlight lang=&quot;console&quot;&gt;
[nil, Nil]
[false, Bool]
[true, Bool]
[42, Int32]
[2.73, Float64]
['Q', Char]
[&quot;string&quot;, String]
[[1, 2, 3], Array(Int32)] 
[{a: 1, b: 2}, NamedTuple(a: Int32, b: Int32)]
&lt;/syntaxhighlight&gt;
: Crystal の整数は Int32、浮動小数点数は Float64 です。

;サイズを指定した数リテラル:&lt;syntaxhighlight lang=Crystal&gt;
[1_i64, 2_u32, 3_u64, 4_i32, 5_i16, 6_u8, 7_i128, 8_u128, 3.14_f32, 1.44_f64].each{|x|
  p [x, x.class]
}
&lt;/syntaxhighlight&gt;
;ruby:Rubyでは、サーフィックスの付いた数値リテラルは無効
;crystalの実行結果:&lt;syntaxhighlight lang=&quot;console&quot;&gt;
[1, Int64]
[2, UInt32]
[3, UInt64]
[4, Int32]
[5, Int16]
[6, UInt8]
[7, Int128]
[8, UInt128]
[3.14, Float32] 
[1.44, Float64]
&lt;/syntaxhighlight&gt;
: Crystal では、数値リテラルに _ で始まるサーフィックスを付け { i:符号付き整数, u:符号なし整数, f:浮動小数点数 } と { 8,16,32,64,128 } のビット幅の組合せです&lt;ref&gt;[https://crystal-lang.org/reference/1.5/syntax_and_semantics/literals/ Literals]&lt;/ref&gt;。

=== for式がない ===
Crystal には、Ruby にはある for式がありません。
;Rubyのfor式の構文:&lt;syntaxhighlight lang=&quot;ruby&quot;&gt;
for 変数 in コレクション
  文
end
&lt;/syntaxhighlight&gt;
:コレクションは Range, Array, Hash など内部構造を持つオブジェクトです。
:for式は、最後に評価した値を返すので、for'''式'''です。

;for式のeachメソッドによる置換え:&lt;syntaxhighlight lang=&quot;ruby&quot;&gt;
for x in [ 2, 3, 5, 7, 11 ] do
  p x
end
# ↓
[ 2, 3, 5, 7, 11 ].each do | x |
  p x
end
&lt;/syntaxhighlight&gt;
: の様にコレクションの each メソッドで置換え可能なので、Rubyからの移植でも小規模な書換えで済みます&lt;ref&gt;[https://github.com/crystal-lang/crystal/issues/830 &quot;For&quot; Loop support #830]&lt;/ref&gt;（後述のマクロで実装できないかと思いましたが、いまのところ無理のようです）。
また loop 式もありませんが while true;  … end で間に合います。Ruby では while 式の条件の次に do が置けますが、Crystal では置けません。

=== eval()がない ===
Crystal には eval() はありません。
Crystalはコンパイル型言語ですので、無理もないことです。
もし、Crystal で eval() を実装しようとすると、Common Lisp の様にインタープリターを丸ごとランタイムに含む必要があります。
これはリーズナブルな選択ではありません。
Crystal では、eval() が必要なケースに（限定的ですが）マクロを使うことが出来る可能性があります。

=== マクロ ===
Crystalには、Rubyにはないマクロがあります&lt;ref&gt;[https://crystal-lang.org/reference/1.5/syntax_and_semantics/macros/ Macros - Crystal]&lt;/ref&gt;。Rubyは実行時にすべてのオブジェクトにアクセス出来て、メソッド生やし放題なのでマクロは必要ありませんが、Crystalはコンパイル時に型やメソッドを確定する必要があり、特にメソッドジェネレターとしてのマクロにニーズがあります。また、テンプレート言語的なマクロなので、環境変数による条件分岐や、コンテナを渡し繰返し処理する構文もあります（面白いことにマクロには for 文があり、反対にマクロの中では、eachメソッドは使えません）。マクロには &lt;code&gt;&lt;nowiki&gt;{{&lt;/nowiki&gt;attr.id}}&lt;/code&gt; の様にASTへのアクセス手順が用意されており、半ば言語を拡張するようなアプローチを取ることも出来ます。

[TODO:ASTについての解説；コラム向き？]

;マクロを使ったattr_accessorのイミュレーション:&lt;syntaxhighlight lang=crystal&gt;
class Point
  def initialize(@x : Int32, @y : Int32)
  end

  # macro定義
  macro attr_accessor(*attrs)
    {% for attr in attrs %}
      def {{attr.id}}() @{{attr.id}} end
      def {{attr.id}}=(var) @{{attr.id}} = var end
    {% end %}
  end

  # macro呼出し
  attr_accessor :x, :y
end

pt = Point.new(20, 30)
p [pt.x, pt.y]
t = pt.x
pt.x = pt.y
pt.y = t
p [pt.x, pt.y]
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
[20, 30]
[30, 20]
&lt;/syntaxhighlight&gt;
: Ruby には、attr_accessor と言う「クラスのメンバーのアクセサーを自動生成するメソッド」がありますが、Crystalにはないようなので、マクロで実装しました。
:: attr_accessor :name からは
::&lt;syntaxhighlight lang=ruby&gt;
def name()     @name end
def name=(val) @name = val end
&lt;/syntaxhighlight&gt;相当のコードが生成されます。
[TODO:マクロの機能と構文の説明 *の付いた引数、 &lt;nowiki&gt;{{&lt;/nowiki&gt;引数}}、{% … %} 構文]

==== マクロ p! ====
メソッド p は、与えられた「式」の inspaect() の返す値を puts しますが、マクロ p! は、それに先んじて（評価前の）「式」を表示します&lt;ref&gt;[https://crystal-lang.org/api/1.5.0/Crystal/Macros.html#p%21%28%2Aexpressions%29%3ANop-instance-method def p!(*expressions) : Nop]&lt;/ref&gt;。
;p!の例:&lt;syntaxhighlight lang=crystal&gt;
x, y = true, false

p! x,y,x &amp;&amp; y, x || y, x ^ y, !x, x != y, x == y

ary = [ 1, 2, 3 ]

p! ary

p! ary.map(&amp;. &lt;&lt; 1)

p! ary.map(&amp;.to_f)
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
x      # =&gt; true
y      # =&gt; false
x &amp;&amp; y # =&gt; false
x || y # =&gt; true
x ^ y  # =&gt; true
!x     # =&gt; false
x != y # =&gt; true
x == y # =&gt; false
ary # =&gt; [1, 2, 3]
ary.map(&amp;.&lt;&lt;(1)) # =&gt; [2, 4, 6]
ary.map(&amp;.to_f) # =&gt; [1.0, 2.0, 3.0]
&lt;/syntaxhighlight&gt;

===== 入れ子のp! =====
マクロ p! は入れ子に出来ます。また、一旦ASTに変換してから再度ソースコードに変換するので、等価な別の構文に変換されることがあります。
;入れ子のp!:&lt;syntaxhighlight lang=crystal&gt;
p! (
  100.times{|i|
    p! i
    break i if i &gt; 12
  }
)
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
(100.times do |i|
 p!(i)
 if i &gt; 12
   break i
 end
end) # =&gt; i
# =&gt; 0
i # =&gt; 1
i # =&gt; 2
i # =&gt; 3
i # =&gt; 4
i # =&gt; 5
i # =&gt; 6
i # =&gt; 7
i # =&gt; 8
i # =&gt; 9
i # =&gt; 10
i # =&gt; 11
i # =&gt; 12
i # =&gt; 13
13
&lt;/syntaxhighlight&gt;

=== クラス ===

==== シンプルなクラス ====
;シンプルなクラス:&lt;syntaxhighlight lang=crystal highlight=&quot;2&quot; line&gt;
class Hello
  def initialize(@name : String = &quot;World&quot;)
  end

  def greeting
    puts &quot;Hello #{@name}!&quot;
  end
end

hello = Hello.new()
hello.greeting

universe = Hello.new(&quot;Universe&quot;)
universe.greeting
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
Hello World!
Hello Universe!
&lt;/syntaxhighlight&gt;
:;初期化メソッド
:: &lt;syntaxhighlight lang=crystal line start=4&gt;
  def initialize(@name : String = &quot;World&quot;)
  end
&lt;/syntaxhighlight&gt;
::Rubyであれば
:: &lt;syntaxhighlight lang=ruby line start=4&gt;
  def initialize(name = &quot;World&quot;)
    @name = name
  end
&lt;/syntaxhighlight&gt;
::とするところですが、Crystalでは、型アノテーション &lt;code&gt; : String&lt;/code&gt; を使い、引数の型を限定しました。
::また、（@ 付きの）アトリビュート名を仮引数にすると、そのままアトリビュート（a.k.a. インスタンス変数）に仮引数が代入されます。
::これは、C++のコンストラクターのメンバー初期化リストと同じアイディアですが、Crystalではインスタンス変数に @ が前置されるので、仮引数に @ が出現すればインスタンス変数の初期値だと自明で、聡明な選択です。


==== 都市間の大圏距離 ====
[[Ruby#ユーザー定義クラス]]の都市間の大圏距離を求めるメソッドを追加した例を、Crystalに移植しました。

;都市間の大圏距離:&lt;syntaxhighlight lang=crystal highlight=”2,7,12” line&gt;
class GeoCoord
  getter :longitude, :latitude

  def initialize(@longitude : Float64, @latitude : Float64)
  end

  def to_s(io)
    ew, ns = &quot;東経&quot;, &quot;北緯&quot;
    long, lat = @longitude, @latitude
    ew, long = &quot;西経&quot;, -long if long &lt; 0.0
    ns, lat = &quot;南緯&quot;, -lat if lat &lt; 0.0
    io &lt;&lt; &quot;(#{ew}: #{long}, #{ns}: #{lat})&quot;
  end # https://github.com/crystal-lang/crystal/issues/259
  def distance(other)
    i, r = Math::PI / 180, 6371.008
    Math.acos(Math.sin(@latitude*i) * Math.sin(other.latitude * i) +
              Math.cos(@latitude*i) * Math.cos(other.latitude * i) * Math.cos(@longitude * i - other.longitude * i)) * r
  end
end

# メソッドの先頭を大文字に出来ないのでクラス名のメソッドは作ることが出来ない
# def GeoCoord(lng : Float64, lat : Float64)
#  GeoCoord.new(lng, lat)
# end

Sites = {
  &quot;東京駅&quot;:         GeoCoord.new(139.7673068, 35.6809591),
  &quot;シドニー・オペラハウス&quot;: GeoCoord.new(151.215278, -33.856778),
  &quot;グリニッジ天文台&quot;:    GeoCoord.new(-0.0014, 51.4778),
}

Sites.each { |name, gc|
  puts &quot;#{name}: #{gc}&quot;
}

puts &quot;&quot;

keys, len = Sites.keys, Sites.size
keys.each_with_index { |x, i|
  y = keys[(i + 1) % len]
  puts &quot;#{x} ⇔ #{y}: #{Sites[x].distance(Sites[y])} [km]&quot;
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
東京駅: (東経: 139.7673068, 北緯: 35.6809591)
シドニー・オペラハウス: (東経: 151.215278, 南緯: 33.856778)
グリニッジ天文台: (西経: 0.0014, 北緯: 51.4778)

東京駅 ⇔ シドニー・オペラハウス: 7823.269299386704 [km]
シドニー・オペラハウス ⇔ グリニッジ天文台: 16987.2708377249 [km]
グリニッジ天文台 ⇔ 東京駅: 9560.546566490015 [km]
&lt;/syntaxhighlight&gt;
:Crystal には、&lt;syntaxhighlight lang=ruby inline&gt;  attr_accessor &lt;/syntaxhighlight&gt; はありませんが、標準ライブラリーのマクロに &lt;syntaxhighlight lang=crystal inline&gt;  getter &lt;/syntaxhighlight&gt;があるので
:: &lt;syntaxhighlight lang=crystal line start=2&gt;
  getter :longitude, :latitude
&lt;/syntaxhighlight&gt;
::としました。
::将来、&lt;syntaxhighlight lang=ruby inline&gt;  attr_accessor &lt;/syntaxhighlight&gt; が実装される可能性はありますが、姉妹品の&lt;syntaxhighlight lang=crystal inline&gt;  setter &lt;/syntaxhighlight&gt;　との併用が下位互換性を考えると確実です。
: to_s は、Ruby ならば
:: &lt;syntaxhighlight lang=ruby line start=7&gt;
  def to_s()
&lt;/syntaxhighlight&gt;
:: &lt;syntaxhighlight lang=ruby line start=12&gt;
    &quot;(#{ew}: #{long}, #{ns}: #{lat})&quot;
&lt;/syntaxhighlight&gt;
:: ですが、Crystalでは追加の引数 &lt;var&gt;io&lt;/var&gt; が必要で
:: &lt;syntaxhighlight lang=ruby line start=7&gt;
  def to_s(io)
&lt;/syntaxhighlight&gt;
:: &lt;syntaxhighlight lang=ruby line start=12&gt;
    io &lt;&lt; &quot;(#{ew}: #{long}, #{ns}: #{lat})&quot;
&lt;/syntaxhighlight&gt;
: Ruby にはクラス名と同じ名前のメソッドで .new を呼出す文化があるのですが、Crystalはメソッドの先頭を大文字に出来ないので、これは見送りました。

==== 包含と継承 ====
[[JavaScript/クラス#包含と継承]]を、Rubyに移植した[[Ruby#包含と継承]]を、Crystalに移植しました。

;包含と継承の例:&lt;syntaxhighlight lang=crystal line&gt;
class Point
  def initialize(@x = 0, @y = 0)
  end

  def inspect(io)
    io &lt;&lt; &quot;x:#{@x}, y:#{@y}&quot;
  end

  def move(dx = 0, dy = 0)
    @x, @y = @x + dx, @y + dy
    self
  end
end

class Shape
  def initialize(x = 0, y = 0)
    @location = Point.new(x, y)
  end

  def inspect(io)
    @location.inspect(io)
  end

  def move(x, y)
    @location.move(x, y)
    self
  end
end

class Rectangle &lt; Shape
  def initialize(x = 0, y = 0, @width = 0, @height = 0)
    super(x, y)
  end

  def inspect(io)
    super(io)
    io &lt;&lt; &quot;, width:#{@width}, height:#{@height}&quot;
  end
end

rct = Rectangle.new(12, 32, 100, 50)
p! rct,
  rct.is_a?(Rectangle),
  rct.is_a?(Shape),
  rct.is_a?(Point),
  rct.move(11, 21)
(END)&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
rct                  # =&gt; x:12, y:32, width:100, height:50 
rct.is_a?(Rectangle) # =&gt; true 
rct.is_a?(Shape)     # =&gt; true 
rct.is_a?(Point)     # =&gt; false 
rct.move(11, 21)     # =&gt; x:23, y:53, width:100, height:50 
&lt;/syntaxhighlight&gt;
;crystal tool hierarchy:&lt;syntaxhighlight lang=console&gt;
% crystal tool hierarchy inclusion-and-inheritance.cr -e Shape
- class Object (4 bytes)
  |
  +- class Reference (4 bytes)
     |
     +- class Shape (16 bytes)
        .   @location : Point (8 bytes)
        |
        +- class Rectangle (24 bytes)
               @width  : Int32 (4 bytes)
               @height : Int32 (4 bytes)
&lt;/syntaxhighlight&gt;
: crystal の tool hierarchy サブコマンドで、クラスの継承関係がわかります。

===== superclass と subclasses =====
Crystal には、RubyのClassにあるメソッド superclass と subclasses がないので、マクロで実装しました。
;superclass と subclasses:&lt;syntaxhighlight lang=crystal line&gt;
class Class
  def self.superclass
    {{ @type.superclass }}
  end

  def self.subclasses : Array(self.class)
    {{ @type.subclasses }}.map(&amp;.as(self.class))
  end

  def self.all_subclasses : Array(self.class)
    {% begin %}
      [{{ @type.all_subclasses.join(&quot;,&quot;).id }}] of self.class
    {% end %}
  end
end
 
class A end
class AA &lt; A end
class AAA &lt; AA end
class AAB &lt; AA end
class AB &lt; A end

p! A,
  A.subclasses,
  A.all_subclasses,
  AAA.superclass,
  A.superclass
 
c = AAA
while !c.is_a? Nil
  p! c.superclass
  c = c.superclass
end&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
A                # =&gt; A 
A.subclasses     # =&gt; [AA, AB] 
A.all_subclasses # =&gt; [AA, AAA, AAB, AB] 
AAA.superclass   # =&gt; AA 
A.superclass     # =&gt; Reference 
c.superclass # =&gt; AA 
c.superclass # =&gt; A 
c.superclass # =&gt; Reference 
c.superclass # =&gt; Object 
c.superclass # =&gt; nil
&lt;/syntaxhighlight&gt;

==== 抽象クラス ====
[[Java/抽象クラス]]を、Crystalに移植しました。

;抽象クラスの宣言:&lt;syntaxhighlight lang=Java&gt;
abstract class クラス名
  #
end
&lt;/syntaxhighlight&gt;
: このクラス名は、 .new でインスタンス化出来ません。
:: Error: can't instantiate abstract class クラス名
: となります。
:インスタンス化することは出来ませんが、抽象クラスを別のクラスが継承する事は出来ます。
:また、抽象クラスを &lt;code&gt;super()&lt;/code&gt; を使うことでメソッドを呼び出せるので、抽象メソッドではないメソッド（具象メソッド）を持つことも、インスタンス変数も持つことも出来ます。
:'''抽象クラスの例'''では、Shapeのinitializeメソッドが抽象クラスの具象メソッドとなっています。
;抽象メソッドの宣言:&lt;syntaxhighlight lang=Java&gt;
  abstract def メソッド名
&lt;/syntaxhighlight&gt;
: 派生先のクラスで、「メソッド名」を定義(def)し忘れると
:: Error: abstract `def クラス名#メソッド名()` must be implemented by クラス名
: となります

;抽象クラスの例:&lt;syntaxhighlight lang=crystal line&gt;
abstract class Shape
  def initialize(@x = 0.0, @y = 0.0)
  end

  abstract def to_s(io)
  abstract def area
end

class Square &lt; Shape
  def initialize(x, y, @wh = 0.0)
    super(x, y)
  end

  def to_s(io)
    io &lt;&lt; &quot;Square(#{@x}, #{@y}, #{@wh})&quot;
  end

  def area
    @wh * @wh
  end
end

abstract class Shape
  def initialize(@x = 0.0, @y = 0.0)
  end

  abstract def to_s(io)
  abstract def area
end

class Square &lt; Shape
  def initialize(x, y, @wh = 0.0)
    super(x, y)
  end

  def to_s(io)
    io &lt;&lt; &quot;Square(#{@x}, #{@y}, #{@wh})&quot;
  end

  def area
    @wh * @wh
  end
end

class Recrangle &lt; Shape
  def initialize(x, y, @w = 0.0, @h = 0.0)
    super(x, y)
  end

  def to_s(io)
    io &lt;&lt; &quot;Rectanle(#{@x}, #{@y}, #{@w}, #{@h})&quot;
  end

  def area
    @w * @h
  end
end

class Circle &lt; Shape
  def initialize(x, y, @r = 0.0)
    super(x, y)
  end

  def to_s(io)
    io &lt;&lt; &quot;Circle(#{@x}, #{@y}, #{@r})&quot;
  end

  def area
    3.1425926536 * @r * @r
  end
end

shapes = [
  Square.new(5.0, 10.0, 15.0),
  Recrangle.new(13.0, 23.0, 20.0, 10.0),
  Circle.new(3.0, 2.0, 20.0),
] of Shape

shapes.each do |shape|
  puts(&quot;#{shape}: #{shape.area}&quot;)
end
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=text&gt;
Square(5.0, 10.0, 15.0): 225.0
Rectanle(13.0, 23.0, 20.0, 10.0): 200.0
Circle(3.0, 2.0, 20.0): 1257.03706144
&lt;/syntaxhighlight&gt;
;crystal tool hierarchy:&lt;syntaxhighlight lang=console&gt;
% crystal tool hierarchy abstract.cr -e Shape
- class Object (4 bytes)
  |
  +- class Reference (4 bytes)
     |
     +- class Shape (24 bytes)
        .   @x : Float64 (8 bytes)
        .   @y : Float64 (8 bytes)
        |
        +- class Circle (32 bytes)
        |      @r : Float64 (8 bytes)
        |
        +- class Recrangle (40 bytes)
        |      @w : Float64 (8 bytes)
        |      @h : Float64 (8 bytes)
        |
        +- class Square (32 bytes)
               @wh : Float64 (8 bytes)
&lt;/syntaxhighlight&gt;
: crystal の tool hierarchy サブコマンドで、クラスの継承関係がわかります。
: 「包含と継承の例」と比べると、ShapeとRectangleが同じ階層にあることがわかると思います。

[TODO:virtual class::いい例がない]

== キーワード ==
Crystalのキーワード( ''keywords'' ) は、以下の通り。

&lt;code&gt;abstract&lt;/code&gt; &lt;code&gt;alias&lt;/code&gt; &lt;code&gt;as&lt;/code&gt; &lt;code&gt;asm&lt;/code&gt; &lt;code&gt;begin&lt;/code&gt; &lt;code&gt;break&lt;/code&gt; &lt;code&gt;case&lt;/code&gt; &lt;code&gt;class&lt;/code&gt; &lt;code&gt;def&lt;/code&gt; &lt;code&gt;do&lt;/code&gt; &lt;code&gt;else&lt;/code&gt; &lt;code&gt;elsif&lt;/code&gt; &lt;code&gt;end&lt;/code&gt; &lt;code&gt;ensure&lt;/code&gt; &lt;code&gt;enum&lt;/code&gt; &lt;code&gt;extend&lt;/code&gt; &lt;code&gt;for&lt;/code&gt; &lt;code&gt;fun&lt;/code&gt; &lt;code&gt;if&lt;/code&gt; &lt;code&gt;include&lt;/code&gt; &lt;code&gt;instance_sizeof&lt;/code&gt; &lt;code&gt;lib&lt;/code&gt; &lt;code&gt;macro&lt;/code&gt; &lt;code&gt;module&lt;/code&gt; &lt;code&gt;next&lt;/code&gt; &lt;code&gt;of&lt;/code&gt; &lt;code&gt;out&lt;/code&gt; &lt;code&gt;pointerof&lt;/code&gt; &lt;code&gt;private&lt;/code&gt; &lt;code&gt;protected&lt;/code&gt; &lt;code&gt;rescue&lt;/code&gt; &lt;code&gt;return&lt;/code&gt; &lt;code&gt;require&lt;/code&gt; &lt;code&gt;select&lt;/code&gt; &lt;code&gt;sizeof&lt;/code&gt; &lt;code&gt;struct&lt;/code&gt; &lt;code&gt;super&lt;/code&gt; &lt;code&gt;then&lt;/code&gt; &lt;code&gt;type&lt;/code&gt; &lt;code&gt;typeof&lt;/code&gt; &lt;code&gt;uninitialized&lt;/code&gt; &lt;code&gt;union&lt;/code&gt; &lt;code&gt;unless&lt;/code&gt; &lt;code&gt;until&lt;/code&gt; &lt;code&gt;when&lt;/code&gt; &lt;code&gt;while&lt;/code&gt; &lt;code&gt;with&lt;/code&gt; &lt;code&gt;yield&lt;/code&gt;
&lt;!--
 &lt;code&gt;__DIR__&lt;/code&gt; &lt;code&gt;__END_LINE__&lt;/code&gt; &lt;code&gt;__FILE__&lt;/code&gt; &lt;code&gt;__LINE__&lt;/code&gt;
--&gt;

==  演算子 ==
Crystalは、1つ、2つ、または3つのオペランドを持つ数多くの演算子をサポートしています&lt;ref&gt;[https://crystal-lang.org/reference/1.5/syntax_and_semantics/operators.html Operators]access-date:2022-07-22&lt;/ref&gt;。

演算子式は、実際にはメソッド呼び出しとしてパースされます。例えば、&lt;code&gt;a + b&lt;/code&gt; は &lt;code&gt;a.+(b)&lt;/code&gt; と意味的に同じで、引数 b を持つ a のメソッド + を呼び出すことになります。

{| class=&quot;wikitable&quot;
|+ 演算子の優先度
!種類
!演算子
|-
|インデックス アクセサー
|&lt;code&gt;[]&lt;/code&gt;, &lt;code&gt;[]?&lt;/code&gt;
|-
|単項
|&lt;code&gt;+&lt;/code&gt;, &lt;code&gt;&amp;+&lt;/code&gt;, &lt;code&gt;-&lt;/code&gt;, &lt;code&gt;&amp;-&lt;/code&gt;, &lt;code&gt;!&lt;/code&gt;, &lt;code&gt;~&lt;/code&gt;
|-
|指数
|&lt;code&gt;**&lt;/code&gt;, &lt;code&gt;&amp;**&lt;/code&gt;
|-
|乗除
|&lt;code&gt;*&lt;/code&gt;, &lt;code&gt;&amp;*&lt;/code&gt;, &lt;code&gt;/&lt;/code&gt;, &lt;code&gt;//&lt;/code&gt;, &lt;code&gt;%&lt;/code&gt;
|-
|加減
|&lt;code&gt;+&lt;/code&gt;, &lt;code&gt;&amp;+&lt;/code&gt;, &lt;code&gt;-&lt;/code&gt;, &lt;code&gt;&amp;-&lt;/code&gt;
|-
|シフト
|&lt;code&gt;&lt;&lt;&lt;/code&gt;, &lt;code&gt;&gt;&gt;&lt;/code&gt;
|-
|ビット間 AND
|&lt;code&gt;&amp;&lt;/code&gt;
|-
|ビット間 OR/XOR
|&lt;code&gt;&lt;nowiki&gt;|&lt;/nowiki&gt;&lt;/code&gt;,&lt;code&gt;^&lt;/code&gt;
|-
|等値
|&lt;code&gt;==&lt;/code&gt;, &lt;code&gt;!=&lt;/code&gt;, &lt;code&gt;=~&lt;/code&gt;, &lt;code&gt;!~&lt;/code&gt;, &lt;code&gt;===&lt;/code&gt;
|-
|比較
|&lt;code&gt;&lt;&lt;/code&gt;, &lt;code&gt;&lt;=&lt;/code&gt;, &lt;code&gt;&gt;&lt;/code&gt;, &lt;code&gt;&gt;=&lt;/code&gt;, &lt;code&gt;&lt;=&gt;&lt;/code&gt;
|-
|論理 AND
|&lt;code&gt;&amp;&amp;&lt;/code&gt;
|-
|論理 OR
|&lt;code&gt;&lt;nowiki&gt;||&lt;/nowiki&gt;&lt;/code&gt;
|-
|Range
|&lt;code&gt;..&lt;/code&gt;, &lt;code&gt;...&lt;/code&gt;
|-
|条件
|&lt;code&gt;?:&lt;/code&gt;
|-
|代入
|&lt;code&gt;=&lt;/code&gt;, &lt;code&gt;[]=&lt;/code&gt;, &lt;code&gt;+=&lt;/code&gt;, &lt;code&gt;&amp;+=&lt;/code&gt;, &lt;code&gt;-=&lt;/code&gt;, &lt;code&gt;&amp;-=&lt;/code&gt;, &lt;code&gt;*=&lt;/code&gt;, &lt;code&gt;&amp;*=&lt;/code&gt;, &lt;code&gt;/=&lt;/code&gt;, &lt;code&gt;//=&lt;/code&gt;, &lt;code&gt;%=&lt;/code&gt;, &lt;code&gt;&lt;nowiki&gt;|=&lt;/nowiki&gt;&lt;/code&gt;, &lt;code&gt;&amp;=&lt;/code&gt;,&lt;code&gt;^=&lt;/code&gt;,&lt;code&gt;**=&lt;/code&gt;,&lt;code&gt;&lt;&lt;=&lt;/code&gt;,&lt;code&gt;&gt;&gt;=&lt;/code&gt;, &lt;code&gt;&lt;nowiki&gt;||=&lt;/nowiki&gt;&lt;/code&gt;, &lt;code&gt;&amp;&amp;=&lt;/code&gt;
|-
|スプラット
|&lt;code&gt;*&lt;/code&gt;, &lt;code&gt;**&lt;/code&gt;
|}

== 制御構造 ==
'''[[w:制御構造|制御構造]]'''（せいぎょこうぞう、''control flow''）とは、「順次」「分岐」「反復」という基本的な処理のことを言います。

{{コラム|Crystalの真理値|2=
制御構造は「条件式」が真であるか偽であるかによって分岐や反復の振る舞いが変わります。
では「条件式」が真・偽はどの様に決まるのでしょう？

Crystalでは &lt;code&gt;false&lt;/code&gt; あるいは &lt;code&gt;nil&lt;/code&gt; であると偽、それ以外が真です。

なので &lt;code&gt;0&lt;/code&gt; も &lt;code&gt;[]&lt;/code&gt;（空のArray） も &lt;code&gt;{}&lt;/code&gt;（空のNamedTuple）も真です。
}}
=== 条件分岐 ===
Crystalの条件分岐には、[[#if|if]], [[#until|until]] と [[#case|case]]の3つの構文があります。

==== if ====
'''[[w:if|if]]'''は条件式によって実行・否を切り替える構造構文で、評価した式の値を返すので条件演算子でもあります。

;ifの例:&lt;syntaxhighlight lang=crystal line&gt;
a = 0.0 / 0.0

if a &lt; 0
    puts &quot;minus&quot;
elsif a &gt; 0
    puts &quot;plus&quot;
elsif a == 0
    puts &quot;zero&quot;
else
    puts a
end

p! (
    if a &lt; 0
        &quot;minus&quot;
    elsif a &gt; 0
        &quot;plus&quot;
    elsif a == 0
        &quot;zero&quot;
    else
        a
    end
)
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
NaN 
(if a &lt; 0 
 &quot;minus&quot; 
else 
 if a &gt; 0 
   &quot;plus&quot; 
 else 
   if a == 0 
     &quot;zero&quot; 
   else 
     a 
   end 
 end 
end) # =&gt; NaN
&lt;/syntaxhighlight&gt;
:; elsif節:ifは、オプショナルな elsif 節を設け、条件式が偽であった時に別の条件に合致した処理を実行させることが出来ます。
:; else節:ifは、オプショナルな else 節を設け、条件式が偽であった時に処理を実行させることが出来ます。
: ifは値を返すので、メソッドの実引数に使うことが出来ますし、代入演算の右辺にも使えます。

==== 後置のif ====
Crystalには、RubyやPerlのような後置のifがあります。

;後置のifの例:&lt;syntaxhighlight lang=crystal&gt;
n = 0

puts &quot;nは0&quot; if n == 0
puts &quot;nは1&quot; if n == 1
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
nは0
&lt;/syntaxhighlight&gt;

==== unless====
'''unless'''（アンレス）は条件式によって実行・否を切り替える構造構文ですが、ifとは条件式に対する挙動が逆です。

;unless文の例:&lt;syntaxhighlight lang=crystal line&gt;
a = 0.0 / 0.0

unless a == 0
    puts &quot;Non-zero&quot;
else
    puts a
end
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
Non-zero
&lt;/syntaxhighlight&gt;
:; else節 : unless文は、オプショナルな else 節を設け、条件式が真であった時に処理を実行させることが出来ます。
::また、unless文は elsif 節は持てません。

==== 後置のunless ====
Crystalには、RubyやPerlのような後置のunlessがあります。

;後置のunlessの例:&lt;syntaxhighlight lang=crystal&gt;
n = 0

puts &quot;nは0&quot; unless n == 0
puts &quot;nは1&quot; unless n == 1
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
nは1ではない
&lt;/syntaxhighlight&gt;

==== case ====
caseは、複数の条件式によって処理を降る分ける用途の為に用意されています。

;caseの例:&lt;syntaxhighlight lang=crystal line&gt;
n = 2

case n
when 1
    puts &quot;one&quot;
when 2
    puts &quot;two&quot;
when 3
    puts &quot;three&quot;
else
    puts &quot;other&quot;
end

p! (
case n
when 1
    &quot;one&quot;
when 2
    &quot;two&quot;
when 3
    &quot;three&quot;
else
    &quot;other&quot;
end
)
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
two 
(case n 
when 1 
 &quot;one&quot; 
when 2 
 &quot;two&quot; 
when 3 
 &quot;three&quot; 
else 
 &quot;other&quot; 
end) # =&gt; &quot;two&quot;&lt;/syntaxhighlight&gt;
:C言語系のswitch文に慣れた人はbreakがないことに気がつくと思います。Crystalのcaseはfall throughしませんし、fall throughさせる方法もありません。

===== when節が定数でなく式を受付けます =====
[[#if|if]]を使ったコードをcaseに書き換えてみましょう。

;case の式の省略:&lt;syntaxhighlight lang=crystal line&gt;
a = 0.0 / 0.0
 
case
when a &lt; 0
  puts &quot;minus&quot;
when a &gt; 0
  puts &quot;plus&quot;
when a == 0
  puts &quot;zero&quot;
else
  puts a
end
 
p! (
case true
when a &lt; 0
  &quot;minus&quot;
when a &gt; 0
  &quot;plus&quot;
when a == 0
  &quot;zero&quot;
else
  a
end
)
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
NaN 
(case true 
when a &lt; 0 
 &quot;minus&quot; 
when a &gt; 0 
 &quot;plus&quot; 
when a == 0 
 &quot;zero&quot; 
else 
 a 
end) # =&gt; NaN
&lt;/syntaxhighlight&gt;
このコードは when 節の式の値とcaseの式を &lt;code&gt;===&lt;/code&gt; で比較し、最初に一致した when に対応する式が実行される事を利用しています。

===== 型による分岐 =====
when 節が式ではなく型であった場合、caseの式を &lt;code&gt;is_a?&lt;/code&gt; で評価し、最初に一致した when に対応する式が実行されます。

;型による分岐:&lt;syntaxhighlight lang=crystal line&gt;
p! 0.class,
	0.is_a?(Object),
	0.is_a?(Int32),
	0.is_a?(Number),
	0.is_a?(String)
 
case 0
when String
    puts &quot;String&quot;
when Number
    puts &quot;Number&quot;
when Int32
    puts &quot;Int32&quot;
when Object
    puts &quot;Object&quot;
else
    puts &quot;Unknown&quot;
end
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
0.class         # =&gt; Int32 
0.is_a?(Object) # =&gt; true 
0.is_a?(Int32)  # =&gt; true 
0.is_a?(Number) # =&gt; true 
0.is_a?(String) # =&gt; false 
Number
&lt;/syntaxhighlight&gt;
暗黙のオブジェクト構文を使うと
:&lt;syntaxhighlight lang=crystal line&gt;
case 0
when .is_a?(String)
    puts &quot;String&quot;
when .is_a?(Number)
    puts &quot;Number&quot;
when .is_a(Int32)
    puts &quot;Int32&quot;
when .is_a(Object)
    puts &quot;Object&quot;
else
    puts &quot;Unknown&quot;
end
&lt;/syntaxhighlight&gt;
:と書くことが出来ます。
:: メソッドは、.is_a? に限定しないので、 .odd? .even? .include? など Bool を返すメソッドなら何でも使えます。
when に対応する式は、1つのことが珍しくないので、その場合は省略可能な then を補うと、１行で書けます。
:&lt;syntaxhighlight lang=crystal line&gt;
case 0
when String then puts &quot;String&quot;
when Number then puts &quot;Number&quot;
when Int32  then puts &quot;Int32&quot;
when Object then puts &quot;Object&quot;
else             puts &quot;Unknown&quot;
end
&lt;/syntaxhighlight&gt;

[TODO:タプルとダミー識別子 _ ]

===== 網羅性の検査 =====
when の代わりに in を使用すると、exhaustive case 式が作成されます。exhaustive case では、必要な in 条件を省略するとコンパイル時にエラーとなります。排他的論理和では、when 節と else 節を含むことはできません。

コンパイラは、以下の in 条件をサポートしています。
:&lt;syntaxhighlight lang=crystal line&gt;
case 0
when String then puts &quot;String&quot;
when Number then puts &quot;Number&quot;
when Int32  then puts &quot;Int32&quot;
when Object then puts &quot;Object&quot;
else             puts &quot;Unknown&quot;
end
&lt;/syntaxhighlight&gt;

caseの式がユニオンの場合、各要素型を条件として使用することができる。
;組合型チェック:&lt;syntaxhighlight lang=crystal line&gt;
var : ( Bool | Int32 | Float64 )?
 
var = 3.14
 
p! (
case var
in Bool    then var ? 1 : 0
in Int32   then var
in Float64 then var.to_i
end
)
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
(case var 
in Bool 
 var ? 1 : 0 
in Int32 
 var 
in Float64 
 var.to_i 
end) # =&gt; 3
&lt;/syntaxhighlight&gt;

[TODO:case in は enum にも使える]

[TODO:短絡評価 &amp;&amp; || ]

=== 繰返し ===
Crystalには、他のプログラミング言語のような[[#繰返し構文|繰返し構文]]と、[[#イテレーターメソッド|イテレーターメソッド]]があります。

==== 繰返し構文 ====
Crystalの繰返し構文には、while と untilの2つがあります&lt;ref&gt;for も do-while も loop もありません。&lt;/ref&gt;。

===== while =====
while（ホワイル）は条件が'''真'''である間、式を実行しつづけます。
;構文:&lt;syntaxhighlight lang=crystal&gt;
while 条件式
    式１
    式２
      ：
    式ｎ
end
&lt;/syntaxhighlight&gt;
: Rubyと違い、条件式の後ろに &lt;code&gt;do&lt;/code&gt; をつけることは出来ません。

;while文のコード例:&lt;syntaxhighlight lang=crystal line&gt;
i = 0
p! (
while i &lt; 10
    p! i
    i += 1
    break i if i &gt; 5
end
)
&lt;/syntaxhighlight&gt;
: ２行目の &lt;code&gt;i &lt; 5&lt;/code&gt;が真の間、次の２行を繰返します。
: ４行目の &lt;code&gt;i += 1&lt;/code&gt; は &lt;code&gt;i = i + 1&lt;/code&gt; の構文糖
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
(while i &lt; 10 
 p!(i) 
 i = i + 1 
 if i &gt; 5 
   break i 
  end 
end)# =&gt; 
i # =&gt; 0 
i # =&gt; 1 
i # =&gt; 2 
i # =&gt; 3 
i # =&gt; 4 
i # =&gt; 5 
6
&lt;/syntaxhighlight&gt;

===== until =====
until（アンティル）は条件が'''偽'''である間、式を実行しつづけます。whileとは条件に対する挙動が逆です。
;構文:&lt;syntaxhighlight lang=crystal&gt;
until 条件式 [ do ]
    文１
    文２
      ：
    文ｎ
end
&lt;/syntaxhighlight&gt;
: &lt;code&gt;do&lt;/code&gt; は省略できます。

;untilのコード例:&lt;syntaxhighlight lang=crystal line&gt;
i = 0
until i == 3
    puts i
    i += 1
end
&lt;/syntaxhighlight&gt;
: ２行目の &lt;code&gt;i == 3&lt;/code&gt;が偽の間、次の２行を繰返します。
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
0
1
2
&lt;/syntaxhighlight&gt;

===== for =====
Crystalにはforがありませんが、コレクションのイテレーションメソッドを使うことで繰返しを簡素に実現出来ます。

==== Rangeオブジェクト ====
Rangeオブジェクトは、整数の区間を表し範囲演算子 &lt;code&gt;開始 ... 終了&lt;/code&gt; で生成します。

;コード:&lt;syntaxhighlight lang=crystal&gt;
rng = 1..3
puts rng.class
rng.each do | n |
  puts &quot;#{n}番&quot;;
end
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
Range(Int32, Int32) 
1番 
2番 
3番
&lt;/syntaxhighlight&gt;

==== Arrayオブジェクト ====
Arrayオブジェクトは、任意の Crystal オブジェクトを要素として持つことができます。
配列式&lt;code&gt;[要素1, 要素2, … 要素n]&lt;/code&gt; で生成します。

;コード:&lt;syntaxhighlight lang=crystal&gt;
animals = [&quot;ネコ&quot;, &quot;金魚&quot;, &quot;ハムスター&quot;]
 
puts animals.class
animals.each do | animal |
  puts &quot;動物 #{animal}&quot;
end
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
Array(String) 
動物 ネコ 
動物 金魚 
動物 ハムスター
&lt;/syntaxhighlight&gt;

==== NamedTupleオブジェクト ====
NamedTupleオブジェクトは、任意の Crystal オブジェクトをキーに、任意の Crystal オブジェクトを値に持つことができる連想配列です。
NamedTuple式&lt;code&gt;{キー1 =&gt; 値1, キー2 =&gt; 値2, キーn =&gt; 値n}&lt;/code&gt; で生成します。
また、キーが Symbol の場合
NamedTuple式&lt;code&gt;{キー1: 値1, キー2: 値2, キーn: 値n}&lt;/code&gt; で生成することが出来ます。

;コード:&lt;syntaxhighlight lang=crystal&gt;
animals = {cat: &quot;ネコ&quot;, gold_fish: &quot;金魚&quot;, hamster: &quot;ハムスター&quot;}
 
puts animals.class
 
animals.each do | en, animal |
  puts &quot;動物 #{en}: #{animal}&quot;
end
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
NamedTuple(cat: String, gold_fish: String, hamster: String)
動物 cat: ネコ
動物 gold_fish: 金魚
動物 hamster: ハムスター
&lt;/syntaxhighlight&gt;

このように、Crystalではforがなくてもコレクションのメソッドで同様の処理を実現できます。

===== loop =====
loop、ありません。
while true で代用します。

;loopの代用コード例:&lt;syntaxhighlight lang=crystal line&gt;
i = 1
while true
    puts &quot;0b%b&quot; % i
    i &lt;&lt;= 1
    break if i &gt; 2**8
end
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
0b1
0b10
0b100
0b1000
0b10000
0b100000
0b1000000
0b10000000 
0b100000000
&lt;/syntaxhighlight&gt;
:５行目の、&lt;code&gt;break if i &gt; 2**8&lt;/code&gt;でループを脱出するようにしています。この様に break や return あるいは例外が上がらないとループは永久に終わりません。
:このコードは、Crystalにはない do-while文を模倣する例にもなっています。

==== イテレーターメソッド ====
===== Integer#times =====
Integer#timesは与えられたブロックをオブジェクトの示す整数値回くりかえします。

:コード&lt;syntaxhighlight lang=crystal&gt;
3.times{ puts &quot;Hello, world!&quot; }
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
Hello, world!
Hello, world!
Hello, world!
&lt;/syntaxhighlight&gt;

;繰返したい処理が2行以上ある場合:&lt;syntaxhighlight lang=crystal&gt;
3.times {
  puts &quot;Hello&quot;
  puts &quot;World&quot;
  puts &quot;&quot;
}
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
Hello
World

Hello
World

Hello
World
&lt;/syntaxhighlight&gt;

;ループ変数を使た例:&lt;syntaxhighlight lang=crystal&gt;
3.times do |i|
  puts &quot;#{i}の倍は#{2 * i}&quot;
end
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
0の倍は0
1の倍は2
2の倍は4
&lt;/syntaxhighlight&gt;

;ブロックを伴わないtimesメソッド:&lt;syntaxhighlight lang=crystal&gt;
iter = 3.times
puts iter.class
p! iter.next
p! iter.next
p! iter.next
p! iter.next
p! iter.next
p! iter.next
# puts iter.next #  `next': StopIteration: iteration reached an end
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
Int::TimesIterator(Int32) 
iter.next # =&gt; 0 
iter.next # =&gt; 1 
iter.next # =&gt; 2 
iter.next # =&gt; #&lt;Iterator::Stop:0x7fb5bedd7fe0&gt; 
iter.next # =&gt; #&lt;Iterator::Stop:0x7fb5bedd7fe0&gt; 
iter.next # =&gt; #&lt;Iterator::Stop:0x7fb5bedd7fe0&gt;
&lt;/syntaxhighlight&gt;
: Integer#times にブロックを渡さないと、Int::TimesIterator([T])オブジェクトが返ります。
: Int::TimesIterator([T])オブジェクトは外部イテレーターと呼ばれnextメソッドで反復を行えます。

== メソッド ==
=== クラスのメソッド一覧 ===
Crystal には、Objectクラスにmethodsメソッドがないので、マクロで実装しました。

;RubyのObject#methods:&lt;syntaxhighlight lang=ruby&gt;
p Object.methods.sort,
  Integer.methods.sort,
  Float.methods.sort,
  Array.methods.sort,
  Range.methods.sort
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
[:!, :!=, :!~, :&lt;, :&lt;=, :&lt;=&gt;, :==, :===, :=~, :&gt;, :&gt;=, :__id__, :__send__, :alias_method, :allocate, :ancestors, :attr, :attr_accessor, :attr_reader, :attr_writer, :autoload, :autoload?, :class, :class_eval, :class_exec, :class_variable_defined?, :class_variable_get, :class_variable_set, :class_variables, :clone, :const_defined?, :const_get, :const_missing, :const_set, :const_source_location, :constants, :define_method, :define_singleton_method, :deprecate_constant, :display, :dup, :enum_for, :eql?, :equal?, :extend, :freeze, :frozen?, :hash, :include, :include?, :included_modules, :inspect, :instance_eval, :instance_exec, :instance_method, :instance_methods, :instance_of?, :instance_variable_defined?, :instance_variable_get, :instance_variable_set, :instance_variables, :is_a?, :itself, :kind_of?, :method, :method_defined?, :methods, :module_eval, :module_exec, :name, :new, :nil?, :object_id, :prepend, :private_class_method, :private_constant, :private_instance_methods, :private_method_defined?, :private_methods, :protected_instance_methods, :protected_method_defined?, :protected_methods, :public_class_method, :public_constant, :public_instance_method, :public_instance_methods, :public_method, :public_method_defined?, :public_methods, :public_send, :remove_class_variable, :remove_instance_variable, :remove_method, :respond_to?, :send, :singleton_class, :singleton_class?, :singleton_method, :singleton_methods, :subclasses, :superclass, :taint, :tainted?, :tap, :then, :to_enum, :to_s, :trust, :undef_method, :untaint, :untrust, :untrusted?, :yield_self]
[:!, :!=, :!~, :&lt;, :&lt;=, :&lt;=&gt;, :==, :===, :=~, :&gt;, :&gt;=, :__id__, :__send__, :alias_method, :allocate, :ancestors, :attr, :attr_accessor, :attr_reader, :attr_writer, :autoload, :autoload?, :class, :class_eval, :class_exec, :class_variable_defined?, :class_variable_get, :class_variable_set, :class_variables, :clone, :const_defined?, :const_get, :const_missing, :const_set, :const_source_location, :constants, :define_method, :define_singleton_method, :deprecate_constant, :display, :dup, :enum_for, :eql?, :equal?, :extend, :freeze, :frozen?, :hash, :include, :include?, :included_modules, :inspect, :instance_eval, :instance_exec, :instance_method, :instance_methods, :instance_of?, :instance_variable_defined?, :instance_variable_get, :instance_variable_set, :instance_variables, :is_a?, :itself, :kind_of?, :method, :method_defined?, :methods, :module_eval, :module_exec, :name, :nil?, :object_id, :prepend, :private_class_method, :private_constant, :private_instance_methods, :private_method_defined?, :private_methods, :protected_instance_methods, :protected_method_defined?, :protected_methods, :public_class_method, :public_constant, :public_instance_method, :public_instance_methods, :public_method, :public_method_defined?, :public_methods, :public_send, :remove_class_variable, :remove_instance_variable, :remove_method, :respond_to?, :send, :singleton_class, :singleton_class?, :singleton_method, :singleton_methods, :sqrt, :subclasses, :superclass, :taint, :tainted?, :tap, :then, :to_enum, :to_s, :trust, :try_convert, :undef_method, :untaint, :untrust, :untrusted?, :yield_self]
[:!, :!=, :!~, :&lt;, :&lt;=, :&lt;=&gt;, :==, :===, :=~, :&gt;, :&gt;=, :__id__, :__send__, :alias_method, :allocate, :ancestors, :attr, :attr_accessor, :attr_reader, :attr_writer, :autoload, :autoload?, :class, :class_eval, :class_exec, :class_variable_defined?, :class_variable_get, :class_variable_set, :class_variables, :clone, :const_defined?, :const_get, :const_missing, :const_set, :const_source_location, :constants, :define_method, :define_singleton_method, :deprecate_constant, :display, :dup, :enum_for, :eql?, :equal?, :extend, :freeze, :frozen?, :hash, :include, :include?, :included_modules, :inspect, :instance_eval, :instance_exec, :instance_method, :instance_methods, :instance_of?, :instance_variable_defined?, :instance_variable_get, :instance_variable_set, :instance_variables, :is_a?, :itself, :kind_of?, :method, :method_defined?, :methods, :module_eval, :module_exec, :name, :nil?, :object_id, :prepend, :private_class_method, :private_constant, :private_instance_methods, :private_method_defined?, :private_methods, :protected_instance_methods, :protected_method_defined?, :protected_methods, :public_class_method, :public_constant, :public_instance_method, :public_instance_methods, :public_method, :public_method_defined?, :public_methods, :public_send, :remove_class_variable, :remove_instance_variable, :remove_method, :respond_to?, :send, :singleton_class, :singleton_class?, :singleton_method, :singleton_methods, :subclasses, :superclass, :taint, :tainted?, :tap, :then, :to_enum, :to_s, :trust, :undef_method, :untaint, :untrust, :untrusted?, :yield_self]
[:!, :!=, :!~, :&lt;, :&lt;=, :&lt;=&gt;, :==, :===, :=~, :&gt;, :&gt;=, :[], :__id__, :__send__, :alias_method, :allocate, :ancestors, :attr, :attr_accessor, :attr_reader, :attr_writer, :autoload, :autoload?, :class, :class_eval, :class_exec, :class_variable_defined?, :class_variable_get, :class_variable_set, :class_variables, :clone, :const_defined?, :const_get, :const_missing, :const_set, :const_source_location, :constants, :define_method, :define_singleton_method, :deprecate_constant, :display, :dup, :enum_for, :eql?, :equal?, :extend, :freeze, :frozen?, :hash, :include, :include?, :included_modules, :inspect, :instance_eval, :instance_exec, :instance_method, :instance_methods, :instance_of?, :instance_variable_defined?, :instance_variable_get, :instance_variable_set, :instance_variables, :is_a?, :itself, :kind_of?, :method, :method_defined?, :methods, :module_eval, :module_exec, :name, :new, :nil?, :object_id, :prepend, :private_class_method, :private_constant, :private_instance_methods, :private_method_defined?, :private_methods, :protected_instance_methods, :protected_method_defined?, :protected_methods, :public_class_method, :public_constant, :public_instance_method, :public_instance_methods, :public_method, :public_method_defined?, :public_methods, :public_send, :remove_class_variable, :remove_instance_variable, :remove_method, :respond_to?, :send, :singleton_class, :singleton_class?, :singleton_method, :singleton_methods, :subclasses, :superclass, :taint, :tainted?, :tap, :then, :to_enum, :to_s, :trust, :try_convert, :undef_method, :untaint, :untrust, :untrusted?, :yield_self] 
[:!, :!=, :!~, :&lt;, :&lt;=, :&lt;=&gt;, :==, :===, :=~, :&gt;, :&gt;=, :__id__, :__send__, :alias_method, :allocate, :ancestors, :attr, :attr_accessor, :attr_reader, :attr_writer, :autoload, :autoload?, :class, :class_eval, :class_exec, :class_variable_defined?, :class_variable_get, :class_variable_set, :class_variables, :clone, :const_defined?, :const_get, :const_missing, :const_set, :const_source_location, :constants, :define_method, :define_singleton_method, :deprecate_constant, :display, :dup, :enum_for, :eql?, :equal?, :extend, :freeze, :frozen?, :hash, :include, :include?, :included_modules, :inspect, :instance_eval, :instance_exec, :instance_method, :instance_methods, :instance_of?, :instance_variable_defined?, :instance_variable_get, :instance_variable_set, :instance_variables, :is_a?, :itself, :kind_of?, :method, :method_defined?, :methods, :module_eval, :module_exec, :name, :new, :nil?, :object_id, :prepend, :private_class_method, :private_constant, :private_instance_methods, :private_method_defined?, :private_methods, :protected_instance_methods, :protected_method_defined?, :protected_methods, :public_class_method, :public_constant, :public_instance_method, :public_instance_methods, :public_method, :public_method_defined?, :public_methods, :public_send, :remove_class_variable, :remove_instance_variable, :remove_method, :respond_to?, :send, :singleton_class, :singleton_class?, :singleton_method, :singleton_methods, :subclasses, :superclass, :taint, :tainted?, :tap, :then, :to_enum, :to_s, :trust, :undef_method, :untaint, :untrust, :untrusted?, :yield_self]
&lt;/syntaxhighlight&gt;
;Crystalに実装したmethodsマクロ:&lt;syntaxhighlight lang=crystal&gt;
class Object
  macro methods
    {{ @type.methods.map(&amp;.name.stringify).sort.uniq }}
  end
end

p! Object.methods,
  Reference.methods,
  Array.methods,
  Box.methods,
  Channel.methods,
  Deque.methods,
  Dir.methods,
  Exception.methods,
  ArgumentError.methods,
  DivisionByZeroError.methods,
  IndexError.methods,
  InvalidByteSequenceError.methods,
  Fiber.methods,
  Hash.methods,
  IO.methods,
  File.methods,
  Mutex.methods,
  PrettyPrint.methods,
  Process.methods,
  Regex.methods,
  String.methods,
  Thread.methods,
  Bool.methods,
  Int32.methods,
  Float64.methods,
  Proc.methods
&lt;/syntaxhighlight&gt;
;実行結果:&lt;syntaxhighlight lang=&quot;text&quot;&gt;
Object.methods                   # =&gt; [&quot;!=&quot;, &quot;!~&quot;, &quot;==&quot;, &quot;===&quot;, &quot;=~&quot;, &quot;class&quot;, &quot;crystal_type_id&quot;, &quot;dup&quot;, &quot;hash&quot;, &quot;in?&quot;, &quot;inspect&quot;, &quot;itself&quot;, &quot;not_nil!&quot;, &quot;pretty_inspect&quot;, &quot;pretty_print&quot;, &quot;tap&quot;, &quot;to_s&quot;, &quot;try&quot;, &quot;unsafe_as&quot;]
Reference.methods                # =&gt; [&quot;==&quot;, &quot;dup&quot;, &quot;exec_recursive&quot;, &quot;exec_recursive_clone&quot;, &quot;hash&quot;, &quot;inspect&quot;, &quot;object_id&quot;, &quot;pretty_print&quot;, &quot;same?&quot;, &quot;to_s&quot;]
Array.methods                    # =&gt; [&quot;&amp;&quot;, &quot;*&quot;, &quot;+&quot;, &quot;-&quot;, &quot;&lt;&lt;&quot;, &quot;&lt;=&gt;&quot;, &quot;==&quot;, &quot;[]&quot;, &quot;[]=&quot;, &quot;[]?&quot;, &quot;calculate_new_capacity&quot;, &quot;check_needs_resize&quot;, &quot;check_needs_resize_for_unshift&quot;, &quot;clear&quot;, &quot;clone&quot;, &quot;compact&quot;, &quot;compact!&quot;, &quot;concat&quot;, &quot;delete&quot;, &quot;delete_at&quot;, &quot;dup&quot;, &quot;each_repeated_permutation&quot;, &quot;fill&quot;, &quot;first&quot;, &quot;flatten&quot;, &quot;increase_capacity&quot;, &quot;increase_capacity_for_unshift&quot;, &quot;index&quot;, &quot;initialize&quot;, &quot;insert&quot;, &quot;inspect&quot;, &quot;internal_delete&quot;, &quot;last&quot;, &quot;map&quot;, &quot;map_with_index&quot;, &quot;needs_resize?&quot;, &quot;pop&quot;, &quot;pop?&quot;, &quot;pretty_print&quot;, &quot;product&quot;, &quot;push&quot;, &quot;reject!&quot;, &quot;remaining_capacity&quot;, &quot;repeated_permutations&quot;, &quot;replace&quot;, &quot;reset_buffer_to_root_buffer&quot;, &quot;resize_if_cant_insert&quot;, &quot;resize_to_capacity&quot;, &quot;resize_to_capacity_for_unshift&quot;, &quot;reverse&quot;, &quot;root_buffer&quot;, &quot;rotate&quot;, &quot;rotate!&quot;, &quot;select!&quot;, &quot;shift&quot;, &quot;shift?&quot;, &quot;shift_buffer_by&quot;, &quot;shift_when_not_empty&quot;, &quot;shuffle&quot;, &quot;size&quot;, &quot;size=&quot;, &quot;skip&quot;, &quot;sort&quot;, &quot;sort!&quot;, &quot;sort_by&quot;, &quot;sort_by!&quot;, &quot;to_a&quot;, &quot;to_lookup_hash&quot;, &quot;to_s&quot;, &quot;to_unsafe&quot;, &quot;to_unsafe_slice&quot;, &quot;transpose&quot;, &quot;truncate&quot;, &quot;uniq&quot;, &quot;uniq!&quot;, &quot;unsafe_fetch&quot;, &quot;unsafe_put&quot;, &quot;unshift&quot;, &quot;unstable_sort&quot;, &quot;unstable_sort!&quot;, &quot;unstable_sort_by&quot;, &quot;unstable_sort_by!&quot;, &quot;|&quot;]
Box.methods                      # =&gt; [&quot;initialize&quot;, &quot;object&quot;]
Channel.methods                  # =&gt; [&quot;close&quot;, &quot;closed?&quot;, &quot;dequeue_receiver&quot;, &quot;dequeue_sender&quot;, &quot;initialize&quot;, &quot;inspect&quot;, &quot;pretty_print&quot;, &quot;receive&quot;, &quot;receive?&quot;, &quot;receive_impl&quot;, &quot;receive_internal&quot;, &quot;receive_select_action&quot;, &quot;receive_select_action?&quot;, &quot;send&quot;, &quot;send_internal&quot;, &quot;send_select_action&quot;]
Deque.methods                    # =&gt; [&quot;+&quot;, &quot;&lt;&lt;&quot;, &quot;==&quot;, &quot;buffer&quot;, &quot;clear&quot;, &quot;clone&quot;, &quot;concat&quot;, &quot;delete&quot;, &quot;delete_at&quot;, &quot;dup&quot;, &quot;each&quot;, &quot;halfs&quot;, &quot;increase_capacity&quot;, &quot;initialize&quot;, &quot;insert&quot;, &quot;inspect&quot;, &quot;internal_delete&quot;, &quot;pop&quot;, &quot;pop?&quot;, &quot;pretty_print&quot;, &quot;push&quot;, &quot;reject!&quot;, &quot;rotate!&quot;, &quot;select!&quot;, &quot;shift&quot;, &quot;shift?&quot;, &quot;size&quot;, &quot;size=&quot;, &quot;to_s&quot;, &quot;unsafe_fetch&quot;, &quot;unsafe_put&quot;, &quot;unshift&quot;]
Dir.methods                      # =&gt; [&quot;children&quot;, &quot;close&quot;, &quot;each&quot;, &quot;each_child&quot;, &quot;entries&quot;, &quot;initialize&quot;, &quot;inspect&quot;, &quot;path&quot;, &quot;pretty_print&quot;, &quot;read&quot;, &quot;rewind&quot;, &quot;to_s&quot;]
Exception.methods                # =&gt; [&quot;backtrace&quot;, &quot;backtrace?&quot;, &quot;callstack&quot;, &quot;callstack=&quot;, &quot;cause&quot;, &quot;initialize&quot;, &quot;inspect&quot;, &quot;inspect_with_backtrace&quot;, &quot;message&quot;, &quot;to_s&quot;]
ArgumentError.methods            # =&gt; [&quot;initialize&quot;]
DivisionByZeroError.methods      # =&gt; [&quot;initialize&quot;]
IndexError.methods               # =&gt; [&quot;initialize&quot;]
InvalidByteSequenceError.methods # =&gt; [&quot;initialize&quot;]
Fiber.methods                    # =&gt; [&quot;cancel_timeout&quot;, &quot;dead?&quot;, &quot;enqueue&quot;, &quot;initialize&quot;, &quot;inspect&quot;, &quot;makecontext&quot;, &quot;name&quot;, &quot;name=&quot;, &quot;next&quot;, &quot;next=&quot;, &quot;previous&quot;, &quot;previous=&quot;, &quot;push_gc_roots&quot;, &quot;resumable?&quot;, &quot;resume&quot;, &quot;resume_event&quot;, &quot;run&quot;, &quot;running?&quot;, &quot;stack_bottom&quot;, &quot;stack_bottom=&quot;, &quot;timeout&quot;, &quot;timeout_event&quot;, &quot;timeout_select_action&quot;, &quot;timeout_select_action=&quot;, &quot;to_s&quot;]
Hash.methods                     # =&gt; [&quot;==&quot;, &quot;[]&quot;, &quot;[]=&quot;, &quot;[]?&quot;, &quot;add_entry_and_increment_size&quot;, &quot;clear&quot;, &quot;clear_entries&quot;, &quot;clear_impl&quot;, &quot;clear_indices&quot;, &quot;clone&quot;, &quot;compact&quot;, &quot;compact!&quot;, &quot;compare_by_identity&quot;, &quot;compare_by_identity?&quot;, &quot;compute_indices_bytesize&quot;, &quot;delete&quot;, &quot;delete_entry&quot;, &quot;delete_entry_and_update_counts&quot;, &quot;delete_impl&quot;, &quot;delete_linear_scan&quot;, &quot;dig&quot;, &quot;dig?&quot;, &quot;do_compaction&quot;, &quot;double_indices_size&quot;, &quot;dup&quot;, &quot;each&quot;, &quot;each_entry_with_index&quot;, &quot;each_key&quot;, &quot;each_value&quot;, &quot;empty?&quot;, &quot;entries&quot;, &quot;entries_capacity&quot;, &quot;entries_full?&quot;, &quot;entries_size&quot;, &quot;entry_matches?&quot;, &quot;fetch&quot;, &quot;find_entry&quot;, &quot;find_entry_with_index&quot;, &quot;find_entry_with_index_linear_scan&quot;, &quot;first_entry?&quot;, &quot;first_key&quot;, &quot;first_key?&quot;, &quot;first_value&quot;, &quot;first_value?&quot;, &quot;fit_in_indices&quot;, &quot;get_entry&quot;, &quot;get_index&quot;, &quot;has_key?&quot;, &quot;has_value?&quot;, &quot;hash&quot;, &quot;indices_malloc_size&quot;, &quot;indices_size&quot;, &quot;initialize&quot;, &quot;initialize_clone&quot;, &quot;initialize_clone_entries&quot;, &quot;initialize_compare_by_identity&quot;, &quot;initialize_copy_non_entries_vars&quot;, &quot;initialize_default_block&quot;, &quot;initialize_dup&quot;, &quot;initialize_dup_entries&quot;, &quot;inspect&quot;, &quot;invert&quot;, &quot;key_for&quot;, &quot;key_for?&quot;, &quot;key_hash&quot;, &quot;keys&quot;, &quot;last_entry?&quot;, &quot;last_key&quot;, &quot;last_key?&quot;, &quot;last_value&quot;, &quot;last_value?&quot;, &quot;malloc_entries&quot;, &quot;malloc_indices&quot;, &quot;merge&quot;, &quot;merge!&quot;, &quot;merge_into!&quot;, &quot;next_index&quot;, &quot;pretty_print&quot;, &quot;proper_subset_of?&quot;, &quot;proper_superset_of?&quot;, &quot;put&quot;, &quot;realloc_entries&quot;, &quot;realloc_indices&quot;, &quot;rehash&quot;, &quot;reject&quot;, &quot;reject!&quot;, &quot;resize&quot;, &quot;select&quot;, &quot;select!&quot;, &quot;set_entry&quot;, &quot;set_index&quot;, &quot;shift&quot;, &quot;shift?&quot;, &quot;size&quot;, &quot;subset_of?&quot;, &quot;superset_of?&quot;, &quot;to_a&quot;, &quot;to_a_impl&quot;, &quot;to_h&quot;, &quot;to_s&quot;, &quot;transform_keys&quot;, &quot;transform_values&quot;, &quot;transform_values!&quot;, &quot;update&quot;, &quot;update_linear_scan&quot;, &quot;upsert&quot;, &quot;values&quot;, &quot;values_at&quot;]
IO.methods                       # =&gt; [&quot;&lt;&lt;&quot;, &quot;check_open&quot;, &quot;close&quot;, &quot;closed?&quot;, &quot;decoder&quot;, &quot;each_byte&quot;, &quot;each_char&quot;, &quot;each_line&quot;, &quot;encoder&quot;, &quot;encoding&quot;, &quot;flush&quot;, &quot;getb_to_end&quot;, &quot;gets&quot;, &quot;gets_peek&quot;, &quot;gets_slow&quot;, &quot;gets_to_end&quot;, &quot;has_non_utf8_encoding?&quot;, &quot;peek&quot;, &quot;peek_or_read_utf8&quot;, &quot;peek_or_read_utf8_masked&quot;, &quot;pos&quot;, &quot;pos=&quot;, &quot;print&quot;, &quot;printf&quot;, &quot;puts&quot;, &quot;read&quot;, &quot;read_at&quot;, &quot;read_byte&quot;, &quot;read_bytes&quot;, &quot;read_char&quot;, &quot;read_char_with_bytesize&quot;, &quot;read_fully&quot;, &quot;read_fully?&quot;, &quot;read_line&quot;, &quot;read_string&quot;, &quot;read_utf8&quot;, &quot;read_utf8_byte&quot;, &quot;rewind&quot;, &quot;seek&quot;, &quot;set_encoding&quot;, &quot;skip&quot;, &quot;skip_to_end&quot;, &quot;tell&quot;, &quot;tty?&quot;, &quot;utf8_encoding?&quot;, &quot;write&quot;, &quot;write_byte&quot;, &quot;write_bytes&quot;, &quot;write_string&quot;, &quot;write_utf8&quot;]
File.methods                     # =&gt; [&quot;delete&quot;, &quot;initialize&quot;, &quot;inspect&quot;, &quot;path&quot;, &quot;read_at&quot;, &quot;size&quot;, &quot;truncate&quot;]
Mutex.methods                    # =&gt; [&quot;initialize&quot;, &quot;lock&quot;, &quot;lock_slow&quot;, &quot;synchronize&quot;, &quot;try_lock&quot;, &quot;unlock&quot;]
PrettyPrint.methods              # =&gt; [&quot;break_outmost_groups&quot;, &quot;breakable&quot;, &quot;comma&quot;, &quot;current_group&quot;, &quot;fill_breakable&quot;, &quot;flush&quot;, &quot;group&quot;, &quot;group_queue&quot;, &quot;group_sub&quot;, &quot;indent&quot;, &quot;initialize&quot;, &quot;list&quot;, &quot;nest&quot;, &quot;newline&quot;, &quot;surround&quot;, &quot;text&quot;]
Process.methods                  # =&gt; [&quot;channel&quot;, &quot;close&quot;, &quot;close_io&quot;, &quot;copy_io&quot;, &quot;ensure_channel&quot;, &quot;error&quot;, &quot;error?&quot;, &quot;exists?&quot;, &quot;finalize&quot;, &quot;initialize&quot;, &quot;input&quot;, &quot;input?&quot;, &quot;output&quot;, &quot;output?&quot;, &quot;pid&quot;, &quot;signal&quot;, &quot;stdio_to_fd&quot;, &quot;terminate&quot;, &quot;terminated?&quot;, &quot;wait&quot;]
Regex.methods                    # =&gt; [&quot;+&quot;, &quot;==&quot;, &quot;===&quot;, &quot;=~&quot;, &quot;capture_count&quot;, &quot;clone&quot;, &quot;dup&quot;, &quot;finalize&quot;, &quot;hash&quot;, &quot;initialize&quot;, &quot;inspect&quot;, &quot;internal_matches?&quot;, &quot;match&quot;, &quot;match_at_byte_index&quot;, &quot;matches?&quot;, &quot;matches_at_byte_index?&quot;, &quot;name_table&quot;, &quot;options&quot;, &quot;source&quot;, &quot;to_s&quot;]
String.methods                   # =&gt; [&quot;%&quot;, &quot;*&quot;, &quot;+&quot;, &quot;&lt;=&gt;&quot;, &quot;==&quot;, &quot;=~&quot;, &quot;[]&quot;, &quot;[]?&quot;, &quot;ascii_only?&quot;, &quot;blank?&quot;, &quot;byte_at&quot;, &quot;byte_at?&quot;, &quot;byte_delete_at&quot;, &quot;byte_index&quot;, &quot;byte_index_to_char_index&quot;, &quot;byte_slice&quot;, &quot;byte_slice?&quot;, &quot;bytes&quot;, &quot;bytesize&quot;, &quot;calc_excess_left&quot;, &quot;calc_excess_right&quot;, &quot;camelcase&quot;, &quot;capitalize&quot;, &quot;center&quot;, &quot;char_at&quot;, &quot;char_bytesize_at&quot;, &quot;char_index_to_byte_index&quot;, &quot;chars&quot;, &quot;check_no_null_byte&quot;, &quot;chomp&quot;, &quot;clone&quot;, &quot;codepoint_at&quot;, &quot;codepoints&quot;, &quot;compare&quot;, &quot;count&quot;, &quot;delete&quot;, &quot;delete_at&quot;, &quot;downcase&quot;, &quot;dump&quot;, &quot;dump_char&quot;, &quot;dump_hex&quot;, &quot;dump_or_inspect&quot;, &quot;dump_or_inspect_char&quot;, &quot;dump_or_inspect_unquoted&quot;, &quot;dump_unquoted&quot;, &quot;dup&quot;, &quot;each_byte&quot;, &quot;each_byte_index_and_char_index&quot;, &quot;each_char&quot;, &quot;each_char_with_index&quot;, &quot;each_codepoint&quot;, &quot;each_grapheme&quot;, &quot;each_grapheme_boundary&quot;, &quot;each_line&quot;, &quot;empty?&quot;, &quot;encode&quot;, &quot;ends_with?&quot;, &quot;find_start_and_end&quot;, &quot;grapheme_size&quot;, &quot;graphemes&quot;, &quot;gsub&quot;, &quot;gsub_append&quot;, &quot;gsub_ascii_char&quot;, &quot;has_back_references?&quot;, &quot;hash&quot;, &quot;hexbytes&quot;, &quot;hexbytes?&quot;, &quot;includes?&quot;, &quot;index&quot;, &quot;insert&quot;, &quot;insert_impl&quot;, &quot;inspect&quot;, &quot;inspect_char&quot;, &quot;inspect_unquoted&quot;, &quot;just&quot;, &quot;lchop&quot;, &quot;lchop?&quot;, &quot;lines&quot;, &quot;ljust&quot;, &quot;lstrip&quot;, &quot;match&quot;, &quot;matches?&quot;, &quot;partition&quot;, &quot;presence&quot;, &quot;pretty_print&quot;, &quot;rchop&quot;, &quot;rchop?&quot;, &quot;remove_excess&quot;, &quot;remove_excess_left&quot;, &quot;remove_excess_right&quot;, &quot;reverse&quot;, &quot;rindex&quot;, &quot;rjust&quot;, &quot;rpartition&quot;, &quot;rstrip&quot;, &quot;scan&quot;, &quot;scan_backreferences&quot;, &quot;scrub&quot;, &quot;single_byte_optimizable?&quot;, &quot;size&quot;, &quot;size_known?&quot;, &quot;split&quot;, &quot;split_by_empty_separator&quot;, &quot;split_single_byte&quot;, &quot;squeeze&quot;, &quot;starts_with?&quot;, &quot;strip&quot;, &quot;sub&quot;, &quot;sub_append&quot;, &quot;sub_index&quot;, &quot;sub_range&quot;, &quot;succ&quot;, &quot;titleize&quot;, &quot;to_f&quot;, &quot;to_f32&quot;, &quot;to_f32?&quot;, &quot;to_f64&quot;, &quot;to_f64?&quot;, &quot;to_f?&quot;, &quot;to_f_impl&quot;, &quot;to_i&quot;, &quot;to_i128&quot;, &quot;to_i128?&quot;, &quot;to_i16&quot;, &quot;to_i16?&quot;, &quot;to_i32&quot;, &quot;to_i32?&quot;, &quot;to_i64&quot;, &quot;to_i64?&quot;, &quot;to_i8&quot;, &quot;to_i8?&quot;, &quot;to_i?&quot;, &quot;to_s&quot;, &quot;to_slice&quot;, &quot;to_u128&quot;, &quot;to_u128?&quot;, &quot;to_u16&quot;, &quot;to_u16?&quot;, &quot;to_u32&quot;, &quot;to_u32?&quot;, &quot;to_u64&quot;, &quot;to_u64?&quot;, &quot;to_u8&quot;, &quot;to_u8?&quot;, &quot;to_unsafe&quot;, &quot;to_unsigned_info&quot;, &quot;to_utf16&quot;, &quot;tr&quot;, &quot;underscore&quot;, &quot;unicode_delete_at&quot;, &quot;unsafe_byte_at&quot;, &quot;unsafe_byte_slice&quot;, &quot;unsafe_byte_slice_string&quot;, &quot;upcase&quot;, &quot;valid_encoding?&quot;]
Thread.methods                   # =&gt; [&quot;detach&quot;, &quot;event_base&quot;, &quot;gc_thread_handler&quot;, &quot;gc_thread_handler=&quot;, &quot;initialize&quot;, &quot;join&quot;, &quot;main_fiber&quot;, &quot;next&quot;, &quot;next=&quot;, &quot;previous&quot;, &quot;previous=&quot;, &quot;scheduler&quot;, &quot;stack_address&quot;, &quot;start&quot;, &quot;to_unsafe&quot;]
Bool.methods                     # =&gt; [&quot;!=&quot;, &quot;&amp;&quot;, &quot;==&quot;, &quot;^&quot;, &quot;clone&quot;, &quot;hash&quot;, &quot;to_s&quot;, &quot;to_unsafe&quot;, &quot;|&quot;]
Int32.methods                    # =&gt; [&quot;!=&quot;, &quot;&amp;&quot;, &quot;&amp;*&quot;, &quot;&amp;+&quot;, &quot;&amp;-&quot;, &quot;*&quot;, &quot;+&quot;, &quot;-&quot;, &quot;/&quot;, &quot;&lt;&quot;, &quot;&lt;=&quot;, &quot;==&quot;, &quot;&gt;&quot;, &quot;&gt;=&quot;, &quot;^&quot;, &quot;clone&quot;, &quot;leading_zeros_count&quot;, &quot;popcount&quot;, &quot;to_f&quot;, &quot;to_f!&quot;, &quot;to_f32&quot;, &quot;to_f32!&quot;, &quot;to_f64&quot;, &quot;to_f64!&quot;, &quot;to_i&quot;, &quot;to_i!&quot;, &quot;to_i128&quot;, &quot;to_i128!&quot;, &quot;to_i16&quot;, &quot;to_i16!&quot;, &quot;to_i32&quot;, &quot;to_i32!&quot;, &quot;to_i64&quot;, &quot;to_i64!&quot;, &quot;to_i8&quot;, &quot;to_i8!&quot;, &quot;to_u&quot;, &quot;to_u!&quot;, &quot;to_u128&quot;, &quot;to_u128!&quot;, &quot;to_u16&quot;, &quot;to_u16!&quot;, &quot;to_u32&quot;, &quot;to_u32!&quot;, &quot;to_u64&quot;, &quot;to_u64!&quot;, &quot;to_u8&quot;, &quot;to_u8!&quot;, &quot;trailing_zeros_count&quot;, &quot;unsafe_chr&quot;, &quot;unsafe_div&quot;, &quot;unsafe_mod&quot;, &quot;unsafe_shl&quot;, &quot;unsafe_shr&quot;, &quot;|&quot;]
Float64.methods                  # =&gt; [&quot;!=&quot;, &quot;*&quot;, &quot;**&quot;, &quot;+&quot;, &quot;-&quot;, &quot;/&quot;, &quot;&lt;&quot;, &quot;&lt;=&quot;, &quot;==&quot;, &quot;&gt;&quot;, &quot;&gt;=&quot;, &quot;ceil&quot;, &quot;clone&quot;, &quot;fdiv&quot;, &quot;floor&quot;, &quot;next_float&quot;, &quot;prev_float&quot;, &quot;round_away&quot;, &quot;round_even&quot;, &quot;to_f&quot;, &quot;to_f!&quot;, &quot;to_f32&quot;, &quot;to_f32!&quot;, &quot;to_f64&quot;, &quot;to_f64!&quot;, &quot;to_i&quot;, &quot;to_i!&quot;, &quot;to_i128&quot;, &quot;to_i128!&quot;, &quot;to_i16&quot;, &quot;to_i16!&quot;, &quot;to_i32&quot;, &quot;to_i32!&quot;, &quot;to_i64&quot;, &quot;to_i64!&quot;, &quot;to_i8&quot;, &quot;to_i8!&quot;, &quot;to_s&quot;, &quot;to_u&quot;, &quot;to_u!&quot;, &quot;to_u128&quot;, &quot;to_u128!&quot;, &quot;to_u16&quot;, &quot;to_u16!&quot;, &quot;to_u32&quot;, &quot;to_u32!&quot;, &quot;to_u64&quot;, &quot;to_u64!&quot;, &quot;to_u8&quot;, &quot;to_u8!&quot;, &quot;trunc&quot;]
Proc.methods                     # =&gt; [&quot;==&quot;, &quot;===&quot;, &quot;arity&quot;, &quot;call&quot;, &quot;clone&quot;, &quot;closure?&quot;, &quot;closure_data&quot;, &quot;hash&quot;, &quot;internal_representation&quot;, &quot;partial&quot;, &quot;pointer&quot;, &quot;to_s&quot;]&lt;/syntaxhighlight&gt;

== 脚註 ==
&lt;references /&gt;

== 外部リンク ==
* [https://crystal-lang.org/ The Crystal Programming Language] {{---}} 公式サイト
** [https://crystal-lang.org/api/1.5.0/ Crystal 1.5.0 リファレンス]
** [https://play.crystal-lang.org/#/cr Compile &amp; run code in Crystal] {{---}} playground

[[Category:Crystal|*]]
[[Category:プログラミング言語]]
{{NDC|007.64}}</text>
      <sha1>4hwaja3rlk0sly94vmf8bn0u4gzj3mo</sha1>
    </revision>
  </page>
  <page>
    <title>Wikibooks:GUS2Wiki</title>
    <ns>4</ns>
    <id>35248</id>
    <revision>
      <id>205743</id>
      <parentid>205590</parentid>
      <timestamp>2022-07-23T20:47:36Z</timestamp>
      <contributor>
        <username>Alexis Jazz</username>
        <id>56315</id>
      </contributor>
      <comment>Updating gadget usage statistics from [[Special:GadgetUsage]] ([[phab:T121049]])</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="668" xml:space="preserve">{{#ifexist:Project:GUS2Wiki/top|{{/top}}|This page provides a historical record of [[Special:GadgetUsage]] through its page history. To get the data in CSV format, see wikitext. To customize this message or add categories, create [[/top]].}}
以下のデータは 2022-07-23T09:12:57Z に最終更新されたキャッシュです。
{| class=&quot;sortable wikitable&quot;
! ガジェット !! data-sort-type=&quot;number&quot; | 利用者の数 !! data-sort-type=&quot;number&quot; | 活動中の利用者
|-
|Navigation popups || 79 || 2
|-
|wikEd || 42 || 1
|}
* [[特別:GadgetUsage]]
* [[w:en:Wikipedia:GUS2Wiki/Script|GUS2Wiki]]
&lt;!-- data in CSV format:
Navigation popups,79,2
wikEd,42,1
--&gt;</text>
      <sha1>meiu1ifj36qy65kaawt6mxyfo5u1clp</sha1>
    </revision>
  </page>
  <page>
    <title>カテゴリ:高等学校日本史</title>
    <ns>14</ns>
    <id>35254</id>
    <revision>
      <id>205724</id>
      <timestamp>2022-07-23T13:49:08Z</timestamp>
      <contributor>
        <username>椎楽</username>
        <id>32225</id>
      </contributor>
      <comment>カテゴリ作成。</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="288" xml:space="preserve">高等学校の日本史(旧課程「日本史A」「日本史B」、現行過程「歴史総合」「日本史探究」)に関する全ての文書を、こちらに分類してください。
[[カテゴリ:高等学校教育|にほんし]]
[[カテゴリ:社会科教育|にほんし]]</text>
      <sha1>tqakhied6cznib5qkgtwkxg0sj8rcyq</sha1>
    </revision>
  </page>
  <page>
    <title>倫理を学ぶ目的</title>
    <ns>0</ns>
    <id>35255</id>
    <redirect title="高等学校倫理/倫理を学ぶ目的" />
    <revision>
      <id>205740</id>
      <timestamp>2022-07-23T14:12:03Z</timestamp>
      <contributor>
        <username>椎楽</username>
        <id>32225</id>
      </contributor>
      <comment>椎楽 がページ「[[倫理を学ぶ目的]]」を「[[高等学校倫理/倫理を学ぶ目的]]」に移動しました: 高校「倫理」のサブページとするため</comment>
      <model>wikitext</model>
      <format>text/x-wiki</format>
      <text bytes="52" xml:space="preserve">#転送 [[高等学校倫理/倫理を学ぶ目的]]</text>
      <sha1>2w2407vqlgpzucwet5vtyh1djfu6lmr</sha1>
    </revision>
  </page>
</mediawiki>