プログラミング言語 単語


ニコニコ動画でプログラミング言語の動画を見に行く

プログラミングゲンゴ

1.1万文字の記事
これはリビジョン 2553860 の記事です。
内容が古い・もしくは誤っている可能性があります。
最新版をみる

プログラミング言語とは、コンピュータにおけるソフトウエアを開発することを主目的に作られた人工言語である。つまり、ソフトを作るときに書いたりする、映画とかで研修室の画面に流れてたりする、ムズカシソーなアレ

概要

プログラミング言語の歴史は、コンピュータこと電子計算機よりも長いわけだが、面倒なのでここではスルー。詳しくは、Wikipedia:階差機関にでも。

プログラミング言語は、コンピュータへの命令することを第一に作られている。それを支援する、構造記述能力、表現力が備わっていることが普通である。また、日本語や英語といった自然言語と異なり、曖昧な解釈はできない[1]

一般に歴史的な理由と使える領域の広さから、C言語はプログラマーの一般教養言語となっている。

高級言語と低級言語

プログラミング言語には高級言語と低級言語がある。

低級言語

低級言語とは、機械語及びアセンブリ言語(アセンブラ)のことである。

アセンブリ言語は、機械語を英語などの自然言語などで解釈しやすいように作られたものだが、いずれもCPUの処理手順を1つずつ記述しなければいけない。しかもCPU毎に言語仕様が違うため、あるCPU用に書いた機械語プログラムを全く別のCPUに再利用することはできない。

また、論理的には1つの処理も、複数の手順を踏まえないといけないので記述数が膨大になりやすく、現在では処理手順の細かい最適化を行う際に部分的に使われることが多い。 

高級言語

対して高級言語とは、自然言語をベースに人間の論理に合わせて作られたプログラミング言語を指す。CPUの仕様から自由ならば高級言語である。

低級言語よりは習得が楽ではあるが、高級言語を機械語に翻訳するコンパイラーやインタープリターの性能が悪いと、非効率で処理の遅いプログラムになる恐れがある。

高級言語の中でも、記述内容が機械語に近いもの(例えばメモリへの書き込みの方法やタイミングを指定できるなど)ほど低級で、人間の感覚に近いもの(オブジェクト指向など)をより高級とする考え方もある。

近年の様々なパラダイムを取り込み洗練された言語に親しんでいる人から見ると、過去の言語は野暮ったく低級のように見えてしまうかもしれないが、あくまでも人間の考え方に近いか遠いかの違いを表す表現であって、言語の優劣を論じる用語ではない。パフォーマンスの問題から言えば、むしろ低級な言語ほど(労力を惜しまなければ)できることの種類が多く、高級な言語ほど処理速度が遅くなる傾向にある。

実際の言語の優劣は、言語仕様の良し悪しよりも入手可能なライブラリの量と質や処理系の最適化レベル、開発環境の充実度、動作可能なプラットフォームの普及状態などによって決まってしまうことが少なくない。

コンパイラ言語とスクリプト言語

実行する前にコンパイルという変換作業を必要とするものをコンパイラ言語と呼び、操作や処理を記述したプログラムをそのままインタプリタに解釈させ実行する言語をスクリプト言語(インタプリタ言語)と呼ぶ。言語仕様そのものの違いではなく、処理系の違いなのだが(スクリプト言語でも別途コンパイラを作ってコンパイルしてから実行するようにすればコンパイラ言語といえなくもない)、実用上は両者を区別することが多い。

一つのアプリケーション上で動作し、アプリケーション上の操作を一括して行うように記述できるものもプログラミング言語(スクリプト言語)と呼ぶことができるが、一般にはマクロと呼ばれて汎用プログラミング言語とは分けて扱われる。

一般的な傾向としては処理速度はマクロ < スクリプト言語 < コンパイラ言語 < 機械語 の順番だが、処理系の最適化やプログラマの技量(使用するアルゴリズム)によって大きく変わってしまうこともあるので、「〜で書かれているから速い」という考え方があてはまらない場合もありえる。

静的型付けと動的型付け

ほとんどの高級言語に型の概念が実装されているが、型が実行前に決まっていなければならないかどうかで静的型付け言語と動的型付け言語に分かれる。

型付け

プログラミング言語におけるパラダイム

プログラミング言語では、その言語に対するパラダイムが存在する。
パラダイムとは、プログラムを離れて一般的な広義で言えば、物の捉え方の事を指す。
プログラミング言語におけるパラダイムとは、プログラミング言語の捉え方を表したものである。
以下に、代表的なパラダイムを記述する。詳細はプログラミングパラダイムの記事参照

  • 構造化プログラミング
  • 手続き型言語
  • モジュール型
  • オブジェクト指向
  • アスペクト指向
  • イベント駆動型
  • 関数型言語

これらは、排他的な特徴ではないため、当然複数のパラダイムをを併せ持つ言語が存在する。そのような言語をマルチパラダイム言語という。多くの言語はマルチパラダイム言語だが、特に多くのパラダイムを実現している言語を指して言うことが多い(例: C++, D言語)。

主なプログラミング言語(高級言語)

  • BASIC
  • COBOL
  • FORTRAN
  • Pascal
  • C
  • C++
  • C#
  • Java

主なスクリプト言語

  • Perl
  • Python
  • Ruby
  • JavaScript
  • Visual Basic for Application(VBA)
  • PHP

プログラミング言語が作られる目的(一覧)

現在、プログラミング言語は非常に多く存在しているが、言語が作られる理由にはさまざまな理由がある。

  • 以前の言語の拡張として (例: C++, C++マネージ拡張, C++/CLI, Objective-C)
  • ちょっとしたことをお手軽にやりたい (例: シェルスクリプト系)
  • ちょっとしたことをお手軽にやりたい。高機能で (例: Ruby, Python)
  • OSを移植しやすくするため (例: C言語)
  • そもそも仮想マシンで動かせばどこでも動くんじゃね (例: Java)
  • Javaの人気に嫉妬して(いつものように)パクった。後悔はしていない(例: C#)
  • 言語設計の研究のため。ネタ言語じゃないよ!! (例: BrainF*ck)
  • コンビネータ理論に基づいて言語を作ってみたもの。ネタ言語じゃな…くもない(例: unlambda, LazyK)
  • 環境に特化した言語が必要になって (例: PostScript, SQL, JavaScript, ニワン語&ニコス)
  • 実は別目的だったんだけど、機能追加してたら言語になってた (例: ActionScript)
  • 新しい概念実装のため (例: Lisp)
  • ハードウエア設計のため (例: Verilog)
  • 英語よりも日本語だろJK (例: ひまわり, なでしこ)
  • 他の言語に組み込むため (例: Lua)
  • 俺最強言語を作って、俺TUEEEEEしたくなって (例: D言語)
  • サンプルプログラム内蔵してみた (例: HQ9+)
  • 読みにくくしてみた (例: grass, whitespace)
  • ゲームだ (例: CarnageHeart)
  • 教育用だ (例: LEGO MindStorm, LOGO, CASL)
  • Hello,World!を最短コードで表示してみた (例: BrainCrash)
  • WebとDBに強い言語を作ってみた。文法?とりあえずCっぽくしとけば良いんじゃね。(例: PHP)
  • 新言語(信玄後)だから(例: 織田信長)
  • 昔は皆これから始めたもんだ(例: BASIC)
  • IT土方専用 (例: Visual Basic)
  • 元祖最強俺言語、何でもできるよ! (例: Perl)
  • 成果物のスパゲッティさは他の追随を許さない。爺専用 (例: COBOL)
  • 非情シス部門で勝手システムを作るためのもの。あまり関りたくない (例: Visual Basic for Applications)
  • 日本においては税金の無駄使い公共事業用だった (例: Prolog)
  • 真祖とか始祖とかそんな感じ。ゆとり世代には伝説の類 (例: Fortran)
  • なにげにインストールベースでは最多クラス (例: Visual Basic Scripting Edition)
  • 主に教育用だ。ターボとか付いてて、エディタにタダで付いてくるすごいのもあった (例: Pascal)
  • 副作用が許されるのは小学生までだよね (例: Haskell)
  • 関数型言語とオブジェクト指向を合せたら最強じゃね? (例: Objective Caml, F#, Scala)
  • マイクロソフト帝国には誰も逆らえないことを、結果的に証明した(例: Delphi, Object Pascal)
  • 制御構造を持たないシンプルな文法、なんでも文字列、簡単GUI(例: Tcl/Tk)
  • grepやsedじゃ物足りなくなって (例: awk、Perl)
  • WebでもやっぱりBASICだろう(例: VBScript)
  • おれは数学向け組版用言語を開発していたと思っていたら いつのまにかチューリング完全になっていた (例: TeX)
  • Cの速さ、Rubyの動的さが欲しいし、科学計算、線形代数計算、統計処理、機械学習を手軽に分散コンピューティングで出来るようにしたい。でも言語としてはシンプルなのがいいね。え?欲張りだって?(例: Julia)
  • プラットフォームが十分に普及し、何をしてもみんな追随してくれるようになったので (例: Swift)
  • ぬるぽをなくしたかった ← ガッ (例: Swift, Kotlin)

面倒なことに、言語内でもバージョンやら実装の違いがあって、トラブルの原因になったりもする。とても面倒。

関連動画

タグ検索「プログラミング」

関連商品

ニコニコ市場は2023年11月に終了しました。ニコニコ市場は2023年11月に終了しました。ニコニコ市場は2023年11月に終了しました。ニコニコ市場は2023年11月に終了しました。

関連コミュニティ

ニコニコミュニティは2024年8月に終了しました。

関連用語

  • プログラミング
  • 日本語じゃない日本語
  • チューリング完全
  • 統合開発環境(IDE)
  • ガベージコレクション
  • プログラミング関連用語の一覧
  • ソフトウェアの一覧
  • ソフトウェア開発

コラム: プログラミング言語選択ガイド

同様の趣旨で検索すればいくらでも類似の記事が見つかるのに今更感があるが、どのような視点でプログラミング言語を選択するべきか記しておく(個人の感想です)。異論は認める。

まとめ

無駄に長くなったのでまとめを書いておくと、

  • やりたいことが決まっているなら、目的に最適なライブラリを選べば、選択すべき言語がほぼ決まる。
  • プログラミングを勉強したいだけなら最初は情報の多いJava。
  • Microsoftに囲われるのが嫌でなければC#という選択も。

もちろん異論は認める。

その幻想をぶち殺す!!

プログラミングは、入門書で文法を一通り覚えればゲームだろうがExcelのような高度なアプリケーションだろうが何でも作れるようになる、というようなものではない(TASレベルの意味で理論上可能かもしれないが、現実的ではない)。

プログラミングをマスターしたと言えるためには以下のようなものを全部とまでは言わないが習得する必要がある。文法よりもそれ以外の習得事項のほうが多いかもしれない。

  • 文法
  • 統合開発環境の使い方
  • 個々のライブラリの使い方
  • 並列処理の書き方
  • GUIフレームワークの使い方
  • ユニットテストの書き方
  • ビルドシステムの使い方
  • UML設計ツールetc.....
  • アルゴリズム

多くの言語において、「コンソール上でHello Worldする」のと、「Hello Worldと書かれたウィンドウを表示する」との間には大きな隔たりが存在する。前者は知っての通り初心者が最初に書くプログラム(Haskellを除く)、後者は並列処理あたりまで理解した中級者がGUIフレームワークの勉強を始めるときに書くプログラムである。

希望を打ち砕くようで申し訳ないが、入門書を読んだくらいでは「Hello Worldと書かれたウィンドウを表示する」ことすらおぼつかないのが現実である(例外: Javascript, PHP)。

プログラミング言語? そんなことより英語だ!

プログラミング言語以前の問題として、あなたは英語力に自信はあるだろうか。多くのプログラミング言語が英語圏出身である以上、プログラミングに関する情報は英語が原文で提供される。

もちろんWeb上には日本語で書かれたリソースも存在する。しかしそれもメジャーな言語に限られ、マイナーな言語は公式ページの英語のチュートリアルが唯一の情報源ということも珍しくない。メジャーな言語でも、マイナーなライブラリやフレームワークになると同じような状態になる。バグなどのように非常にマイナーな話題は、メジャーな言語でも英語の掲示板にしか情報がないことが多い。

とはいえ、日本語の情報である程度勉強すれば、英語は完全に読めなくても(サンプルコードを参考にして)どうすればいいか見当がつくこともあるので、それほど悲観しなくてもいいかもしれない。

数学力…たったの5か…

コンピューターの計算能力の上昇はすさまじいものがあるが、それでも限界はある。1万件の単純なデータの処理はすぐに終わっても、1万件の個々のデータに1万個ずつ項目が入っていていたら1億の処理をすることになり結構な時間を要する、その1項目にさらに1万ずつの小項目が存在したら、1兆の処理をしなければならなくなり、合理的な時間で終わらないケースも出てくる。

こういった問題を解決するにはアルゴリズムを工夫する必要があるが、アルゴリズムの理解・応用にはかなりの数学力が必要になる。ここでいう数学力は「数学は70点だったけど国語は55点だったから得意科目を強いて言うなら数学かな」と言ったレベルではなく、「証明問題は解けない問題はなかった。可算無限と非可算無限の違いの証明も余裕。」といったレベルの数学力である。

あなたが中高生ならともかく、文系大学生や社会人だったりするならば、スーパーハカーになろうと思っても既に越えられない壁が出来てしまっている可能性がある。学校の勉強は将来役立たないって言ってた奴出てこいwwww

もっとも、手作業でやっている定型的パソコン操作を自動化したり、IT土方の仕事をするレベルでは関係のない話だと思われるので、気にしなくていいのかもしれない。

それでも、マニュアルに「以上、以下」を調べる機能だけ記載されていて、「より大きい、より小さい」を調べる機能がないときに「より大きい」=「以下ではない」、「より小さい」=「以上ではない」と脳内変換する程度の機転は求められる。

「これをやりたい」と心の中で思ったならッ!その時スデに選択は終わっているんだッ!

まずは、あなたがプログラミングで何を実現したいのか思い浮かべよう。

何がしたいか(具体的に)決まっている人は幸いである。目的に一番近い機能を有したライブラリを探せばよい。そのライブラリが対応している言語が、あなたの使うべき言語である。選択の余地がないという意味では不幸かもしれない。

プログラミングとはミスとの闘いである

プログラミングをすると必ずと言っていいほどプログラミングミス(バグ)が発生する。プログラミング言語の進化の歴史は、いかにこのミスの発生を防ぐかの歴史でもある。

決してミスを犯さないプログラマであるならば、どの言語を選ぼうと関係ない。

関数型プログラミングという潮流

プログラミング言語の選択方法について検索すると「オブジェクト指向は時代遅れだ。これからは関数型プログラミングだ」という記述をみつけるかもしれない。

関数型プログラミングの項目で私見を述べたが、関数型プログラミングがもてはやされるのは、参照透過性があるという点と、高階関数を駆使した抽象が可能になるという点が理由になっていると思われる。

参照透過性は、間違いを防ぐために、他の言語を使用する場合でも積極的に心がけると良い。

しかし、参照透過性に完全性を求めると純粋関数型言語に行き着く。2017年の時点で最もメジャーな純粋関数型言語といえばHaskell(それでもかなりマイナーである)だが、これを使いこなすには、モナドを初めとする高階関数を駆使した抽象化の理解を要する。

高階関数を駆使した抽象化というのは、理解するのに数学的素養しかも、単純な数値計算ではなく抽象的なものに関する理解力・応用力が求められる。根性で使っているうちに体得するという考え方もあるが、それは学習が大変ということに他ならない。

関数型プログラミングという言葉に踊らされて言語選択するよりは、関数型プログラミングがどうして有用なのかを理解し、選択した言語でそれを実現するよう心がけた方がいいように思う。関数型プログラミングの重要性も2010年代前半には声高に叫ばれたが、後半には前半ほどは強調されなくなったように思う。

静的型付け vs. 動的型付け

プログラミング言語の大きな分類に静的型付けと動的型付けという分類がある。動的型付けは型を決めなくていいので初心者向けとすることが多いが、(前述のように選択の余地がない場合は別として)少々面倒でも静的型付けの言語を選択することを勧める。

動的型付け言語は、動作内容の詳細が日本語2-3行で表現できてしまうような本当に小さなプログラムを組むときには確かに有利だが、少しでも複雑な動作をさせようとすると静的型付けの言語の型チェックが働いた方が有利になってくる。プログラミングをしようというからには、プログラミングを学んでまでコンピューターにやらせたい面倒な仕事があるのだと思われる。そして面倒な仕事は往々にして複雑であり、単純だと思っていても繰り返す中に例外的な扱いを要するものが混じっていて複雑だったりするものである。

やりたいことがなく、単にプログラミングを勉強したいというだけの場合でも、静的型付けの型安全の考え方は学ぶ価値がある。

書きやすい言語 vs. 読みやすい言語

書きにくく読みにくい言語」というのは、どこまでも書きにくく、どこまでも読みにくくすることが可能だが、「書きやすく読みやすい言語」を追求しようとするとどこかで限界にぶち当たる。

書きやすいということは、複雑な処理を短く書ける記法が多数存在するということである。しかし、それを読むときには短い記法からその裏に隠れている複雑な処理を思い出さなければならない(ということは使用頻度の低い記法も含めて多数のことを覚えていなければならない)ということである。つまり書きやすさを追求すると読みにくくなり、読みやすくしようとして文法を単純化し過ぎると書きにくくなる(やりすぎると読みにくくもなる)[2]ということである。

どこかで、書きやすさと読みやすさの折り合いを付けないといけないわけだが、ベストのバランスというのは人によって異なる。すなわち、職業がプログラマだという理由で毎日コードを書くのであれば記法は多いほうが良く、趣味などでたまにしかコードを書かないのであれば記法は少なくていい。

従って万人にとって最良な言語というものはないと思って良いが、「プログラムを書く時間よりも、(バグ探しや仕様確認等のため)にプログラムを読む時間の方が長い」と広く言われており、言語仕様を聞いたときの「書きやすそう」という直感で走るよりも、使用頻度が少なくて忘れてしまいそうな言語仕様はないか、書きやすくても読むときに不利にならないだろうか、など冷静に考えて選んだほうが良いのではないかといえる。

使わない機能は覚えなくていいやと思っても、サンプルプログラムを読む時に知らない言語機能を用いていることがあり、実際に使用していて不便をきたすことは結構ある。

時代はnull安全?

NullPointerException が引き起こすバグを防止するnull安全の考え方が2010年代に入ってからのトレンド。

  • Optionという考え方を導入した: Scala, , Java
  • 言語仕様でnull対応を強制した: Swift, Kotlin
  • null安全モードを用意した: Typescript
  • 参照透過だから関係ない: Haskell

HaskellにはMaybeモナドがあるが、ScalaのOptionやJavaのOptionalは中身ではなくそれ自身がnullとなりうるのに対し、Maybeモナドはそれ自体がnullになることはないので、上記では区別している。

GUIへの道は遠い

プログラミング言語は無数にあるが、GUIの製作方法が標準化されている言語は意外と少ない。標準化されていない部分は書籍化もされず情報も手に入りにくいので、GUIアプリを作りたい場合は、闇雲に進んで文法を学んだ後に立ち往生しないためにも、事前にGUIをどうやって作るかまで視野に入れておきたい。

またオープンソース化されているが、GUI製作部分はクローズドになっている場合もある。

各論

使ってない言語のことも書いているので、大きな偏りはある。異論は認める。

こうして書いてみると、言語が設計された経緯が、特徴として色濃く反映されている気がする。

プログラミングをしたことがある人とない人で感じ方はかなり変わるので、余裕があるならとりあえず適当な言語で少しプログラミングを経験した後、ゆっくり本格的に使う言語を探すといいのかもしれない。一つの言語から次の言語に移ると強く違和感を感じるのは慣れの問題か。

C言語 / C++

何でもできるが、出来てはいけないことまで出来てしまう。ミスを防ぐという観点からは、あまり良くないと思われる。また、C++は仕様が複雑すぎることで悪名高い。

Java

CやC++の反省を元に作られた言語。静的型付け。

APIドキュメントの書き方が言語仕様で規定されている。実際に使ってみるとライブラリの使用方法の調べ方が統一されているというのは大きい。統合開発環境との組み合わせでさらに効果を発揮する。

大半の言語でソースコード内にコメントは書けるが、たいていは言語仕様の策定に終始してドキュメントの仕様がJavaほど厳密に規定されている言語は少ない。

ソースコードが冗長になるという批判が多いが、ソースコードを読むという観点からは黙示的に定義される部分を補う必要がないので読みやすいという見方もできる。

歴史ある言語のため古い考え方も残っているが、後発の言語に一見無駄に複雑と思える仕様が存在する理由が理解できるので勉強にはなる?

2014年のJava8でラムダ式やOptionalが導入されてから、かなり変化したので、書籍や情報源はそれ以降のものを頼ったほうが良い。

JavaScript

動的型付け。ブラウザ上でHTMLにインタラクティブな要素を加えるために開発されたという経緯がある。そのため、プログラミング言語としてはややいびつなところがある。

GUI構築に関してはHTMLと組み合わせる方法が標準化されている一方で、ファイルの読み書きが弱い(ブラウザが勝手にファイルを読み書きしたら困るから)。

Typescript

Microsoftが開発した、JavaScriptを静的型付けにした言語。JavaScriptの上位互換でJavaScriptのコードをそのまま持ってきても動作するのが特徴。今から始めるならJavaScriptよりはこちらか。

JavaScriptとの互換性を保つため、プログラミング言語としてはややいびつなところが引き継がれている。

PHP

動的型付け。実行結果がHTMLになる。インタラクティブなWebページ製作という観点からは最も手軽に結果を得られる反面、もともとプログラミング言語ではなかったせいか、プログラミング言語としては扱いづらい。

Swift

iPhoneアプリ開発向けにAppleが2014年に発表した言語。null安全

オープンソース化されて他のプラットフォームでも動作するが、GUIを構成するCocoaの部分はオープンになっていない。

iPhoneのイヤホンジャックに限らずAppleは昔から旧環境を切り捨てることに定評があるが、SwiftもObjective-Cを捨てて移行したし、Swift自身もメジャーバージョンアップ時に互換性を保てない変更をしている。バージョンも4になったし、もうそろそろ落ち着いてもいいのかも。

C#

Microsoftが開発した.NET Frameworkのメイン言語。

Javaに対抗して作られた経緯があるので、Javaに似てJavaより書きやすいと言われている。

有志が作ったオープンソース実装Monoが存在するが、2016年に公式からオープンソース化された。

GUI周りに関してはオープンソースになっておらず、Monoでも実装されていない。

Ruby / Python

動的型付け言語。ライブラリやフレームワークの関係でこれらの言語を選択するケースも多いと思われる。

注意点としてはいずれもRuby2.0, Python3.0で互換性のなくなる変更を行っており、区別して検索しないといけない(特にPython)ということがある。

蛇足だが、Rubyの開発者は日本人。

日本人の開発したRubyを推すべきなのかもしれないが、Rubyのキャッチフレーズは「書くのが楽しい」に対しPythonは「見やすさ」を目標に掲げているので、このコラムでは以下省略

Scala / Kotlin

静的型付け言語。いずれもJava仮想マシン上で動作するため、Javaで作られた豊富なライブラリが利用可能。Kotlinはnull安全な言語仕様が売り。ScalaもOption型でnull問題に対処しているが、Java8でOptional型が導入されたのでその点ではJavaと差が無くなった。

Javaでの反省を元に作られ、Javaよりも短いコードが書けるという触れ込みだが、コードを読もうとすると黙示的動作を脳内補完する必要があり、いきなりこの言語から入るのは厳しいかもしれない(特にScala)。

コードを書く頻度が高いなら、これくらい機能があった方が便利だと思われる(Scalaはそれでも高機能すぎるという意見もある)。

Haskell

純粋関数型言語。ちまたに出回っている解説はそれなりに数学力のある人が書いていると思われ、数学力に強い自信がないなら平易な情報が手に入らないのでやめておいたほうがいい。

他の言語と同じようなことをする分には言われているほど難しい言語ではないのかもしれないが、Haskellならではの使い方をしようとするならかなりの数学力が必要。

職業プログラマーが時間をかけて長く付き合っていくならありかもしれない。

意識高い系がうっかり手を出すと、挫折した腹いせにこんな毒を吐くことになる。

Perl

書きやすく読みにくい言語の代表格。どうしても使いたいライブラリがあるのでなければ、今から始める理由はないように思う。

脚注

  1. *曖昧さがないといっても実行時の話で、言語仕様書の段階では曖昧さが取り除ききれていない場合も少なくない。リファレンス実装がこの問題を解決している場合もある。
  2. *単純さを追求したい方は純Lispについて、極限まで追求したい方はLazy Kについて調べてみるとよい。本当に単純な話なのですぐ調べ終わる。
関連記事

親記事

子記事

兄弟記事

おすすめトレンド

ニコニ広告で宣伝された記事

記事と一緒に動画もおすすめ!
山姥切長義(刀剣乱舞)[単語]

提供: 足屋コーヒー

もっと見る

急上昇ワード改

最終更新:2025/12/10(水) 17:00

ほめられた記事

最終更新:2025/12/10(水) 16:00

ウォッチリストに追加しました!

すでにウォッチリストに
入っています。

OK

追加に失敗しました。

OK

追加にはログインが必要です。

           

ほめた!

すでにほめています。

すでにほめています。

ほめるを取消しました。

OK

ほめるに失敗しました。

OK

ほめるの取消しに失敗しました。

OK

ほめるにはログインが必要です。

タグ編集にはログインが必要です。

タグ編集には利用規約の同意が必要です。

TOP